thanks for the response, i see some of that…, oddly i moved my iphone litterally 3-4 away from the pi zero and my rssi drops to almost -9, i would have expect it to be in the 70’s
When you’re on beta, make sure to update as often as possible. Updating is always best.
Monitor is meant to track mobile devices - generally one device per person is what I use, what is the reason you want to track the presence of your echo dot? The pi zero is best suited to track only a few devices. Simplifying will be best. For example, try one device first to be sure you understand how the script works and then add additional devices.
Next, try filtering your devices.
If you still don’t see any response from any of your named devices, please open an issue on github.
i did, sudo bash monitor.sh -t[adr], how come if i turn off bluetooth it doens’t depart? does it not work like that? i also waited 2 minutes and the next mqtt i would assume would be -1 or zero, but it came back as -99 (like it being on and right next to it)
@andrewjfreyer, I’m still struggling with a couple of Nut Mini BLE tokens and monitor.sh. http://nutspace.com/products/nutmini is the product I’m using. However - starting monitor with -b - the Nuts are found but the confidence stays at 100% even when the token has left the house. I’m currently using three Pi Zero Ws and have no issues with iPhones with monitor.sh but these tokens are giving me a headache.
Thanks for any advice!
I have the square ones and they even do not appear in the log (at least I am not able to)
Are you on beta or master? Beta has some improvements to beacon expiration that I’m working out. Do you have any logs that you could post or DM that show the Nut being recognized? Have you changed any of your behavior preferences?
I suggest reading the documentation to understand how monitor works. If you are using the -td flag, no departure scan will occur until you trigger it via mqtt.
Also note that -99 is the value that we’d expect to see when your phone is out of range. That’s the lowest rssi value that monitor reports.
@andrewjfreyer, I’m on the beta branch, v0.2.146. I read on your original description and are now trying the following replica of your setup:
Main node near the entrance: -trd -b
Node in the other end of the house: -tad -b
Node on the first floor: -tad -b
Having Home Assistant trigger arrive and depart scans when there’s motion near the main doors.
Gonna watch the logs of all three nodes, greeping on the mac address of the nut. Nothing special in the behaviours file with relation except PREF_BEACON_EXPIRATION=240.
Does this sound reasonable ?
Looks good. Any flags?
If the nut reports as a random beacon, then I suggest trying the new -F flag in a console session to see what Monitor sees.
Flags (if these are what you meant):
#ARRIVE TRIGGER FILTER(S)
PREF_PASS_FILTER_ADV_FLAGS_ARRIVE="."
PREF_PASS_FILTER_MANUFACTURER_ARRIVE="."
#ARRIVE TRIGGER NEGATIVE FILTER(S)
PREF_FAIL_FILTER_ADV_FLAGS_ARRIVE=“NONE”
PREF_FAIL_FILTER_MANUFACTURER_ARRIVE=“Google|August|Microsoft|Samsung|Xiaomi”
Sample entry where the nut was detected:
D7:2A:29:80:9B:07 nut Nordic Semiconductor ASA for Link Loss -90 dBm
(forget what I mentioned about crash, it was a controlled restart triggered by Home Assistant restart)
Oh, on the beta version with the -b miband was tracked.
In the code found the desired parameter PREF_BEACON_MODE = true. Now it works in the background. Thank you, good project!
How do you do a scan for leaving?
Hi, this is second time that after triggering a depart scan, a device is marked as absent even though it is not. First time I incremented PREF_DEPART_SCAN_ATTEMPTS, but it happened again, triggering the away mode.
Is there anything I can do to prevent this from happening? I know that since I trigger a lot of depart scans when my door opens, I increase the chances to not getting a response and therefore being marked as away, but otherwise I could potentially be missing departures.
Per the documentation, this can happen unless you have a very high PREF_DEPART_SCAN_ATTEMPTS to a high number (e.g., 5 or more). This is why a second or third node for a large house is a good idea. Also increasing PREF_MINIMUM_TIME_BETWEEN_SCANS can help too.
Send your settings via DM and I can help you debug.
Thanks. I’ll increase the number further and see how it works for me. I don’t think my house is big but I’ll see if I can setup a second node,
I’m having some hard time understanding where do I put e.g. the -x flag to have retained message when running with “sudo systemctl start monitor.service”.
Also what should be used as payload when trying to activate departure and arrival scans?
use the -u flag to update the service. So, if you run monitor with -b -tdr and you want to add the retain flag of -x, run from the command line with: -b -tdr -x -u
no payload is required for arrive or depart mqtt triggers
1 Like
Hello everyone,
it is possible to use an external hardware (perhaps with an external antenna) to cover a house (10mx10m, 2 floors) with a single device
if yes, which device do you recommend to insert in a raspberry pi 3
Depends on the walls, but why not buy a Raspberry Pi Zero? I’ve got a pair of them so that I’m not trying to cover the whole house from a single device, but two devices in opposite corners. That works really well, and they’re pretty cheap.
2 Likes
Apologies for the probably obvious questions - I have searched the thread and can’t find what I am looking for.
I would like to use this, at the moment, just for tracking generic beacons (Nut mini, fitbit) - my Oneplus 5T does not support random advertisements so doesn’t trigger arrival scans.
With the -b flag, am I correct in thinking that I don’t need to perform a departure scan to detect when beacons lost their connection? I have played with it, and seems to detect a beacon as away within around 2 mins, and home within a few secs without arrive/depart scans?
Also, I am laso correct in thinking that generic beacons don’t need to be added to the known devices or known beacon file?
Thanks!
1 Like