ESP32 RS485 inverter/battery monitor

[chicagoandy]

There's some interesting movement on RS485 monitoring of inverters/batteries.

First, I've found this github which will encode an ESP32 with an ESPHome configuration for controlling a SolArk. This would give full read/write control of a Sol-Ark 15k with an Open Source, Open Home foundation approved solution. It would negate the need for the closed-source Solar-Assistant.

Sunsynk-Home-Assistant-Dash/ESPHome-1P-Sunsynk-Deye.yaml at main · slipx06/Sunsynk-Home-Assistant-Dash

Home Assistant Dashboard to display Inverter information. ESPHome configuration to collect inverter sensor data via modbus - slipx06/Sunsynk-Home-Assistant-Dash

github.com

I've also discovered there is a similar setup for the Standard chinese BMS's, here's a SEPLOS one that can read cell-level data from pack of multiple batteries:

esphome-seplos-bms/esp32-seplos-v3-example-multiple-battery-banks.yaml at main · syssi/esphome-seplos-bms

ESPHome component to monitor a Seplos Battery Management System (Seplos-BMS) via UART or RS485 - syssi/esphome-seplos-bms

github.com

And the one I'm following still has some work to do, but he's reading Ruixu single battery BMS for cell-level data.

esphome-ruixu-bms/esp32-s3-ruixu-example.yaml at main · easybotics/esphome-ruixu-bms

ESPHome component to monitor a Ruixu Battery Management System (Ruixu-BMS) via RS485 - easybotics/esphome-ruixu-bms

github.com

Really neat stuff. You could take this code, pair it with inexpensive M5Stack ESP32 chips,
ESP32 Chip: https://shop.m5stack.com/products/atom-lite-esp32-development-kit $7.99
RS485 Hat: https://shop.m5stack.com/products/atomic-rs485-base $9.99

So with $16 of hardware, some open-source software, you'd get your full integration into HomeAssistant, or other SmartHome platform of choice.

Which is awesome.

I guess I've got some questions, my RS485 knowledge is limited.

Currently I have my SolArk15K in closed loop with the Ruixu battery using RS485. The SOlArk only has high-lvel data displayed. Multiple batteries show as one big battery.
I also have the Solar-Assistant on the same wire, in parallel, but only getting Inverter data. SA does not want to mount the same usb/port for battery & Inverter

But... that data should be there, right? The cable is carrying Battery Data and Inverter Data. I should be able to read the detailed battery data off the same cable?

Can anyone explain how RS485 works? I understand it is designed for multiple hosts. The signals do not "end" unless there is a terminating resistor. That means I should be able to add an ESP32 based monitor to the same wire used for Battery->SolArk without disrupting the inverter closed-loop. Is this correct?

Is it a reasonable expectation to be able to add an listening ESP32 chip to the Battery comms wire and pull off battery data, without disrupting the inverter closed-loop?

 

[SomethingAppropriate]

There's some interesting movement on RS485 monitoring of inverters/batteries.

First, I've found this github which will encode an ESP32 with an ESPHome configuration for controlling a SolArk. This would give full read/write control of a Sol-Ark 15k with an Open Source, Open Home foundation approved solution. It would negate the need for the closed-source Solar-Assistant.

Sunsynk-Home-Assistant-Dash/ESPHome-1P-Sunsynk-Deye.yaml at main · slipx06/Sunsynk-Home-Assistant-Dash

Home Assistant Dashboard to display Inverter information. ESPHome configuration to collect inverter sensor data via modbus - slipx06/Sunsynk-Home-Assistant-Dash

github.com

I've also discovered there is a similar setup for the Standard chinese BMS's, here's a SEPLOS one that can read cell-level data from pack of multiple batteries:

esphome-seplos-bms/esp32-seplos-v3-example-multiple-battery-banks.yaml at main · syssi/esphome-seplos-bms

ESPHome component to monitor a Seplos Battery Management System (Seplos-BMS) via UART or RS485 - syssi/esphome-seplos-bms

github.com

And the one I'm following still has some work to do, but he's reading Ruixu single battery BMS for cell-level data.

esphome-ruixu-bms/esp32-s3-ruixu-example.yaml at main · easybotics/esphome-ruixu-bms

ESPHome component to monitor a Ruixu Battery Management System (Ruixu-BMS) via RS485 - easybotics/esphome-ruixu-bms

github.com

Really neat stuff. You could take this code, pair it with inexpensive M5Stack ESP32 chips,
ESP32 Chip: https://shop.m5stack.com/products/atom-lite-esp32-development-kit $7.99
RS485 Hat: https://shop.m5stack.com/products/atomic-rs485-base $9.99

So with $16 of hardware, some open-source software, you'd get your full integration into HomeAssistant, or other SmartHome platform of choice.

Which is awesome.

I guess I've got some questions, my RS485 knowledge is limited.

Currently I have my SolArk15K in closed loop with the Ruixu battery using RS485. The SOlArk only has high-lvel data displayed. Multiple batteries show as one big battery.
I also have the Solar-Assistant on the same wire, in parallel, but only getting Inverter data. SA does not want to mount the same usb/port for battery & Inverter

But... that data should be there, right? The cable is carrying Battery Data and Inverter Data. I should be able to read the detailed battery data off the same cable?

Can anyone explain how RS485 works? I understand it is designed for multiple hosts. The signals do not "end" unless there is a terminating resistor. That means I should be able to add an ESP32 based monitor to the same wire used for Battery->SolArk without disrupting the inverter closed-loop. Is this correct?

Is it a reasonable expectation to be able to add an listening ESP32 chip to the Battery comms wire and pull off battery data, without disrupting the inverter closed-loop?

Good question. Hope some one knows

 

[wpns]

There's some interesting movement on RS485 monitoring of inverters/batteries.

First, I've found this github which will encode an ESP32 with an ESPHome configuration for controlling a SolArk. This would give full read/write control of a Sol-Ark 15k with an Open Source, Open Home foundation approved solution. It would negate the need for the closed-source Solar-Assistant.

Sunsynk-Home-Assistant-Dash/ESPHome-1P-Sunsynk-Deye.yaml at main · slipx06/Sunsynk-Home-Assistant-Dash

Home Assistant Dashboard to display Inverter information. ESPHome configuration to collect inverter sensor data via modbus - slipx06/Sunsynk-Home-Assistant-Dash

github.com

I've also discovered there is a similar setup for the Standard chinese BMS's, here's a SEPLOS one that can read cell-level data from pack of multiple batteries:

esphome-seplos-bms/esp32-seplos-v3-example-multiple-battery-banks.yaml at main · syssi/esphome-seplos-bms

ESPHome component to monitor a Seplos Battery Management System (Seplos-BMS) via UART or RS485 - syssi/esphome-seplos-bms

github.com

And the one I'm following still has some work to do, but he's reading Ruixu single battery BMS for cell-level data.

esphome-ruixu-bms/esp32-s3-ruixu-example.yaml at main · easybotics/esphome-ruixu-bms

ESPHome component to monitor a Ruixu Battery Management System (Ruixu-BMS) via RS485 - easybotics/esphome-ruixu-bms

github.com

Really neat stuff. You could take this code, pair it with inexpensive M5Stack ESP32 chips,
ESP32 Chip: https://shop.m5stack.com/products/atom-lite-esp32-development-kit $7.99
RS485 Hat: https://shop.m5stack.com/products/atomic-rs485-base $9.99

So with $16 of hardware, some open-source software, you'd get your full integration into HomeAssistant, or other SmartHome platform of choice.

Which is awesome.

I guess I've got some questions, my RS485 knowledge is limited.

Currently I have my SolArk15K in closed loop with the Ruixu battery using RS485. The SOlArk only has high-lvel data displayed. Multiple batteries show as one big battery.
I also have the Solar-Assistant on the same wire, in parallel, but only getting Inverter data. SA does not want to mount the same usb/port for battery & Inverter

But... that data should be there, right? The cable is carrying Battery Data and Inverter Data. I should be able to read the detailed battery data off the same cable?

Can anyone explain how RS485 works? I understand it is designed for multiple hosts. The signals do not "end" unless there is a terminating resistor. That means I should be able to add an ESP32 based monitor to the same wire used for Battery->SolArk without disrupting the inverter closed-loop. Is this correct?

Is it a reasonable expectation to be able to add an listening ESP32 chip to the Battery comms wire and pull off battery data, without disrupting the inverter closed-loop?

@SeaGal might have some thoughts, while this is conceptually simple, it's not as easy as plugging some things in and running some software...

 

[Quattrohead]

Look for data splitter for Solark, basically you can let the inverter talk to the battery via CAN and you can read data from the inverter and/or battery via RS485.

 

[SeaGal]

But... that data should be there, right? The cable is carrying Battery Data and Inverter Data. I should be able to read the detailed battery data off the same cable?

It is likely that multiple batteries will consolidate their data, prior to sending it to the inverter over CAN or RS485.

Can anyone explain how RS485 works? I understand it is designed for multiple hosts. The signals do not "end" unless there is a terminating resistor. That means I should be able to add an ESP32 based monitor to the same wire used for Battery->SolArk without disrupting the inverter closed-loop. Is this correct?

Is it a reasonable expectation to be able to add an listening ESP32 chip to the Battery comms wire and pull off battery data, without disrupting the inverter closed-loop?

With RS485 you can passively tap / listen to an existing Modbus RTU data exchange. You will need an isolated adapter with no terminating resistor.

The issue then is to identify the send vs. receive data by either timing or data content. See also my posting here..
https://diysolarforum.com/threads/e...or-invertor-and-monitoring.65157/post-1143686

 

[marionw]

RS485 much like RS232, RS232-TTL and CAN defines the "Hardware" communications protocol. This is the chip level definition that defines the encoding and voltage levels used to send/receive data on a pair of wires.

Protocols such as Pylontech, Growatt, Seplos and others define the "Data" communications protocol. These define the format of the commands and responses that are sent/received over the wire pair.

RS232, RS232-TTL really only allow one device on each end of the pair of wires whereas RS485 and CAN allow multiple devices to be connected in parallel on the same wire pair.

For RS485 you can only have one "Master" and multiple "Slaves". The "Master" sends commands out over the wire pair and all slaves receive the command. Only the slave to which the command was addressed will respond provided the slave can decode and validate the command.

The "Master" sends out the command and what it then received it assumes is a response to the command sent. If you for example have two Masters communicating on the same wire pair they will stomp all over each other when receiving the other's commands or responses to the others commands.

RS285 generally uses two types on command and response formats: Modbus RTU and Modbus ASCII RTU.

I use an RJ45 splitter and an RS485 to USB converter to snoop/sniff what data is being sent/received on the wire pair. Since my software is a "Slave" I can receive both the commands from the Master and the responses from the Slave(s). Capturing the Master's command provides the data needed to decode the Slave's response which hopefully is received right after receiving the Master's command

 

[chicagoandy]

Helpful. Is there a good list of Deye/Solark battery supported protocols?

I have what seems like a solvable problem. I can load Ruixu software on a Windows machine and use an RS485 cable to view cell-level data, which is awesome.
I also have the Ruixus linked to the SolArk using “BMS Lithium Batt” and set its value to “00”, which I believe is CAN mode.

Then I'm using RS485 to connect SolArk to SolarAssistant. I use a splitter since SolArk has a combined RS485/CAN port.

What I'd really like is to get cell-level data somewhere, and the CAN protocols don't seem to include it.

I'm contemplating :
1. Just trying Ruixu to Solark integration using RS485 instead of CAN.
2. Using one of these ESP32 chips to pull RS485 off the battery, if the battery can do both simultaneously?
3. Something else.

 

[SeaGal]

What I'd really like is to get cell-level data somewhere, and the CAN protocols don't seem to include it.

That is the point I was making in post #5. The batteries will consolidate the data and send basic info to the inverter. The inverter doesn't care or likely want to know about cell-level or even battery-level info. All it really needs to know is what is the SOC of the battery "pack" (be it 1, 2 or 5) batteries and what rate it should charge and discharge at. The inverter doesn't need to know if there are 16 or 256 cells or what their individual voltages are. Hence the data exchanged between batteries and inverter does not typically include that redundant information.

FYI; the info sent via the Pylontech protocol over CAN is like this..
Message ID and contents..
0x351: Charge and Discharge parameters
= (max charge voltage, charge current, discharge current, discharge voltage (the latter is not used by Solis))
0x355: SOC & SOH
0x356: Current measurement of Battery Voltage, Current & Temp
0x359: Protection & Alarm flags
0x35C: Battery charge request flags (which I heard are ignored by Solis; I don't use them)
0x35E: Manufacturer name ("PYLON ") = ASCII "PYLON" followed by 3 spaces.

As you noted, the solution will be to query each battery separately to get the raw, unconsolidated, info from each battery - I'm not familiar with that battery though to know whether you can run the RS485-based comms simultaneously with the CAN comms between batteries and the inverter,.

 

[Quattrohead]

When I had the EG4 PowerPro connected to a Solark 12k, it just took the combined data for all the batteries. It was basic data, enough for the BMS and inverter to do controlled charging.
The 18kpv does grab more data from the batteries as it will show each battery along with its current, voltage, temperature, SOC, SOH, cycle count and min/max cell voltage.

Battery 0 - Battery_ID_01 - V 2.17

53.3 V Total Vol
10.8 A Current
3.323 V Min Volt / Cell 1
3.338 V Max Volt / Cell 1
65 % SOC
100 % SOH
29 ℃ Min Temp / Cell 4
29 ℃ Max Temp / Cell 4
324 Cycle Count

 

[marionw]

The Pylontech protocol on an RS485 connection will provide data for all connected batteries if you use address 0xFF when sending a command to the Master BMS.

I have five Sungoldpower rack batteries. If I send an 0x42 (Get Pack Analog Data) with a device address of 0xFF to the Master BMS then the response contains the number of batteries in the response and all analog data (cell voltages, six temp sensors, MOSFET Temps, SOC, SOH, Voltage and Current) for each battery.

I can also send the 0x42 (Get Pack Analog Data) addressed to each battery and get the data for just the battery addressed.

0xFF for a device address also works for other commands such as 0x42 (Get Pack Alarm Info) 0xC1 (Get Pack Software Version) and 0xC2 (Get Pack Product Info)

 

[SeaGal]

The Pylontech protocol on an RS485 connection will provide data for all connected batteries if you use address 0xFF when sending a command to the Master BMS.

That's good to know. But does the Deye/Solark inverter request data for all connected batteries?

 

[Quattrohead]

That's good to know. But does the Deye/Solark inverter request data for all connected batteries?

It must do, mine added the 3 batteries capacity together.

 

[SeaGal]

But did the inverter get all battery data separately and add them, or request the consolidated data from the master battery?

 

[marionw]

Normally (each inverter firmware/programming is different) the Master BMS reports to the inverter the status of all batteries as ONE BIG BATTERY.
The SOC will be the average of all batteries.
The Battery Capacity (Total) will be the sum of all individual battery capacities.

For the Pylontech protocol the Master BMS also reports:
Lowest cell voltage and the first battery number with this voltage.
Max cell voltage and the first battery number with this voltage.
Average cell voltage.
Lowest cell temp and the first battery number with this temp.
Max cell temp and the first battery number with this temp.
Average cell temp.
Max MOSFET Temp and battery number with this temp.
Min MOSFET Temp and battery number with this temp.
Max Ambient/Environment Temp and battery number with this temp.
Min Ambient/Environment Temp and battery number with this temp.

 

[wpns]

Unfortunately, EG4 PowerPro consolidates all the batteries into One Giant Battery (at least when querying the 18Kpv inverter), and reports min and max cell voltage across all the batteries. So I get graphs like:

and

Which isn't quite as useful. I mean 100mv delta across cells in one battery is probably pretty bad, but across 6 batteries? Is there anything I can tell from this data, or is it impossible to tell?

Also not clear why the minimum cell voltage drops during the balancing phase...

 

[Luk88]

I don't have any of these batteries, but I've been researching Pylontech protocol recently as I wrote my own battery emulator to have more control over charging and the usual message used with Pylontech is 61H which contains all cell data and has a provision for reporting individual cell data for each battery in the bank, but as was said before sometimes the main BMS will average this.

In such situation I imagine it would be fairly easy to tap the BMs to BMS RS485 comms and read from that. There is no need to distinguis reading from writing. A $5 buck USB to RS485 adapter is all that's needed. But one would have to write some software to interpret the data.

I found the best documentation for Pylontech in a document titled "Sunsynk_BatteryCompatibility_v16_English_j1196"(google if interested). All other Pylontech protocol references were missing the 61h command. The one mostly used by my inverters.

 

[chicagoandy]

As you noted, the solution will be to query each battery separately to get the raw, unconsolidated, info from each battery - I'm not familiar with that battery though to know whether you can run the RS485-based comms simultaneously with the CAN comms between batteries and the inverter,.

It seems I have a path forward. I've found some battery docs that does suggest it can supply both RS485 & CAN, so we'll give it a shot.

I've ordered some ESP32 gear and will see if I can pull the cell-data with ESP32 via RS485 without disturbing the Sol-Ark CAN integration.

The docs mention using a RJ-45 splitter, which of course works because typical cables are setup with different pins for RS485 & CAN.
The docs also mention connecting CAN connection to the first battery & RS485 to the last one.

$17 worth of parts and completely Open Software is awesome.

We'll find out.

 

[wpns]

It seems I have a path forward. I've found some battery docs that does suggest it can supply both RS485 & CAN, so we'll give it a shot.

I've ordered some ESP32 gear and will see if I can pull the cell-data with ESP32 via RS485 without disturbing the Sol-Ark CAN integration.

The docs mention using a RJ-45 splitter, which of course works because typical cables are setup with different pins for RS485 & CAN.
The docs also mention connecting CAN connection to the first battery & RS485 to the last one.

$17 worth of parts and completely Open Software is awesome.

We'll find out.

Let us know, when I get back to mine I'm going to see if I can talk CAN (from the inverter) and RS485 (from my monitoring software) simultaneously to the EG4 PowerPro WallMount OutDoor batteries.

 

[chicagoandy]

That's good to know. But does the Deye/Solark inverter request data for all connected batteries?

The Battery integration guide from Ruixu specifies CAN for SolArk , and with any of the CAN configurations, SolArk only presents aggregated data. I Think you've told me twice now that CAN w/ Pylontech protocol will always only show aggregate data. (surprised you didn't need to tell me a third time...)

Sol-ARK docs show different battery brands using RS485 which displays some cherry-picked data, like Highest Pack SOC, and Corresponding Pack Number. I assume it has the full data-set and is only displaying a few. I also assume it would send the full set downstream to Solar-Assistant.

I think we can summarize if you want cell-level data you need to use RS485.

So, ESP32 with a RS485 hat should do the trick.

 

[SeaGal]

I Think you've told me twice now that CAN w/ Pylontech protocol will always only show aggregate data. (surprised you didn't need to tell me a third time...)

LOL... I think that comment was aimed at @marionw, and it was a question - I don't know that for sure, just know what I've seen my Solis inverters do. But at my age, with over 3000 posts, I do forget who I've told what sometimes

Either way, it's good you have a plan so do keep us updated with the dual CAN and RS485 querying. It's a learning process for us all, especially as different inverters will query different data and different battery providers will provide different data and we'll probably see different data being available over CAN vs. RS485.

 

[chicagoandy]

A quick update that I've gone and implemented this, Ruixu Battery monitor, with Cell level data, into HomeAssistant via ESP32 and ESPHome, using very inexpensive components. I did this with my Ruixu batteries, I assume this approach will work for any other batteries that can communicate over RS485.

Bill-of-materials:
Atom M5 Stack S3 Lite: $7.50 https://shop.m5stack.com/products/atoms3-lite-esp32s3-dev-kit
Atom RS485 Isolated : $9.95 https://shop.m5stack.com/products/isolated-rs485-unit
RJ-45 3-way splitter: $7.99 https://www.amazon.com/Ethernet-Splitter-HRIOEKAX-Adapter-Switch/dp/B0B5CYXV8B/

And of course, Solar-Assistant integrates to Home-Assistant via MQTT, which gives Inverter data. ESP32 integrates to Home Assistant via ESPHome, which makes the cell-lvel data avilable. All of these are able to coexist on the same single RJ45 cable.

Wiring - all using 1 single standard CAT-5 cable
Configured as following:
1. Battery to Sol-Ark for Closed-Loop Comms
2. Battery to ESP32 for detailed cell-level data
3. Sol-Ark to Solar-Assistant for battery monitoring.

Wiring Details

Pin 1	Orange / White	RS485 B1: Sol-Ark to Solar Assistant
Pin 2	Orange	RS485 A1 : Sol-Ark to Solar Assistant
Pin 3	Green/White	Common Ground
Pin 4	Blue	CAN: Ruixu to Sol-Ark
Pin 5	Blue/White	CAN: Ruixu to Sol-Ark
Pin 6	Green	Common Ground
Pin 7	Brown/White	RS485 A1 : Ruixu to ESP32
Pin 8	Brown	RS485 B1 : Ruixu to ESP32

I used a 3-way RJ45 splitter, which allowed me to send only specific wires to each device.

Cable from Splitter to Inverter had pins 1,2,3,4,5,6 connected (7,8 disconnected).
Cable from splitter to ESP32 had pins 3,6,7,8 connected
Cable from splitter to Solar Assistant had pins 1,2,3,6 connected.
Cable from splitter to battery had all 8 pins.

Solar Assistant, Sol-Ark closed-loop, and ESP32 are all happily coexisting.


Oddly, everything powered-up fine on the first try.

For software:
I started with https://github.com/easybotics/esphome-ruixu-bms - which got me very close. This repo is written for the new 16kwh wallmount batteries. It worked fine, but I observed a bug where reported current was miscalculated. I'm not sure if that current miscalculation required for the 16kwh wallmount? I have 10 48100 server-rack batteries.

Ruixu batteries use a slightly modified very common chinese BMS. The Semplos BMS is very similar, other BMS's are also very similar. The ESPHome configuration I used was based on a similar Semplos one. There are likely other repos for other similar Chinese BMS.s

So I forked that repo, https://github.com/chicagoandy/esphome-ruixu-bms correcting the misreported current. Works great.

I am not particularly interested in maintaining this repo, if anyone is interested please do take it now.

Note: In a future project I will replace the Solar-Assistant integration with a similar-setup using this repo: https://github.com/slipx06/Sunsynk-Home-Assistant-Dash/blob/main/ESPHome-1P-Sunsynk-Deye.yaml

So what do I end up with?
1. Closed loop comms, over CAN - Batteries to Sol-Ark
2. Solar Assistant over RS485 - Sol-Ark to SolarAssistant, then onto HomeAssistant via MQTT
3. Ruixu batteries to ESPHome / Home Assistant over RS485, with cell-level data.

All over 1 Cat-5 cable.

Works great.





Now I need to figure out a good dashboard for all this data with 10 batteries. Not my strong suit.

 

[gary_lankford]

There's some interesting movement on RS485 monitoring of inverters/batteries.

First, I've found this github which will encode an ESP32 with an ESPHome configuration for controlling a SolArk. This would give full read/write control of a Sol-Ark 15k with an Open Source, Open Home foundation approved solution. It would negate the need for the closed-source Solar-Assistant.

Sunsynk-Home-Assistant-Dash/ESPHome-1P-Sunsynk-Deye.yaml at main · slipx06/Sunsynk-Home-Assistant-Dash

Home Assistant Dashboard to display Inverter information. ESPHome configuration to collect inverter sensor data via modbus - slipx06/Sunsynk-Home-Assistant-Dash

github.com

I've also discovered there is a similar setup for the Standard chinese BMS's, here's a SEPLOS one that can read cell-level data from pack of multiple batteries:

esphome-seplos-bms/esp32-seplos-v3-example-multiple-battery-banks.yaml at main · syssi/esphome-seplos-bms

ESPHome component to monitor a Seplos Battery Management System (Seplos-BMS) via UART or RS485 - syssi/esphome-seplos-bms

github.com

And the one I'm following still has some work to do, but he's reading Ruixu single battery BMS for cell-level data.

esphome-ruixu-bms/esp32-s3-ruixu-example.yaml at main · easybotics/esphome-ruixu-bms

ESPHome component to monitor a Ruixu Battery Management System (Ruixu-BMS) via RS485 - easybotics/esphome-ruixu-bms

github.com

Really neat stuff. You could take this code, pair it with inexpensive M5Stack ESP32 chips,
ESP32 Chip: https://shop.m5stack.com/products/atom-lite-esp32-development-kit $7.99
RS485 Hat: https://shop.m5stack.com/products/atomic-rs485-base $9.99

So with $16 of hardware, some open-source software, you'd get your full integration into HomeAssistant, or other SmartHome platform of choice.

Which is awesome.

I guess I've got some questions, my RS485 knowledge is limited.

Currently I have my SolArk15K in closed loop with the Ruixu battery using RS485. The SOlArk only has high-lvel data displayed. Multiple batteries show as one big battery.
I also have the Solar-Assistant on the same wire, in parallel, but only getting Inverter data. SA does not want to mount the same usb/port for battery & Inverter

But... that data should be there, right? The cable is carrying Battery Data and Inverter Data. I should be able to read the detailed battery data off the same cable?

Can anyone explain how RS485 works? I understand it is designed for multiple hosts. The signals do not "end" unless there is a terminating resistor. That means I should be able to add an ESP32 based monitor to the same wire used for Battery->SolArk without disrupting the inverter closed-loop. Is this correct?

Is it a reasonable expectation to be able to add an listening ESP32 chip to the Battery comms wire and pull off battery data, without disrupting the inverter closed-loop?

Not nearly the same, but I was able to get RS485 modbus data off of my Magnum MS4448PAE simply by using a phone splitter adapter plugged into the back of the Magnum ME-ARC50 monitor/control and daisy chaining to an RS485 converter using a Orange Pi 3 LTE for a github project to read data into MQTT.

GitHub - CharlesGodwin/pymagnum: A read only interface for Magnum Energy Network devices

A read only interface for Magnum Energy Network devices - CharlesGodwin/pymagnum

github.com

I ultimately abandoned that project, because I gained no remote control, and the limited remote data wasn't worth the trouble, but I think it demonstrates the possibility of splitting mod-bus data to 2 outputs.

 

[wpns]

Let us know, when I get back to mine I'm going to see if I can talk CAN (from the inverter) and RS485 (from my monitoring software) simultaneously to the EG4 PowerPro WallMount OutDoor batteries.

So I finally got around to building the special CAN-Only cable and connecting my primary EG4 PowerPro WallMount Outdoor battery to my RS-485 bus, while leaving the 18Kpv inverter talking CAN to it.

Yeah, as I feared, the protocol for a battery with ID=1 is different, and (AFAICT undocumented) gives the inverter consolidated battery numbers for the entire bank. So far I've got the following non-zero registers (register number, hex, unsigned, signed, my guess):

019 0063 99 99
021 0064 100 100.            SOC (for the bank?  Counts down with bank SOC)
022 1565 5477 5477         54.77 volts?
023 fa74 64116 -1420      -14.20 amps (total across the bank)
024 0020 32 32                 Max BMS Temp in C?
025 2ee0 12000 12000
026 8de8 36328 -29208
027 9040 36928 -28608
028 0211 529 529
030 0099 153 153             Cycles across the bank?
032 0064 100 100             SOH for battery or bank?
033 15e0 5600 5600         56.00 volts?
035 7530 30000 30000
037 0d66 3430 3430         Pack-wide max cell voltage
038 0d4c 3404 3404         Pack-wide min cell voltage
039 0002 2 2                     Pack status 2 for charging, 1 for discharging?
040 0001 1 1                     Also sometimes 2
041 0010 16 16                 # of cells?
113 0d62 3426 3426         # cell voltages for this battery?
114 0d5f 3423 3423
115 0d5e 3422 3422
116 0d5b 3419 3419
117 0d59 3417 3417
118 0d5b 3419 3419
119 0d62 3426 3426
120 0d5a 3418 3418
121 0d63 3427 3427
122 0d65 3429 3429
123 0d63 3427 3427
124 0d62 3426 3426
125 0d62 3426 3426
126 0d54 3412 3412
127 0d65 3429 3429
128 0d66 3430 3430

@EG4 Electronics James
@EG4TechSolutionsTeam

Any chance of finding the primary Battery modbus list for us?

Anyone else have any thoughts?

Thanks!

 

[EG4TechSolutionsTeam]

Unfortunately, I’m unable to provide the primary battery Modbus list.

 

[qcda1]

I don't have any of these batteries, but I've been researching Pylontech protocol recently as I wrote my own battery emulator to have more control over charging and the usual message used with Pylontech is 61H which contains all cell data and has a provision for reporting individual cell data for each battery in the bank, but as was said before sometimes the main BMS will average this.

In such situation I imagine it would be fairly easy to tap the BMs to BMS RS485 comms and read from that. There is no need to distinguis reading from writing. A $5 buck USB to RS485 adapter is all that's needed. But one would have to write some software to interpret the data.

I found the best documentation for Pylontech in a document titled "Sunsynk_BatteryCompatibility_v16_English_j1196"(google if interested). All other Pylontech protocol references were missing the 61h command. The one mostly used by my inverters.

You will find some info on command 61H in this document (Google search: PYLON RS485-protocol-V3.5-20190807ru (1)) page 14-16.