EG4-6500 Modbus

[Madco]

I guess we can gnaw at it with some assumptions (lacking any definitive information). I would assume those holding registers it continuously requests would likely include a average bank state of charge, maybe an average bank voltage (maybe not since the inverter can digitize that), maybe some alarms, maybe bank charge/discharge current, maybe number of batteries?

I'll poke around on your data and see if I can make any sense of it.

I'm curious if the data changes if you switch off a battery!

 

[solarhombre]

I guess we can gnaw at it with some assumptions (lacking any definitive information). I would assume those holding registers it continuously requests would likely include a average bank state of charge, maybe an average bank voltage (maybe not since the inverter can digitize that), maybe some alarms, maybe bank charge/discharge current, maybe number of batteries?

I'll poke around on your data and see if I can make any sense of it.

I'm curious if the data changes if you switch off a battery!

Yes,.it does. The battery count is adjusted, the 1500 number decreases by 500, and the 29700/40000 numbers also change.

I'm going to do a few things while saving the data that goes between inverter and master battery:
-no load, no grid
-no load, grid (charging)
-load, grid (not charging)
-turn off up to 2 batteries and then back on

I'll mark in the data as events happen and upload a text file here. It should be done in <1h.

Thanks a lot for offering your help.

P.S.: I've emailed SS asking for documentation for the registers served by the master battery, but I am not expecting docs to be available.

 

[Madco]

when I asked, they could only tell me baud rate-said no other info was abailable!

 

[Madco]

some of the data looks plausible but it is not in agreement with any of the modbus register descriptions. I'll bet good money that the master battery uses a different register map for the inverter comms than it does for other battery queries.

 

[solarhombre]

some of the data looks plausible but it is not in agreement with any of the modbus register descriptions. I'll bet good money that the master battery uses a different register map for the inverter comms than it does for other battery queries.

Definitely. For non-master batteries, address 19 is the average temperature. I've yet to finish testing a cable I built with ethernet wires 1,2 (like the inverter to battery cable) and 7,8 (like the battery comms cable). I want to see how different RS485 connections to each pair of pins behave, but that's a different story...

Attached is the data I collected for about 25m.
Inverter always sends: 010300130010b5c3
* 0103 - slave 1 read registers
* 0013 - starting address
* 0010 - number of registers
* b5c3 - CRC

* Starting SOC 99%
* Notes:
- To avoid repeating a lot of lines, only data where the CRC changed from the previous line are present in the attached file.
- Time of the annotations might be off by a few seconds.
- Assuming big endian registers.
- Columns:
2) Never changes.
3) SOC (63 -> 99%)
4) Voltage in 10mV (i.e. 14d3 -> 5331 -> 53.31V)
6) Never changes.
10) thru 16) never change.

 

[Madco]

Any more data? Just a thought - what if tou "emulated" the inverter by requesting the holding registers via

 

[Madco]

your interface to see if there are any more registers in the "custom" map in addition to the 16 you see requested.

More info might help figure out what's going on.

 

[solarhombre]

your interface to see if there are any more registers in the "custom" map in addition to the 16 you see requested.

More info might help figure out what's going on.

Reading 16 holding registers at a time while the battery breakers are off and the inverter is not connected yields this. The first three bytes of each response are client ID, function code, and length. The last 2 are the CRC:

2023/08/02 20:08:02.715593 Sending: 0103000000104406
[1] 2023/08/02 20:08:02.766851 010320 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 927a
2023/08/02 20:08:02.766910 Sending: 01030010001045c3
[2] 2023/08/02 20:08:02.818070 010320 0000 0000 0000 0065 0000 0043 14b3 0000 0021 2710 3458 4e20 0204 0000 0006 0000 bede
2023/08/02 20:08:02.818121 Sending: 01030020001045cc
[3] 2023/08/02 20:08:02.869497 010320 0000 15e0 0000 4e20 0000 0cf7 0cec 0001 0001 0010 0000 0000 0000 0000 0000 0000 ee7e
2023/08/02 20:08:02.869578 Sending: 0103003000104409
[4] 2023/08/02 20:08:02.920844 010320 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 927a
2023/08/02 20:08:02.920886 Sending: 01030040001045d2
[5] 2023/08/02 20:08:02.972166 010320 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 927a
2023/08/02 20:08:02.972248 Sending: 0103005000104417
[6] 2023/08/02 20:08:03.023584 010320 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 927a
2023/08/02 20:08:03.023671 Sending: 0103006000104418
[7] 2023/08/02 20:08:03.074998 010320 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 927a
2023/08/02 20:08:03.075081 Sending: 01030070001045dd
[8] 2023/08/02 20:08:03.126404 010320 0000 0cec 0cf7 0cef 0cf1 0cef 0cf1 0cf2 0cf0 0cee 0cf0 0cf0 0cef 0cf0 0cf2 0cf0 56ba
2023/08/02 20:08:03.126484 Sending: 01030080001045ee
[9] 2023/08/02 20:08:03.177767 010320 0cef 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 e593

After that point, the requests don't get a response which means that only registers 0 thru 144 are available, I guess.

The inverter only reads the 16 registers starting at position 19, first one being that 0065 row 2, in bold, and we know that in the same row the 0043 is SOC (67%), and the 14b3 is 10mV (5299 -> 52.99V), and my guess these two numbers are aggregated from all the batteries. not just ID 1.

After all the zeroes there's a surprise in line [8], which is reading 16 registers starting at address 112. The 16 registers starting at address 113 represent the mV of each cell for the master battery! (0cec -> 3308mV -> 3.308V) and so on.

[Edit] 0cf7 0cec in line 3 looks like highest and lowest mV across all cells(?).

At least I can export to home assistant the voltage of all cells in all batteries, while still using the EG4 protocol for inverter to battery comms. This is progress!


P.S.: btw, it doesn't matter which ethernet wires I use for RS485. Both{1,2} as inverter does or {7,8} as the battery comms cable does "speak" the same protocol and get "angry" if you use both of them at the same time.

 

[solarhombre]

Reading 16 holding registers at a time while the battery breakers are off and the inverter is not connected yields this. The first three bytes of each response are client ID, function code, and length. The last 2 are the CRC:

2023/08/02 20:08:02.715593 Sending: 0103000000104406
[1] 2023/08/02 20:08:02.766851 010320 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 927a
2023/08/02 20:08:02.766910 Sending: 01030010001045c3
[2] 2023/08/02 20:08:02.818070 010320 0000 0000 0000 0065 0000 0043 14b3 0000 0021 2710 3458 4e20 0204 0000 0006 0000 bede
2023/08/02 20:08:02.818121 Sending: 01030020001045cc
[3] 2023/08/02 20:08:02.869497 010320 0000 15e0 0000 4e20 0000 0cf7 0cec 0001 0001 0010 0000 0000 0000 0000 0000 0000 ee7e
2023/08/02 20:08:02.869578 Sending: 0103003000104409
[4] 2023/08/02 20:08:02.920844 010320 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 927a
2023/08/02 20:08:02.920886 Sending: 01030040001045d2
[5] 2023/08/02 20:08:02.972166 010320 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 927a
2023/08/02 20:08:02.972248 Sending: 0103005000104417
[6] 2023/08/02 20:08:03.023584 010320 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 927a
2023/08/02 20:08:03.023671 Sending: 0103006000104418
[7] 2023/08/02 20:08:03.074998 010320 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 927a
2023/08/02 20:08:03.075081 Sending: 01030070001045dd
[8] 2023/08/02 20:08:03.126404 010320 0000 0cec 0cf7 0cef 0cf1 0cef 0cf1 0cf2 0cf0 0cee 0cf0 0cf0 0cef 0cf0 0cf2 0cf0 56ba
2023/08/02 20:08:03.126484 Sending: 01030080001045ee
[9] 2023/08/02 20:08:03.177767 010320 0cef 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 e593

After that point, the requests don't get a response which means that only registers 0 thru 144 are available, I guess.

The inverter only reads the 16 registers starting at position 19, first one being that 0065 row 2, in bold, and we know that in the same row the 0043 is SOC (67%), and the 14b3 is 10mV (5299 -> 52.99V), and my guess these two numbers are aggregated from all the batteries. not just ID 1.

After all the zeroes there's a surprise in line [8], which is reading 16 registers starting at address 112. The 16 registers starting at address 113 represent the mV of each cell for the master battery! (0cec -> 3308mV -> 3.308V) and so on.

[Edit] 0cf7 0cec in line 3 looks like highest and lowest mV across all cells(?).

At least I can export to home assistant the voltage of all cells in all batteries, while still using the EG4 protocol for inverter to battery comms. This is progress!


P.S.: btw, it doesn't matter which ethernet wires I use for RS485. Both{1,2} as inverter does or {7,8} as the battery comms cable does "speak" the same protocol and get "angry" if you use both of them at the same time.

I am now reading data from batteries 2-6 and sending that to MQTT with autodiscovery config for homeassistant dashboards. The last bit is battery ID 1, I'll see if I can figure out this one out today, while still using the EG4 protocol between inverter and batteries.