Yepp i am using the correct address but it is still always reported as 0 confidence. Its a Series 4 watch.
Could it be something with my RPi?
Its the latest RPi3 B+
what happens when you run the following command:
sudo hcitool name MACOFYOURWATCH
it outputs nothing.
Tried running it from my NUC aswell with the same reslut.
If i do the same but put in my iPhones MAC i do get output
Could be this added in custom_updater?
Have you connected your Apple Watch to any other bluetooth device before? AirPods? MacBook?
1 Like
Ahh good catch! I thought pairing it with the iPhone would suffice, but since its the phone pairing to the Watch it didnt cause the Watch to start advertising.
As soon as I paired the Watch with some headphones it showed up right away.
Thanks!
1 Like
Great to hear!
@andrewjfreyerI like you… thanks for all your work
1 Like
I have 3 Pi Zero’s running monitor and every couple days I start getting this in the logs:
Feb 14 00:23:14 monitor1 kernel: [287338.363791] Bluetooth: hci0 command 0x200b tx timeout
Feb 14 00:23:27 monitor1 kernel: [287350.603884] Bluetooth: hci0 command 0x200b tx timeout
Feb 14 00:23:39 monitor1 kernel: [287362.763874] Bluetooth: hci0 command 0x200b tx timeout
Feb 14 00:23:51 monitor1 kernel: [287375.003913] Bluetooth: hci0 command 0x200b tx timeout
Feb 14 00:24:03 monitor1 kernel: [287387.163974] Bluetooth: hci0 command 0x200b tx timeout
Feb 14 00:24:15 monitor1 kernel: [287399.324053] Bluetooth: hci0 command 0x200b tx timeout
Feb 14 00:24:27 monitor1 kernel: [287411.484032] Bluetooth: hci0 command 0x200b tx timeout
Feb 14 00:24:40 monitor1 kernel: [287423.724074] Bluetooth: hci0 command 0x200b tx timeout
Feb 14 00:24:52 monitor1 kernel: [287435.884118] Bluetooth: hci0 command 0x200b tx timeout
Feb 14 00:25:04 monitor1 kernel: [287448.044157] Bluetooth: hci0 command 0x200b tx timeout
Feb 14 00:25:16 monitor1 kernel: [287460.204192] Bluetooth: hci0 command 0x200b tx timeout
Feb 14 00:25:28 monitor1 kernel: [287472.444237] Bluetooth: hci0 command 0x200b tx timeout
Feb 14 00:25:41 monitor1 kernel: [287484.604293] Bluetooth: hci0 command 0x200b tx timeout
Feb 14 00:25:53 monitor1 kernel: [287496.764315] Bluetooth: hci0 command 0x200b tx timeout
Feb 14 00:26:05 monitor1 kernel: [287508.924356] Bluetooth: hci0 command 0x200b tx timeout
Feb 14 00:26:17 monitor1 kernel: [287521.084396] Bluetooth: hci0 command 0x200b tx timeout
Feb 14 00:26:29 monitor1 kernel: [287533.324447] Bluetooth: hci0 command 0x200b tx timeout
Feb 14 00:26:41 monitor1 kernel: [287545.484486] Bluetooth: hci0 command 0x200b tx timeout
Feb 14 00:26:54 monitor1 kernel: [287557.644521] Bluetooth: hci0 command 0x200b tx timeout
Feb 14 00:27:06 monitor1 kernel: [287569.804570] Bluetooth: hci0 command 0x200b tx timeout
Feb 14 00:27:18 monitor1 kernel: [287581.964601] Bluetooth: hci0 command 0x200b tx timeout
Feb 14 00:27:30 monitor1 kernel: [287594.124645] Bluetooth: hci0 command 0x200b tx timeout
Feb 14 00:27:42 monitor1 kernel: [287606.364679] Bluetooth: hci0 command 0x200b tx timeout
Any idea what could be causing these as once this happens it quits reporting status and I have to reboot my Pi Zero.
Also is it normal for so many instances of the script to be running?
root 448 1 0 00:29 ? 00:00:00 /usr/sbin/sshd -D
root 509 418 0 00:29 ? 00:00:02 /bin/bash /home/pi/monitor/monitor.sh -r -a &
root 510 418 0 00:29 ? 00:00:00 /bin/bash /home/pi/monitor/monitor.sh -r -a &
root 511 418 1 00:29 ? 00:00:35 /bin/bash /home/pi/monitor/monitor.sh -r -a &
root 512 418 0 00:29 ? 00:00:00 /bin/bash /home/pi/monitor/monitor.sh -r -a &
root 513 418 0 00:29 ? 00:00:00 /bin/bash /home/pi/monitor/monitor.sh -r -a &
root 514 418 0 00:29 ? 00:00:00 /bin/bash /home/pi/monitor/monitor.sh -r -a &
root 516 511 0 00:29 ? 00:00:00 /bin/bash /home/pi/monitor/monitor.sh -r -a &
root 521 516 0 00:29 ? 00:00:00 hcidump -i hci0 --raw
First, yes, monitor spawns a number of processes to leverage parallel processing as much as possible.
Second, you are using some depreciated options here - -r has been removed. If you want periodic scanning, you should use presence instead. I suggest, however that you use monitor with default settings (or settings adjusted for your home) because it does work much better than presence.
Third, to your question - I have not seen this error before. Have you changed default settings?
Thanks again for your help. I am making good progress now. I have tweaked the PREF_BEACON_EXPIRATION parameter to make monitor timeout beacons a bit quicker and that worked well. I just had a funny glitch with my HASS automation. It might be due to my bad coding but I just wanted to check with you first in case it’s an artifact of the monitor/mqtt process.
I have an automation that I want to trigger when a beacon that has gone away comes back into range.
My sensor looks like this
- platform: mqtt
state_topic: 'monitor/living_room/EBEFD083-70A2-47C8-9837-E7B5634DF522-31932-62422'
value_template: '{{ value_json.confidence }}'
unit_of_measurement: '%'
name: 'BTmon Bike Rachel'
And my testing automation looks like this.
- alias: Bike Returned
trigger:
- platform: numeric_state
entity_id: sensor.btmon_bike_rachel
above: 50
action:
service: notify.ios_michaels_iphone_8
data:
message: "bike is back"
The trigger works as expected ie when confidence goes from under 50% to over 50% as the beacon arrives. That’s what I’m after.
But the trigger also fires when the confidence goes from 100% to 58% ie as the beacon leaves.
That’s not right is it? I thought the “above” part of the trigger is looking for the value to cross the specified threshold.
Wdyt? Is it my sloppy coding or something else? Thanks very much.
I’ve noticed that running -tdr on the beta branch (with otherwise default settings) is keeping my fragile 2.4Ghz WiFi devices connected…but…it’s nowhere near as fast as it used to be at detecting my arrival. Now Life360 is quicker which seems really odd. It’s about three minutes of being inside the home before Monitor picks me up now. Used to be when I was walking down the street.
Guys I am running the latest stable version and I have the following issue
After running shell script I am getting an error time out and I need to restart interface(see below)
root@raspberrypi:/home/pi/scripts/monitor# bash monitor.sh
====================== DEBUG ======================
starting monitor.sh (v. 0.2.002)…
removing web request caches
removing public name cache
preference: using mqtt protocol version mqttv311
preference: minimum time between the same type of scan = 15
preference: regex filter for flags to accept = .*
preference: regex filter for flags to reject = NONE
preference: regex filter for manufacturers to accept = .*
preference: regex filter for manufacturers to reject = NONE
preference: maximum sequential arrive scan attempts = 1
preference: maximum sequential depart scan attempts = 2
preference: selected HCI device = hci0
mqtt trigger: monitor/scan/ARRIVE
mqtt trigger: monitor/scan/DEPART
AC:37:43:D4:2F:4B publishes to: monitor/hass/AC:37:43:D4:2F:4B (has not previously connected to hci0)
00:3D:E8:8A:76:D7 publishes to: monitor/hass/00:3D:E8:8A:76:D7 (has not previously connected to hci0)
================== BEGIN LOGGING ==================
0.2.002 05:56:05 pm [CMD-RAND] [passed filter] data: 53:FD:6A:76:0D:7F pdu: ADV_SCAN_IND rssi: -72 dBm flags: none man: unknown delay: 0
0.2.002 05:56:06 pm [CMD-INFO] **** started arrival scan. [x1 max rep] ****
0.2.002 05:56:07 pm [CMD-SCAN] (No. 1) AC:37:43:D4:2F:4B arrival?
0.2.002 05:56:08 pm [CMD-NAME] AC:37:43:D4:2F:4B Nicolas - Pixel XL HTC Corporation
monitor/hass/AC:37:43:D4:2F:4B
{
“id”:“AC:37:43:D4:2F:4B”,
“confidence”:“100”,
“name”:"NicolasPhone ",
“manufacturer”:“HTC Corporation”,
“type”:“KNOWN_MAC”,
“retained”:“false”,
“timestamp”:“Thu Feb 14 2019 17:56:08 GMT+0200 (EET)”,
“version”:“0.2.002”
}
Error: Connection timed out
oot@raspberrypi:/home/pi/scripts/monitor# hcitool lescan
Set scan parameters failed: Input/output error
root@raspberrypi:/home/pi/scripts/monitor# hciconfig hci0 down
root@raspberrypi:/home/pi/scripts/monitor# hciconfig hci0 up
root@raspberrypi:/home/pi/scripts/monitor# hcitool lescan
LE Scan …
5E:49:42:CE:7B:D6 (unknown)
5E:49:42:CE:7B:D6 (unknown)
5E:49:42:CE:7B:D6 (unknown)
5E:49:42:CE:7B:D6 (unknown)
5E:49:42:CE:7B:D6 (unknown)
5E:49:42:CE:7B:D6 (unknown)
5E:49:42:CE:7B:D6 (unknown)
5E:49:42:CE:7B:D6 (unknown)
5E:49:42:CE:7B:D6 (unknown)
5E:49:42:CE:7B:D6 (unknown)
5E:49:42:CE:7B:D6 (unknown)
1 Like
Filters will help quite a bit here. See the README.
Is your bluetooth hardware a USB dongle perhaps?
That is highly likely to be the problem. After developing monitor for a while, a number of users have reported issues that were eventually found to be caused by their dongle not filtering duplicate reports at the hardware level.
This means that a flood of advertisements (which you can see in your hcitool lescan output above), most of which are duplicates, bombard monitor and it cannot keep up. Then it gets out of sync with the hci interface and makes too many simultaneous calls to access the hardware. This is what causes the need to cycle the interface.
At present, I have not found a way to get around this but I’m still investigating.
So, a am I screwed?
Is there a way around this?
1 Like
Why don’t you buy a Raspberry Pi Zero W? That way you’d be using the hardware used to develop monitor.
I have bought a bluetooth dongle class 1 which has a large range.