Multiple Seplos via RS485 #652
Comments
|
Multiple devices on one RS485 adapter are not supported yet. See #8 |
|
this is via two adapters not one |
|
Oh ok. That you meaned with indivitually. Only connected one at a time over USB to serial adapter. If you connect both at the same time, with one adapter each it do not work. Is this correct? @wollew maybe you can take a look? |
|
yeah so once the first one is detected the second one gets ignored / either on boot or boot once a second one is connected either as usb0 / 1 / 2 ... it does not matter. the once i am using is shown as : lrwxrwxrwx 1 root root 13 Jan 1 1970 usb-FTDI_FT232R_USB_UART_A9HJMHE8-if00-port0 -> ../../ttyUSB0 in my case ttyUSB0 works just fine - both converters work fine individually - also it does not matter if they come up as ttyUSB 1-7 . both packs have no dip switch enabled - switching between the packs and all various combinations bring the same result if i try to manually start them with ./start-serialbattery.sh ttyUSB7 i am getting -> |
I will ty to look into it, sorry for the delay, it seems I did not get a notification (or I overlooked it). EDIT: I did receive the notification emails but apparently deleted them immediately, my bad. |
|
@schindlerit1984 Are you saying you're getting the above log output when you already have a running (and working) dbus-serialbattery.py on /dev/ttyUSB0 ? And you then manually start python /opt/victronenergy/dbus-serialbattery/dbus-serialbattery.py /dev/ttyUSB7 ? |
|
Also, if you unplug usb-FTDI_FT232R_USB_UART_A9HJMHE8-if00-port0, does the other adapter still show up as something other than ttyUSB0 but then works? |
Yes thats correct. Once the other is disconnected the other one shows up ( Takes Like 1-2 mins ) |
|
So this would mean if we have two separate Python processes using different ttyUSBx it does not work. To me this would mean this is not a problem specific to Seplos but rather at least one level above that. @mr-manuel: Can you confirm we have working examples of the same BMS on more than one separate ttyUSBx? @schindlerit1984 can you provide the output of |
with the newest it shows up in the gui with 2 but one on --- and tail -n 100 -f /data/log/dbus-serialbattery.ttyUSB7/current | tai64nlocal gives constant |
|
I guess you already checked this always happens for the second adapter, no matter which adapter you use as the second one (looking at #652 (comment) you own two different ones) and also no matter which physical BMS is connected to which adapter? If so, I have no idea what could be the issue here because the two python process should not interfere with each other. Would you be able to change the loglevel to DEBUG and then give us the output (check /opt/victronenergy/dbus-serialbattery/utils.py)? Not that I really know how that could help but maybe I'm missing something here. |
|
Yes tried all the various ways. Different Adapter / Same Type Adapter , different cables , swapped them and so on. Checking on the loglevel |
|
sometimes both are there an then 20 secs later one is gone and the other one is there both then end up in checksum error - during loading this happens |
|
reboot gave debug infos - let me check |
|
rebooted with usb0 + 4 now : the moment usb4 goes out it posts 2023-06-05 13:52:15.555094500 DEBUG:SerialBattery:wrote 20 bytes to serial port /dev/ttyUSB4, command=b'~20004644E00201FD34\r' |
|
and then for a longer period posts this : ``` 2023-06-05 13:53:14.445112500 DEBUG:SerialBattery:wrote 20 bytes to serial port /dev/ttyUSB4, command=b'~20004642E00201FD36\r' |
|
To me, this looks like more than one serial batterydriver is trying to read from the same port. into and then restart the driver (you don't need to reboot, it is enough to kill all dbus-serialbattery.py processes)? |
|
done it definitly runs longer in parallel but still second usb ( usb4 goes lost after ~1-2 mins) |
|
after keep trying and trying the second one comes back shortly and dies again ( pulled from the log thats why it looks different) |
|
first one also does with the same error but not in parallel and randomly |
|
So, if the log output in #652 (comment) is complete (what happens between 14:55:25.494761500 and 14:55:25.494761500 ?) we have both PID 3000 and PID 3180 working on the same tty, this cannot work. Are you starting these processes manually or are you getting the messages from the log? |
|
nothing manual - let me restart again and pull the log again |
|
nope keeps doing it and doesnt seem to me that its doing on an other tty |
Not sure what you mean, but in order to read from the BMS you first need to send a command to let it know what information you want, |
|
The backtraces you posted are just a consequence of reading garbled data from the serial port, doesn't really help, sorry. |
|
the 2899 was in log for usb0 and 3073 was for usb4 - currently running for a few minutes with 0 or 4 going out after each other with the same messages seems like the driver restarts - pid changes |
|
thats what i am getting on usb4 the moment it dies and comes back |
|
I am out of ideas, I still suspect "something else" is trying to use the same serial port while it is also used by the dbus-serialbattery/seplos. But this is only a guess, at least according to the logs it is not a second instance of the driver itself. Unfortunately Venus OS doesn't have lsof, so maybe you could try something like and check if something else shows up. |
|
confused as well : did disconnect usb4 earlier now reconnected it again - and so far (fingers crossed) it stays up - already for more then 3-4mins |
|
Well it is definitely possible to get the Seplos BMS into a state where it doesn't reply anymore. Happened a few times during my initial implementation and also just now while fiddling with it. Had to turn it off and on again to make it behave again. |
|
the gps dbus tries to connect to the usb devices |
|
But - current state is that it works in parallel - i will keep an eye on it and report again. gps dbus definitly tries to use the device - saw it in the watch .. command |
|
spoke to soon. its pulling data after doing the disconnect reconnect usb thingy - but does not pull cell voltages and some other details ^^ |
What exactly did you see there?
What exactly do you mean, did you do anything or did it happen automatically? Please post the full log output, ideally including the command that you used to extract that particular output. If you did something in between, please also add what you did. I have to admit it is a little bit hard to follow which of your outputs belong to what action and or file (not that I am currently having a lot of ideas, but still, it doesn't make it easier). One more thing: do you have any idea why your USB TTY numbering changes all the time, do you have any other USB devices connected? It should be consistent if I'm not mistaken but appararently it is not. |
will try to use the device sometimes ( thats from 10h ago). during the night i could see that almost every 30 minutes something is going on that interferes with the usb / rs485 connection. the driver then goes into the checksum error loop on ttyUSB0 - USB1 i was not pulling data via dbus mqtt . usb numbering was changing because the second controller was running via usb hub - i had changed this after you wrote and both come up as usb0 +1 now. i will try to keep an eye on whats going on every 20-30 mins |
|
so its running now since ~3h without any problems. however - what i did was : /opt/victronenergy/gps-dbus/start-gps.sh modified to args="-v --banner --dbus system --timeout 2 -s /dev/ttyUSB9" ( had usb7 before which killed the autodetec from one of the victron mppt´s ) also changed inside the bms/seplos.py the parameter self.poll_interval = 5000 to self.poll_interval = 15000 ( it think this does not have any impact) with the gps change the device has not disappeared anymore . i will keep monitoring and rebooting once in a wile and report back. from my perspective the gps process trying out all the usb´s kills it. maybe the serial driver and dbus serial battery is stuck shortly and the device is "free" again to be tried out for all processes that it goes in a weird mode that serial battery cant take it anymore. |
This is the inverval which is used to poll the data. If the interval is to long, then the serial adapter is free and could be used from other drivers. I'm not sure if this is good, that the driver take 15 seconds to refresh all data. This has to be evaluated. Please try also at least to run the driver without restarting for 2 days. Better would be 7 days. |
|
thanks for the info : if its pulling data only every 5 seconds would this mean that cell voltages are only updated every 5 seconds ? because currently i feel like its faster then that. |
|
Thats correct. Add a message in the log with the battery ID, so you see exactly which battery updates the cell informations with which interval |
|
thanks again for all of your and the teams affords . really appreciate it |
|
You're welcome. Thanks for helping to improve the driver :-) |
|
I just read through https://github.com/victronenergy/venus/wiki/howto-add-a-driver-to-Venus and from what I understand as long as the driver doesn't exit (which it shouldn't as long as we can read valid data) the serial port should not be probed by other drivers. No matter what poll interval is used. That is what confuses me. So right now I don't see any necessary changes to the seplos driver, all the problems seem to lie somewhere outside the seplos part. Do you agree @mr-manuel? Also I was considering making this all a little bit more robust by catching excpetions when reading garbled data, but the aforementioned Victron documentation explicitly states "Which means: don't code too defensively." So I guess I'm gonna leave it as is?! |
|
@schindlerit1984 After reading the docs I gathered that everything that serial-starter does should be logged, maybe you can watch (and post) the output of
|
|
so i think i have found the process that kills it ( it was stable for 6 hours now) fresh after the reboot - dbus battery comes up - gps does something - dbus battery goes down - and so on. i have tried around with the combination of fake usb gps device or real one and there is no change - the only "fix" for now is adjusting the parameter self.poll_interval = 5000 to self.poll_interval = 15000 - ( have not tested how low i can go but its obvious that with 5000 the process gets sucked away by the dbus gpus because maybe some data does not come back and the process is restarted and usb0 +1 is free again. not sure if this helps in any way |
|
That's really weird, as far as I understand after "Start service dbus-serialbattery.ttyUSB1 once" there should not be any more entries in serial-starter for that tty, because dbus-serialbattery on ttyUSB1 would not exit thus no more work for serial-starter for that tty. Can you attach/post the logs of dbus-serialbattery.ttyUSB0 and dbus-serialbattery.ttyUSB1 for that same time frame also? |
mr-manuel
added
enhancement
|
I added some new documentation regarding the serial starter. See https://louisvdw.github.io/dbus-serialbattery/troubleshoot/#no-log-file |
|
Thanks for the added documentation. I'll wait and see if @schindlerit1984 comes up with more logs of the startup. As already stated in #652 (comment), I currently don't see that this is a problem of the driver but rather something outside of it, possibly handling the serial ttys. But we'll see, without any additional information I won't be able to work on it, though. |
|
Will try in the coming days. |
|
@schindlerit1984 any updates on this? |
Describe the bug
Hi,
getting an error when i try to connect two Seplos Batteries individually via Rs485 - two USB Devices and no daisy chaining - individually the work fine - once both are connected only one of them is working.
ERROR:SerialBattery:Unexpected err=SerialException('read failed: device reports readiness to read but returned no data (device disconnected or multiple access on port?)'), type(err)=<class 'serial.serialutil.SerialException'>is what i am getting on the second usb then once first one is running.
any idea how to fix it ? for me its mainly to pull the rs485 infos out of the pack like cell voltages etc.
How to reproduce
Steps to reproduce the behavior:
Expected behavior
hope to get both bms visible - this was only working once a few versions ago ( i am not 100% sure)
Driver version
1.0.20230518dev
Venus OS device type
Raspberry Pi
Venus OS version
3.042
BMS type
Seplos
Cell count
16
Connection type
Serial USB adapter to RS485
Config file
Relevant log output
Any other information that may be helpful
No response
The text was updated successfully, but these errors were encountered: