GOOTÜ JSY-H4862E120-D inverter + Dyness B3 battery , how to configure ?

[muwlgr]

Dear community, I am a bit new in this area, and so far I was unable to make this inverter work directly with this battery.
All I know is that the inverter does not support CAN communication, only RS485 and RS232.

Over RS232, it supports PACE BMS protocol (battery type LIC).
Over RS485 it supports PACE and PYLON protocols (battery types LIP and LIL).
As I understand, PACE is the same as MODBUS over serial line.
Overall, its battery type and BMS protocol configuration is similar to some better-known inverters like PowMr, Daxtromn, Anenji and so on.

The battery prefers CAN communication but also supports RS485.
It has a number of DIP switches, and about 5 variants of switch positions listed in its manual for different type of inverters (https://dyness.com/Public/Uploads/uploadfile/files/20241023/B3UserManualEN.pdf , pages 10..11 of 29).
Of course GOOTÜ brand is not mentioned among them.
Of course PACE/MODBUS or PYLON is not mentioned there at all, only RS485 or CAN.
For some DIP positions, neither RS485 nor CAN is mentioned, only the inverter type.
We made a cable connecting pins 1 and 2 of the inverter RJ45 port to pins 1 and 3 of the battery RJ45 (RS485 A-to-A and B-to-B).
We tried LIP or LIL battery types in the inverter and all 5 DIP switch positions from the battery manual, but were unable to see any non-zero numbers in the inverter's BMS screens.

In Ukrainian technical forums I learned about a similar type of inverter and Dyness B4850 battery, that the inverter supports PYLON protocol version 3.* while the battery supports only 2.*, so a protocol conversion is required. One savvy guy made a firmware for Arduino nano to do this kind of protocol conversion (but he does not distribute its source code).
Ukrainian thread on this topic can be read at https://greenpowertalk.tech/threads/komunikacija-invertora-anenji-6-2kw-i-batareji-dyness-b4850.1543/ but you will need to translate it into your language.

I found this project, ai-republic/bms-to-inverter , and decided to try if it could help me to do this kind of conversion (as I don't have enough experience with Arduinos).
Now I have 2 USB-RS485 adapters plugged into a Linux host, and into the inverter and the battery with their RJ45 sides.
I can see some serial traffic going from the inverter and from the battery (using cu or minicom).
I cloned the project from github, installed JDK 25 and started configurator.jar

Now I would like to get some help from you to avoid enumeration of all possible inverter+bms combinations in the Configurator.
If anyone had some useful experience, I would appreciate if you shared it with me.

Thanks in advance for your responses.

[ai-republic]

I would give the Pylon RS485 binding a try. It does include commands from versions 2.x-3.5. First try to see if you can get any data from the batteries before configuring the inverter or any other optional services.

[muwlgr]

Well, using https://github.com/Frankkkkk/python-pylontech/ , I discovered is that the battery responds to the 0x42 request (~20024642...), specified by Pylontech protocol v 2.x as "Get analog value, fixed point",
while the inverter sends 0x61 request (~20024661...), specified in Pylontech protocol v 3.x also as "Get analog values, fixed point"
but having different response format and contents (and to which the battery does not respond).

By attentive reading of both specifications, I ended up with a short Python script ( https://github.com/muwlgr/scripts/blob/main/relay-inv-bat.py ) operating on 2 USB-RS485 ports and converting inverter's requests and battery's responses in both directions.
Currently this script is working in my setup and filling the inverter's BMS screens with realistically looking numbers.

I just felt I would spend more time finding out if your Java code is capable of doing this exact conversion, so I decided to sketch a WFM/MVP in Python.

[muwlgr]

So I went deeper into
https://github.com/ai-republic/bms-to-inverter/blob/main/bms-pylon-rs485/src/main/java/com/airepublic/bmstoinverter/bms/pylon/rs485/PylonBmsRS485Processor.java
and
https://github.com/ai-republic/bms-to-inverter/blob/main/inverter-pylon-rs485/src/main/java/com/airepublic/bmstoinverter/inverter/pylon/rs485/PylonInverterRS485Processor.java ,
and do I guess it right, that when the battery does not respond to 0x61 request, then "pack = getBatteryPack(address)" does not get filled in needed places, and the inverter will receive only partial information on its 0x61 request ?

PylonBmsRS485Processor.readCellInformation() fills the following fields of BatteryPack: .numberOfCells , cellVmV[] , .numOfTempSensors , .cellTemperature[] , .packCurrent , .packVoltage , .remainingCapacitymAh , .ratedCapacitymAh
(BTW, there is also cycle count in 0x42 response after Rated Capacity, suitable for filling .bmsCycles but ignored for unknown reason)

PylonBmsRS485Processor.readBatteryInformation() fills the following fields of BatteryPack: .packVoltage , .packCurrent , .packSOC , .bmsCycles , .packSOH , .maxCellmV , .maxCellVNum , .minCellmV , .minCellVNum , .tempAverage , .tempMax , .tempMaxCellNum , .tempMin , .tempMinCellNum
(BTW, there are 2 more temperature arrays in 0x61 response after CellTemps, that is MOSFET temps and BMS temps which are also ignored in parsing)

Then, PylonInverterRS485Processor.createBatteryInformation() uses the following fields of BatteryPack: .packVoltage , .packCurrent , .packSOC (unfilled without 0x61 response), .bmsCycles (unfilled) , .packSOH (unfilled), .maxCellmV (unfilled) , .maxCellVNum (unfilled) , .minCellmV (unfilled) , .minCellVNum (unfilled) , .tempAverage (unfilled) , .tempMax (unfilled) , .tempMaxCellNum (unfilled) , .tempMin (unfilled) , .tempMinCellNum (unfilled) , MOSFET and BMS temperatures are just filled as .tempAverage

My Python code so far does not handle multi-battery packs (that is, responses to 0x42 request with battery number 0xFF), as I don't have multi-battery setup. But it tries to synthesize SOC as ((.remainingCapacitymAh*100-1)/.ratedCapacitymAh), find min. and max. voltages and temperatures along with their indexes to reasonably fill appropriate fields in 0x61 response, and creatively lie in most other cases (replace SOH with calculated SOC, and so on).

Probably this approach can be ported to your Java code with some kind of special case handling when the battery does not respond to 0x61 request as Dyness B3 does.
And of course, I don't have a choice in my inverter's menu to make it send 0x42 requests. In Pylon-RS485 mode it sends only 0x61 ones.

[muwlgr]

BTW, Frankkkkk/python-pylontech code, calling scan_for_batteries() using request 0x93 with sequential battery numbers on my Dyness B3 finds, the single battery at 3 addresses: 00, 01 and 02, in the following way:
['write', b'~200246930000FDA6\r']
['read', b'~20024600C0220298B8000C98B8000C98B8000C98B8000CF641\r']
['write', b'~20014693E00201FD2F\r']
['read', b'~20014600C0220198B8000C98B8000C98B8000C98B8000CF643\r']
['write', b'~20024693E00202FD2D\r']
['read', b'~20024600C0220298B8000C98B8000C98B8000C98B8000CF641\r']
(the rest of writes end with read timeout)
and with the returned map:
{0: '\x98¸\x00\x0c\x98¸\x00\x0c\x98¸\x00\x0c\x98¸\x00\x0c',
1: '\x98¸\x00\x0c\x98¸\x00\x0c\x98¸\x00\x0c\x98¸\x00\x0c',
2: '\x98¸\x00\x0c\x98¸\x00\x0c\x98¸\x00\x0c\x98¸\x00\x0c'}

Also, calling get_values() (request 0x42 with battery number 0xFF) goes in this way:
['write', b'~20024642E002FFFD09\r']
['read', b'~20024600C06E00020F0D540D500D4E0D4F0D540D6B0D510D4F0D4F0D530D6E0D4F0D500D510D56050BE90BEA0BE50BE50BE50129C7EC76340284D00009E533\r']
then it interprets the byte '02' going after 'C06E00' as 'NumberOfModules' and fails to parse the whole response as it expects cell information section for a second module.

calling get_value_single() with numbers 0, 1 or 2 returns similar information:

.get_values_single(0)
['write', b'~20004642E00200FD37\r']
['read', b'~20004600C06E00000F0D560D530D500D550D580D700D540D520D510D550D700D540D530D530D57050BEA0BEC0BE70BE70BE70FA0000000000284D00000E5D8\r']
Container(NumberOfModule=0, NumberOfCells=15, CellVoltages=ListContainer([3.414, 3.411, 3.408, 3.413, 3.416, 3.44, 3.412, 3.41, 3.409, 3.413, 3.44, 3.412, 3.411, 3.411, 3.415]), NumberOfTemperatures=5, AverageBMSTemperature=31.9, GroupedCellsTemperatures=ListContainer([32.1, 31.6, 31.6, 31.6]), Current=400.0, Voltage=0.0, Power=0.0, CycleNumber=0, RemainingCapacity=0.0, TotalCapacity=34.0, TotalPower=0.0, StateOfCharge=0.0)

.get_values_single(1)
['write', b'~20014642E00201FD35\r']
['read', b'~20014600C06E00010F0D550D510D500D530D580D710D540D520D530D560D710D530D530D550D57050BEB0BEC0BE70BE70BE7F6AE6A8201540284D00000E58E\r']
Container(NumberOfModule=1, NumberOfCells=15, CellVoltages=ListContainer([3.413, 3.409, 3.408, 3.411, 3.416, 3.441, 3.412, 3.41, 3.411, 3.414, 3.441, 3.411, 3.411, 3.413, 3.415]), NumberOfTemperatures=5, AverageBMSTemperature=32.0, GroupedCellsTemperatures=ListContainer([32.1, 31.6, 31.6, 31.6]), Current=-238.6, Voltage=27.266, Power=-6505.6676, CycleNumber=0, RemainingCapacity=0.34, TotalCapacity=34.0, TotalPower=-6505.6676, StateOfCharge=0.01)

.get_values_single(2)
['write', b'~20024642E00202FD33\r']
['read', b'~20024600C06E00020F0D550D530D500D540D570D6E0D540D530D530D560D720D540D530D550D59050BEB0BEC0BE70BE70BE70129C82878DC0284D00009E56F\r']
Container(NumberOfModule=2, NumberOfCells=15, CellVoltages=ListContainer([3.413, 3.411, 3.408, 3.412, 3.415, 3.438, 3.412, 3.411, 3.411, 3.414, 3.442, 3.412, 3.411, 3.413, 3.417]), NumberOfTemperatures=5, AverageBMSTemperature=32.0, GroupedCellsTemperatures=ListContainer([32.1, 31.6, 31.6, 31.6]), Current=29.7, Voltage=51.24, Power=1521.828, CycleNumber=9, RemainingCapacity=30.94, TotalCapacity=34.0, TotalPower=1521.828, StateOfCharge=0.91)

(later update: upon thorough review of these 3 responses, I noticed that only response for .get_values_single(2) contains realistic information; .g_v(0) and (1) have wrong Current, Voltage, CycleNumber and RemainingCapacity)

So as you see, Dyness B3 implements Pylontech protocol in pretty crooked way.
get_protocol_version() (request 0x4F) also produces a pretty unclear response:

.get_protocol_version()
['write', b'~2000464F0000FD9A\r']
['read', b'~200046000000FDB4\r']
Container(ver=b' ', adr=b'\x00', cid1=b'F', cid2=b'\x00', infolength=b'\x00\x00', info=b'')

at the same time, request 0x61 is not mentioned in https://github.com/Frankkkkk/python-pylontech/blob/master/pylontech/pylontech.py at all

as I don't have other combinations of battery and inverter than this one (GOOTÜ JSY-H4862E120-D + Dyness B3), I can't provide any other realistic test results than what I already put above. Hope they would be of some use for your software.

[ai-republic]

@muwlgr, thanks for the feedback. I changed the way the battery data is read from the BMS for the Pylon RS485 binding to treat it as one big battery per configured BMS. The BMS will always use the master ID (0x12) + the configured BMS Id (starting at 0 for master).
Could you please do a Clean install on the Configurator application and test if the data is read correctly?

[muwlgr]

I see a number of useful changes in git log, but in the line 341 of the file PylonBmsRS485Processor.java I still see that BMS cycles are skipped and not put into the BatteryPack's field.

[ai-republic]

Thanks for that. I added the max bms cycles to the pack data.