Ok, so I’ve setup monitor and added the Mac addresses of the devices I want to monitor in known_static_addresses but when I reboot the known address only seems to appear once in MQTT.fx, even when I simulate the device going out of range (turning off bluetooth) the device confidence doesn’t update, where as every other device that not in known_static_addresses updates with more frequency. Have I configured it wrong something on the line?
Edit: I’m using sudo bash monitor.sh -r
Depends on the device that isn’t showing up. What type of device is that?
I’d suggest using without -r initially.
I have 2 iPhones currently monitored.
so just sudo bash monitor.sh -h
Will that change stick over reboots?
I’d strongly recommend that you try without -r first. Run sudo bash monitor.sh
If you use the -u flag, whatever options you include will be saved for systemctl purposes.
I’d suggest stopping the systemctl process while you’re testing - sudo systemctl stop monitor
Then just run monitor from the command line with different options to see what its doing. Start with sudo bash monitor.sh
Ok tried that, getting only an initial entry for my iPhone, no matter what I do the confidence isn’t changing and MQTT.fx isn’t receiving any further updates from the device. Can I confirm the syntax for the known_static_addresses file as I think I may have altered it and its stopping it from working.
I know the mac addr - however the hcitool doesn’t come up with anything - however btmon and bluetoothctl both see it as ‘nut’ with the correct mac addr.
On a name request? Sounds like this might be broadcasting as a beacon.
The only required syntax is the file is line-separated mac addresses:
00:00:00:00:00:00
11:11:11:11:11:11
Yeah that’s what I thought. I was also adding a name at the end of each line as mqtt.fx is showing no name when pinging the devices. This was as per the pre-populated example in the known_static_addresses (which I removed).
Should I be keeping:
00:00:00:00:00:00
On the first line?
My thought behind using the RSSI positioning is not to “pin point” a person some where, but to determine whereabouts. For e.g
If one has monitor running on Pi Zero W in each room, and you enter a room, the bluetooth might be picked up by the two adjacent rooms. Thus monitor is now reporting 3 RSSI values/distance - For e.g
Room A - 2m
Room B - 9m
Room C - 5m
By looking at the values reported on can deduct, that the bluetooth device is closest to monitor in Room A. Then use that information for automation etc.
I hope it makes sense.
Thank you for all your effort with this - Much Appreciated!
If I do
sudo hcitool lescan
then the ‘nut’ shows up in the scan.
Yes, you’ll need to remove that line.
It seems that the nut is showing up as a general beacon. Can you run sudo hcitool lescan in one shell session while simultaenously running sudo hcidump -a in another shell session? If you can copy the output from the hcidump session here so that I can see how the nut reports itself, that would be very helpful.
I do understand what you’re after. That is why I started with Happy Bubbles - I wanted room-based detection. The issue is very simple if the reality followed your example. Of course, if RSSI correlated accurately to distance, we could easily triangulate a room or position between two or more points in space. However, and I think you can see this if you run hcidump -a for a while with a stationary beacon, RSSI jumps all over the place, varies with battery, varies with transmission power (which is not always reported by the beacon), and varies with the current RF environment.
A more realistic RSSI log, over maybe 5 seconds without movement, would look like this, reporting RSSI every 1 second:
Room A: 2m 5m 1m 9m 9m 12m
Room B: 9m 12m unknown 8m 7m 3m
Room C: 5m 3m 5m 6m 8m 9m
Yes, if you average these over a long period of time you can find that you’re probably “closest” to Room A. But, as I’m sure you can see, selection of the averaging window is very important. If our averaging window is only 3 seconds, Room A would show as the farthest room from the device by second 5. If our averaging window is long, then the user’s movement will not be captured unless they’re still for a long period of time.
Further, RSSI is dramatically impacted by RF environment. Your measurements will become inaccurate if more devices are present, if your neighbors have a number of 2.4GHz wifi or bluetooth devices, and if your monitor or presence nodes are set to scan particularly frequently.
Anecdotally, I found that averaging over a very long period was the only way to get moderately accurate results for a particular device in a low-noise environment. I averaged RSSI values for three points in space over about 60 seconds. With these measurements, I could output a general guess where the user’s device was placed. When new devices were added to the environment, or when my battery started dying… and so on.
It’s a problem. It’s not reliable.
@andrewjfreyer can -t be used with other options like -b, -g, etc? Basically I want to be able to trigger a search for both known and other beacon devices.
Yes, that is the intended behavior.
Great - didn’t seem to be acting that way earlier but I’m seeing that behavior now…