Louisvdw commented 2 years ago

Multiple RS485 modules on the same interface

andzie82 commented 1 year 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.

Louisvdw commented 1 year ago

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.

stanhausc commented 1 year ago

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

ramack commented 1 year ago

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.

maxx8888 commented 1 year ago

I think also JKBMS support it.

Within Settings in Mobile App, there is a setting called: "Device Addr: " within default Value 1

seamaster101 commented 1 year ago

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: @.***>

maxx8888 commented 1 year ago

BMS Type: JK_B2A20S20P HW-Version: V11.XW SW-Version: V11.25 Version: V4.10.1

seamaster101 commented 1 year ago

@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)?

seamaster101 commented 1 year ago

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?

maxx8888 commented 1 year ago

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.

seamaster101 commented 1 year ago

What SW/HW Revision are your units currently?

Where can i check that?

maxx8888 commented 1 year ago

Check my previous post with Picture. Can be found on the Phone App -> Menu -> About

seamaster101 commented 1 year ago

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

seamaster101 commented 1 year ago

@Louisvdw do you think that the RS485 bus communication can be implements soon?

TazerReloaded commented 1 year ago

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?

seamaster101 commented 1 year ago

@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.

TazerReloaded commented 1 year ago

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.

Louisvdw commented 1 year ago

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

ramack commented 1 year ago

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:

nagstaku commented 1 year ago

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.

mr-manuel commented 1 year ago

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.

ats-rozruch commented 1 year ago

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 :)

anaro-nicolas commented 1 year ago

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

ats-rozruch commented 1 year ago

BoardNr

I have PCMonitor 2.1.6 on Tab Engineering Model there is an option to change BoardNumber.

anaro-nicolas commented 1 year ago

Thanks, i test today. Nice day Nicolas

seamaster101 commented 1 year ago

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:

Finding the proper connector to the GPS port of JK BMS (actual TTL level port that supports the RS485 protocol, but needs additional RS485 hardware). After long searches I found the proper connector and a complete cable assembly could be ordered on DigyKey:

https://www.digikey.ca/en/products/detail/molex/2181120400/14309221

Testing TTL-to-485 board. I bought the chipset ones you can find on aliexpess and tested them:

https://www.aliexpress.com/item/1005005265390131.html?spm=a2g0o.productlist.main.35.424bjfjrjfjryd&algo_pvid=17067daa-e993-4711-8cfa-c90938bce72b&algo_exp_id=17067daa-e993-4711-8cfa-c90938bce72b-17&pdp_npi=4%40dis%21CAD%210.62%210.55%21%21%210.45%21%21%40210323f716925456405177406e30d6%2112000032413689146%21sea%21CA%21117876247%21&curPageLogUid=Lfo1tnf9KHuC

the next challenge was that the GPS port send out not 3.3V or 5V but rather the battery voltage, in my case 12-14V but in some other in installations up to 24-28V. I tried fudging it with LDO but unfortunately it was getting too hot as it ah to drop to many volts.
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.

ramack commented 1 year ago

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.

mr-manuel commented 1 year ago

Did you check all open issues? Every help would be very welcome!

Please see #8 (comment)

ramack commented 12 months ago

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)

mr-manuel commented 12 months ago

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.

ramack commented 12 months ago

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?

mr-manuel commented 12 months ago

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.

seamaster101 commented 12 months ago

@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…

mr-manuel commented 12 months ago

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.

seamaster101 commented 6 months ago

@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?

mr-manuel commented 6 months ago

See https://github.com/Louisvdw/dbus-serialbattery/issues/872#issuecomment-1828434571

mr-manuel commented 6 months ago

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.

NorthTown2022 commented 6 months ago

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

TheVodden commented 2 months ago

@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.

mr-manuel commented 2 months ago

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 ;-)

TheVodden commented 2 months ago

@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.

mr-manuel commented 2 months ago

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.

TheVodden commented 2 months ago

Ok I can test this morning (9 am here).

I will let you know how I make out.

mr-manuel commented 2 months ago

BIG NEWS

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

BlueY21 commented 2 months ago

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.

mr-manuel commented 2 months ago

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.

BlueY21 commented 2 months ago

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:

Using this version that supports multiple, identical, paralleled batteries on a single RS485 -USB serial connection, should the MAX_BATTERY_CHARGE_CURRENT and MAX_BATTERY_DISCHARGE_CURRENT values in the config.ini be set to the sum of the values for the connected batteries or the values for the individual batteries?

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.
Would you mind posting the config.ini that you settled on? It would be great to see what settings work best for Renogy batteries.

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 . . .

mr-manuel commented 2 months ago

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!

TheVodden commented 2 months ago

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

mr-manuel commented 2 months ago

@ramack @nagstaku @seamaster101 @maxx8888 @TazerReloaded @andzie82 @ats-rozruch @stanhausc @NorthTown2022 @anaro-nicolas @BlueY21 Are you still interested in this?

Louisvdw / dbus-serialbattery

Multiple RS485 modules on the same interface #142

BIG NEWS