Closed brettdaman closed 8 years ago
The info is coming from Bluez cache. You can find it in /var/lib/bluetooth , as far as I remember. This is again a question related to API semantics: what device "seen" means. I think the only reasonable solution is to add richer info, including something like "reachable", "last_seen", etc.
We have changed the behavior to avoid startup problems where we had to manually disconnect devices just to make protocol.BLE see them. When we did this, we intentionally avoided adding a filter based on some kind of "reachability", as we did not have a good definition for what that means.
Adding the richer data would solve the problem for my use case. And I really think that others would find that data useful as well.
A script on my pi uses the call /protocols/devices to sniff for devices in range. then it tries to connect with those devices if they are sensorTags.
Since the last update old devices stay in the list even after a reboot of the pi and a docker rm of the container.
I dont know where the cache is coming from but now I don't know which devices are in range and I can connect with. This is a problem for my use case where The sensorTags can be dynamically added to the setup.