-
Notifications
You must be signed in to change notification settings - Fork 195
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
monitor stopped performing scans, bluetoothctl error #312
Comments
I have the same thing, the log shows the following: Running Tried to use this: https://github.com/gadric/monitor/tree/dev-python-bluez because of #295 |
Did you connected your phones via monitor.sh -c <> for rssi? |
No, I have not connected any device with monitor. |
Please try to connect first. I did not modify the script to always measure rssi. |
@gadric my apologies, perhaps your question was not for me - I am not using your fork, just the vanilla monitor script. I am not looking for RSSI measurements. |
Update on this issue: my monitor instance became |
FWIW I have multiple instances of monitor running, two on 0.2.197 and one on 0.2.200. Only the latest version gets the |
@michaelblight helpful feedback. Thanks! |
I'm creating this issue mostly to document a problem I found, in case it happens to someone else.
I noticed after a long period (weeks) of uptime, at some point after a restart of HA and monitor (using an MQTT message to
monitor/scan/restart
), monitor stopped actually scanning and finding my devices.monitor continued to respond to MQTT messages such as
restart
andstatus
, but any time a scan was requested, nothing would be posted back to MQTT - no confidence report messages or anything indicating that the scan happened.The only log entry that I could find that seemed relevant was a message from
bluetoothctl
regarding a source not found. The presence of this message during monitor's startup seemed to correlate with monitor not working.Restarting monitor (using
monitor/scan/restart
) did not fix things, nor did anything else I tried short of a full reboot of my Raspberry Pi.It would be cool if there was a way to trigger a full reboot of the host device that monitor was running on via MQTT, for times where something like this happens. However, this might not be a realistic request: host devices/monitor setups vary considerably, and a simple
sudo reboot
might not always work.The text was updated successfully, but these errors were encountered: