I’ve gotten OpenHab to see my device as an unknown device when I have my phone discoverable, but I cannot get OpenHab to see it when my device is not discoverable. I have the MAC address keyed in as a switch, and the switch works correctly when my phone is discoverable, but not when it’s not.
What’s the trick? I’ve even paired my phone with the Pi using bluetoothctl and it still shows 0 paired devices in range (regardless of the visibility of my phone)… Do I need to use something other than bluetoothctl to do the pairing?
I even tried pairing with the bluez tools, but the phone was already shown as paired because of what bluetoothctl did.
Does your python script require the devices to be paired in order to be seen when they’re not visible? I’ve heard of some python scripts that don’t require pairing, but only the Mac addresses.
Visibility without pairing is what I’d like to see.
It does not require the phone to be paired with the computer. It works great with iPhone 5s, 2014 Moto X, and Moto X PE. It dies notvwork with the iPhone 6 P.
The script works good with my phone (although sometimes it does report the wrong status) when it’s the only bluetooth sensor, but when I start adding the other 3 or 4 phones I’d like to also monitor, it seems to stop working shortly after startup. I get the initial status updates just fine, but then they stop updating. I’ve looked over the code myself, and do not have any idea as to why this would be happening. The code looks great, but I definitely could of missed something. This afternoon I’ll start by adding only 2 total devices, and go from there to see how that does.
Let me know if you find something wrong. I am not a Python programmer by any means and it is always possible to mess something up when working with multi-threaded code in any language.
Edit: One thing you might experiment with increasing the poll period, though I would think 30 seconds would be plenty of time for pyBluez to find the phone if it is there.
I’m working on using a different bluetooth command altogether, and so far, I’m getting positive results. It’s even working now with my wife’s iPhone 6… It’s a little more code overall, but I’m using it in your format, so when I’m done, you should be able to just substitute my bluetoothScanner.py with yours for testing. I just got to weed out the false positives, and I think it’ll be done. So far I have 6 devices configured, and they are all working as desired. And what’s even cooler, is my poll rate is set to 3 seconds!
I’m not very good with GitHub, but I think I just sent you a pull request with my current version of my new file. You should just be able to change the import line in your mqttReporter to point to the new file instead of overwriting the old one just yet.
EDIT: Still seem to be getting some false positives randomly for devices that I know are not in range (bluetooth not even turned on). I’ll see if I can fix that today as well.
I just tried the script and there was a small problem. It had a log statement trying to print out an “item” variable but item was not defined. I updated that to “topic” and it seems to run. No one is home right now so I can’t tell if it is working or not, but I haven’t received any false positives yet.
Ahh, yes… I also made a restReporter and a restConn to use instead of MQTT and I was using item instead of topic. Thought I had changed all of those back to topic before submitting the pull request. If interested, I can show you the rest scripts as well. I would just need to clean up my restReporter a bit first.
I’ve made some minor adjustments… Going to run it for a bit and see how it does… The script was still giving me some false positives every once and awhile…
I’ve let it run all night and it seems to be working pretty well so far. I get an occasional false negative but because I have three instances of it running I get pretty good coverage and that is no different than previous. I’ve not seen a false positive yet.
If you want to check in your rest stuff I’m sure others would find it useful. I know a number of users on this forum prefer using the REST API to MQTT. I’m ambivalent myself. I mainly settled on MQTT because I already had the broker set up from experimenting with the Mqttitude binding so it was easier to get going when I started. The only really nice feature is the Last Will and Testament feature which I’ve found to be much more reliable than Network Health in detecting when one of my Raspberry Pis goes down.
I added two new pull requests for the REST API files needed. You should be able to simply execute the restReporter.py instead of mqttReporter.py with the same config file. The only difference (and we can resolve if needed) is it uses the “Topic” as the OpenHAB “Item” name. If you’d like, you could add a new line to each of the config sensors listing the OpenHAB “Item” so that the topic can remain unchanged. Just let me know, and I can assist with the changes if you’d like.
Also, it looks as if I’ve not had any false readings since my changes, but since I’m not home at this time, I cannot do further testing to make sure the changes I made today have any negative effects. As soon as I get home and can do more testing, I’ll update you here.
I was thinking of changing that to “destination” anyway so it remains generic and handles both cases.
I also think it might be possible to use the same main script and only have to pass around the different comm object. It will take a bit of time to do that though.
When I initially wrote it I figured that MQTT was pretty well supported in Home Automation in general so I was hoping to keep it more general. Though I really don’t expect anyone outside of the OH community to use it. Honestly I didn’t really expect anyone else besides me to use it.
Well, I was actually going to write something myself, but I really liked the way you configured your script so that the one script could handle more than one sensor.
What would be a good replacement name then for mqttReporter that’s still universal? sensorReporter.py?
I can tell you it didn’t start out that way. I initially wrote it to only handle GPIO and everything was in one big file. I used the adding of the Bluetooth sensing as an opportunity to learn me some more Python and I broke it up. Then I tried adding Dash and had to rework it again so the sensor polling would work in separate threads because the ARP sniffing ends up blocking and wouldn’t work with the polling. The Dash support was a good exercise and it improved the script, but I do not find them all that useful, and there is a bug where if one has Dash enabled the script no longer responds to <ctrl>-c.
I like the idea of sensorReporter.py as a name. Though I’ve been toying with the idea of making it work both ways (i.e. receive additional commands beyond the request for update). I have two relays that I currently control using the REST API of WebIOPi which works just fine, but I wonder if it makes sense to consolidate commanding those relays into this script. I’m not certain how easily I can do this in the script’s current structure and I am weary of “when your only tool is a hammer all problems look like nails.” Maybe it makes more sense to create two scripts that can use some of the same code (particularly the comms classes and some of the init code): sensorReporter.py and deviceCommander.py.
Also, it is neither here nor there, but I intend on wiring up a RMF69 transceiver to one of my Pis to act as a gateway to some custom Arduino based sensors and plan on using this script (with a new sensor type) to bridge between the RMF69 and MQTT (and now REST ). That is going to take a lot of time though as I’ve zero experience with Arduino at this point and little spare time.
Overall my goal is to have something lightweight running in satellite devices rather than having multiple instances of OH running all over the place.
I wonder if GitHub allows one to rename their repository…
