Open coconup opened 4 months ago
Update: it appears this is only happening when other processes (in my case in a separate container) access other bluetooth devices.
Does it recover after the timeout?
For the Operation already in progress
issue, did you try bt_power_cycle
?
@fl4p it appears the issue only occurs when some other service is accessing the bluetooth. In my case, I have another container fetching data from my Renogy MPPT controller. Both services (the renogy and batmon
) poll for data every 15 seconds.
It seems when I turn the renogy container off, batmon
works fine and without interruption. If the renogy service is running, batmon
starts showing the behaviour above very quickly. To answer your first question - it never recovers after the timeout and it appears the only way to regain connectivity to the BMS is to restart the bluetooth in my Raspberry Pi. I suspect therefore that some orphan connection is left behind when the timeout occurs, which keeps the BMS's bluetooth busy.
As an additional piece of info, this is the library I am using to communicate with the MPPT controller: https://github.com/cyrils/renogy-bt
That one never seems to lose connectivity because of batmon
running alongside it.
Aah, I have a similar issue that could be due to the same reason - I'm using the victron hacs integration to access my victron mptt controller. Will disable that integration and try it out, not a big deal as the solar isn't producing much at all up in Shetland. But it would be great to have them both working.
I'm running
batmon
in standalone mode through docker as outlined here (on a Raspberry Pi):https://github.com/fl4p/batmon-ha/issues/25#issuecomment-1952473454
This is my
options.json
file:Everything runs smoothly for a few minutes, then suddenly I start getting timeouts and not a single successful update goes through:
Note that the log hangs forever at the last line when this happens. No new logs are ever added
This is how the same scenario looks with verbose logging enabled:
Finally - but this might be an unrelated issue - many times after restarting the container, I get this error:
The only way out of this last issue is a reboot or running
systemctl restart bluetooth
on the host. I suspect when the container restarts, some child process is not terminated.