Either restart the pi, or simply take the interface offline and bring it back. I would also recommend changing the name_timeout to something larger than 5 seconds, effectively disabling the feature.
To refresh the bluetooth interface:
sudo hciconfig hci0 down && sudo hciconfig hci0 upHi @DamianFlynn - I think I have a workable solution for this feature that pairs in neatly with other needed improvements. My alpha version right now is able to detect anyone approaching our house that has a bluetooth LE device (phone, fob, etc). That said, these will be anonymous; BTLE only advertises with anonymous addresses. Working on making these more useful, but right now they’re a great trigger to search for new devices.
I had this working nicely… but started to get all sorts of problems with HASS - components not being found, HASS going down completely and requiring re-powering the pi.
Gone once I stopped the mqtt beacons. Anyone else have this?
Now you have me intrigued…
I see the same behaviour on a Netgear PLW1100. Did you ever figure out why ?
I also experience a lot of lag in terminal when ssh’ing to the Pi Zero W.
Yes, it’s all Bluetooth and WiFi interference. Solution incoming.
Thanks Andrew, it’s a brilliant script you’ve done.
I currently have a setup where I use the presence.sh script for detecting iPhones and Apple Watches, works well. On the sideI have a Room Assistant running for iBeacons (placed in the kids school bags). I consider using presence.sh for the iBeacons as well, any thoughts on how RA and presence.sh compares ?
Thanks for the kind words! The good news is that the next version of the presence script will include full support for iBeacons and other BTLE sensors. Room Assistant is great software, and was an inspiration for the script. I found, however, that since it was limited to BTLE devices, accurate presence detection was difficult to achieve.
Hi, thanks for the ideas. I had restarted the pi several times without success already. I also have an Intel NUC which I got to work after removing behavior_preferences files and get it created from scratch. Will try the same with the Pi tomorrow.
Lars
Thanks, I’ve pushed the numbers up and it seems to be OK now. Great to hear that you have a fix on the way, would love to be able to put those numbers back down and speed up the presence detection. I’m going to test with -t1 and -t2 on my door reed and motion sensors, hopefully I can speed detection up that way.
I left it running last night with beacon mode enabled to track a Tile BTLE Beacon.
Looks like that could be the cause of it crashing?
Active: active (running) since Tue 2018-05-08 21:41:56 UTC; 10h ago
Main PID: 211 (bash)
CGroup: /system.slice/presence.service
├─ 211 /bin/bash /home/pi/presence/presence.sh &
├─8799 /bin/bash /home/pi/presence/presence.sh &
├─8800 sudo timeout --signal SIGINT 10 hcitool lescan --duplicates
├─8804 timeout --signal SIGINT 10 hcitool lescan --duplicates
└─8805 hcitool lescan --duplicates
May 09 00:26:48 raspberrypi sudo[8697]: pam_unix(sudo:session): session opened for user root by (uid=0)
May 09 00:26:58 raspberrypi sudo[8697]: pam_unix(sudo:session): session closed for user root
May 09 00:27:29 raspberrypi sudo[8731]: root : TTY=unknown ; PWD=/home/pi/presence ; USER=root ; COMMAND=/usr/bin/timeout --signal SIGINT 10 hcitool lescan --duplicates
May 09 00:27:29 raspberrypi sudo[8731]: pam_unix(sudo:session): session opened for user root by (uid=0)
May 09 00:27:39 raspberrypi sudo[8731]: pam_unix(sudo:session): session closed for user root
May 09 00:28:13 raspberrypi sudo[8765]: root : TTY=unknown ; PWD=/home/pi/presence ; USER=root ; COMMAND=/usr/bin/timeout --signal SIGINT 10 hcitool lescan --duplicates
May 09 00:28:13 raspberrypi sudo[8765]: pam_unix(sudo:session): session opened for user root by (uid=0)
May 09 00:28:23 raspberrypi sudo[8765]: pam_unix(sudo:session): session closed for user root
May 09 00:28:54 raspberrypi sudo[8800]: root : TTY=unknown ; PWD=/home/pi/presence ; USER=root ; COMMAND=/usr/bin/timeout --signal SIGINT 10 hcitool lescan --duplicates
May 09 00:28:54 raspberrypi sudo[8800]: pam_unix(sudo:session): session opened for user root by (uid=0)
~
~
lines 1-21/21 (END)
name_scan_timeout=5
delay_between_owner_scans_away=10
delay_between_owner_scans_present=30
verification_of_away_loop_size=6
verification_of_away_loop_delay=5
beacon_scan_interval=10
beacon_scan_enabled=1
Will try running in debug now.
Ran for an hour before freezing again:
livingroom/owner/living room/DE:66:F4:50:80:47 { confidence : 0, name : Unknown, scan_duration_ms: 5077, timestamp : Wed May 09 2018 09:51:32 GMT+0000 (UTC)}
DEBUG MSG: Scanning for 0 guest devices between owner scans (no owner device is present).
DEBUG MSG: Remainder of delay before next owner scan: 10
DEBUG MSG: Scan result: []
livingroom/owner/living room/F0:EE:10:53:18:27 { confidence : 0, name : Unknown, scan_duration_ms: 5077, timestamp : Wed May 09 2018 09:52:02 GMT+0000 (UTC)}
DEBUG MSG: Scan result: []
livingroom/owner/living room/DE:66:F4:50:80:47 { confidence : 0, name : Unknown, scan_duration_ms: 5090, timestamp : Wed May 09 2018 09:52:12 GMT+0000 (UTC)}
DEBUG MSG: Scanning for 0 guest devices between owner scans (no owner device is present).
DEBUG MSG: Remainder of delay before next owner scan: 10
Have now disabled beacon mode and removed the MAC from the owners. Will run it again in debug mode.
Sounds good, Andrew - looking forward to giving it a - you expect to be done soon?
Struggling with an MQTT problem while setting this up. My broker is locally hosted Mosquitto running within my Hassio instance. It accepts anonymous connections, but I have put a username and password on it for Presence to connect to. I have other devices working happily with it at the moment - a cloudMQTT bridge and an ESP device.
If i SSH into my pi zero I can see the following:
xyz@raspberrypi:~ $ journalctl -u presence.service
-- Logs begin at Thu 2018-05-10 00:02:19 UTC, end at Thu 2018-05-10 00:03:07 UTC. --
May 10 00:02:27 raspberrypi systemd[1]: Started Presence service.
May 10 00:02:29 raspberrypi bash[211]: Error: Network is unreachable
May 10 00:02:30 raspberrypi bash[211]: Error: Network is unreachable
And my Mosquitto log repeats the following lines repeatedly:
1525910591: New connection from 192.168.1.123 on port 1883.
1525910591: New client connected from 192.168.1.123 as mosqpub|540-raspberrypi (c1, k60, u'xyz').
1525910591: Client mosqpub|540-raspberrypi disconnected.
MQTT_preferences looks like this:
mqtt_address="192.168.1.126"
mqtt_user="xyz"
mqtt_password="a valid password"
mqtt_topicpath="location"
mqtt_room="frontdoor"
Any ideas?
What happens when you use mosquitto_pub on the presence server?
xyz@raspberrypi:~/presence $ mosquitto_pub -h 192.168.1.126 -p 1883 -t 'michael/location' -m 'derp' -d
Client mosqpub|13814-raspberry sending CONNECT
Client mosqpub|13814-raspberry received CONNACK
Client mosqpub|13814-raspberry sending PUBLISH (d0, q0, r0, m1, 'michael/location', ... (4 bytes))
Client mosqpub|13814-raspberry sending DISCONNECT
and I see the sensor tied to “michael/location” change to derp in the HA front end…
Seems like the issue is with authentication? Will presence run without authentication?
Yes. Password and Username should be blank strings.
Hi ! Awesome work !
Got it working and commented out the line calling mosquito as I don’t need MQTT
Did you think about implemeting it on SmartThings ? I would like to push notifications to a virtual device on Smartthings. Would you guide me on what I need to do ?
Sorry, I just don’t understand what different this solution and happy bubble or other bluetooth/ble based solution?
Any advantage than https://github.com/mKeRix/room-assistant
This is mentioned in the first few paragraphs of the original post, but the gist is that room-assistant does not detect phones (since phones do not broadcast non-random beacon packets) and is reliant on BTLE beacons, which were not reliable or fast in my experience.