Open coconup opened 9 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 have the same error:
Sep 30 16:49:37 rpitemp python3[2691]: 16:49:37 INFO [sampling] Bleak version 0.13.1a1
Sep 30 16:49:37 rpitemp python3[2691]: 16:49:37 ERROR [main] 1 exceptions occurred fetching BMSs
Sep 30 16:49:37 rpitemp python3[2691]: 16:49:37 ERROR [main] Error (num 7, max 0) reading BMS: timeout waiting for 3
Sep 30 16:49:37 rpitemp python3[2691]: 16:49:37 ERROR [main] Stack: Traceback (most recent call last):
Sep 30 16:49:37 rpitemp python3[2691]: File "/usr/lib/python3.11/asyncio/tasks.py", line 490, in wait_for
Sep 30 16:49:37 rpitemp python3[2691]: return fut.result()
Sep 30 16:49:37 rpitemp python3[2691]: ^^^^^^^^^^^^
Sep 30 16:49:37 rpitemp python3[2691]: asyncio.exceptions.CancelledError
Sep 30 16:49:37 rpitemp python3[2691]: The above exception was the direct cause of the following exception:
Sep 30 16:49:37 rpitemp python3[2691]: Traceback (most recent call last):
Sep 30 16:49:37 rpitemp python3[2691]: File "/opt/batmon-ha/bmslib/__init__.py", line 81, in wait_for
Sep 30 16:49:37 rpitemp python3[2691]: return await asyncio.wait_for(self._futures.get(name), timeout)
Sep 30 16:49:37 rpitemp python3[2691]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Sep 30 16:49:37 rpitemp python3[2691]: File "/usr/lib/python3.11/asyncio/tasks.py", line 492, in wait_for
Sep 30 16:49:37 rpitemp python3[2691]: raise exceptions.TimeoutError() from exc
Sep 30 16:49:37 rpitemp python3[2691]: TimeoutError
Sep 30 16:49:37 rpitemp python3[2691]: During handling of the above exception, another exception occurred:
Sep 30 16:49:37 rpitemp python3[2691]: Traceback (most recent call last):
Sep 30 16:49:37 rpitemp python3[2691]: File "/opt/batmon-ha/main.py", line 36, in fetch_loop
Sep 30 16:49:37 rpitemp python3[2691]: if await fn():
Sep 30 16:49:37 rpitemp python3[2691]: ^^^^^^^^^^
Sep 30 16:49:37 rpitemp python3[2691]: File "/opt/batmon-ha/main.py", line 319, in fn
Sep 30 16:49:37 rpitemp python3[2691]: raise exceptions[0]
Sep 30 16:49:37 rpitemp python3[2691]: File "/opt/batmon-ha/main.py", line 314, in fn
Sep 30 16:49:37 rpitemp python3[2691]: await t()
Sep 30 16:49:37 rpitemp python3[2691]: File "/opt/batmon-ha/bmslib/sampling.py", line 155, in __call__
Sep 30 16:49:37 rpitemp python3[2691]: s = await self._sample_inner()
Sep 30 16:49:37 rpitemp python3[2691]: ^^^^^^^^^^^^^^^^^^^^^^^^^^
Sep 30 16:49:37 rpitemp python3[2691]: File "/opt/batmon-ha/bmslib/sampling.py", line 237, in _sample_inner
Sep 30 16:49:37 rpitemp python3[2691]: sample = await bms.fetch()
Sep 30 16:49:37 rpitemp python3[2691]: ^^^^^^^^^^^^^^^^^
Sep 30 16:49:37 rpitemp python3[2691]: File "/opt/batmon-ha/bmslib/models/jbd.py", line 75, in fetch
Sep 30 16:49:37 rpitemp python3[2691]: buf = await self._q(cmd=0x03)
Sep 30 16:49:37 rpitemp python3[2691]: ^^^^^^^^^^^^^^^^^^^^^^^
Sep 30 16:49:37 rpitemp python3[2691]: File "/opt/batmon-ha/bmslib/models/jbd.py", line 69, in _q
Sep 30 16:49:37 rpitemp python3[2691]: return await self._fetch_futures.wait_for(cmd, self.TIMEOUT)
Sep 30 16:49:37 rpitemp python3[2691]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Sep 30 16:49:37 rpitemp python3[2691]: File "/opt/batmon-ha/bmslib/__init__.py", line 84, in wait_for
Sep 30 16:49:37 rpitemp python3[2691]: raise asyncio.TimeoutError("timeout waiting for %s" % name)
Sep 30 16:49:37 rpitemp python3[2691]: TimeoutError: timeout waiting for 3
Sep 30 16:49:38 rpitemp python3[2691]: 16:49:38 INFO [sampling] connecting bms JbdBt(10:A5:62:23:B8:B5,jbd1)
Sep 30 16:49:39 rpitemp python3[2691]: 16:49:39 ERROR [bt] [org.bluez.Error.Failed] le-connection-abort-by-local, starting scanner
But I don't have any other application which is communication with the BMS and also the BT interface of the Raspberry Pi Zero 2 W is no used by any other app.
Maybe a protocol implementation error? Can we supply any detailed logs?
I was searching yesterday for more information`s about the BMS which is build into my Vatrer Power 51.2v 100ah LiFePo4 battery - it should be Jiabaida / JBD SP16S020
Informations from Overkill Solar App: Manufacturer: ZJDY Firmware Version: 6.2 Device Name: SP16S020L16S100A
I also found maybe some useful informations on that download page: JDB RS485-RS232-UART-Bluetooth-Communication Protocol
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.