Can it be useful to daisy chain all batteries in a NONE Closed Loop setup?

[fmeili1]

I try to understand if it would make sense or may it have advantages in an open loop setup (no BMS communication with inverters/chargers) if I daisy chain the batteries.

Some additional information about my setup:

• My setup consists out of 9x EG4-LL-V2 and 3x EG4-LL-S batteries - a total of 12 batteries with 60kWh
• I've decided not to go the closed loop way (if this is useful or not is a separate discussion).
• I've attached all batteries via separate RS485 cables to passive RS485 HUBs and also connected SolarAssistant (SA) via RS485 to one HUB. Monitoring via SA of all 12 batteries works great and if have no issues.
• Because SA can only monitor the EG4 batteries (via Modbus RS485 protocol) if the first battery starts at address #2. SA does not support the EG4 batteries with the so called "address 1 protocol" and therefore the fist battery needs to be at address #2, the next battery #3, etc.
• Currently neither my CAN ports nor my Battery-Comm ports are used

I ask myself, what would happen if I would daisy chain all my 12 batteries via the Battery-Comm ports (but still no closed loop communication)?

• Would all 12 batteries shutdown if just one would detect a failure (e.g. BMS over/under voltage, temp, current, etc.)?
• Would it be possible to just connect the first battery (address #2) to SA to be able to monitor all of them?
• Would it be possible to E-stop all 12 batteries by just connecting a separate "E-Stop button (or dry contact relay)" to the first Battery-Comm port? Btw. With a specific firmware the older EG4-LL (V2) models are also able to use the E-Stop feature - I've double checked that with EG4 support.
• Would a different monitoring solution (eg. Victron Cerbo GX) be able to monitor all batteries if just connected to the first battery's CAN bus port?
• Would configuration changes to the first battery (address #2) automatically replicated to all other batteries?
• Something else?

Any ideas?

 

[fmeili1]

No one?

It seems that no one in the forum has any idea about my questions?

Does anyone have the E-Stop mechanism of an EG4-LL-S battery working with an external emergency stop switch (not connected to an internal inverter RSD), like described in the manual (ideally without closed-loop-communication)?

 

[Quattrohead]

No but I don't see why it shouldn't work, it's just a 12 volt control signal.

 

[fmeili1]

No but I don't see why it shouldn't work, it's just a 12 volt control signal.

Is it just a switch (NO) which has to be connected between pins 3 & 6, like this on the first battery?


Or do I need to feed 12V between the pins 3 & 6 to trigger the emergency stop?

 

[gotsolar]

I try to understand if it would make sense or may it have advantages in an open loop setup (no BMS communication with inverters/chargers) if I daisy chain the batteries.

Some additional information about my setup:

• My setup consists out of 9x EG4-LL-V2 and 3x EG4-LL-S batteries - a total of 12 batteries with 60kWh
• I've decided not to go the closed loop way (if this is useful or not is a separate discussion).
• I've attached all batteries via separate RS485 cables to passive RS485 HUBs and also connected SolarAssistant (SA) via RS485 to one HUB. Monitoring via SA of all 12 batteries works great and if have no issues.
• Because SA can only monitor the EG4 batteries (via Modbus RS485 protocol) if the first battery starts at address #2. SA does not support the EG4 batteries with the so called "address 1 protocol" and therefore the fist battery needs to be at address #2, the next battery #3, etc.
• Currently neither my CAN ports nor my Battery-Comm ports are used

I ask myself, what would happen if I would daisy chain all my 12 batteries via the Battery-Comm ports (but still no closed loop communication)?

• Would all 12 batteries shutdown if just one would detect a failure (e.g. BMS over/under voltage, temp, current, etc.)?
• Would it be possible to just connect the first battery (address #2) to SA to be able to monitor all of them?
• Would it be possible to E-stop all 12 batteries by just connecting a separate "E-Stop button (or dry contact relay)" to the first Battery-Comm port? Btw. With a specific firmware the older EG4-LL (V2) models are also able to use the E-Stop feature - I've double checked that with EG4 support.
• Would a different monitoring solution (eg. Victron Cerbo GX) be able to monitor all batteries if just connected to the first battery's CAN bus port?
• Would configuration changes to the first battery (address #2) automatically replicated to all other batteries?
• Something else?

Any ideas?

Regarding the statement below:

• Btw. With a specific firmware the older EG4-LL (V2) models are also able to use the E-Stop feature - I've double checked that with EG4 support.

Can you share EG4's response? Which firmware and where to get it?
Thank you.

 

[fmeili1]

Regarding the statement below:

• Btw. With a specific firmware the older EG4-LL (V2) models are also able to use the E-Stop feature - I've double checked that with EG4 support.

Can you share EG4's response? Which firmware and where to get it?
Thank you.

I've contacted @EG4TechSolutionsTeam in an personal message and I've got this feedback after I told them about @Markus_EG4 message in this thread where he mentioned, that it's possible to use the LL-2 firmware with the LL-V2 and will have RSD feature.

I was informed that this is the firmware for the LL V2 and LL-S, ID:4 and ID:6 batteries that will allow them both to communicate and also have RSD.

Also, the file is too large to upload to the forum so here is a link:

Dropbox​

www.dropbox.com

I've not yet updated my batteries firmware and no testing from my side so far but I want to do it if I'll find time (I have a mix of 9x EG4-LL-V2 (4-DIP-Switch) and 3x EG4-LL-S which I want to use with a manual E-Stop button (and a remote controlled relay in parallel to enable a remote shutdown also).

update:
Just wanted to upload the file in the resource section, but it's too large to put it in the resource section (121MB zip)

 

[gotsolar]

Thank you for the details. I have 6x EG4LL-V2 and also want to enable a manual E-Stop button. I will try to update my batteries and test them as soon as I find time.

 

[fmeili1]

Thank you for the details. I have 6x EG4LL-V2 and also want to enable a manual E-Stop button. I will try to update my batteries and test them as soon as I find time.

Please give feeback how they work. Do you use an external E-stop button or do you connect the batteries to an inverter's RSD connector?

 

[gotsolar]

I have 2x EG4-6500EX (no E-stop capability). I plan to add a shutdown button to stop power to the Tigo RSS transmitter and close the battery-coms pins 3 and 6 to activate battery E-stop. This would stop all sourced of power to the EG4-6500EX (they are not connected to the grid AC). That assumes (1) EG4-LLV2 will support E-stop with the firmware update and (2) to trigger E-stop directly with the battery all you need to do is close the battery-coms pins 3 and 6.

 

[gotsolar]

I updated my 6 x LL-V2 to firmware version Z02T18 (the same firmware as LL-S). I did both the RS232 and RS485 firmware updates. The batteries are working fine and BMS Tools confirms all batteries are running Z02T18.

Using a multimeter, I measured the voltage between Battery-Comm port pins 3 and 6. On my LL-V2 batteries, the voltage between pins 3 and 6 fluctuates below +-5mV. I was expecting to see a fixed signal/voltage that one could short to trigger RSD. That does not seem to be the case. I tried shorting these two pins and nothing happened. I also tried applying 5V through a 4.7K resistor to raise the voltage of pin 3 relative to 6 and vice versa (in case one of these pins is being monitored by an IO input to detect a logic level). Nothing happened.

I am guessing that pins 3 and 6 of the LL-V2 are not wired the same way as the ones in LL-S. I do not have access to a LL-S battery to compare how these pins react on the LL-S.

If LL-V2 hardware does not support pins 3 and 6 to trigger RSD, we need to find out the required closed loop command to trigger RSD/E-stop.

 

[fmeili1]

I updated my 6 x LL-V2 to firmware version Z02T18 (the same firmware as LL-S). I did both the RS232 and RS485 firmware updates. The batteries are working fine and BMS Tools confirms all batteries are running Z02T18.

Using a multimeter, I measured the voltage between Battery-Comm port pins 3 and 6. On my LL-V2 batteries, the voltage between pins 3 and 6 fluctuates below +-5mV. I was expecting to see a fixed signal/voltage that one could short to trigger RSD. That does not seem to be the case. I tried shorting these two pins and nothing happened. I also tried applying 5V through a 4.7K resistor to raise the voltage of pin 3 relative to 6 and vice versa (in case one of these pins is being monitored by an IO input to detect a logic level). Nothing happened.

I am guessing that pins 3 and 6 of the LL-V2 are not wired the same way as the ones in LL-S. I do not have access to a LL-S battery to compare how these pins react on the LL-S.

If LL-V2 hardware does not support pins 3 and 6 to trigger RSD, we need to find out the required closed loop command to trigger RSD/E-stop.

I've planning exact the same setup (including Tigo PVRSS) and hoped it would work like you've already tried (but no spare time right now). Maybe SS support can help to answer the question how to wire an external RSD button to LL-V2.

 

[gotsolar]

According to EG4TechSolutionsTeam (see below), LL-V2 with Z02T18 firmware only supports RSD through closed loop BMS communication. I requested information on the specific closed loop command to trigger RSD.

Below is this thread: https://diysolarforum.com/threads/new-eg4-rack-battery-eg4-ll-s-now-with-e-stop.70657/page-2

 

[MainerUSNR]

I hope this is the correct thread, but here goes. I have two EG4 LL V2 48v batteries, they are communicating with a EG4 6000XP (which has E-Stop). If I am understand things correctly, if I attach a E-Stop external switch for firefighters to the inverter, the inverter will shut the batteries down, even though the batteries are not LL-S, yes?

 

[gotsolar]

According to EG4TechSolutionsTeam (see below), LL-V2 with Z02T18 firmware only supports RSD through closed loop BMS communication. I requested information on the specific closed loop command to trigger RSD.

Below is this thread: https://diysolarforum.com/threads/new-eg4-rack-battery-eg4-ll-s-now-with-e-stop.70657/page-2

View attachment 265171

After several messages to EG4TechSolutions begging for information on the specific closed loop command to trigger RSD on LL-V2 with Z02T18 firmware, their response was the usual: "Unfortunately, we are unable to provide the command line at this time."

 

[fmeili1]

After several messages to EG4TechSolutions begging for information on the specific closed loop command to trigger RSD on LL-V2 with Z02T18 firmware, their response was the usual: "Unfortunately, we are unable to provide the command line at this time."

I've just double checked the EG4-LL battery modus protocol spec (I've downloaded this many month ago from EG4 website and uploaded a copy to the resource section - it's gone in the meantime from the EG4 website).
There is nothing mentioned in this spec regarding RSD feature. I've searched for keywords RSD, shutdown, rapid, breaker, but no hit. The spec. release is v01.06 with a date of 06-21-2017 (started with revision v01.01 on 04-21-2015). It looks like my spec is outdated and does not yet cover the RSD features. I have no idea where a newer spec could be downloaded.

 

[gotsolar]

I've just double checked the EG4-LL battery modus protocol spec (I've downloaded this many month ago from EG4 website and uploaded a copy to the resource section - it's gone in the meantime from the EG4 website).
There is nothing mentioned in this spec regarding RSD feature. I've searched for keywords RSD, shutdown, rapid, breaker, but no hit. The spec. release is v01.06 with a date of 06-21-2017 (started with revision v01.01 on 04-21-2015). It looks like my spec is outdated and does not yet cover the RSD features. I have no idea where a newer spec could be downloaded.

Yeah, that EG4-LL battery MODBUS protocol spec (v01.06 from 2017) seems too old to include the RSD feature. The RSD feature was introduced recently with the EG4 LL-S battery.

It would be great if someone out there with an EG4 6000XP inverter (or any other EG4 inverter that supports the RSD feature) connected to EG4 LL-S batteries could look at the communication between them when pressing the RSD button. Unfortunately, my inverters (EG4 6500EX) do not support the RSD feature.

By the way, I verified most of that MODBUS protocol spec using 6 x EG4 LL-V2 batteries.
Below are comments for some apparent discrepancies and some additional registers that are not listed in that document.

Existing Registers with Apparent Discrepancies
0027: (2 bytes) The value "0x1000: Low Capacity" was set for each battery when they reached 100% SOC. Should this be “0x1000: Full Capacity” instead, as an indication that the battery is fully charged?

0120 to 0127: (16 bytes) This is supposed to be the Product Serial Number listed as a 16-byte string. However, from two observations (before and after upgrading 6 batteries from firmware Z02T05 to Z02T18), these registers contained the *date* of the firmware as a 16-byte string. BMS Tolls also reported the Serial Number as the date strings below. The Product Serial No. shoud have nothing to do with firmware version or date. This should be the battery (hardware) serial number instead.

• Z02T18: Serial number = 2024-01-04
• Z02T05; Serial number = 2022-11-14

New Registers found
Note: In my setup, it was observed that the Host/Master Battery (id = 1) periodically sends read request commands to the batteries with id 2 to 6 using pins 1&2 of the Battery-Comm port at 19,200 baud. A read command is sent to the next battery after ~50ms has passed since the previous battery response. The read commands are for registers 0000 to 0044. That is how I found registers 0039 to 0044. These registers must have some meaning for the Host/Master Battery (id = 1).

0039: (2 bytes) Always returned 0x0064 = 100
0040: (2 bytes) Always returned 0x0007 = 7
0041: (2 bytes) Always returned 0x0FFF = 4095
0042: (2 bytes) Always returned 0x07FF = 2047
0043: (2 bytes) Always returned 0x000F = 15
0044: (2 bytes) Always returned 0x0005 = 5

0045 to 0046: (4 bytes) Date and Time
All 6 batteries returned the same date consistent with the current London timezone. The time was also consistent with the current London time, but the batteries listed different minutes and seconds, i.e., their minutes and seconds were not in sync.
This was found by reading registers beyond 0044.

Encoding
Bits 0-5 (6 bits): Second (0 to 59)
Bits 6-11 (6 bits): Minute (0 to 59)
Bits 12-16 (5 bits): Hour (0 to 23)
Bits 17-21 (5 bits): Day (1 to 31)
Bits 22-25 (4 bits): Month (1 to 12)
Bits 26-31 (6 bits): Year (2000 to 2063) (value is from 0 to 63 - add 2000).

The encoding is consistent with the “Date and Time bits Table” of this document: Search web online for
“1xSxxP_ESS_485 protocal_rev _23_20171128”. Note that this document can be used as good hints for the interpretation of the MODBUS protocol used by the EG4 LL-V2 Host/Master (id=1) battery.

 

[gotsolar]

I hope this is the correct thread, but here goes. I have two EG4 LL V2 48v batteries, they are communicating with a EG4 6000XP (which has E-Stop). If I am understand things correctly, if I attach a E-Stop external switch for firefighters to the inverter, the inverter will shut the batteries down, even though the batteries are not LL-S, yes?

The information we have from EG4TechSolutionsTeam (see below) is that EG4 LL-V2 48V batteries updated to Z02T18 firmware should shutdown when pushing the RSD button on the side of the EG4 6000XP inverter. However, I have not seen anyone confirming this. I do not have EG4 6000XP to test this.