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
Well, I don’t know if was upgrading to the latest hass.io, or upgrading to the latest monitor beta code, but no more dangerous client! I seem to be getting something, now just to figure out how to add something to Lovelace to play with and verify things are working correctly.
1 Like
So far so good on this latest Beta.
Can you check for me if your MQTT server is still retaining messages? Mine for some reason on the Beta is not retaining them. I saw you changed a couple things but it looked correct…
EDIT
it could be something im doing
EDIT
It seems that doing -u isnt working for me…
I think two of my SD cards were corrupted so I flashed an entirely new instance of monitor.
then I used sudo bash monitor.sh -u -d -tdr -x
Unfortunately this did not change the config.
I went to the service and manually changed the service parameters. and my messages are now retained and the depart scan only on trigger is also working. No reboots so far!!!
So one of my Pi’s is on 0.1.675 and the other is 0.1.878. Ill keep on testing but so far so good. Keep up the great work!!!
1 Like
Thanks for the report. I’ll see if I can figure out why it isn’t updating
Fyi in the newer versions of HASS (This took me longer than it shouldve to figure out so im posting it here)
This OLD config
- platform: mqtt
state_topic: 'location/first floor/[MAC ADDRESS]'
value_template: '{{ value_json.confidence }}'
unit_of_measurement: '%'
name: 'Apple Watch - First Floor'
availability_topic: "location/first floor/status"
payload_available: "online"
payload_not_available: "offline"
json_attributes:
- id
- name
- rssi
- version
- manufacturer
- type
- timestamp
- retained
- confidence
turn Into this new config
- platform: mqtt
state_topic: 'location/first floor/[MAC ADDRESS]'
value_template: '{{ value_json.confidence }}'
unit_of_measurement: '%'
name: 'Apple Watch - First Floor'
availability_topic: "location/first floor/status"
payload_available: "online"
payload_not_available: "offline"
json_attributes_topic: 'location/first floor/[MAC ADDRESS]'
6 Likes
Still having issues with BT adv. Some days it works, but for most of the part it doesn’t. I’m guessing that when it works it’s because some neighbor triggered the scan (we’re reasonably close). So it seems I’m stuck with triggers, since none of my devices seem to work.
Any ideas on how to trigger an arrive scan? I could use the doors for departure. Would it be OK to use the same door for both scans?
(Btw I’ve been paying attention to this thread and I’m running the latest beta).
1 Like
How many people/devices would you estimate are within ~50m of you node?
Running the latest beta 0.1.887
I am getting the following error:
monitor.sh: line 1074: [: : integer expression expected
That line reads:
[ "$beacon_last_seen" -gt "$last_seen" ] && last_seen=$beacon_last_seen
I assume the $ is missing? I entered it but still get the same error.
Also, my ibeacon used to work well in a previous beta. Now, it will be recognized as home but wont ever lose confidence from 100 when it leaves. UUID loses confidence well. Should I just use the UUID and call it a day?
I’m using -b -u flags on my 1 and only pi running monitor.
Also, if you want to make a device_tracker out of your monitor devices, you could use MQTT Device Tracker. I made one for my dog Nilly for her Pawscout iBeacon Tag :
Create an MQTT Device Tracker:
device_tracker:
- platform: mqtt
devices:
nilly_rpi: 'location/nilly-rpi'
Create automations for Home & Away:
automation:
- id: '############'
alias: Nilly Away - RPi Monitor
trigger:
- platform: numeric_state
entity_id: sensor.nillys_pawscout_tag_rpi_zero_uuid
above: '10'
action:
- service: mqtt.publish
data:
topic: location/nilly-rpi
payload: home
for home
- id: '############'
alias: Nilly Away - RPi Monitor
trigger:
- platform: numeric_state
entity_id: sensor.nillys_pawscout_tag_rpi_zero_uuid
below: '10'
action:
- service: mqtt.publish
data:
topic: location/nilly-rpi
payload: away
for away.
As soon as it publishes a payload, a new device_tracker.nilly_rpi will be made in known_devices.yaml
1 Like
Smartphones probably around 10 including two of our own. The Raspberry pi is really close to he front door so may be within range of people walking down the street. Why? Do you have something in mind?
Your theory about triggering too often may be correct. Drivers, pedestrians, etc may be triggering an arrive too frequently.
When you run btmon on its own, how many devices do you see?