Closed Louisvdw closed 1 month ago
@Louisvdw any updates on this? It would be nice to see multiple batteries in the GUI or at least a fusion on all BMSes to one battery.
see issue #8 Multiplu modules on RS485 is something that only some BMS will be able to handle if their protocol has the ability for address. Most don't. So the multiple modules feature currently will be using a seperate serial connection to each bms. This RS485 enhancement will only be done later.
Hi @Louisvdw.
This drive sees the battery pack as a single battery, but queries all batteries to collect parameters, if you are interested: https://github.com/stanhausc/fzsonic-48tl
For some it is the case - at least from the manual point of view, as I did not yet test it - the YYBMS / Heltec Smart BMS do support it and as I have 4 batteries it would be strange (if not even impossible) to go with 4 USB/RS485 adapters.
So I'd appreciate if this could be implemented.
I think also JKBMS support it.
Within Settings in Mobile App, there is a setting called: "Device Addr: " within default Value 1
I just went to all setting in the Bluetooth app on IOS and did not see that setting. Can you provide picture? I’m doing install with 4 batteries and would like to know if I can set all BMSs with different address. JordanOn Apr 17, 2023, at 23:03, maxx8888 @.***> wrote: I think also JKBMS support it. Within Settings in Mobile App, there is a setting called: "Device Addr: " within default Value 1
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>
BMS Type: JK_B2A20S20P HW-Version: V11.XW SW-Version: V11.25 Version: V4.10.1
@Louisvdw it appears that the very popular JKBMS (on recently purchased bms supposedly latest firmware) now can setup the RS485 address. I tried today two new JKBMSs on the same bus with different addresses, but no luck. I’m planning to connect 4 BMSs so it will be nice to use single rs485 to USB on the RPI side. Do you plan to address the addressing issue (no pun intended ;0)?
BMS Type: JK_B2A20S20P HW-Version: V11.XW SW-Version: V11.25 Version: V4.10.1
@maxx8888 I installed same type of 4xBMS about 6 months ago and this setting did not exist. I just purchased 8 more JKBMS and when I powered up today, I was surprised to see the new setting exactly as on your image! The question now is is it possible to upgrade the FW on the older units to handle RS485 address change? Is there a way to upload new FW to JKBMS?
Not clue if Update would be possible. What SW/HW Revision are your units currently?
Update anyway only makes sense if it is really possible to read multiple Units. That would really be cool also for my project.
What SW/HW Revision are your units currently?
Where can i check that?
Check my previous post with Picture. Can be found on the Phone App -> Menu -> About
Here is the version of fresh JKBMS bought about 2 weeks ago that supports RS485 addressing:
BMS Type: JK_B2A8S20P
HW-Version: V11.XW
SW-Version: V11.261
Version: V4.10.1
@Louisvdw do you think that the RS485 bus communication can be implements soon?
Do you guys use the JKBMS RS485 adapter? I wired my BMS directly to a 3.3V USB-TTL-Adapter, and the communication works fine and looks like RS232 TTL, not RS485. Does that adapter convert the RS232 to RS485?
@TazerReloaded TTL is TTL. It is not 485 or 232. This is why you need/use adapter. You can convert TTL to almost any serial protocol with an adapter. If you want RS485 output you can use TTL to RS485. Then on the other side you can use 485 to usb or 485 to serial or 485 to TTL depending to what are you trying to talk to. RS485 is best for transmitting data over longer cables as it is running on 2 differential wires. I have successfully used cheap $2 TTL to RS485 on the BMS side then long cat 5 cable then RS485 to usb to the RPI. All from AliExpress.
Ah, so you are using a TTL to RS485. I use a TTL to USB directly, because my wire is shielded and only around 2 meters. What I meant is that the TTL signal from the BMS behaves like RS232, two channels (RX/TX) and no differential voltage. So an adapter is needed either way. JKBMS labels the connector as RS485, which is definitely incorrect, because it's 3.3V TTL, and one MAY attach a RS485 adapter there. Sorry for the confusion, just wanted to know why everyone talks about RS485 when the BMS has no RS485 on board.
Chinese lables are sometimes a bit hard to understand. I think a lot has to do with language translation. The port on the JKBMS that is labled RS485 is not a RS485 port. It is the port where you should plug in the JKBMS RS485 module (if that makes more sence).
Here is also some more information on the different type of UART connections. https://louisvdw.github.io/dbus-serialbattery/faq/#which-serial-adaptercable-should-i-use https://louisvdw.github.io/dbus-serialbattery/faq/#which-uart-connection-is-the-best-to-use-ttlrs232rs485
Do you already have an idea how this will be implemented? Is there anything we can help with? Do you have a rough estimate? (is it weeks, months or years ahead?) - It would be so cool to avoid several USB-RS485 converters :wink:
Yeah, I would also be willing to help with this. I have some medium programming abilities, and 2x+ EG4 LifePower Batteries.
I've done a lot of work in C#, but I've touched on Python for some projects. I guess i'll snoop and see what the data structures look like. Maybe someone can tell me ahead of time if this is something where a moderate re-write would be required to represent an array of batteries as a single entity, or if there is already similar patterns in use that could be piggy-backed.
Please see https://github.com/Louisvdw/dbus-serialbattery/issues/8#issuecomment-1566248750
I think it will only work for BMS that are fast enough. The Daly for example is to slow for this in my eyes.
I have using 4 Daly BMS so I added couple lines to daly.py
In declaration
self.board = 0
self.cycle_count = 0
In def refresh_data(self) at the end
self.write_charge_discharge_mos(ser)
// new lines
logger.info("serialbattery current board " + str(self.board) + " cycle count " + str(self.cycle_count))
self.cycle_count = ((int(self.cycle_count) + 1) % 10)
if (int(self.cycle_count)) == 0:
self.board = ((int(self.board) + 1) % 4)
In generate command
buffer[1] = self.command_address[0] + self.board # Always serial 40 or 80
In read sentence
if id != (1 + self.board) or length != 8 or cmd != expected_reply[0]:
Right now my dbus-serial reads 4 different BMS on one RS485 line so mayby it will be possible :)
Hello, I have 2 daly BMS (8s with can/rs485). I can't get them to work on the same RS485 serial bus, and I believe they have the same device address. Should I request a new firmware? With Daly's PC Monitor, I didn't find any configurable parameter to change it. Before modifying the code, I would like to be sure about this. Thank you for your response. best regards - Nicolas
I have PCMonitor 2.1.6 on Tab Engineering Model there is an option to change BoardNumber.
Thanks, i test today. Nice day Nicolas
I'm waiting for the support of multiple batteries on the same RS485 port i I hope it will be available soon. I have RPI with VENUS OS and intend to connect my 4 X 300 AH batteries to it. In order to do that i had to do the following: Open the batteries cases and replace the existing BMSs with JK BMS. I have installed more tan a dozen of these BMSs on other peoples boats and everyone is happy with the results. The BMSs built in in my Pollinovel batteries were absolute crap, and did not balance cells well and then not to mention - "0" customization and "0" support form the manufacturer even to identify to me the make and the model of these BMSs.... here is picture with the battery cracked open and the old BMS about to be removed and thrown out and JK BMS takes its place
there are few challenges:
https://www.digikey.ca/en/products/detail/molex/2181120400/14309221
I designed little motherboard (actually just switching power supply with the proper dimension to avcoomodate the RS485 board and power it) to accommodate the RS485 module and be able to power it with either 3.3V or 5V.
if there is an interest I can make that available on JLCPCB for others to order.
The idea is to have that PS and the RS485 hosted in the battery and connect to the BMS directly with the cable which link was provided above. on the other end we have A+ and B- (true level and protocol) communication. this could be brought to a RS485 to USB adapter connected to the RPI running Venus - one per battery for no until https://github.com/Louisvdw/dbus-serialbattery/issues/142#top is being resolved and then eventually connect all batteries to the same RS485 bus and spare running multiple communication cables form the batteries BMSs to the RPI.
I would really appreciate if someone give us an update of how this issue is progressing and it is in the immediate development plans.
Please let me come back to ask about the status of this... Even if there are BMS types where this could be problematic in terms of timing it would be great to have this.
Today I have a flying wiring with 4 USB-RS485 converters which works but there is a timing bottleneck on the VenusOS side to handle the updates fast enough, so I wouldn't care too much if we couldn't read all systems each second. But it would be quite cool to switch to one USB-interface, the smaller USB hub and the prepared wiring :grinning:
If there is the general interest I can support in implementing and/or testing this, but I would like to invest into it only if the maintainers clearly want to push for it. But my main goal would be to close the battery housings somehow soon (TM), so if there is no chance to get this done and merged by the end of the year, I would prefer to keep the setup as I have and clean it up, even though I technically don't like the big amount of USB-RS485 converters ...
Adding a new battery driver was more or less straight forward, but this one here I cannot do on my own with confidence that I would reach a state acceptable to be merged, so I'd appreciate if @mr-manuel or @Louisvdw could take the lead on this - then I'd happy to help and test.
Did you check all open issues? Every help would be very welcome!
Please see #8 (comment)
Yes, but there it sounds as @Louisvdw would like to have it, while your comments read a bit as if it would be impossible, so I am a bit confused.
Also the other ticket is more general, as it includes the battery aggregation - a great goal but with https://github.com/Dr-Gigavolt/dbus-aggregate-batteries I have a (not perfect but working) soluton for a big part of the problem addressed by the other ticket. So maybe it could be good to do it in two steps and first allow multiple batteries on the same RS485 and later integrate the aggregation into dbus-serialbattery?
Last but not least also over there I don't catch the expected timeline (and yes, I know it's free software done in free time – thanks a lot for all this effort! I don't want to pressure, just ask as I want to decide what to do with my hardware)
Then the goal with this issue is to make visible multiple batteries on the same RS485 line as individual batteries.
Since on every connect it might be that the batteries get random VRM ID's I think this issue should be solved fist: https://github.com/Louisvdw/dbus-serialbattery/issues/718
Then you can cycle through the found BMS and assign them a unused VRM ID.
Yes, the VRM id mapping is an important issue to solve, (maybe before). You introduced already the battery id on the low level for that, didn't you?
Not only maybe, but it has to be done before, else it will create a lot of problems. Yes therefore I introduced the unique_identifier
.
@mr-manuel @Louisvdw thank you guys for all work on this amazing driver! We all really appreciate the great work you’ve done. I myself same as @ramack don't want to pressure, just ask as I want to decide what to do with my hardware. I have to either run 4 wire bundle or one wire bundle to the length of my boat or relocate the RPI running Venus OS. On the other-hand, if this issue is solved it will be so much easier for me and others. Please give us all some timeframe and hopefully some hope…
If this issue is solved, you will never know how it behaves on the long therm. Therefore I would recommend you to wire it for the situation as it is now. Later you can always use less cables then before.
I do not have the possibility to test such a scenario. Therefore from my side there won‘t happen much.
@mr-manuel i finally connected 3 of my 4 batteries to the RPI. They work perfectly well when I directly connect the usb -485 to the RPI usb ports. I try to connect via 4 port USB HUB and I get regular disconnects. Actually to trouble shoot I tried different usb-485 converters and they all behave which makes me believe it is not the converter. The usb to 485 converters don’t use much current so I don’t think is a lack of power to the devices going to the usb hub. What should I do to troubleshoot further?
Then the goal with this issue is to make visible multiple batteries on the same RS485 line as individual batteries.
Since on every connect it might be that the batteries get random VRM ID's I think this issue should be solved fist: #718
Then you can cycle through the found BMS and assign them a unused VRM ID.
Now finally I managed to solve this problem. Now the recognition of multiple BMS on a single RS485 port needs to be managed, but I have not the hardware for it to test. Maybe someone have spare BMS that are not used anymore?
Which BMS are capable of setting a different ID for the RS485 bus?
Are the newest JKBMS, LLT/JBD, Daly and Seplos capable of it? This are the most used once, which I would implement.
Any help in any form is appreciated.
There is a bit of information on setting address here for the new style JK BMS I am trying to gather more information for this particular model: JKBMS Inverter BMS instructions.pdf
@mr-manuel I've got 4 Renogy Smart Lithium batteries that would benefit from this functionality. I currently have these batteries connected on the same channel via RS485.
As mentioned elsewhere, these batteries were all assigned different addresses when managed using a Renogy battery monitor. The default address 247 (0xF7) is replaced with a starting address of 48 (0x30) and each additional connected battery is assigned a consecutively higher address, in my case 0x31, 0x32, and 0x33. I have tested and confirmed this with a direct connection to my computer and a modbus master program.
Initially the driver did not work at all for me. The logs showed that it connected to the battery on 0x30 and returned the model number of the battery, but the next command returned a decoding error with UTF-8 which is the same as this error outlined by mark-1003.
After poking around a bit in the github and looking at code, I removed the 6 lines most recently added (44-46, 131-133) in the renogy.py to add the unique identifier, and made a successful connection to the battery at 0x30.
This is what I have for questions. I apologize for my level of ignorance, as I'm not a programmer, just a hack. I'm thumbing through code with very limited experience, hoping something jumps off the page at me.
How does the unique identifier work? It appears to me that it is trying to retrieve the serial number of the battery to determine which battery it is connected with. I'm having a hard time understanding this, because we are only connecting with one address, (0x30) and all the other batteries are found at different addresses. How are you retrieving additional identifier data if you aren't connecting to the other addresses? If we were looking to different addresses for additional devices, wouldn't it make sense to use the address as the unique identifier?
I tweaked a bit of code in the dbus-serialbattery.py file as well, changing the 0xF7 address to 0x31 for the second Renogy connection address hoping that it will try that address after connecting with my first battery. Unfortunately, it stops trying other connection addresses after finding a successful connection (makes sense....why keep looking), so the second address was never attempted.
It doesn't look like the there is anywhere in the code (there might be, I just cant find it) where it checks other addresses. In order for this to work, you would need to do checks to see if there were other batteries at different addresses, or somehow tell the driver which addresses have batteries.
A few things we could deduce:
-In order for this method to work, a device, likely a Renogy battery monitor, would need to be used to readdress the batteries first. This would automatically set addresses consecutively, as mine were. This would be optimal, as the start address would always be known. (0x30)
-Only if the start address was 0x30, would we need to check additional addresses, which would be '+1' from the last address. These could be checked, and if no response is returned, stop checking.
-If the address of the first battery is 247 (default), the batteries have not been readdressed using a Renogy battery monitoring device, therefore all of the batteries would have the same address and this method wouldn't work, as all batteries would be attempting to respond at the same time.
I would happily help you test iterations of this code.
Hi @TheVodden
The unique identifier is used to make sure that the battery gets always the same VRM ID indipendend of which tty port or modbus address is recognized. This happens sometimes especially with multiple USB to serial adapters. The VRM ID is then used to assign and keep the custom name. https://github.com/Louisvdw/dbus-serialbattery/blob/59a6d00c096c3e708aaf9cd827275c6500450374/etc/dbus-serialbattery/battery.py#L149-L162
Currently one BMS per serial adapter is recognized. The goal of this issue is exactly that, that multiple BMS per adapter are recognized.
Your proposed solution would only work for Renogy. It has to work for all ;-)
@mr-manuel so any idea why the driver was throwing an error with the new code in place, but worked with the code removed?
The log says its a UTF-8 decode error.
Because there is an error in reading the data or the data is corrupt. I added a log entry, so you see what data is received.
I worked the last two days to get this finally done. You can test, if you want: https://github.com/mr-manuel/venus-os_dbus-serialbattery/tree/multiple-batteries-per-serial-adapter
You have to copy the files manually over and then run bash /data/etc/dbus-serialbattery/reinstall-local.sh
. The permissions for the files are corrected automatically.
Since I have not multiple BMS or any BMS with Modbus and a device address I could not test it.
Ok I can test this morning (9 am here).
I will let you know how I make out.
After a lot of effort, many days of rewriting the driver and troubleshooting it's finally available to test. Execute this commands to install this version. Check the config.default.ini
for the configuration.
wget -O /tmp/install.sh https://raw.githubusercontent.com/mr-manuel/venus-os_dbus-serialbattery/master/etc/dbus-serialbattery/install.sh
bash /tmp/install.sh
Select option "4 specific branch" and then "multiple-batteries-per-serial-adapter".
This took lot of hours to implement. Would appreciate a donation, if you find this useful: https://www.paypal.com/donate/?hosted_button_id=3NEVZBDM5KABW
Is it possible to load the "BIG NEWS" version using the USB flash drive method?
I'm excited to test it on a bank of three Renogy RBT100LFP12S (V2)s.
Yes, but why? Have you no internet access or no SSH access?
If you have no SSH access you cannot check the logs, which makes it very difficult to understand what's going on.
I made a pre-release so you can use the USB install method: https://github.com/mr-manuel/venus-os_dbus-serialbattery/releases/tag/v1.3.20240623modbus
Don't forget to prepare your config.ini
with the Modbus addresses, else it won't work. Eventually you have also to set this to true, if your BMS has no unique identifier: https://github.com/mr-manuel/venus-os_dbus-serialbattery/blob/07b10ff13ac040e1311a012655eda274610ce498/etc/dbus-serialbattery/config.default.ini#L419-L423 You would see that in the log output.
Thanks, @mr-manuel My installation is on a boat some distance away. SSH access is inconvenient most of the time and needs to be specifically arranged. (And dbus-serialbattery for just one of my batteries installed easily from a USB flash drive with no need to look at the log.) I'm going to install this version for all three tomorrow. I'll have SSH and Modbus access.
Question:
Question for @TheVodden
Actually, it might help other users and reduce the support load if there was a library on this site of config.ini files configured for many of the batteries/BMSs people are using.
Thanks, again. I just visited your PayPal page . . .
As long as the GX device has internet access you could use Tailscale to access your GX device as it would be on the same network as you are: venus-os_TailscaleGX
Currently there is no way, that the modbus addresses are automatically recognized. I don't know, if that is even possible for different devices, since the process then probably will take a very long time.
The values should always be per battery. Then you need an aggregator to aggregate the batteries as normal. See How to aggregate multiple batteries?
Thank you!
Question for @TheVodden
- What is the Modbus address of the register on your Renogy batteries where you found the 0x30, 0x31, 0x32, and 0x33 device addresses? I plan to check/set mine tomorrow using a Modbus app. I'm thinking that the Renogy BT module I've been using may have set them similarly to your Renogy battery monitor.
The register number is 5223 and it's a holding register.
From what I've read, the BT2 and 485 battery monitor I have readdress the batteries the same, so yours are likely 0x30, 0x31, and 0x32
@ramack @nagstaku @seamaster101 @maxx8888 @TazerReloaded @andzie82 @ats-rozruch @stanhausc @NorthTown2022 @anaro-nicolas @BlueY21 Are you still interested in this?
Multiple RS485 modules on the same interface