Nice case.
Just following up on this (it has been awhile since the MOL has been to the house). When I run the hcitool it returns no response. Have you seen this behavior before? Is it a matter of the iOS version?
Edit: just updated her phone to iOS 12 and itās still happening. Reports the status and then when the screen turns off, goes to zero.
I think iāll adopt this implmentation instead much more simplified.
What is āLocation/scan/restartā?
This calls a restart to all nodes in the topic path. It basically does
Sudo systemctl restart monitor.service
On all of your nodes
Excellent didnāt know that was possible!
I didnāt know this either - sounds perfect?! Like an arrive scan and a depart scan all in one?!
Yeah, I dont think that was the Intentā¦ But for me it works well because there are still random times where one of my sensors isnt reporting correctly. This way I know that they will most likely be correct once the automatic restart happens. Honestly since its just calling a systemctl restart I feel that it shouldnt have a negative affect.
Poyfect!! Love it.
I trying to get the only departure on mqtt trigger to work with my motion sensor. But even though I ssh into monitor and then sudo bash monitor.sh -td
and have set PREF_MQTT_REPORT_SCAN_MESSAGES=true
it wont work.
I tried with going into my sensor in HA, turn off my bluetooth on my phone to simulate a drop off or weak signal. And even then the sensors slowly starts to go to 0% confidence. Shouldnāt this only happen when Iāve triggered mqtt monitor/scan/DEPART
in node red?
my PREF_MQTT_REPORT_SCAN_MESSAGES is set to False. but i dont think that matters.
A follow up to my previous post.
When I woke up this morning I turned off Bluetooth on my phone and same result, phone sensor 0%. But now when I left home for work and my phone sensor in HA is still on 100%. How is that? Whatās the difference? Anyhow - I guess my mqtt departure trigger in node red isnāt working.
False is default but read somewhere earlier in the thread that I should have that as true with mqtt dept trigger. Hm
Is there a docker container available for this?
Have you searched the thread?
I have search the thread, nothing more then a suggestion.
Try this
sudo bash monitor.sh -d -td -u
This will also change the service file. I just checked my instance and I happen to be using -trd because I want the other piās to send depart triggers also.
@andrewjfreyer
These are the logs with Both of my devices home already for several hours.
Oct 17 10:06:54 blue2 bash[16460]: 0.1.675 10:06:54 am [CHECK-DEL] 5D:55:D1:93:AB:D3 expired after 55 seconds
Oct 17 10:06:55 blue2 bash[16460]: 0.1.675 10:06:55 am [CHECK-DEL] 42:E1:10:2B:85:6F expired after 51 seconds
Oct 17 10:06:55 blue2 bash[16460]: 0.1.675 10:06:55 am [CHECK-DEL] 4D:A9:59:DE:4C:0B expired after 53 seconds
Oct 17 10:06:55 blue2 bash[16460]: 0.1.675 10:06:55 am [CHECK-DEL] 66:89:3E:18:B1:71 expired after 52 seconds
Oct 17 10:06:55 blue2 bash[16460]: 0.1.675 10:06:55 am [CHECK-DEL] 68:2C:65:00:44:5F expired after 56 seconds
Oct 17 10:06:55 blue2 bash[16460]: 0.1.675 10:06:55 am [CHECK-DEL] 71:E4:FA:B1:A8:F5 expired after 56 seconds
Oct 17 10:06:55 blue2 bash[16460]: 0.1.675 10:06:55 am [CHECK-DEL] 5C:66:37:0D:F3:16 expired after 61 seconds
Oct 17 10:06:55 blue2 bash[16460]: 0.1.675 10:06:55 am [CHECK-DEL] 70:89:B5:D2:F4:9B expired after 50 seconds
Oct 17 10:06:56 blue2 bash[16460]: 0.1.675 10:06:56 am [CHECK-DEL] 7B:49:10:17:38:CA expired after 59 seconds
Oct 17 10:06:56 blue2 bash[16460]: 0.1.675 10:06:56 am [CHECK-DEL] 4D:F6:6B:20:11:CD expired after 47 seconds
Oct 17 10:06:56 blue2 bash[16460]: 0.1.675 10:06:56 am [CHECK-DEL] 7C:56:C3:AC:A4:51 expired after 50 seconds
Oct 17 10:07:01 blue2 bash[16460]: 0.1.675 10:07:01 am [CMD-RAND] 5D:55:D1:93:AB:D3 ADV_NONCONN_IND -94 dBm
Oct 17 10:07:03 blue2 bash[16460]: 0.1.675 10:07:03 am [CMD-RAND] 71:BC:26:EB:42:AE ADV_IND -87 dBm
Oct 17 10:07:05 blue2 bash[16460]: 0.1.675 10:07:05 am [CMD-RAND] 5C:66:37:0D:F3:16 ADV_IND -92 dBm
Oct 17 10:07:07 blue2 bash[16460]: 0.1.675 10:07:07 am [CMD-RAND] 42:E1:10:2B:85:6F ADV_NONCONN_IND -94 dBm
Oct 17 10:07:08 blue2 bash[16460]: 0.1.675 10:07:08 am [CMD-RAND] 5B:7A:8A:AC:9D:59 ADV_NONCONN_IND -92 dBm
Oct 17 10:07:10 blue2 bash[16460]: 0.1.675 10:07:10 am [CMD-RAND] 74:C8:D5:21:1A:FC ADV_IND -96 dBm
Oct 17 10:07:30 blue2 bash[16460]: 0.1.675 10:07:30 am [CHECK-DEL] 7C:1C:4E:3E:5A:B1 expired after 150 seconds
Oct 17 10:07:34 blue2 bash[16460]: 0.1.675 10:07:34 am [CMD-RAND] 68:2C:65:00:44:5F ADV_IND -87 dBm
Oct 17 10:07:46 blue2 bash[16460]: 0.1.675 10:07:46 am [CMD-RAND] 66:89:3E:18:B1:71 ADV_NONCONN_IND -92 dBm
Oct 17 10:07:49 blue2 bash[16460]: 0.1.675 10:07:49 am [CMD-RAND] 5D:55:D1:93:AB:D3 ADV_NONCONN_IND -93 dBm
Oct 17 10:07:49 blue2 bash[16460]: 0.1.675 10:07:49 am [CMD-RAND] 71:BC:26:EB:42:AE ADV_IND -90 dBm
Oct 17 10:07:51 blue2 bash[16460]: 0.1.675 10:07:51 am [CMD-RAND] 30:49:17:2D:CA:06 ADV_NONCONN_IND -91 dBm
Oct 17 10:07:53 blue2 bash[16460]: 0.1.675 10:07:53 am [CMD-RAND] 7B:49:10:17:38:CA ADV_NONCONN_IND -92 dBm
Oct 17 10:08:05 blue2 bash[16460]: 0.1.675 10:08:05 am [CHECK-DEL] 42:E1:10:2B:85:6F expired after 57 seconds
Oct 17 10:08:05 blue2 bash[16460]: 0.1.675 10:08:05 am [CHECK-DEL] 5B:7A:8A:AC:9D:59 expired after 57 seconds
Hiya @andrewjfreyer been playing around some more, and still getting interference problems. I am going to just guess this is the nature of the beast we are playing with.
Running it with just my mac address in it, its no problems at all, but as soon as I add in some friends one, thatās when problems start to arise. I have been running monitor with the following flags,
monitor.sh -tdr
So it just does the arrival scans by default, and the depart scanās are triggered. Now my friends arenāt here much, but would love to just leave their macās in there to set it and forget it, but with 5 in total there, mine, plus 4 others, then I am getting drop outās again from my tablets.
This one is directly below the access point,
This one is the other end of the house but past one of monitor piās and this one gets hit hard
I presume, there probably isnāt much I can do apart from either remove my friends macās till the day they are due to come round, but seemās super messy and annoying, or either have arrival scanās triggered as well, but again, that kinda defeats the object of Monitor completely.
Any help would much appreciated if possible, but I think I am beyond help
Iām really curious as to why some people have no problems and other people have lots. Is it that some IoT devices are super sensitive to interference? Are those people NOT reporting problems also NOT trying to run ESP8266 / Particle devices etc etc ?
Is this a ānormalā Mosquitto broker log? Seems like a lot of connect/disconnects in a five minute period!
1539818033: New client connected from 192.168.0.116 as mosqpub|562-raspberrypi (c1, k60, u'').
1539818033: Client mosqpub|562-raspberrypi disconnected.
1539818033: New connection from 192.168.0.116 on port 1883.
1539818033: New client connected from 192.168.0.116 as mosqsub|576-raspberrypi (c1, k60, u'').
1539818036: New connection from 192.168.0.116 on port 1883.
1539818036: New client connected from 192.168.0.116 as mosqpub|796-raspberrypi (c1, k60, u'').
1539818036: Client mosqpub|796-raspberrypi disconnected.
1539818037: New connection from 192.168.0.116 on port 1883.
1539818037: New client connected from 192.168.0.116 as mosqpub|849-raspberrypi (c1, k60, u'').
1539818037: Client mosqpub|849-raspberrypi disconnected.
1539818049: New connection from 192.168.0.116 on port 1883.
1539818049: New client connected from 192.168.0.116 as mosqpub|1447-raspberryp (c1, k60, u'').
1539818049: Client mosqpub|1447-raspberryp disconnected.
1539818049: New connection from 192.168.0.116 on port 1883.
1539818049: New client connected from 192.168.0.116 as mosqpub|1481-raspberryp (c1, k60, u'').
1539818049: Client mosqpub|1481-raspberryp disconnected.
1539818052: New connection from 192.168.0.116 on port 1883.
1539818052: New client connected from 192.168.0.116 as mosqpub|1542-raspberryp (c1, k60, u'').
1539818057: Client mosqpub|1542-raspberryp disconnected.
1539818072: New connection from 192.168.0.116 on port 1883.
1539818072: New client connected from 192.168.0.116 as mosqpub|1873-raspberryp (c1, k60, u'').
1539818072: Client mosqpub|1873-raspberryp disconnected.
1539818092: New connection from 192.168.0.116 on port 1883.
1539818092: New client connected from 192.168.0.116 as mosqpub|2166-raspberryp (c1, k60, u'').
1539818092: Client mosqpub|2166-raspberryp disconnected.
1539818092: New connection from 192.168.0.116 on port 1883.
1539818092: New client connected from 192.168.0.116 as mosqpub|2195-raspberryp (c1, k60, u'').
1539818092: Client mosqpub|2195-raspberryp disconnected.
1539818093: New connection from 192.168.0.116 on port 1883.
1539818093: New client connected from 192.168.0.116 as mosqpub|2224-raspberryp (c1, k60, u'').
1539818093: Client mosqpub|2224-raspberryp disconnected.
1539818145: New connection from 192.168.0.116 on port 1883.
1539818145: New client connected from 192.168.0.116 as mosqpub|2810-raspberryp (c1, k60, u'').
1539818145: Client mosqpub|2810-raspberryp disconnected.
1539818147: New connection from 192.168.0.116 on port 1883.
1539818147: New client connected from 192.168.0.116 as mosqpub|2953-raspberryp (c1, k60, u'').
1539818147: Client mosqpub|2953-raspberryp disconnected.
1539818150: New connection from 192.168.0.116 on port 1883.
1539818150: New client connected from 192.168.0.116 as mosqpub|3015-raspberryp (c1, k60, u'').
1539818150: Client mosqpub|3015-raspberryp disconnected.
1539818161: New connection from 192.168.0.116 on port 1883.
1539818161: New client connected from 192.168.0.116 as mosqpub|3198-raspberryp (c1, k60, u'').
1539818161: Client mosqpub|3198-raspberryp disconnected.
Yes, so I think that makes your answer ānoā.
And I am curious why you would need docker for a single bash script?
Do you have a fence ? driveway? camera motion sensor? that could trigger your arrive scans?
Iām in the middle of creating one, it should be ready this weekend