That readout shows you switching to beta, so you’re good from here. 
1 Like
Perfect i will check it everyday now to see if behaves normal. Thanks!
1 Like
@VGE I just pushed an update that separates the ‘filters’ I reference above into two separate filters, one for advert flags and one for the manufacturer. Just as an FYI that it’s a good idea to refresh the default settings again with -d if you update to the most recent beta.
1 Like
This is great!
I had an old RPi Zero W collecting dust and I’m using it for this now.
I live in an apartment, so having just 1 covers the whole place.
I have a few questions though (I read through most of the comments here):
First, I am running the beta branch that was just updated minutes ago (v. 0.1.844).
I would like to track 3 devices: 2 iPhones and a tag for my dog called Pawscout.
Just an observation but when running sudo bash monitor.sh -b, I see all the devices; however, the Pawscout tag shows up both as APPLE_IBEACON with a uuid and a GENERIC_BEACON with a MAC address.
I put the 2 iPhone MAC addresses in known_static_addresses and the Pawscout MAC address in known_beacon_addresses. I did nothing with the uuid. I also tried putting the Pawscout MAC address in known_static_addresses but that didn’t work.
I have 4 sensor entries in Home Assistant: 1 for each iPhone, 1 for Pawscout uuid and 1 for Pawscout MAC.
Everything is working pretty well; however, when triggering a depart or arrive scan, Monitor only checks for the iPhones (iPhone 1 is currently home, iPhone 2 is currently away):
0.1.844 01:55:50 pm [INSTRUCT] mqtt trigger depart
0.1.844 01:55:50 pm [CMD-INFO] **** Started departure scan. [x2 max rep] ****
0.1.844 01:55:50 pm [CMD-SCAN] (No. 1) IPHONE_1_MAC departure?
0.1.844 01:55:53 pm [CMD-INFO] **** Completed departure scan. ****
0.1.844 01:56:04 pm [INSTRUCT] mqtt trigger arrive
0.1.844 01:56:04 pm [CMD-INFO] **** Started arrival scan. [x1 max rep] ****
0.1.844 01:56:04 pm [CMD-SCAN] (No. 1) IPHONE_2_MAC arrival?
0.1.844 01:56:12 pm [CMD-INFO] **** Completed arrival scan. ****
0.1.844 01:56:12 pm [CMD-NAME] IPHONE_2_MAC Melissa's iPhone Apple Inc
This is what shows up in the last lines when I run sudo bash monitor.sh -b:
> IPHONE_1_MAC will publish updates to: monitor/home/IPHONE_1_MAC (has not previously connected to hci0)
> IPHONE_2_MAC will publish updates to: monitor/home/IPHONE_2_MAC (has not previously connected to hci0)
> known beacon: PAWSCOUT_MAC will publish to: monitor/home/PAWSCOUT_MAC
Just wondering if this is a known issue or if I’m doing something incorrectly.
Thanks again for the awesome work!
1 Like
Since beacon devices don’t respond to scans, beacons will simply “expire” - there’s no mechanism to affirmatively determine whether a beacon is absent otherwise.
your logs show expected behavior.
1 Like
Great stuff! What divider should i use between manufacturer names? like so: Apple|Samsung?
Yes, if you have the earlier versions up to 844. If you’ve updated since then, you’ll want to refresh the default settings with -d and modify the filters separately.
In either case, a pipe | should be used to separate the fields.
I’m nearing my wits end here; I’ve got to be missing something simple or I’m over thinking it. I have home assistant running on a rpi (10.10.1.80) and monitor.sh installed on another rpi (10.10.1.50). I am watching monitor.sh run live, it see’s my two phones (one is an X the other is a 7), it sees them just fine, confidence 100%. In Home Assistant, I have the below code in configuration.yaml, and the entities are showing up, but with a null value. Is there a connection I am missing to get HA to associate the scan data in monitor.sh?
MOSQUITTO PREFERENCES:
# IP ADDRESS OF MQTT BROKER
mqtt_address=
# MQTT BROKER USERNAME (OR BLANK FOR NONE)
mqtt_user=username
# MQTT BROKER PASSWORD (OR BLANK FOR NONE)
mqtt_password=hello
# MQTT PUBLISH TOPIC ROOT
mqtt_topicpath=monitor
# PUBLISHER IDENTITY
mqtt_publisher_identity='Garage'
# MQTT PORT
mqtt_port='1883'
# MQTT CERTIFICATE FILE (LEAVE BLANK IF NONE)
mqtt_certificate_path=''
PUBLIC MAC ADDRESS LIST
00:12:0A:23:3R:FD Dads iPhone #This is dads iphone
FA:23:00:CA:0A:F1 Moms iPhone #This is moms iphone
CONFIGURATION.YAML
sensor:
- platform: mqtt
state_topic: 'location/garage/00:12:0A:23:3R:FD'
value_template: '{{ value_json.confidence }}'
unit_of_measurement: '%'
name: 'Dads iPhone'
- platform: mqtt
state_topic: 'location/garage/FA:23:00:CA:0A:F1'
value_template: '{{ value_json.confidence }}'
unit_of_measurement: '%'
name: 'Moms iPhone'
mqtt:
broker: 10.10.1.50
port: 1883
username: username
password: hello
1 Like
Replace “location” with “monitor” in your sensor topic path. Note the “topic path” variable in the mqtt settings is set to “monitor”
Ah, good catch. I have fixed it as described, but still no joy.
I am not sure how anything is showing up with no mqtt address in your configuration file.
1 Like
That was it, holy crap; I knew it was something simple. Thank you!
1 Like
Hi, great project Andrew i have used both presence and monitor and both have been great at home!!
I am trying to implement something similar in our office where i have added 41 devices to the known device list of monitor, but i seem to get an issue where the scans take so long they start overlapping; and when an arrive scan hasn’t finished and a depart scan starts, the arrives start failing to register devices that are present!? is there any way to ensure that the arrive has finished before the depart scan starts??
1 Like
That number of devices is probably too many for the current structure of either app. Presence is probably a better starting point, but even then you’d have to increase scan intervals substantially. I’d try to target no more than one scan per minute. Might take an hour to recognize a device.
I’ll think on this issue.
1 Like
First, I’m really impressed with this solution, it works great to an extent (YMMV). However, I’ve spent a long time trying to tune it’s settings and many other things to make it work for me. It’s just too aggressive with the 2.4Ghz disturbance in my house and with all of my other devices. I’m going to explore other options and device tracker combos. Again, I really liked the approach and simplicity of your project, thanks for sharing.
Is there a quick one/two punch to uninstall/disable this from running on my Rpi, short of flashing my SSD?
1 Like
Whatever startup mechanism you enabled, reverse it.
Hi!
I’ve been using monitor for a long time now, without any trouble. Yesterday, I added another phone (iPhone Xs) to the list of known_static_devices, and did all the necessary changes to Hass.io. I updated monitor to the latest version (not running beta) and now this phone and another iPhone X will not give any data from sudo hcitool name MACADDRESS unless I unlock the phones and goes to the Settings/Bluetooth menu. Same goes for the scan, it gives a confidence reading of “0” if phone is locked or not in the BT menu. Both phones has the latest iOS (12.1.2).
retain: false
version : 0.1.675
address : MAC (BT Mac from "about menu")
confidence : 0
name : "Name"
timestamp : Sun Jan 20 2019 11:29:51 GMT+0000 (UTC)
manufacturer : Unknown
type : KNOWN_MAC
I actually have no clue why this happens now. The iPhone X worked previously without this being an issue, only thing I did was giving it another name in the “known_device_list”. I ran bash.sh -d -u to make sure everything was default. I have another iPhone 6s in the list which is working fine.
PS! Tried changing to the beta branch but experiencing same behaviour.
UPDATE! Ok, so by reading some other threads, I might have the solution. By adding the phones to another BT-device (ie. a Mac) I got the expected behaviour. Now it shows up with hcitool and it gives the correct status (at least for now).
1 Like
@andrewjfreyer im stil on 0.1.675
I kept trying the Beta’s but they would randomly restart constantly. I only do depart scan on a trigger but once the monitor instance is restarted it does a scan like it suppose to and y automations start going crazy lol.
Have you seen anymore restarts on the latest beta?
I’m actively testing some new features on beta. It probably won’t be reliably stable until this afternoon. Sorry for any inconvenience
Great! For future reference, the recent versions of the beta happy ability to connect directly to a device to mitigate this. Documentation coming soon
1 Like