MaikaiLifeDIY
Solar Enthusiast
DELETED: didn't want to change topics
Last edited:
JBD BMS and JK BMS.I may be a little slow but what abbreviation does JBD and JK stand for?
EG4 just put out a new video and the configuration process seems to be the same as for the LL V2's... and you're right it will definitely be uncharted territory so I'll let you know when I know. Probably do a video on the results no matter if its positive or negative.With regards to the PowerPro, you're going to be in uncharted territory. I'm not aware of who makes the BMS in that unit and it's not currently listed in the supported batteries for Solar Assistant.
EG4 battery setup in SolarAssistant
How to connect an EG4 battery to SolarAssistant.solar-assistant.io
Display seems to be the same, so the BMS could be the same or similar between them.configuration process seems to be the same as for the LL V2's
I have my two 15k's talking to solar assistant and I know how to change the setting to view them both. I also have the smart shunt connected to the pi but I can't figure out the setting to view it remotely.... what setting do you use when you switch to the victron smart shunt? Thanks in advanceA couple points of clarification for consideration.
The reason I have the shunt is for validation, if I ever feel like the data from the batteries could be wrong, the shunt is my single source of truth that accurately measures the entire volume of energy in or out of the batteries. I keep it connected to SA so that in a remote situation I can toggle settings in HA and view it remotely, otherwise, if I'm onsite, I use the Victron app with Bluetooth to look at the shunt. Yes, I could purchase a CerboGX and make the shunt data always local and remotely accessible, but I don't need the data bad enough to justify purchasing another $300+ dollar device for this purpose.
- Solar Assistant (SA) can only communicate with one source at a time for battery information. If I want to view the data from the Victron shunt, I have to stop the connection in SA, and switch the USB input selection to the port the Victron is connected to. Afterward, if I want to flip back to direct communication with the EG4 batteries, I have to repeat the same steps forgoing active communication with the Victron. Basically, it's one or the other, multiple simultaneous battery measurement sources cannot be monitored at the same time (maybe SA will add this in the future, but I have no awareness of whether it could be included in their upcoming development plans).
- If you want to see the individual battery data in SA, you can only do this by directly getting the data from each battery. SA cannot parse the aggregate battery data communicated to either the ComHub or the Inverter into individual battery data.
If you decide it's a must-have to simultaneously see the individual battery data from all your different types of batteries, "assuming they're supported by SA", then you'll need multiple Pis with SA for each battery type/protocol. If you went down this road, you would have to toggle back and forth between different SA instances. The only way to combine that data into a single location would then be to feed that data from your multiple SA instances using MQTT to Home Assistant and build a dashboard.
Hopefully, that helps, if you want to soundboard your ideas or share your plans I'm always willing to find a quick time for a phone call, private message me if interested.
Cheers!
I have my two 15k's talking to solar assistant and I know how to change the setting to view them both. I also have the smart shunt connected to the pi but I can't figure out the setting to view it remotely.... what setting do you use when you switch to the victron smart shunt? Thanks in advance
Let me see if I have this right.A couple points of clarification for consideration.
- Solar Assistant (SA) can only communicate with one source at a time for battery information. If I want to view the data from the Victron shunt, I have to stop the connection in SA, and switch the USB input selection to the port the Victron is connected to. Afterward, if I want to flip back to direct communication with the EG4 batteries, I have to repeat the same steps forgoing active communication with the Victron. Basically, it's one or the other, multiple simultaneous battery measurement sources cannot be monitored at the same time (maybe SA will add this in the future, but I have no awareness of whether it could be included in their upcoming development plans).
- If you want to see the individual battery data in SA, you can only do this by directly getting the data from each battery. SA cannot parse the aggregate battery data communicated to either the ComHub or the Inverter into individual battery data.
The HUB is only needed because the batteries cannot send their data directly to the inverter, it has no purpose with SA.OBSERVATION:
Some combinations of Inverters and Batteries require an intermediate "Communication Hub" for the former to read and direct the latter.
SUB-PREMISE_1 Not all information available either destination survives the transit through the hub.
No difference, the information flows between each connected battery using the network cable much like a network hub, rebroadcasting the information.QUERY_1
Is there any difference in the information available at the proximal and distal ends of the string of Batteries? If so, what are those differences?
The splitter is used on the "Inverter" so that both SA and the CommHub can talk to the Inverter, not so you can split the battery communication in multiple ways. Both SA and the CommHub are speaking RS435 to the batteries, the CommHum is relaying that data via CANBUS to the Inverter using a separate set of wires/pins. Basically the port on the Sol-Ark, the RJ45 port has certain sets of pins that do different things.QUERY_2:
If not, wouldn't a splitter placed at the proximal end of the Battery string (i.e., between the Batteries and the Hub/Inverter) achieve the same data result as having the data connection at the distal end of the string (at Battery #7 in your set-up)?
No hub is required when using for example the EG4_LL batteries, they can speak natively to the Sol-Ark inverter. The HUB translates RS435 to CANBUS because the Lifepower batteries do not have this ability in their BMS. The HUB has no purpose for SA, it's just there to tell the inverter what's happening with the batteries. The splitter is there so the single port on the inverter can be used to receive data from the inverter for SA and so that the HUB can send data to the inverter, for whatever design reason this occurs over a single RJ45 port.RELATED QUERY:
If no Hub was required between the Inverter and Battery string, would the single splitter adjacent to the Inverter be able to read all the Inverter information AND all the Battery information? If not, why not?
I should have never mentioned the shunt, it confuses everyone. I don't "actively" use the shunt, I have it so connected to SA so that I "could" make it the source for battery data and see that in SA, which SA is remotely accessible. The shunt is only Bluetooth and its data cannot be read remotely without some sort of host, AKA SA or a Victron Cerbo-type device. The shunt is my validation component, if I ever feel like the data I'm getting from the batteries after a botched firmware update, or something else is odd, I can use the shunt to validate it, and why not have it connected to SA, so that I can see it from my phone/tablet/computer wherever SA is available remotely instead of only while I'm standing near it over it's limited Bluetooth range.Separately, what is the difference to SA from reading Inverter data and the Battery string data (presumably at once) and being able to read the Shunt data? (Wherein your example, it would read, presumably Inverter data and Shunt data at once). Is there something categorically different in the data, as processed by the Pi, that makes "Inverter/Battery" or "Inverter/Shunt" work, but not "Battery/Shunt" or "Inverter/Battery/Shunt"?
So, to boil it down, the "categorical difference" is the comm protocol; RS435 for the batteries, and CANBUS for the inverter. And, SA can only process one protocol on a USB port at a time, hence needing two ports. Makes sense. Thank you.The HUB is only needed because the batteries cannot send their data directly to the inverter, it has no purpose with SA.
No difference, the information flows between each connected battery using the network cable much like a network hub, rebroadcasting the information.
The splitter is used on the "Inverter" so that both SA and the CommHub can talk to the Inverter, not so you can split the battery communication in multiple ways. Both SA and the CommHub are speaking RS435 to the batteries, the CommHum is relaying that data via CANBUS to the Inverter using a separate set of wires/pins. Basically the port on the Sol-Ark, the RJ45 port has certain sets of pins that do different things.
No hub is required when using for example the EG4_LL batteries, they can speak natively to the Sol-Ark inverter. The HUB translates RS435 to CANBUS because the Lifepower batteries do not have this ability in their BMS. The HUB has no purpose for SA, it's just there to tell the inverter what's happening with the batteries. The splitter is there so the single port on the inverter can be used to receive data from the inverter for SA and so that the HUB can send data to the inverter, for whatever design reason this occurs over a single RJ45 port.
I should have never mentioned the shunt, it confuses everyone. I don't "actively" use the shunt, I have it so connected to SA so that I "could" make it the source for battery data and see that in SA, which SA is remotely accessible. The shunt is only Bluetooth and its data cannot be read remotely without some sort of host, AKA SA or a Victron Cerbo-type device. The shunt is my validation component, if I ever feel like the data I'm getting from the batteries after a botched firmware update, or something else is odd, I can use the shunt to validate it, and why not have it connected to SA, so that I can see it from my phone/tablet/computer wherever SA is available remotely instead of only while I'm standing near it over it's limited Bluetooth range.
The LL batteries supposedly have a native ability to talk to a Sol-Ark individually. So as long as each battery is daisy chained to the next and one battery is ultimately connected on the right port to the Sol-Ark, and the batteries are using the correct inverter COMM mode, then the Sol-Ark should see all the batteries individually.I have 5 LL v'2 and I'm regretting it more and more every day. The screens wake up ridiculously slow. I guess the extra warranty will be nice. I will mess around with them this weekend when I get back over to the property but I think I already know the answer. If I have battery 1 speaking directly to the solark 15K on CAN, will battery 1 show up on the SA? I'm waiting on SS to send me a second cable. I figured each battery came with one but no such luck.
message sent. please check.The LL batteries supposedly have a native ability to talk to a Sol-Ark individually. So as long as each battery is daisy chained to the next and one battery is ultimately connected on the right port to the Sol-Ark, and the batteries are using the correct inverter COMM mode, then the Sol-Ark should see all the batteries individually.
Thanks I hope those settings work for my LL batteries. Since the last time I communicated with you on this topic my situation has progressed. I now have my two 15Ks connected to 3 Power Pro’s and my 6 LL V2’s after I updated the firmware for the LL V2’s so that they can communicate with the PP batteries and not void warranty according to EG4 head of R&D.USB Naranda RS485
Then the USB port and that’s it.
Hi, can i ask you to elaborate on your setup? i have 2 x 8kw sunsynks 3 15kwh seplos's bats. Ive set up a trial of Solar assistant and Home assistant. i wanted to get as much battery information as i can into HA/SA without compromising the information given to the inverters. At the moment the batt info is pulled to the inverters via CAN.This is the same config I use with my sunsynk and seplos mason's.
Works extremely well, and will allow extra automation too in combination with home assistant ( water heater on/off , pumps on/off) based on incoming solar and SOC for instance..
Possibilities are almost endless