TM48
Solar Wizard
Question: why connect to each battery when RS485 is a daisy chain addressed type configuration?
Using Solar Assistant to read multiple batteries of different types
- Thread starter Jamsolar876
- Start date
wpns
Solar Joules are catch and release
Right you are, I wasn't sure it would work, but it works fine. I can talk to batteries 4, 5, and 6 and get all their stats, now I'm parsing the numbers I can figure out to load Redis and MQTT and (somewhere in there) SQL. I've got parts on order to hook the other 3 batteries in, but there's some question of what happens when I talk RS485 to battery 1, will it respond like an individual battery, or do I have to talk the (undocumented) multi-battery-of-which-this-is-the-primary modbus-ish protocol? I should know soon enough...
FWIW, the inverter is talking to the primary battery (ID=1) with CAN, and the batteries are linked with whatever the Batt/Comm ports are, so I'm hoping talking to the batteries with Modbus on the RS485/CAN ports won't cause any issues...
Code:
PP.py V1.2 11/04/2024 WPNS at 2024/11/04 09:22:48
Connected to MQTT Broker!
found it at /dev/ttyUSB1
Batt04
Battery Voltage: 53.12
Batt05
Battery Voltage: 53.03
Batt06
Battery Voltage: 53.04
Quattrohead
Emperor Of Solar
It seems to me like it should be possible to talk to the inverter via can and to home assistant via rs485.
As you say the master battery behavior is going to be critical.
As you say the master battery behavior is going to be critical.
TM48
Solar Wizard
Yeah Me too.
wpns
Solar Joules are catch and release
OK, so I can poll three batteries (until more hardware arrives), load 26 parameters from each battery into an MQTT broker, and run that in a loop with no delay, and I don't seem to get any errors or effect the monitor... website or my other modbus polling of the two 18Kpv inverters. Tomorrow I'll look at splitting out the modbus from the CAN bus on the Primary battery (ID=1) and see if I can talk modbus to that battery directly.
TM48
Solar Wizard
That's good to hear.
wpns
Solar Joules are catch and release
Just because I'm proud of myself (mostly that it hasn't crashed yet!):
Code:
root@sand:/home/MQTT# redis-get.py | grep Batt0
EG4_PP.Batt04.AH 179
EG4_PP.Batt04.CellmV.Cell00mV 3282
EG4_PP.Batt04.CellmV.Cell01mV 3283
EG4_PP.Batt04.CellmV.Cell02mV 3284
EG4_PP.Batt04.CellmV.Cell03mV 3284
EG4_PP.Batt04.CellmV.Cell04mV 3283
EG4_PP.Batt04.CellmV.Cell05mV 3283
EG4_PP.Batt04.CellmV.Cell06mV 3283
EG4_PP.Batt04.CellmV.Cell07mV 3283
EG4_PP.Batt04.CellmV.Cell08mV 3281
EG4_PP.Batt04.CellmV.Cell09mV 3284
EG4_PP.Batt04.CellmV.Cell10mV 3282
EG4_PP.Batt04.CellmV.Cell11mV 3284
EG4_PP.Batt04.CellmV.Cell12mV 3283
EG4_PP.Batt04.CellmV.Cell13mV 3284
EG4_PP.Batt04.CellmV.Cell14mV 3282
EG4_PP.Batt04.CellmV.Cell15mV 3283
EG4_PP.Batt04.Current -12.5
EG4_PP.Batt04.Cycles 145
EG4_PP.Batt04.SOC 64
EG4_PP.Batt04.SOH 100
EG4_PP.Batt04.Temp0 32
EG4_PP.Batt04.Temp1 33
EG4_PP.Batt04.Temp2 34
EG4_PP.Batt04.Voltage 52.52
EG4_PP.Batt04.mVdelta 3283
EG4_PP.Batt05.AH 176
EG4_PP.Batt05.CellmV.Cell00mV 3281
EG4_PP.Batt05.CellmV.Cell01mV 3284
EG4_PP.Batt05.CellmV.Cell02mV 3283
EG4_PP.Batt05.CellmV.Cell03mV 3283
EG4_PP.Batt05.CellmV.Cell04mV 3282
EG4_PP.Batt05.CellmV.Cell05mV 3284
EG4_PP.Batt05.CellmV.Cell06mV 3283
EG4_PP.Batt05.CellmV.Cell07mV 3284
EG4_PP.Batt05.CellmV.Cell08mV 3283
EG4_PP.Batt05.CellmV.Cell09mV 3283
EG4_PP.Batt05.CellmV.Cell10mV 3282
EG4_PP.Batt05.CellmV.Cell11mV 3283
EG4_PP.Batt05.CellmV.Cell12mV 3282
EG4_PP.Batt05.CellmV.Cell13mV 3283
EG4_PP.Batt05.CellmV.Cell14mV 3281
EG4_PP.Batt05.CellmV.Cell15mV 3284
EG4_PP.Batt05.Current -11.1
EG4_PP.Batt05.Cycles 144
EG4_PP.Batt05.SOC 63
EG4_PP.Batt05.SOH 100
EG4_PP.Batt05.Temp0 33
EG4_PP.Batt05.Temp1 33
EG4_PP.Batt05.Temp2 33
EG4_PP.Batt05.Voltage 52.52
EG4_PP.Batt05.mVdelta 3284
EG4_PP.Batt06.AH 184
EG4_PP.Batt06.CellmV.Cell00mV 3282
EG4_PP.Batt06.CellmV.Cell01mV 3284
EG4_PP.Batt06.CellmV.Cell02mV 3283
EG4_PP.Batt06.CellmV.Cell03mV 3285
EG4_PP.Batt06.CellmV.Cell04mV 3283
EG4_PP.Batt06.CellmV.Cell05mV 3285
EG4_PP.Batt06.CellmV.Cell06mV 3283
EG4_PP.Batt06.CellmV.Cell07mV 3283
EG4_PP.Batt06.CellmV.Cell08mV 3282
EG4_PP.Batt06.CellmV.Cell09mV 3284
EG4_PP.Batt06.CellmV.Cell10mV 3282
EG4_PP.Batt06.CellmV.Cell11mV 3285
EG4_PP.Batt06.CellmV.Cell12mV 3284
EG4_PP.Batt06.CellmV.Cell13mV 3285
EG4_PP.Batt06.CellmV.Cell14mV 3283
EG4_PP.Batt06.CellmV.Cell15mV 3284
EG4_PP.Batt06.Current -10.4
EG4_PP.Batt06.Cycles 143
EG4_PP.Batt06.SOC 66
EG4_PP.Batt06.SOH 100
EG4_PP.Batt06.Temp0 32
EG4_PP.Batt06.Temp1 33
EG4_PP.Batt06.Temp2 33
EG4_PP.Batt06.Voltage 52.53
EG4_PP.Batt06.mVdelta 3284
root@sand:/home/MQTT#Quattrohead
Emperor Of Solar
Perfect 
wpns
Solar Joules are catch and release
Learned another factoid today: If you poll the batteries over RS485 continuously (about 90Hz), the primary inverter eventually goes offline from the POV of the cloud monitoring, and the secondary inverter thinks there's no valid primary. Comes right back when you stop, so that's good but a little disconcerting. Takeaway: Don't do that. 
wpns
Solar Joules are catch and release
Update:
Got SOC warning code notifying my phone (and alerting me even when muted) using PushOver.net, so I'll be able to get up in the middle of the night and start the generator(s) if the grid fails and my batteries are running low.
Got 5 of 6 batteries wired together on RS485, scraping data, loading Redis, publishing to MQTT, and logging to SQL. Going to let it run overnight and see what graphs I can create. [Battery with address 1 is going to be a whole other rathole, so that's a task for tomorrow.]. Polling at 10-second intervals (offset by 5 seconds from the 10-second inverter polling) doesn't seem to cause any problems, and that's plenty of time to know something's happening to the batteries.
Got SOC warning code notifying my phone (and alerting me even when muted) using PushOver.net, so I'll be able to get up in the middle of the night and start the generator(s) if the grid fails and my batteries are running low.
Got 5 of 6 batteries wired together on RS485, scraping data, loading Redis, publishing to MQTT, and logging to SQL. Going to let it run overnight and see what graphs I can create. [Battery with address 1 is going to be a whole other rathole, so that's a task for tomorrow.]. Polling at 10-second intervals (offset by 5 seconds from the 10-second inverter polling) doesn't seem to cause any problems, and that's plenty of time to know something's happening to the batteries.
I decided to Google Search to see if it was implemented and found this thread. I messaged Solar Assistant a year ago about this and they said they'd look into it, but I thought maybe I was the only interested in this and was surprised to find this.
I've been trying to figure out why they don't prioritize this and my only guess is that because it won't really sell many more copies. Solar Assistant is great, specially for the price, but I'm starting to question how well it will stand long term because of the way they monetize. Technically once you buy a copy, they save money by you not using it. Not saying they prioritize this, but there's no real incentive to keep customers happy after they've purchased the copies, other than for good word of mouth.
Any ideas on how we can get this better on their radar? I would benefit significantly from this, and based on my software experience they already have most of what they need so it most likely isn't an expensive feature to complete.
I've been trying to figure out why they don't prioritize this and my only guess is that because it won't really sell many more copies. Solar Assistant is great, specially for the price, but I'm starting to question how well it will stand long term because of the way they monetize. Technically once you buy a copy, they save money by you not using it. Not saying they prioritize this, but there's no real incentive to keep customers happy after they've purchased the copies, other than for good word of mouth.
Any ideas on how we can get this better on their radar? I would benefit significantly from this, and based on my software experience they already have most of what they need so it most likely isn't an expensive feature to complete.
SA https://solar-assistant.io/help/battery/canbus states "When multiple batteries are connected in parallel they will display as one large battery. Per pack metrics via CAN bus might be available in future." Vague and disappointing. We need this feature.
I guess you would need to buy cables for every single battery and use the USB ports on the SA Pi. If it would work from master CAN, they/him would not earn more money?
SolarAssistant
I have inquired a few days ago to SA as well about monitoring multiple batteries with different bms. I have a GSL 48v 280ah that i believe has a Seplos bms and a EG4 indoor 48v 280ah . Connecting either to SA with rs485 modbus works fine. Connecting both on the same rs485 modbus will get recognized by SA as two separate batteries but only the higher #address battery will show correct info, the first battery info gets mixed up. I also have 2 homebuilt batteries with BD series JK bms i would like to connect to SA. Easy solution would be to enable multiple usb devices and protocols to be recognized in SA, which currently only possible with certain bms protocol
marionw
Solar Wizard
SA needs to:
1) Recognize multiple RS485 to USB converters (more than just an inverter and one battery stack)
2) Permit the selection of the RS485 to USB converter and then select whether it is a Battery, Inverter or Shunt.
3) When you select an RS485 to USB converter and specify it is a battery then additionally select whether you want it merged with other RS485 to USB converters that you have selected as a Battery.
4) Allow SA to act as a "Software Master BMS" which merges the data from all "Batteries" and provided that data to the Inverter
1) Recognize multiple RS485 to USB converters (more than just an inverter and one battery stack)
2) Permit the selection of the RS485 to USB converter and then select whether it is a Battery, Inverter or Shunt.
3) When you select an RS485 to USB converter and specify it is a battery then additionally select whether you want it merged with other RS485 to USB converters that you have selected as a Battery.
4) Allow SA to act as a "Software Master BMS" which merges the data from all "Batteries" and provided that data to the Inverter
Last edited:
Brett V
Solar Wizard
I have four batteries each with its own Overkill BMS using the USB converters. It sort of works but only to the extent of how accurate the BMS reports SOC. I did this on a separate pi device from the main unit that reports one big battery getting data from a Victron smart shunt. It required buying two licenses and running to pi’s. Not ideal but the only workaround I could come up with.
Attachments
wpns
Solar Joules are catch and release
SA is great for what it does, but if you use the paradigm "only talks to one manufacturer at a time" then it makes a lot more sense.
You can get a _second_ instance of SA to talk to the other brand of battery and export to a common MQTT broker, but now you are into HA territory and out of my wheelhouse.
You can get a _second_ instance of SA to talk to the other brand of battery and export to a common MQTT broker, but now you are into HA territory and out of my wheelhouse.
This seems to be the SA business model to sell more licenses. They replied to my inquiry, but they did not address my questions, almost like they did not read my email. And oh, they did mention buying another license. I like the software, but one system should only require one license.
fmeili1
Solar Addict
Btw. do you have published your python script to read out the EG4-LL battery data via modbus somewhere (github?) - maybe I've missed it. Have you ever used modbus via ESPHome?
I'll try to integrate the SOC value into my existing DIY Chargeverter CAN bus ESPHome controller to have a better control when and for how long to use the grid. I want to "grep/sniff" this data via modbus which SolarAssistant already requests from the batteries (I'm running an open loop setup where all batteries are individually connected to SA via RS485 passive HUBs).
I have the spec, but I've never programmed modbus by myself and need a bit of a kick-start... as far as I understand, I need to set the modbus controller in the ESPHome program as a "Modbus client" (master?) to "sniff" the existing data which SA gets already from the batteries. Beside the baud rate (the EG4-LL spec says 9600 bps) I need to set a modbus address for the ESPHome controller itself (which address do you use?). After that I can just configure ESPHome sensors by specifying the modbus register as the address - still need to find out how to identify the different batteries via ESPHome modbus.
mikeenea
Solar Enthusiast
Using ESP32 devices to pull data from four different batteries (SOK Rack, Sungold Wall Mount, RUIXU Rack, and DIY's w/JK Inverter BMS) and able to display full cell data and set some parameters the code for the ESP2 devices is on github. I am pulling data and monitoring over 21 batteries in real time - Example below:
fmeili1
Solar Addict
Looks great!
Can you provide a link to the github project?
Is it an ESPHome project or Arduino code?
Thanks!
mikeenea
Solar Enthusiast
Ruixu - https://github.com/easybotics/esphome-ruixu-bms
SOK & SunGold - https://github.com/syssi/esphome-pace-bms
JKBMS - https://github.com/syssi/esphome-jk-bms
I built and flashed the ESP32 devices with ESPhome CLI - used M5Stack ATOM modules for the ESP32 (ATOMS3 Lite) and M5Stack isolated RS485 interfaces. Used the example card in the JKBMS git to build the dashboard components.
Mike E.
wpns
Solar Joules are catch and release
Just posted it to:
Enjoy!
And _PLEASE_ let us know if you sniff any more useful data about the Battery One Protocol!
wpns
Solar Joules are catch and release
I use my Modbus interface as a Master, so there's no address setting required (there can be only one).
If you're trying to sniff the data from the Master (SA) to the Primary Battery (ID=1), you'll want to be in slave/client mode.
You would pick an address outside of your currently-used range (if your batteries are 1-6, use 200 or something), and then set it for promiscuous mode, or whatever allows you to see all the traffic on the bus, otherwise it'll only see the traffic addressed to 200.
Or maybe you need to be in a special listen-only mode?
Sniff Modbus RTU Traffic
Hi All, Does anyone know a tool for monitoring / sniffing Modbus RTU / RS485 traffic. I'm wanting to capture and debug some flaky Modbus RTU comms. I was hoping to use a USB to serial interface connected to the RS485 network and capture / sniff the Modbus traffic via Wireshark or something like...
Similar threads
