EG Lifepower (Narada battery that uses Tianpower BMS) - Multi battery setup problems

[Gerno082]

Describe the problem

Good day everyone,

I have 4x Narada 48NPFC50 batteries that use a TianPower ND1502 BMS, so this uses the lifepower BMS driver

I have 2 problems: problem 1: The driver only works if the battery DIP switches are set on address 0x01 problem 2: Getting the driver to communicate with multiple batteries

I have tried both the stable branch and the nightly build with no luck.

Problem 1: If I set the battery DIP switches to address 0x01, then the driver correctly detects and communicates with the battery.

In the code, I found that the 0x01 address is the default for the lifepower BMS, so to test communication with different addresses, I changed the address to 0x00 and 0x02. But if I change the battery DIP switches to 0x00 or 0x02 the driver reads the serial number correctly, but then communication fails, see the extract from the log file below:

2024-08-04 18:39:15.868081500 INFO:SerialBattery:Testing EG4_Lifepower at address "\x02" 2024-08-04 18:39:15.921082500 INFO:SerialBattery:Hardware Version:BA01A77I06230168t 2024-08-04 18:39:16.186051500 ERROR:SerialBattery:>>> ERROR: No reply - returning 2024-08-04 18:39:16.451566500 ERROR:SerialBattery:>>> ERROR: No reply - returning

This was tested with only one battery connected.

Problem 2: It appears that the Lifepower batteries use a master/slave setup to communicate, then the driver only talks to the master BMS. In the Narada manual it also describes a similar master slave setup, but with the master set to address 0x00. However, I have the Tianpower PC software, and if I set it to communicate with multiple batteries, it just talks directly to the different batteries by changing the address, and not through the master.

If I can get the driver to communicate with the batteries at all 4 addresses, then the code can be adapted to communicate with each battery separately at different addresses. Alternatively I can use x4 USB-RS485 converters and a USB hub and all the battery DIP switches on address 0x01, but that is not a very elegant solution, I would rather take some time to implement a better solution.

I am not sure if the master/slave type setup is possible with my batteries and I don't have an easy way to test it at the moment.

Any advice would be appreciated, thanks

Driver version

1.4.20240721dev

Venus OS device type

Raspberry Pi

Venus OS version

v3.33

BMS type

Life/Tian Power

Cell count

15

Battery count

4

Connection type

Serial USB adapter to RS485

Config file

[DEFAULT]

; If you want to add custom values/settings, then check the values/settings you want to change in "config.default.ini"
; and insert them below to persist future driver updates.

; Example (remove the semicolon ";" to uncomment and activate the value/setting):
; MAX_BATTERY_CHARGE_CURRENT = 50.0
; MAX_BATTERY_DISCHARGE_CURRENT = 60.0

Relevant log output

2024-08-04 18:42:46.574533500 INFO:SerialBattery:Testing EG4_Lifepower at address "\x01"
2024-08-04 18:42:46.637733500 INFO:SerialBattery:Hardware Version:BA01A77I06230168v
2024-08-04 18:42:46.787743500 INFO:SerialBattery:Firmware Version:3LM-M01A-ND577-21.B2.00-180611
2024-08-04 18:42:46.938351500 INFO:SerialBattery:Connection established to EG4_Lifepower
2024-08-04 18:42:47.506375500 INFO:SerialBattery:Found existing battery with DeviceInstance = 3
2024-08-04 18:42:47.701746500 INFO:SerialBattery:DeviceInstance = 3
2024-08-04 18:42:47.702901500 INFO:SerialBattery:PID file created successfully: /var/tmp/dbus-serialbattery_3.pid
2024-08-04 18:42:47.703344500 INFO:SerialBattery:Used DeviceInstances = ['1', '2', '3', '4']
2024-08-04 18:42:47.703818500 INFO:SerialBattery:com.victronenergy.battery.ttyUSB0__0
2024-08-04 18:42:47.739347500 INFO:SerialBattery:publish config values = False
2024-08-04 18:42:47.752725500 INFO:SerialBattery:Polling data every 2.000 s
2024-08-04 18:42:47.752731500 INFO:SerialBattery:Battery EG4 Lifepower connected to dbus from /dev/ttyUSB0
2024-08-04 18:42:47.752736500 INFO:SerialBattery:========== Settings ==========
2024-08-04 18:42:47.752739500 INFO:SerialBattery:> Connection voltage: 50.04 V | Current: 0.0 A | SoC: 100.0%
2024-08-04 18:42:47.752744500 INFO:SerialBattery:> Cell count: 15 | Cells populated: 15
2024-08-04 18:42:47.752747500 INFO:SerialBattery:> LINEAR LIMITATION ENABLE: True
2024-08-04 18:42:47.752864500 INFO:SerialBattery:> MIN CELL VOLTAGE: 2.900 V | MAX CELL VOLTAGE: 3.450 V| FLOAT CELL VOLTAGE: 3.375 V
2024-08-04 18:42:47.752946500 INFO:SerialBattery:> MAX BATTERY CHARGE CURRENT: 50.0 A | MAX BATTERY DISCHARGE CURRENT: 60.0 A
2024-08-04 18:42:47.754807500 INFO:SerialBattery:> CVCM:     True
2024-08-04 18:42:47.754812500 INFO:SerialBattery:> CCCM CV:  True  | DCCM CV:  True
2024-08-04 18:42:47.754816500 INFO:SerialBattery:> CCCM T:   True  | DCCM T:   True
2024-08-04 18:42:47.754819500 INFO:SerialBattery:> CCCM SOC: False | DCCM SOC: False
2024-08-04 18:42:47.756365500 INFO:SerialBattery:> CHARGE FET: None | DISCHARGE FET: None | BALANCE FET: None
2024-08-04 18:42:47.756372500 INFO:SerialBattery:Serial Number/Unique Identifier: BA01A77I06230168v_54.04Ah

2024-08-04 18:39:15.868081500 INFO:SerialBattery:Testing EG4_Lifepower at address "\x02"
2024-08-04 18:39:15.921082500 INFO:SerialBattery:Hardware Version:BA01A77I06230168t
2024-08-04 18:39:16.186051500 ERROR:SerialBattery:>>> ERROR: No reply - returning
2024-08-04 18:39:16.451566500 ERROR:SerialBattery:>>> ERROR: No reply - returning

Any other information that may be helpful

No response

[mr-manuel]

The driver has to be the master and the batteries the slave. Once you are successful in connecting single batteries with different addresses you can try it by daisy chain it. I hope this can help you.

[Gerno082]

Makes sense, I will focus on communication with different addresses. Do you have any suggestions on what I can try? I have spent a few days fiddling with the code and trying different branches. I would expect the only change I have to make is to the lifepower address in the dbus-serialbattery.py file?

{"bms": Lifepower, "baud": 9600, "address": b"\x02"},

But then I only get the hardware version as shown in the snippet above.

Thank you

[mr-manuel]

Yes that is correct. You could check, if there is a error somewhere in the protocol (https://github.com/mr-manuel/venus-os_dbus-serialbattery__additional-info) and ask the manifacturer for help.

[Gerno082]

I have tested some additional addresses and found that all uneven addresses work: 0x01, 0x03, 0x05, 0x07.

For now, I will use this this as a workaround to get a solution running.

The next step is to get the driver to communicate with multiple batteries. Currently the driver stops searching for new batteries after the first one has been found. Does such an implementation exist yet? If not, how would you recommend I implement this, create x4 battery objects that each connect to a specific battery?

[mr-manuel]

Just check the config.default.ini.

https://github.com/mr-manuel/venus-os_dbus-serialbattery/blob/526c87550e593a57e2c6d8d6f10ea688af066cad/etc/dbus-serialbattery/config.default.ini#L135-L141

[oabarzua]

Hello, I have a similar problem with Narada 48NPFC100 batteries when modifying this part of the code:

; --------- Modbus (multiple BMS on one serial adapter) ---------
; Description:
;     Specify the modbus addresses as hexadeximal number for which a dbus-serialbattery instance should be started.
;     If left empty, the driver will connect only to the default address specified in the driver.
; Example:
;     MODBUS_ADDRESSES = 0x30, 0x31, 0x32, 0x33
MODBUS_ADDRESSES =

and wanting to put the addresses, the gx cerbo is giving alarms of loss of communication with bms. try with 0x01, 0x02, 0x03, 0x04. I also tried the Narada ones 0x01, 0x10x 0x11, 1x00 and I can't solve the problem, but if I leave it blank it recognizes only 1 module

[Gerno082]

I just got mine to work, I just have to sort out some bugs with the battery aggregator

I believe your addresses are incorrect.

0x means hexadecimal number format (base 16) and the dip switches are in binary (backwards).

so for dip switches 1000 (which is sortof binary for 1), relates to 0x01 0100 means 2, so address 0x02 and so on: 1100 -> 0x03 0010 -> 0x04 1010 -> 0x05 0110 -> 0x06 1110 -> 0x07 0001 -> 0x08

for my setup, I used the following dip switches and addresses: 1000 -> 0x01 1100 -> 0x03 1010 -> 0x05 1110 -> 0x07

These addresses are also in the Narada manual.

Here is an online calculator for binary to hex, just note that the dip switch positions are flipped: https://www.rapidtables.com/convert/number/binary-to-hex.html

Hope this helps

[mr-manuel]

@Gerno082 may it be, that the first dip switch is not working and therefore only odd numbers work? Have you tried to set 4, but connect to 5? Would be curious, if it's a "mechanical" or software issue.

[Gerno082]

I will play around with the DIP switches and test that theory, but i tested address 0x02 on 3 of my 4 batteries.

I can connect my PC directly to each battery with the Tianpower software to test all the different addresses to see if the dip switches work.

[mr-manuel]

It could also be, that the first dip switch is for something other. The other three could be used for 8 addresses. Can you post a picture of the dip switches and the manual for others?

[oabarzua]

In my case I have the dips like this in that sequence in the same order from battery 1 to 4

[oabarzua]

I just got mine to work, I just have to sort out some bugs with the battery aggregator

I believe your addresses are incorrect.

0x means hexadecimal number format (base 16) and the dip switches are in binary (backwards).

so for dip switches 1000 (which is sortof binary for 1), relates to 0x01 0100 means 2, so address 0x02 and so on: 1100 -> 0x03 0010 -> 0x04 1010 -> 0x05 0110 -> 0x06 1110 -> 0x07 0001 -> 0x08

for my setup, I used the following dip switches and addresses: 1000 -> 0x01 1100 -> 0x03 1010 -> 0x05 1110 -> 0x07

These addresses are also in the Narada manual.

Here is an online calculator for binary to hex, just note that the dip switch positions are flipped: https://www.rapidtables.com/convert/number/binary-to-hex.html

Hope this helps

With the configuration you made it worked for me and it recognized the 4 batteries, but now the GX cerbo in the vrm portal disconnects it due to overload. real-time connection disabled due to overload of the GX device

[oabarzua]

Hello, good afternoon, in the meantime, trial and error when checking each battery in an odd way and putting it in the cerbo, they all come out like this and marking the error:

[oabarzua]

please help

[mr-manuel]

@oabarzua your problem is not related to this issue. Open a new one and provide all requested data.

[mr-manuel]

@Gerno082 did you made some progress?

[Gerno082]

Not yet, I was working on the rest of the system to have it running within the next few weeks.

I see there is another issue that is related, I can try to get some additional debug information from the driver if that will help. Where would you suggest I start debugging/what information would you like to see?

[mr-manuel]

Would be interesting, if this commands match: https://github.com/mr-manuel/venus-os_dbus-serialbattery/blob/60eca4c86a0e86debbd8e7c0a2a898d87e9735a5/etc/dbus-serialbattery/bms/eg4_lifepower.py#L16-L18

Maybe the lenght for even addresses is different.

[Gerno082]

I will have a look when I get home later today.

[Gerno082]

I got mine to work on addresses 0x00 and 0x02. I read the output of the Tianpower software for different addresses. The commands are diferent for even addresses:

0x00: 7E 01 01 00 00 0D
0x02: 7E 02 01 00 FC 0D
0x04: 7E 04 01 00 F8 0D
0x06: 7E 06 01 00 FC 0D
0x08: 7E 08 01 00 F0 0D
0x0A: 7E 0A 01 00 FC 0D
0x0C: 7E 0C 01 00 F8 0D
0x0E: 7E 0E 01 00 FC 0D

for uneven addresses up to 15 is always 7E (address) 01 00 FE 0D

I don't see a definitive pattern. The Tianpower software also doesn't request the hardware and firmware versions until a connection is established, so those might also be different. I can test this at a later stage if necessary.

@mr-manuel I can send you the Tianpower software if you would like to look at the output.

Hope this helps

[mr-manuel]

The checksum does not make any sense to me, which should be the 5th byte.

[mr-manuel]

What if you set the 5th byte to \x00 or \xFF? Could you try that?

Change this code https://github.com/mr-manuel/venus-os_dbus-serialbattery/blob/60eca4c86a0e86debbd8e7c0a2a898d87e9735a5/etc/dbus-serialbattery/bms/eg4_lifepower.py#L16-L18

to

        self.command_general = b"\x7E" + address + b"\x01\x00\x00\x0D"
        self.command_hardware_version = b"\x7E" + address + b"\x42\x00\x00\x0D"
        self.command_firmware_version = b"\x7E" + address + b"\x33\x00\x00\x0D"

[Gerno082]

Ok, I will try that when I get home

Here is the software if you would like probe the output in the meantime

ND1502 2020-11-04 -V1.1.634-32-17.zip

[Gerno082]

I tried your suggestions on battery addresses 0x00 and 0x02 by changing the 5th byte of the general, hardware and firmware commands to either 0x00, 0xFF or the corresponding value I got from the Tianpower software

For address 0x00 the 5th byte had to be 0x00 (0xFF did not work)

For address 0x02 the 5th byte had to be 0xFC (0x00 and 0XFF did not work)