Daly Smart BMS connections/ LLT BMS communication with venus

Does anyone know the pinout of the connections of these BMS?
Pin 1 is GND on monitor and UART, in RS485 not verified

I need USB UART interface is 3.3V or 5 Volt TTL ?
or need FTDI FT232R with a Zywyn ZT213 RS232 Transceiver
USB to Serial converter or USB to UART TTL ?

I have done tests and only “MONITOR” works for me with sinowealth V0.1 software with USB serial converter. The UART connection does not work with anything … With DALYBMS software it does not work either.

does not work at all, or the BMS is faulty

I have received an email from DALY saying: All bms uart protocol is same one.

Use port label “monitor” in BMS with USB serial CH340 is working on sinowealth software.
In UART port not work any USB device, ch340 or FTDI FT232R
Has anyone had this problem?

A UART is normally either RS232 (12V system) or RS485 (5V system).
The problem is that normal and Chineese usually (I almost said “normally” :slight_smile: ) don’t go together. So you will need to find out what Daly ment with their UART port.

I suggest one of these multi converters like https://www.robotics.org.za/TEL0070 that you can test with until it communicates.
If you know the ground pin, then the next 2 will be RX/TX (you can just test which way around) and the last one will be the positive pin. Don’t connect the positive pin as the BMS and the USB converter will both have power already.

1 Like

Some information from the mails with Daly.

Daly there are two types of BMS

Daly BMS PC software : suitable for R16T, R32S, R32W, R25A, R25T, R32U, R32ND series products

Sinowealth BMS Tool Zhongying PC: suitable for R05C, R05J, R05A, R05U, R05W, R05ND, R10C, R10J, R16J series products

R05/R10 series only use “monitor” conector for PC software —


For the UART port function,it is used for uart cable,bluetooth or touch control screen.

Do you want to use USB to UART function connect with PC ?You insert the wrong port.

UART is used for bluetooth, MONITOR is used for UART cable.

But 3S 4S bms is different from other Daly bms ,when you use,pls consult the seller.

ALL bms uart protocol is same.

For some reason, the 4-pin BT port (GND, RX, TX, 3.3V) on the 4S BMS is not the same as the 6-pin port (GND, 3.3V, x, x, TX, RX) on the 16S BMS;

But the 4-pin port on the 4S Smart BMS is (GND, RX, TX, 3.3V)

The BMS works with sinowealth software and nothing else.

Daly has not been able to send the protocol for this system

I will not waste any more time with this BMS, I will buy another from another brand.

That is a bit strange that the 4cell and 16cell are so different. But good to know all the details now.
The LTT BMS that I originally wrote the driver for has the same protocol for all their smart BMS from 4cells all the way up to 20cells.

1 Like

I have ordered one, until January 6-10 I receive it
I hope it works the first time

it’s strange. But they themselves on their official website have a software (PC) for 3S and 4S and another Daly BMS for the other models. They tell me that the serial protocol is the same, but it is not clear to me.

Another problem that my Daly Smart 4S BMS has is that for the original sinoweatlh program to work with the original CH340 USB, you have to restart the BMS to read the data, then after hours, you have to re-start it to read.

I already received my LTT BMS. I removed the Daly 4S BMS and everything worked perfect, the first time.
The first impression on seeing the BMS, I liked it
On Venus raspberry pi also works perfect.

Now I only have one problem, it does not appear in the device list, the Bluesolar Charge controller. I use an FTDI Serial cable,

I have tried deleting the files from serialbattery and it appears in device list my bluesolar charger.

any idea what the problem is?

If I understand correctly, when you add the serialbattery driver and reboot the GX, then your BlueSolar MPPT is not picked up anymore.
When you remove the serialbattery driver and reboot the GX, then the BlueSolar MPPT returns.

If this is the case then it might be that the GX is setting the BlueSolar to use the serialbattery driver.

Look in your GX at the log files. There should be a log files for each USB port /data/log/dbus-serialbattery.ttyUSB*/current where ttyUSB* is the USB port. Now look at the log for the USB port that the BlueSolar normally use.
There should also be a log file /data/log/vedirect.ttyUSB*/current

These 2 log files should give an idea of what is happening.

USB LLT are in USB0 and same VE-direct USB0

How can I modify it

Move the MPPT to other USB ports and see it it helps.
It is suppose to give you a unique USB port for each device, so this is a bit strange.

Best option imo is to put the MPPT on the VE-Direct port and the BMS on the USB.

I think this is on a Raspberry Pi Venus, but if it is on a GX then what Jaco said would be the best

Sorry, I missed that part…

Yes, it is installed on a Raspberry pi. The USB-Serial converter is the FTDI that I bought with the BMS (black box) and the ve-direct is an FTDI-Serial.
I think the problem is from all the tests I have done, especially with the Daly 4S BMS.
For me the easiest thing is to erase all the sd and record everything again, much faster.

Now with the LLT BMS it is much more stable, the Daly on the first day had 100% SOC, on the second day it marked 86% SOC without having anything connected. Now with this LLT BMS it works better, this is my experience, I see the technical part of the hardware more robust, better made, more aluminum radiator.

A detail that could be improved in the SerialBattery LLT Smart BMS is that when it does not receive data from the BMS, put “Disconnected” on the display.

Now I want to add the ArduinoXiaoxiangSmartBMSDisplay display at the moment I have not tried it, I have problems with the programmer for the Arduino pro mini. When the new programmer arrives, I hope everything works out.

1 Like

OK, checked on 2 different SD cards. Raspberry pi Venus v2.60

In the tests the 2 USB are connected.

Each test reboots the venus

When I copy the serial-starter.d file in the data / conf folder the BMS works and the Bluesolar charger does not work. I delete the serial-starter.d file from the data / conf folder the bluesolar charger works and there is no BMS.
Tested several times and always the same.

It sounds to me as if the bms process does not cleanly exit (after realising it’s not connected to the expected bit of hardware), and because it does not exit, serial-starter cannot continue trying the next driver.

Something you can do to debug, is check what process is running for that terminal. Eg:

root@raspberrypi2:~# svstat /service/*ttyUSB0
/service/vedirect-interface.ttyUSB0: up (pid 1586) 2010402 seconds, normally down

You will likely see multiple services created for the port (because it tries them all in sequence) and only one will run. What should happen, is that if the wrong “driver” is tried for the device, it will run for some seconds, then terminate, and the next one will start. If no driver can handle the device you plugged in, you should see this process repeat continuously in a loop.

For example, if you plug in a VE.Direct usb cable with nothing on the other end, you will see how it repeatedly tries all the drivers one after the other, simply by running the above svstat command repeatedly.

this is the test result:

root@raspberrypi2:~# lsusb
Bus 001 Device 004: ID 0403:6001 Future Technology Devices International, Ltd FT 232 Serial (UART) IC
Bus 001 Device 005: ID 0403:6001 Future Technology Devices International, Ltd FT 232 Serial (UART) IC
root@raspberrypi2:~# ls -l /dev/serial/by-id
lrwxrwxrwx 1 root root 13 Jan 1 1970 usb-FTDI_FT232R_USB_UART_AB0LIA8S-if00-port0 -> …/…/ttyUSB0
lrwxrwxrwx 1 root root 13 Jan 1 1970 usb-FTDI_USB_Serial_Converter_FTB6SPL3-if00-port0 -> …/…/ttyUSB1

Without serial-starter.d file (ve.direct works)
root@raspberrypi2:~# svstat /service/*ttyUSB0

/service/dbus-cgwacs.ttyUSB0: up (pid 19575) 1 seconds, normally down

/service/dbus-fzsonick-48tl.ttyUSB0: down 25 seconds

/service/dbus-imt-si-rs485tc.ttyUSB0: down 20 seconds

/service/dbus-modbus-client.serial.ttyUSB0: down 15 seconds

/service/gps-dbus.ttyUSB0: down 7 seconds

/service/vedirect-interface.ttyUSB0: down 3 seconds

copy file serial-starter.d file to data / conf
root@raspberrypi2:~# svstat /service/*ttyUSB0

/service/dbus-fzsonick-48tl.ttyUSB0: down 69 seconds

/service/dbus-imt-si-rs485tc.ttyUSB0: down 60 seconds

/service/dbus-modbus-client.serial.ttyUSB0: down 49 seconds

/service/dbus-serialbattery.ttyUSB0: up (pid 1630) 46 seconds


BMS works and the Bluesolar is missing
delete serial-starter.d
Bluesolar works and BMS is missing
with the USB interface of the BMS removed from the rasperry and the file serial-starter.d in data / conf the device list Bluesolar charger does not appear.

file serial-starter.d

alias default vedirect work Blue solar charger
alias default sbattery work LLT BMS

I have tried, but it doesn’t work either. add
service sbattery dbus-serialbattery
service vedirect vedirect-interface

Do the tests with both ttyUSB0 and ttyUSB1.

When you plug in a second usb device, the numbering may change. Your solar charger may move on to USB1.

So what you want to see is:

/service/dbus-serialbattery.ttyUSB0: up (pid 1630) 46 seconds

and also

/service/vedirect-interface.ttyUSB1: up 31 seconds

Or something like that.

If the solar charger is not being correctly detected, then we will probably see some other device hanging on to it. This is what we’re trying to figure out.

Other tests.
Format SD card
Install version venus v2.60
install LLT Smart Battery files
and the same problem.

Only the BMS LLT appears in the device list

Before copying the files and modifications in Venus, the Bluesolar Charger MPPT 150/35 worked correctly
Delete serial-starter.d and Bluesolar Charger MPPT 150/35 worked correctly

Well, this isn’t Windows. This is Linux. when something is wrong, repeating the same old steps usually don’t lead to different results. You have to figure out what is wrong…

My suspicion is that the serialbattery driver is tried on the MPPT and it does not properly terminate. The rule for serial-starter “drivers” is that if they cannot drive the hardware, ie they don’t detect what they expect, they should terminate after a few seconds so the next “driver” can have a go.

All these instructions about running svstat is to see which process is running (ie holding on) to ttyUSB0 and ttyUSB1.

The USB interface of the BMS is new and I never connected to the ve-direct, it is another connector.

I think something strange is happening

The two USB connected and without the serial-starter file in / conf

root@raspberrypi2:~# svstat /service/*ttyUSB0

/service/vedirect-interface.ttyUSB0: up (pid 1310) 193 seconds, normally down

root@raspberrypi2:~# svstat /service/*ttyUSB1

/service/dbus-cgwacs.ttyUSB1: down 9 seconds

/service/dbus-fzsonick-48tl.ttyUSB1: down 3 seconds

/service/dbus-imt-si-rs485tc.ttyUSB1: up (pid 3803) 2 seconds, normally down

/service/dbus-modbus-client.serial.ttyUSB1: down 25 seconds

/service/gps-dbus.ttyUSB1: down 17 seconds

/service/vedirect-interface.ttyUSB1: down 12 seconds

The two USB connected and with the serial-starter file in / conf

root@raspberrypi2:~# svstat /service/*ttyUSB0

/service/dbus-serialbattery.ttyUSB0: up (pid 1877) 2 seconds

root@raspberrypi2:~# svstat /service/*ttyUSB1

/service/dbus-cgwacs.ttyUSB1: down 116 seconds

/service/dbus-fzsonick-48tl.ttyUSB1: down 105 seconds

/service/dbus-imt-si-rs485tc.ttyUSB1: down 95 seconds

/service/dbus-modbus-client.serial.ttyUSB1: down 86 seconds

/service/dbus-serialbattery.ttyUSB1: up (pid 1676) 82 seconds

The only possibility is a problem with the Chinese USB FTDI Serial Converters.

I removed original USB Serial TTL and I test with other USB RS485, same problem, only work sbattery.

Multiple USB converters, TLL and RS485 cannot fail. And it is a new installation on the SD card of the Venus 2.60 version. something strange happens
root@raspberrypi2:~# svstat /service/*ttyUSB1
/service/dbus-serialbattery.ttyUSB1: up (pid 1295) 626 seconds
root@raspberrypi2:~# svstat /service/*ttyUSB0
/service/dbus-serialbattery.ttyUSB0: up (pid 4036) 1 seconds
it does not work