[monitor] Reliable, Multi-User, Distributed Bluetooth Occupancy/Presence Detection

Klagio · March 15, 2019, 8:38am

This morning all instances were stopped (or at least were not broadcasting mqtt messages), tried the publishing of the restart topic but had no effect. I went manually with SSH in each monitor host and restart the service

Which is the best way to restart it, let’s say with an automation/script (NOT with the publishing of monitor/scan/restart (sometimes is not working) but calling sudo systemctl restart monitor?

something like this?

shell_command:
  restart_monitor1: ssh user:[email protected] /monitor/monitor.sh

or

binary_sensor:
  - platform: command_line
    command: 'sudo systemctl restart monitor"

?

Also, without looking at an mqtt listener, what is another way to check that the instances are running correctly in front end?

daneboom · March 15, 2019, 8:42am

Help request:
Had a power cut round this neck of the woods on Wednesday and Monitor has since stopped reporting to HA. The Pi it runs on is still accessible and responding. It’s been restarted a couple of times. How would I go about debugging what might be at fault rather than just restarting the service or running it direct from the command line? I’d like to know what isn’t working if poss. Thank you!

andrewjfreyer · March 16, 2019, 3:59am

I posted an important structural update that should fix a lot of the outstanding issues.

Still working through a few others. Stay tuned!

andrewjfreyer · March 16, 2019, 4:02am

Pushed an update that permits blank usernames.

andrewjfreyer · March 16, 2019, 4:02am

Probably you caught a beta update in the middle of a few bug fixes I was working on. Update please.

Klagio · March 16, 2019, 8:20am

I still struggle to send systrmctl restart monitor.service from another host. I did SSH key between the two host, but that is not enough for calling systectl restart. I guess solution is a server/client monitor
I think I solved my second question (knowing that monitor instance is up and running or not) , having this binary_sensor below.

  - platform: mqtt
    state_topic: "monitor/pioffice/status"
    payload_on: "online"
    payload_off: "offline"
    device_class: connectivity
    name: Office monitor

johnflorin · March 16, 2019, 10:03am

Updated, looks good so far, thanks!

Tinkerer · March 16, 2019, 11:13am

> error: minimum required mosquitto_sub version 1.5+ not found. please update.
> error: minimum required mosquitto_pub version 1.5+ not found. please update.

Details for upgrading Mosquitto on Raspbian are included in the updated README. I’ll admit I found those after I’d already upgraded Mosquitto following instructions found via Google

Klagio · March 16, 2019, 11:31am

may I just change the file monitor.sh (as you know I modified it as per previous posts) ?

EDIT: Found how to

git checkout support/mqtt
sudo git pull origin master

Klagio · March 16, 2019, 1:10pm

@andrewjfreyer thank you again for this tool: I tried all router based, all gps based, even happy-bubbles ble based), presence detection, and failed with all of them

Your component, once well setup for each individual habitat, is the only component, IMO, working

benjimatt · March 16, 2019, 4:09pm

I used sshpass to take care of this. This is just what I do FYI, Not the best way

I have a folder called “shell” in my .homeassistant\ folder. (im using a docker instance) Within the folder there is a file titled “RestartBluetooth.sh”
within the file

#!/bin/bash
sshpass -p password ssh -oStrictHostKeyChecking=no [email protected] sudo systemctl restart monitor.service

this is using

shell_command:
  restart_bluetooth: "bash /config/shell/RestartBluetooth.sh"

Klagio · March 16, 2019, 4:29pm

fantastic, great, thanks.

You use one file to restart all of them? I would create 4 files (I have 4 hosts), trying to understand how shell_command works with 2+ commands. Below gives error

EDIT found the error below correct config

shell_command:
    restart_ble_guest: "bash /config/shell/restart_ble_guest.sh"
    restart_ble_living: "bash /config/shell/restart_ble_living.sh"

benjimatt · March 16, 2019, 5:36pm

technically I do this for a different script. Just modified it for your use. My instance of monitor has been pretty consistent so I really havn’t needed to add this hard restart.

FOR ME Location/Scan/Restart works every time… right now im on 0.1.959

I really havent had a reason to upgrade from 0.1.959 (maybe ill update today)

Actually ill update now, cant really help people if im running this old of a version

johnflorin · March 16, 2019, 6:44pm

Hmm, strange, mine exited now with this message: “monitor.sh: line 1536: -0043120201040106648983106050954696659: value too great for base (error token is “0043120201040106648983106050954696659”)”

andrewjfreyer · March 16, 2019, 7:42pm

That’s an unusual error that shows an misinterpretation of an rssi value. I have not seen this in my own experience. I pushed an update that will filter a bad RSSI reading.

johnflorin · March 16, 2019, 7:44pm

Much appreciated, updated!

johnflorin · March 16, 2019, 8:21pm

Hmm, strange, after this latest update it saw my gf’s Tile as Away a couple of times (then corrected itself 2 mins later each time)…this is what the wrong scan result looked like:

monitor/tile_scan/TILEMAC/device_tracker not_home
monitor/tile_scan/TILEMAC
{
“id”:“TILEMAC”,
“confidence”:“0”,
“last_seen”:“1552767066”,
“retained”:“false”,
“timestamp”:“Sat Mar 16 2019 20:15:51 GMT+0000 (GMT)”,
“version”:“0.2.068”
}

Klagio · March 17, 2019, 10:58am

thanks a lot. Yes I will also use for other services, I was looking for such a solution since long time: its pretty cool that from HASS we can call almost anything on a linux machine

markwalker5 · March 17, 2019, 11:32pm

Hi all,

Just wanted to see what everyone is using for the confidence config now. I’m still using the original NodeRed flows from @andrewjfreyer original setup, but I was just looking at the read me with the simple Min-Max sensor (and reading the thread) and thinking that the flows maybe are overcomplicated now?

benjimatt · March 18, 2019, 9:59am

@andrewjfreyer
quick question

when i was on .0195 the only that that was happening was a trigger on a passed filter and expiring bluetooth nodes.

Now there seems to be a lot of reported rssi’s on devices that arent in any of my lists. Is there anyway I can ignore these devices? Im talking about the drifing, slow moving approach, slow moving depart… (fyi none of the mac’s below are mine)

Further more it seems the google flag that I have being block is still being passed. Is my filter still correct.

PREF_FAIL_FILTER_ADV_FLAGS_ARRIVE="NONE"

PREF_FAIL_FILTER_MANUFACTURER_ARRIVE="google|august|microsoft|samsung"


-- Logs begin at Thu 2016-11-03 13:16:44 EDT. --
Mar 18 05:50:48 blue1 bash[16489]: 0.2.066 18-03-2019 05:50:48 am [CMD-RAND]        [passed filter] data: 4E:19:32:42:9E:5B pdu: ADV_SCAN_IND rssi: -69 dBm flags: none man: unknown delay: 0
Mar 18 05:51:08 blue1 bash[16489]: 0.2.066 18-03-2019 05:51:08 am [CMD-RSSI]        PUBL 08:66:98:CA:84:F5 RSSI LOG: -89 dBm (slow movement depart) 
Mar 18 05:51:12 blue1 bash[16489]: 0.2.066 18-03-2019 05:51:12 am [CMD-RAND]        [passed filter] data: 4F:58:D3:E3:20:2A pdu: SCAN_RSP rssi: -72 dBm flags: none man: Google delay: 2
Mar 18 05:51:20 blue1 bash[16489]: 0.2.066 18-03-2019 05:51:20 am [CMD-RAND]        [passed filter] data: 7D:91:AF:91:76:3B pdu: ADV_IND rssi: UKN dBm flags: 0x1a man: Apple, Inc. delay: 0
Mar 18 05:51:24 blue1 bash[16489]: 0.2.066 18-03-2019 05:51:24 am [CMD-RSSI]        PUBL B8:78:2E:45:C2:94 RSSI LOG: -97 dBm (drifting) 
Mar 18 05:52:02 blue1 bash[16489]: 0.2.066 18-03-2019 05:52:02 am [CMD-RSSI]        PUBL B0:C0:90:8C:EF:71 RSSI LOG: -105 dBm (drifting) 
Mar 18 05:52:06 blue1 bash[16489]: 0.2.066 18-03-2019 05:52:06 am [DEL-RAND]        RAND 4E:3F:27:A1:F8:A7 expired after 182 seconds 
Mar 18 05:52:19 blue1 bash[16489]: 0.2.066 18-03-2019 05:52:19 am [CMD-RSSI]        PUBL 08:66:98:CA:84:F5 RSSI LOG: -76 dBm (slow movement approach) 
Mar 18 05:52:19 blue1 bash[16489]: 0.2.066 18-03-2019 05:52:19 am [CMD-RSSI]        PUBL B8:78:2E:45:C2:94 RSSI LOG: -94 dBm (drifting) 
Mar 18 05:52:20 blue1 bash[16489]: 0.2.066 18-03-2019 05:52:20 am [CMD-RSSI]        PUBL 50:32:37:CC:E5:23 RSSI LOG: -88 dBm (drifting) 
Mar 18 05:52:42 blue1 bash[16489]: 0.2.066 18-03-2019 05:52:42 am [CMD-RAND]        [passed filter] data: 73:30:B1:D1:3C:33 pdu: ADV_SCAN_IND rssi: -71 dBm flags: none man: unknown delay: 0
Mar 18 05:52:49 blue1 bash[16489]: 0.2.066 18-03-2019 05:52:49 am [DEL-RAND]        RAND 47:ED:A2:DC:03:D9 expired after 214 seconds 
Mar 18 05:53:00 blue1 bash[16489]: 0.2.066 18-03-2019 05:53:00 am [CMD-RSSI]        PUBL B0:C0:90:8C:EF:71 RSSI LOG: -101 dBm (drifting) 
Mar 18 05:53:24 blue1 bash[16489]: 0.2.066 18-03-2019 05:53:24 am [CMD-RSSI]        PUBL 50:32:37:CC:E5:23 RSSI LOG: -91 dBm (drifting) 
Mar 18 05:53:26 blue1 bash[16489]: 0.2.066 18-03-2019 05:53:26 am [CMD-RSSI]        PUBL 50:32:37:CC:E5:23 RSSI LOG: -96 dBm (drifting) 
Mar 18 05:53:29 blue1 bash[16489]: 0.2.066 18-03-2019 05:53:29 am [DEL-RAND]        RAND 72:4B:59:4F:F5:62 expired after 193 seconds 
Mar 18 05:53:31 blue1 bash[16489]: 0.2.066 18-03-2019 05:53:31 am [CMD-RSSI]        PUBL B8:78:2E:45:C2:94 RSSI LOG: -96 dBm (drifting) 
Mar 18 05:54:02 blue1 bash[16489]: 0.2.066 18-03-2019 05:54:02 am [CMD-RAND]        [passed filter] data: 53:51:2F:03:E8:12 pdu: ADV_IND rssi: -74 dBm flags: 0x02 man: unknown delay: 0
Mar 18 05:54:05 blue1 bash[16489]: 0.2.066 18-03-2019 05:54:05 am [CMD-RSSI]        PUBL 08:66:98:CA:84:F5 RSSI LOG: -86 dBm (slow movement depart)