Good job I’ll start testing and provide some feedback. I was thinking of writing something similar, however in C/C++, because that should theoretically give it the smallest memory/cpu footprint.
I have an Eve door and window Homekit sensor which I was trying to reverse engineer with a view to creating a complnent for, see Elgato Eve door and window Could your app detect when the sensor is pinging a signal? I have a pi 3
Good suggestion.
Actually using home-assistant API is quite efficient to talk to HA. Do you mean that we could be more generic to generate data consumed by other softwares than home-assistant?
If the sensor is advertises in bluetooth, it is very likely that it could work with home_assistant-ble. It would be great if you could try and tell me what’s going well/wrong.
What I mean is that if the separate app would post it’s state changes over MQTT, than it would be more generic to use. For example for use with other home automation systems or MQTT centered installations. I know there are people that build their entire HA solution around MQTT.
You’re right it would more generic.
At the moment this project is a very small glue between bluetooth and home-assistant born to solve the slowness issue on raspberry.
I don’t really plan to make something larger than that unless the issue appears for other home automation systems.
If there is such a need and a good PR I’ll gladly take it.
Unfortunately it’s not clear. I think it’s the underlying library blocking the whole HASS process for too long.
I’ve been running this code for 12 hours and there’s been no issues whatsoever with performance. For this I want to commend @kamaradclimber on the great work he’s done!
Unfortunately it’s not clear. I think it’s the underlying library blocking the whole HASS process for too long.
Exactly. The ble scanner uses gattlib which essentially just execvs gatttool binary with a bunch of options. It may be indeed stalling the loop for far too long. If that is true just putting the scanning in a thread and reaping results from the thread would fix the issue.
I actually seen the very same issue on regular PC running home assistant. I actually needed different scanner type so I implemented my own, that uses thread and the problem was gone. Let me try to fix the existing tracker the same way.
I still thing this will be useful. I plan to throw around some Pi Zeros to detect presence, and I don’t need the features of the room_presence component.
Exactly. The ble scanner uses gattlib which essentially just execvs gatttool binary with a bunch of options
actually I have to take that back. Current tracker really uses gattlib. Gattlib seem to be using C binding and that stalls the loop. I moved everything to a new thread but the problem is still there.
I will try converting it to use bluepy which execs a binary that uses new bluetooth management interface… this is supposedly better way.
Thanks
To be completely frank, I’ve discovered that detection was not perfect yet (at least on my setup). There is a bug to detect properly device out of range that happen to detect my nut mini. I’ll work on that as soon as possible.
No worries, it’s a process! I have some features in mind and I’ll open a pull as soon as I have implemented them - Zone configuration; Supporting updating multiple hass instances.
I just got my nut mini and I’ll give it a shot to debug this. Can you share with me whether you’ve paired your nut with the iPhone app, or just use turned it on and use it as is?
OK. I’ll look into it as well. Is it possible this is due to wi-fi noise? I easily detect ~30 Wi-Fi hotspots where I live and owntracks on my phone had trouble finding my RPi iBeacon 5 meters away.
