andrewjfreyer / monitor Goto Github PK

View Code? Open in Web Editor NEW

1.6K 62.0 194.0 1.25 MB

Distributed advertisement-based BTLE presence detection reported via mqtt

Shell 100.00%

beacon cell-phone mqtt-message advertisement btle presence-detection bluetooth-devices

monitor's People

Contributors

Stargazers

Watchers

Forkers

x99percent larsac xbmcnut rudders doodip beosro phillprice minimad-diver borpin tadamec landrash dummylabs jquatier lucakaufmann krambriw kabturek captfrank jerryworkman darkmaestro3e8 johnkozan romrider ionoid cameronkelley sibero80 trondsundt luisfocosta derickwarshaw wjmccann bdwyzr b-rockx deepcoresystem mcfrojd pittbull billimek alfiegerner commander-chris piebru ideachengo elamperti leloberg ammmze valcob tkuennen jsinkers thypho0n underknowledge jongilmore robotiko jordandrako shbatm vtracsd magnum jenswilly maniac0r airdrummingfool bahamas10 1300371 kmwoley breakerz ahodges9 ichenlife soldag wochen zeridon roelbroersma jamesagada sulaimangari mvgrimes gadric thestigh odianosen25 voynovia jackmac92 julwil kennedyshead clrkwllms scargill antonjan sillevl xcray hagland cjimti dxdc duongnq2798 acamtech stevenjev koranayle way2busy pjratl boesing i9snyd3r ruifung rofr manjuladangalla ualex73 hackacad cisasteelersfan chen-sky tallguyjames danieleratti

monitor's Issues

Something strange

Hello, great script, been running it for a week or so
However, I have noticed something in my logfile that looks strange
Around 09:37 this morning I left my house when the confidence level was 100
Then my confidence correctly drops from 100 down to zero. But it repeats the same a couple of times, then starting at confidence 90. This must be wrong since I was at that time already far away
I arrived back at 16:43

So the repeated behavior in between is suspicious, the script "thinks" I'm still around. Once it reaches zero, it should not indicate 90-63-45-18 anymore
I think
See below

2018-11-07 09:37:41 100 Walter's iPhone
2018-11-07 09:47:49 90 Walter's iPhone
2018-11-07 09:47:57 63 Walter's iPhone
2018-11-07 09:48:5 45 Walter's iPhone
2018-11-07 09:48:14 18 Walter's iPhone
2018-11-07 09:48:17 0 Walter's iPhone
2018-11-07 09:48:28 90 Walter's iPhone
2018-11-07 09:48:36 63 Walter's iPhone
2018-11-07 09:48:44 45 Walter's iPhone
2018-11-07 09:48:53 18 Walter's iPhone
2018-11-07 09:48:56 0 Walter's iPhone
2018-11-07 09:50:24 90 Walter's iPhone
2018-11-07 09:50:33 63 Walter's iPhone
2018-11-07 09:50:41 45 Walter's iPhone
2018-11-07 09:50:49 18 Walter's iPhone
2018-11-07 09:50:53 0 Walter's iPhone
2018-11-07 09:52:4 90 Walter's iPhone
2018-11-07 09:52:13 63 Walter's iPhone
2018-11-07 09:52:21 45 Walter's iPhone
2018-11-07 09:52:29 18 Walter's iPhone
2018-11-07 09:52:32 0 Walter's iPhone
2018-11-07 16:43:49 100 Walter's iPhone

Blob data

I'm running monitor in the beta branch 0.1.703.
Updated to 0.1.707, the same behaviour...
And I'm seeing a lot of blob data, what does this mean?

pi@PiZero-Living:~/monitor $ sudo service monitor status
● monitor.service - Monitor Service
   Loaded: loaded (/etc/systemd/system/monitor.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2018-11-02 09:53:42 CET; 1 day 22h ago
 Main PID: 18134 (bash)
   CGroup: /system.slice/monitor.service
           ├─18134 /bin/bash /home/pi/monitor/monitor.sh -x -m &
           ├─18206 /bin/bash /home/pi/monitor/monitor.sh -x -m &
           ├─18207 /bin/bash /home/pi/monitor/monitor.sh -x -m &
           ├─18208 /bin/bash /home/pi/monitor/monitor.sh -x -m &
           ├─18209 /bin/bash /home/pi/monitor/monitor.sh -x -m &
           ├─18210 /bin/bash /home/pi/monitor/monitor.sh -x -m &
           ├─18216 /bin/bash /home/pi/monitor/monitor.sh -x -m &
           ├─18229 /bin/bash /home/pi/monitor/monitor.sh -x -m &
           ├─18238 /usr/bin/mosquitto_sub -v -h 192.168.xx.xx -p 1883 -u xxxx -P xxxxxxxxxxxxxx -t monitor/scan/# --will-topic monitor/Living/status --will-payload offline
           ├─31407 sleep 35
           ├─31434 /bin/bash /home/pi/monitor/monitor.sh -x -m &
           ├─31435 timeout --signal SIGINT 30 hcitool -i hci0 lescan
           ├─31436 hcitool -i hci0 lescan
           └─31437 sleep 15

Nov 04 07:56:31 PiZero-Living bash[18134]: [56B blob data]
Nov 04 07:56:46 PiZero-Living bash[18134]: [56B blob data]
Nov 04 07:57:01 PiZero-Living bash[18134]: [56B blob data]
Nov 04 07:57:16 PiZero-Living bash[18134]: [56B blob data]
Nov 04 07:57:31 PiZero-Living bash[18134]: [56B blob data]
Nov 04 07:57:46 PiZero-Living bash[18134]: [56B blob data]
Nov 04 07:58:02 PiZero-Living bash[18134]: [56B blob data]
Nov 04 07:58:17 PiZero-Living bash[18134]: [56B blob data]
Nov 04 07:58:32 PiZero-Living bash[18134]: [56B blob data]
Nov 04 07:58:47 PiZero-Living bash[18134]: [56B blob data]
pi@PiZero-Living:~/monitor $ journalctl -f -u monitor.service
-- Logs begin at Sat 2018-11-03 22:48:55 CET. --
Nov 04 07:56:46 PiZero-Living bash[18134]: [56B blob data]
Nov 04 07:57:01 PiZero-Living bash[18134]: [56B blob data]
Nov 04 07:57:16 PiZero-Living bash[18134]: [56B blob data]
Nov 04 07:57:31 PiZero-Living bash[18134]: [56B blob data]
Nov 04 07:57:46 PiZero-Living bash[18134]: [56B blob data]
Nov 04 07:58:02 PiZero-Living bash[18134]: [56B blob data]
Nov 04 07:58:17 PiZero-Living bash[18134]: [56B blob data]
Nov 04 07:58:32 PiZero-Living bash[18134]: [56B blob data]
Nov 04 07:58:47 PiZero-Living bash[18134]: [56B blob data]
Nov 04 07:59:02 PiZero-Living bash[18134]: [56B blob data]
Nov 04 07:59:17 PiZero-Living bash[18134]: [56B blob data]
^C

I see this on my 3 nodes

pi@PiZero-Keuken:~ $ sudo service monitor status
● monitor.service - Monitor Service
   Loaded: loaded (/etc/systemd/system/monitor.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2018-11-02 09:56:04 CET; 1 day 22h ago
 Main PID: 5006 (bash)
   CGroup: /system.slice/monitor.service
           ├─ 5006 /bin/bash /home/pi/monitor/monitor.sh -x -tad -m &
           ├─ 5078 /bin/bash /home/pi/monitor/monitor.sh -x -tad -m &
           ├─ 5079 /bin/bash /home/pi/monitor/monitor.sh -x -tad -m &
           ├─ 5080 /bin/bash /home/pi/monitor/monitor.sh -x -tad -m &
           ├─ 5082 /bin/bash /home/pi/monitor/monitor.sh -x -tad -m &
           ├─ 5083 /bin/bash /home/pi/monitor/monitor.sh -x -tad -m &
           ├─ 5084 /bin/bash /home/pi/monitor/monitor.sh -x -tad -m &
           ├─ 5114 /bin/bash /home/pi/monitor/monitor.sh -x -tad -m &
           ├─ 5123 /usr/bin/mosquitto_sub -v -h 192.168.xx.xx -p 1883 -u xxxx -P xxxxxxxxxxxxxx -t monitor/scan/# --will-topic monitor/Keuken/status --will-payload offline
           ├─16803 /bin/bash /home/pi/monitor/monitor.sh -x -tad -m &
           ├─16804 timeout --signal SIGINT 30 hcitool -i hci0 lescan
           ├─16805 hcitool -i hci0 lescan
           ├─32453 sleep 35
           ├─32484 sleep 15
           ├─32508 /bin/bash /home/pi/monitor/monitor.sh -x -tad -m &
           ├─32509 timeout --signal SIGINT 65 hcidump -i hci0 --raw
           └─32510 hcidump -i hci0 --raw

Nov 04 07:59:20 PiZero-Keuken bash[5006]: [56B blob data]

pi@PiZero-Garage:~ $ sudo service monitor status
● monitor.service - Monitor Service
   Loaded: loaded (/etc/systemd/system/monitor.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2018-11-02 09:50:03 CET; 1 day 22h ago
 Main PID: 11576 (bash)
   CGroup: /system.slice/monitor.service
           ├─11576 /bin/bash /home/pi/monitor/monitor.sh -x -tad -m &
           ├─11648 /bin/bash /home/pi/monitor/monitor.sh -x -tad -m &
           ├─11649 /bin/bash /home/pi/monitor/monitor.sh -x -tad -m &
           ├─11650 /bin/bash /home/pi/monitor/monitor.sh -x -tad -m &
           ├─11651 /bin/bash /home/pi/monitor/monitor.sh -x -tad -m &
           ├─11655 /bin/bash /home/pi/monitor/monitor.sh -x -tad -m &
           ├─11658 /bin/bash /home/pi/monitor/monitor.sh -x -tad -m &
           ├─11663 /bin/bash /home/pi/monitor/monitor.sh -x -tad -m &
           ├─11666 /usr/bin/mosquitto_sub -v -h 192.168.xx.xx -p 1883 -u xxxx -P xxxxxxxxxxxxxx -t monitor/scan/# --will-topic monitor/Garag
           ├─24077 /bin/bash /home/pi/monitor/monitor.sh -x -tad -m &
           ├─26964 sleep 35
           ├─26966 sleep 15
           └─26979 sleep 3

Nov 04 08:00:29 PiZero-Garage bash[11576]: [56B blob data]
Nov 04 08:00:44 PiZero-Garage bash[11576]: [56B blob data]
Nov 04 08:00:59 PiZero-Garage bash[11576]: [56B blob data]
Nov 04 08:01:14 PiZero-Garage bash[11576]: [56B blob data]

status topic message is retained when it is "online", but not for "offline" (LWT)

Hello,
First off, thank you for this awesome project!

Any time I connect to my MQTT broker and subscribe to the status topic, I see a retained message with a body of online. I can manually clear it (by sending an empty, retained message to the status topic), but any time I restart monitor.sh the retained message comes back. It's worth noting that any "online" status message that monitor sends is retained, not just the one it sends upon launch.

The issue that I run into with this is that even though the "online" message is retained, the LWT "offline" message is not. Therefore if HA (or anything else) loses its state, when it reconnects to the MQTT broker it receives an "online" status message from monitor, even if monitor is offline. I think ideally the online and offline status messages would both be retained - that way the status topic always has the most up-to-date status and delivers it to any new MQTT subscribers. Short of that, I think both the online and the offline message should respect the -X argument, or at least neither should be retained. Basically, as long as they match (either both are retained or neither are) things should work as expected.

I've never used the -X option to instruct monitor to set any messages to retain (so it is perhaps inconsistent that I'd prefer the status messages to be retained). I'm currently running version 0.1.711, but I've seen this in older versions as well.

Thanks!

iBeacon timestamp is truncated in MQTT message

Using iBeacon scanning flag '-b' the timestamp is being truncated `"timestamp":"Tue Oct "

location/first_floor/FDA50693-A4E2-4FB1-AFCF-C6EB07647825-10-7 {"id":"FDA50693-A4E2-4FB1-AFCF-C6EB07647825-10-7", "retained":"false", "version":"0.1.675", "confidence":"100","name":"Undiscoverable Device Name","timestamp":"Tue Oct ","type":"APPLE_IBEACON","rssi":"-83","rssi":"-83","power":"-59"}

Inconsistent regexp for mac address parsing

Hi Andrew, just looking over the code and I notice that your are inconsistent in the regexp used to parse the mac addresses.

Some are [0-9A-Fa-f] but some are A-Z or else just upper or lower case. I am reasonably sure they should be all the same but some of them may have specific purposes.

Cheers

Brian

Please make the device name configurable

My device name is hci1 because I have an external bt device and my internal device does not work...

New update issues 0.1.543

Hello @andrewjfreyer,

Thanks for the updates. But there are a couple of things I am having issues with:

The system doesn't detect when my iphone has departed after it has detected it as in. it comes up with the errormonitor.sh: line 307: F8:95:EA:3C:40:D0: syntax error in expression (error token is ":95:EA:3C:40:D0") . If I restart it, it detects its out. But after it has detected its in, then try to scan for depart, it shows that error. For that reason, it never registers as being departed
I noticed you send a message on the topic [topic]/scan when about to start a scan, and at the end. Thanks for this as I believe its in line with my request. The issue is that its difficult to tell whether its a start of a scan or the end. Will it be possible to use something like [topic]/scan/start & [topic]/scan/end
As a follow-up to the above, when that topic is sent, the system itself reports with [Rejected] Bad MQTT scan command: SCAN (x4). I understand why, but can this message be removed or something?
My iPad used to be detected before, but now it it just doesn't see it at all, and always reporting a confidence of 0

Thanks and regards

Default trigger others

Hello @andrewjfreyer,

Thanks for the updates again.

Please it seems the new updates, the main sensor no longer triggers the others when it’s doing its periodic scans.

iOS this by design? I think it’s a good thing pls, and if it’s not can you kindly look into it or at least make it an option.

Thanks

Latest beta problems 0.1.745

The MQTT topic isn't JSON formatted

Error parsing value: 'value_json' is undefined (value: {"id":"xxxxxxxxxxxx", "retained":"true", "version":"0.1.745", "confidence":"0","name":"gPhone","timestamp":"Sat Nov 24 2018 20:19:33 GMT+0100 (CET)","manufacturer":"Unknown","type":"KNOWN_MAC","}, template: {{ value_json.confidence }})

*** PAYLOAD IS NOT VALID JSON DATA *** 

Unexpected end-of-input: was expecting closing '"' for name
 at [Source: java.io.StringReader@7751f82c; line: 1, column: 401]

pi@PiZero-Garage:~/monitor $ sudo bash monitor.sh -x -tad -m -a -u
====================== DEBUG ======================
Updated monitor.sh (v. 0.1.732) -> (v. 0.1.745)...
> removing web request caches
> retaining mqtt status reports
> trigger mode: scan only (both on arrive and depart) on trigger
> send heartbeat signal
> report all scan results mode enabled
> updating monitor.service
> preference: using default mqtt protocol version
> monitor.service updated with arguments: -x -tad -m -a
> preference: delay between scans = 3
> preference: database refresh interval = 35
> preference: max arrival scan attempts = 2
> preference: max depart scan attempts = 4
> preference: random advertisement expiration = 45
> preference: rssi threshold for triggering arrival = -70
> preference: interval until beacon is considered expired = 145
> preference: trigger a departure scan at other nodes when below [x] confidence = 25
> preference: preferred HCI device = hci0
> preference: minimum time between the same type of scan = 15
> preference: mqtt scan start/end reporting = true
> mqtt trigger: monitor/scan/ARRIVE
> mqtt trigger: monitor/scan/DEPART
> stopping other instances of 'monitor.sh'
> known device: xxxxxxxxxxxx will publish to: monitor/Garage/xxxxxxxxxxxx
> known device: xxxxxxxxxxxx will publish to: monitor/Garage/xxxxxxxxxxxx
rm: cannot remove '.pids': No such file or directory
================== BEGIN LOGGING ==================
0.1.745 07:26:12 pm monitor/scan/arrival/start
0.1.745 07:26:12 pm [CMD-INFO]	**** Started arrival scan. [x2 max rep] ****
0.1.745 07:26:14 pm [CMD-SCAN]	(No. 1)xxxxxxxxxxxx arrival?
monitor.sh: line 361: disown: 2828: no such job
0.1.745 07:26:17 pm monitor/Garage/xxxxxxxxxxxx

0.1.745 08:32:18 pm [ENQ-DEP]	Enqueued depart scan triggered.
0.1.745 08:32:20 pm [CMD-SCAN]	(No. 1) 6C:E8:5C:C6:A8:10 arrival?
monitor.sh: line 698: perform_depart_scan: command not found

0.1.745 08:32:31 pm monitor/scan/arrival/end
error! attempting to correct hci0 hardware fault.
0.1.745 08:33:28 pm [INSTRUCT] mqtt trigger depart

Colon in MQTT topic is not allowed in openHAB

I am trying to subscribe to MQTT topics provided by monitor. The openHAB MQTT binding does not allow colons (":") in a topic. Is there any chance to change the topic via configuration file from 01:02:03:04:05:06 to 010203040506 or use a separate value in the known_static_addresses file?

Beta on Alpine/Docker/Busybox

Hey,
just tried the beta channel on Docker and Alpine linux uses Busybox that has a different version of timeout - it has different params - is uses:
-s SIGINT instead of --signal SIGINT
-t TIMEOUT instead of TIMEOUT

Here is a fix for a similar issue: vishnubob/wait-for-it@8f52a81

Alternatively i can build the Docker image on top of a different/bigger image.

iBeacon rssi is duplicated in MQTT message

Using iBeacon scanning flag '-b' the rssi field is sent twice "rssi":"-83","rssi":"-83",

Upper and lower case letters in mac address

Following on from the bug #29, I note that I am seeing mac addresses in both upper and lower case being transmitted as mqtt topics.

Is the matching of the mac addresses case sensitive?

I think #29 would only work for a mac address in lowercase so the regexp should be [0-9A-Fa-f]{3} unless the case of the whole string is changed somewhere.

Service start throws an error

After configuration of nano known_static_devices and then running sudo bash monitor.sh -r, I get the following error.

pi@pi-presenceup:~/monitor $ sudo bash monitor.sh -r
Starting monitor.sh (v. 0.1.482)...
> repeated scan mode enabled
 - Error: Please customize public mac addresses in: known_static_addresses
pi@pi-presenceup:~/monitor $ sudo systemctl status  monitor.service
● monitor.service - Monitor Service
   Loaded: loaded (/etc/systemd/system/monitor.service; enabled; vendor preset: enabled)
   Active: activating (auto-restart) (Result: exit-code) since Thu 2018-08-16 18:11:13 NZST; 8s ag
  Process: 4275 ExecStart=/bin/bash /home/pi/monitor/monitor.sh & (code=exited, status=1/FAILURE)
 Main PID: 4275 (code=exited, status=1/FAILURE)

Aug 16 18:11:13 pi-presenceup systemd[1]: monitor.service: Failed with result 'exit-code'.
lines 1-7/7 (END)

What should be in the known_static_addresses file if I've already configured the known_static_devices file?

Please confirm MQTT parameters for no secure

Hi Andrew,

Is this correct when no username and password is used?

# ---------------------------
#
# MOSQUITTO PREFERENCES
#
# ---------------------------

# IP ADDRESS OF MQTT BROKER
mqtt_address=10.0.1.200

# MQTT BROKER USERNAME (OR BLANK FOR NONE)
mqtt_user=

# MQTT BROKER PASSWORD (OR BLANK FOR NONE)
mqtt_password=

# MQTT PUBLISH TOPIC ROOT
mqtt_topicpath=location

# PUBLISHER IDENTITY
mqtt_publisher_identity='kitchen'

How are options set

Just installed Monitor on a DietPi Image (if you have not tried it you should) - it looks really good.

However, how do I set options for the running service? I can see that there is a preferences file (needs a bit more explanation of each preference IMHO) and I have set the heartbeat preference via that file (note this preference is not in the template file as it is a recent addition I suspect).

Is this the right way to do it? Running the bash script from the command line with an option, just seems to run monitor interactively.

MiBand2 Data

Hello @andrewjfreyer,

Not an issue, but just got this and this is the code, for I don't know if you have seen this already. its a way to get data from the MiBand2 devices.

Do you think its something that can be integrated? Its written in Python and so I could possible modify it to work over MQTT. But as your script takes control of the hardware occasionally, might be not so easy managing the interaction.

So my thoughts are, is it possible to assume when the monitor is idle, the hardware is released and this code can be ran to carry out its tasks? I am thinking of buying this device, but mainly so I can get out of it all these data.

Regards

RSSI value empty for known device?

Hi all,
First, thank you very much @andrewjfreyer for this very interesting project! Very impressive bash application you've came up with here!
I have set it up on a Orange Pi 2+ with a bluetooth dongle connected to it. It seemed to work nicely but I realized that RSSI values are empty in MQTT status messages for known devices. Here is a sample MQTT message that gets published:
{"id":"4c:49:e3:57:12:34", "retained":"false", "version":"0.1.675", "confidence":"100","name":"MobileDevax","timestamp":"Tue Nov 20 2018 21:22:17 GMT+0100 (CET)","manufacturer":"Xiaomi Communications Co Ltd","type":"KNOWN_MAC","rssi":""}
I though it might be related to my setup, so I ordered a PI Zero W just for this purpose. It arrived today, but it shows the same behavior.

Is this intended behavior?
I would like to get a signal strength value, because I'd like to determine if the device is insede a specific room. Connection will be established before the device is inside the room, so I thought I could use RSSI to determine how close the device is to the monitor.

Am I missing something?

All scan reports are not being reported with "-a" flag

Not sure when this option stopped working, but it definitely worked in an older version.

I've been using the script with the "-r -a -m" options.

environment (-e) mqtt payload is malformed

I am using 0.1.587 with the -e flag

In my mqtt broker, the only payload I get is {
looks like it is not completing the build of the payload before publishing

Other mqtt messages are arriving fine from monitor

I am running on a Pi 3 which is using ethernet to connect to the TCP/IP network (ie not using wifi).

Q: How do I trigger a scan on all my ZeroW's after home assistant (re)start?

First of all : Love your solution! It's giving me so much more reliability to my presence detection!

I would like to have a scan triggered after I restart my Hass instance, because my monitor instances don't detect me for quite a while after a Hass restart.

My topic path = location

- id: trigger_scan
  alias: Trigger Scan
  hide_entity: true
  trigger:
    - platform: homeassistant
      event: start
  action:
    - service: mqtt.publish
      data:
        topic: 'location/scan/arrive'
        payload: '?????'

I have scanned my MQTT broker , and I got this message when I triggered monitor.sh -tr from the command-line :

location/scan/arrive
{"identity":"meterkast"}

But after re-publishing the same message to the broker, my known devices weren't scanned.

Thanks!

Every instance of monitor keeps connecting and disconnecting to MQTT broker

192.168.0.55 --> v0.1.746
192.168.0.57 --> v0.1.711
192.168.0.60 --> v0.1.746
Now I'm using this broker https://github.com/hassio-addons/addon-mqtt
But I saw the same with this add-on https://www.home-assistant.io/addons/mosquitto/

1543305176: New client connected from 192.168.0.55 as Living2327 (c1, k60, u'hass').
1543305176: New connection from 192.168.0.57 on port 1883.
1543305176: New client connected from 192.168.0.57 as mosqpub|20411-PiZero-Ke (c1, k60, u'hass').
1543305176: Client mosqpub|20411-PiZero-Ke disconnected.
1543305176: Client Living2327 disconnected.
1543305176: New connection from 192.168.0.60 on port 1883.
1543305176: New client connected from 192.168.0.60 as Garage29313 (c1, k60, u'hass').
1543305176: Client Garage29313 disconnected.
1543305176: New connection from 192.168.0.60 on port 1883.
1543305176: New client connected from 192.168.0.60 as Garage29318 (c1, k60, u'hass').
1543305176: New connection from 192.168.0.55 on port 1883.
1543305176: New client connected from 192.168.0.55 as Living2338 (c1, k60, u'hass').
1543305176: Client Living2338 disconnected.
1543305176: Client Garage29318 disconnected.
1543305178: New connection from 192.168.0.57 on port 1883.
1543305178: New client connected from 192.168.0.57 as mosqpub|20478-PiZero-Ke (c1, k60, u'hass').
1543305178: Client mosqpub|20478-PiZero-Ke disconnected.
1543305178: New connection from 192.168.0.57 on port 1883.
1543305178: New client connected from 192.168.0.57 as mosqpub|20483-PiZero-Ke (c1, k60, u'hass').
1543305178: Client mosqpub|20483-PiZero-Ke disconnected.
1543305180: New connection from 192.168.0.57 on port 1883.
1543305180: New connection from 192.168.0.57 on port 1883.
1543305180: New client connected from 192.168.0.57 as mosqpub|20493-PiZero-Ke (c1, k60, u'hass').
1543305180: New client connected from 192.168.0.57 as mosqpub|20494-PiZero-Ke (c1, k60, u'hass').
1543305180: Client mosqpub|20493-PiZero-Ke disconnected.
1543305181: Client mosqpub|20494-PiZero-Ke disconnected.
1543305181: New connection from 192.168.0.57 on port 1883.
1543305181: New connection from 192.168.0.57 on port 1883.
1543305181: New client connected from 192.168.0.57 as mosqpub|20502-PiZero-Ke (c1, k60, u'hass').
1543305181: New client connected from 192.168.0.57 as mosqpub|20505-PiZero-Ke (c1, k60, u'hass').
1543305183: Client mosqpub|20502-PiZero-Ke disconnected.
1543305183: Client mosqpub|20505-PiZero-Ke disconnected.
1543305185: New connection from 192.168.0.55 on port 1883.
1543305185: New client connected from 192.168.0.55 as Living2538 (c1, k60, u'hass').
1543305185: New connection from 192.168.0.60 on port 1883.
1543305185: New client connected from 192.168.0.60 as Garage29412 (c1, k60, u'hass').
1543305185: Client Living2538 disconnected.
1543305185: New connection from 192.168.0.55 on port 1883.
1543305185: New client connected from 192.168.0.55 as Living2543 (c1, k60, u'hass').
1543305185: Client Garage29412 disconnected.
1543305185: Client Living2543 disconnected.
1543305185: New connection from 192.168.0.60 on port 1883.
1543305185: New client connected from 192.168.0.60 as Garage29417 (c1, k60, u'hass').
1543305185: Client Garage29417 disconnected.
1543305190: New connection from 192.168.0.55 on port 1883.
1543305190: New client connected from 192.168.0.55 as Living2583 (c1, k60, u'hass').
1543305190: Client Living2583 disconnected.
1543305190: New connection from 192.168.0.60 on port 1883.
1543305190: New client connected from 192.168.0.60 as Garage29490 (c1, k60, u'hass').
1543305190: Client Garage29490 disconnected.
1543305190: New connection from 192.168.0.55 on port 1883.
1543305190: New client connected from 192.168.0.55 as Living2588 (c1, k60, u'hass').
1543305190: Client Living2588 disconnected.
1543305190: New connection from 192.168.0.60 on port 1883.
1543305190: New client connected from 192.168.0.60 as Garage29495 (c1, k60, u'hass').
1543305190: Client Garage29495 disconnected.
1543305193: New connection from 192.168.0.55 on port 1883.
1543305193: New client connected from 192.168.0.55 as Living2619 (c1, k60, u'hass').
1543305194: Client Living2619 disconnected.
1543305194: New connection from 192.168.0.55 on port 1883.
1543305194: New client connected from 192.168.0.55 as Living2632 (c1, k60, u'hass').
1543305194: Client Living2632 disconnected.
1543305195: New connection from 192.168.0.57 on port 1883.
1543305195: New client connected from 192.168.0.57 as mosqpub|20694-PiZero-Ke (c1, k60, u'hass').
1543305195: Client mosqpub|20694-PiZero-Ke disconnected.
1543305195: New connection from 192.168.0.57 on port 1883.
1543305195: New client connected from 192.168.0.57 as mosqpub|20699-PiZero-Ke (c1, k60, u'hass').
1543305195: Client mosqpub|20699-PiZero-Ke disconnected.
1543305196: New connection from 192.168.0.55 on port 1883.
1543305196: New client connected from 192.168.0.55 as Living2767 (c1, k60, u'hass').
1543305196: Client Living2767 disconnected.
1543305196: New connection from 192.168.0.55 on port 1883.
1543305196: New client connected from 192.168.0.55 as Living2772 (c1, k60, u'hass').
1543305196: Client Living2772 disconnected.
1543305198: New connection from 192.168.0.55 on port 1883.
1543305198: New client connected from 192.168.0.55 as Living2780 (c1, k60, u'hass').
1543305198: Client Living2780 disconnected.
1543305199: New connection from 192.168.0.55 on port 1883.
1543305199: New client connected from 192.168.0.55 as Living2785 (c1, k60, u'hass').
1543305199: Client Living2785 disconnected.
1543305210: New connection from 192.168.0.57 on port 1883.
1543305210: New client connected from 192.168.0.57 as mosqpub|20713-PiZero-Ke (c1, k60, u'hass').
1543305210: Client mosqpub|20713-PiZero-Ke disconnected.
1543305210: New connection from 192.168.0.57 on port 1883.
1543305210: New client connected from 192.168.0.57 as mosqpub|20718-PiZero-Ke (c1, k60, u'hass').
1543305210: Client mosqpub|20718-PiZero-Ke disconnected.
1543305214: New connection from 192.168.0.57 on port 1883.
1543305214: New client connected from 192.168.0.57 as mosqpub|20743-PiZero-Ke (c1, k60, u'hass').
1543305214: Client mosqpub|20743-PiZero-Ke disconnected.
1543305214: New connection from 192.168.0.57 on port 1883.
1543305214: New client connected from 192.168.0.57 as mosqpub|20748-PiZero-Ke (c1, k60, u'hass').
1543305214: Client mosqpub|20748-PiZero-Ke disconnected.
1543305215: New connection from 192.168.0.57 on port 1883.
1543305215: New client connected from 192.168.0.57 as mosqpub|20815-PiZero-Ke (c1, k60, u'hass').
1543305216: Client mosqpub|20815-PiZero-Ke disconnected.
1543305216: New connection from 192.168.0.57 on port 1883.
1543305216: New client connected from 192.168.0.57 as mosqpub|20820-PiZero-Ke (c1, k60, u'hass').
1543305216: Client mosqpub|20820-PiZero-Ke disconnected.
1543305218: New connection from 192.168.0.57 on port 1883.
1543305218: New client connected from 192.168.0.57 as mosqpub|20836-PiZero-Ke (c1, k60, u'hass').

status topic only ever shows offline (correctly), never states online

Hi,

Great application.

I am using 0.1.616 (and have noticed this also in earlier versions)

I expected the status topic to publish an online message once connected to the mqtt broker - which I could use to detect health of the connection between monitor and my server. I am not sure if this is by design.

The LWT is working as I get offline status when monitor is stopped ... but I would prefer to not have to assume the status as online and rather read a confirmation in status that the system is online.

Any clarification would be appreciated.

In any case, if not a bug I propose this as a feature request!

edit: looking at the mqtt module around line 33 it does appear to try and set status. I only see the LWT message set later in the routine. I would assume the LWT should be set in the same publish action anyway (ie post this, if I am gone, post LWT)

edit 2: I would also like to sugest that the status is always posted with retain flag true irrespective of the other topics retain flag. Then, anytime you subscribe from your master system (like homeassistant), the status of the monitor link to mqtt is available.

I would also suggest the environment post should be retained irrespective of other topic retain setting. Agaain, it allows a client that connects to mqtt after a post to gather information about status.

Regards
Phil

Should "monitor/xxxxx/status" report every 15 sec?

On the latest beta 0.1.707
monitor/xxxxx/status reports every 15 seconds, just like heartbeat, is this normal?

Invalid connection from (client @=x.x.x.x:XXXX) : [MQTT-3.1.2-1] Incorrect protocol name: "MQIsdp"

I’m trying to use monitor.sh but I have the following error using Home Assistant MQTT server:

Invalid connection from (client @=x.x.x.x:XXXX) : [MQTT-3.1.2-1] Incorrect protocol name: "MQIsdp"

I found out that mosquitto_pub has to use the following option -V mqttv311.

Would it be possible to have an option in the configuration file to add some parameters ?

Scan complete feedback

Please when I run a scan on monitors having the -t flag, can there be some sort of feedback that tells me over mqtt that its done scanning?

it is view-able in console, as **** completed scan. ****. Just needs to be sent over mqtt as something that's easily readable.

Regards

How to update to the newest version?

Just like the title says...
How to update to the newest version?

Do not use if you are already running as root (systemd service)

It looks like your script executes all hci commands using sudo. Which is fine if you run it as pi user. But for the systemd service it is not needed:

Sep 06 13:05:17 hass sudo[30012]: root : TTY=unknown ; PWD=/opt/monitor ; USER=root ; COMMAND=/bin/hciconfig hci1 down
Sep 06 13:05:17 hass sudo[30012]: pam_unix(sudo:session): session opened for user root by (uid=0)
Sep 06 13:05:17 hass sudo[30012]: pam_unix(sudo:session): session closed for user root
Sep 06 13:05:19 hass sudo[30021]: root : TTY=unknown ; PWD=/opt/monitor ; USER=root ; COMMAND=/bin/hciconfig hci1 up
Sep 06 13:05:19 hass sudo[30021]: pam_unix(sudo:session): session opened for user root by (uid=0)
Sep 06 13:05:19 hass sudo[30021]: pam_unix(sudo:session): session closed for user root
Sep 06 13:05:19 hass sudo[30029]: root : TTY=unknown ; PWD=/opt/monitor ; USER=root ; COMMAND=/bin/rm main_pipe
Sep 06 13:05:19 hass sudo[30029]: pam_unix(sudo:session): session opened for user root by (uid=0)
Sep 06 13:05:19 hass sudo[30029]: pam_unix(sudo:session): session closed for user root
Sep 06 13:05:19 hass sudo[30038]: root : TTY=unknown ; PWD=/opt/monitor ; USER=root ; COMMAND=/bin/rm log_pipe
Sep 06 13:05:19 hass sudo[30038]: pam_unix(sudo:session): session opened for user root by (uid=0)
Sep 06 13:05:19 hass sudo[30038]: pam_unix(sudo:session): session closed for user root

This will just spam the log and reduce the lifespan of the sdcard.

Error during install

I followed the instructions to install on a Pi Zero W, and got the following error at step 3:

pi@raspberrypi:~ $ sudo apt-get install rpi-update/raspbian
Reading package lists... Done
Building dependency tree       
Reading state information... Done
E: Release 'raspbian' for 'rpi-update' was not found

Is this just an issue with the instructions? I went on to run the rpi-update and it worked ok.

Mac address bug strangeness

Fresh install (first time user).

Added the following to the behavior_preferences

PREF_PUBLIC_MODE=true
PREF_BEACON_MODE=true
PREF_HEARTBEAT=true

Known mac addresses (slightly modified)

48:80:df:98:f1:f2 Brian #comment
c0:ee:fb:6c:0e:f2 OnePlusX

On restart, the first mac address, that was reporting every 240 seconds, did not report for ages (might be a setting issue).

The second mac address is reported as below on MQTT topic monitor/ha-monitor/3c0:ee:fb:6c:0e:f2

{
	"id": "3c0:ee:fb:6c:0e:f2",
	"retained": "false",
	"version": "0.1.661",
	"confidence": "0",
	"name": "Undiscoverable Device Name",
	"timestamp": "Tue Sep 25 2018 22:32:07 GMT+0100 (BST)",
	"manufacturer": "Unknown",
	"type": "KNOWN_MAC",
	"rssi": ""
}

Note the topic and mac address start with 3c0

On starting interactively;

> preference: delay between scans = 3
> preference: periodic arrive/depart check interval = 15
> preference: periodic arrive interval = 45
> preference: periodic depart interval = 90
> preference: database refresh interval = 35
> preference: max arrival scan attempts = 2
> preference: max depart scan attempts = 4
> preference: random advertisement expiration = 45
> preference: beacon rssi change required for reporting = 10
> preference: bluetooth environmental report frequency = 300
> preference: forced departure check interval = 240
> preference: interval until beacon is considered expired = 145
> preference: trigger a departure scan at other nodes below [x] confidence = 25
> preference: preferred HCI device = hci0
> preference: minimum time between the same type of scan = 15
> preference: mqtt scan start/end reporting = false
> mqtt trigger: monitor/scan/ARRIVE
> mqtt trigger: monitor/scan/DEPART
> known device: 48:80:df:98:f1:f2 will publish to: monitor/ha-monitor/48:80:df:98:f1:f2
> known device: c0:ee:fb:6c:0e:f2 will publish to: monitor/ha-monitor/c0:ee:fb:6c:0e:f2

Final thought - I swapped these 2 mac addresses round in the known_static_addresses file - no difference.

Heartbeat MQTT Message

Would it be possible to implement a heartbeat message? I would like to use this to check if the service is running on the various devices.

An idea on implementation would be
Topic: $mqtt_topicpath/heartbeat Payload: "{\"identity\":\"$mqtt_publisher_identity\"}"

In homeassistant, one could use this single message (and the state.last_updated metadata of the message) to see if updates are still coming in. I find my (remote) Pi Zero W somewhat unreliable in keeping the WiFi alive, so with an automation I can toggle power from the main Pi to give the Zero a reboot.

iBeacon not counting down in confidence

Hey Andrew,

I'm using an iBeacon on my keychain for my arrival/departing at home. Using '-b' as an option it gives me quickly 100 confidence and publishes this at regular intervals while the iBeacon is near. The problem is that the confidence is never decreasing even while using the setting 'PREF_BEACON_EXPIRATION=120' (tried different intervals here) when the iBeacon is not near the raspberry pi. This gives a 100 confidence 24/7 in home assistant as no other confidence is ever reported.

The published mqtt message:
{"id":"E2C56DB5-DFFB-48D2-B060-D0F5A71096E0-0-0", "retained":"false", "version":"0.1.672", "confidence":"100","name":"Beacon ","timestamp":"Mon Oct 08 2018 18:43:40 GMT+0200 (CEST)","manufacturer":"Unknown","type":"APPLE_IBEACON","rssi":"-87","rssi":"-87","power":"-59"}

I think this is a similar issue as mentioned in the thread at the home assistant forum by another user:
https://community.home-assistant.io/t/monitor-reliable-multi-user-distributed-bluetooth-occupancy-presence-detection/68505/153?u=ikbenfrank

Thank you for any help provided and let me know if you need any more information or test something.

BLE not picking up Tile devices

The script is running and publishing to my mqtt broker, but I also added the -b switch to monitor, but it doesn't seem to pick up my Tile devices, however when running hcitool lescan from the command line they do show up.

Heartbeat message

In the latest beta I'm using -m and there is no heartbeat signal send...

Starting monitor.sh (v. 0.1.732)...
> removing web request caches (to determine device manufacturer)
> retaining mqtt status reports
> send heartbeat signal
> report all scan results mode enabled
> updating monitor.service
> preference: using default mqtt protocol version
> monitor.service updated with arguments: -x -m -a
> preference: delay between scans = 3
> preference: database refresh interval = 35
> preference: max arrival scan attempts = 2
> preference: max depart scan attempts = 4
> preference: random advertisement expiration = 45
> preference: rssi threshold for triggering arrival = -70
> preference: beacon rssi change required for reporting = 10
> preference: interval until beacon is considered expired = 145
> preference: trigger a departure scan at other nodes when below [x] confidence = 25
> preference: preferred HCI device = hci0
> preference: minimum time between the same type of scan = 15
> preference: mqtt scan start/end reporting = true
> mqtt trigger: monitor/scan/ARRIVE
> mqtt trigger: monitor/scan/DEPART
> stopping other instances of 'monitor.sh'

Migrate from presence

Hi Andrew,

Great work, thank you. I've been using presence for some months on two Pi Zero's and it has been rock solid but lately the broker has been connecting and disconnecting both Pi's all the time. I've tried two different brokers, same deal.

1534132924: New connection from 10.0.1.52 on port 1883.
1534132924: New client connected from 10.0.1.52 as mosqpub|725-pi-presence (c1, k60, u'').
1534132924: Client mosqpub|725-pi-presence disconnected.
1534132927: New connection from 10.0.1.51 on port 1883.
1534132927: New client connected from 10.0.1.51 as mosqpub|29235-pi-presen (c1, k60, u'').
1534132927: Client mosqpub|29235-pi-presen disconnected.

I'm looking to change over to monitor to try that. What's the easiest way to uninstall presence dependencies and move over to monitor?

iBeacon: unescaped JSON in manufacturer information

Home Assistant has been unable to parse the iBeacon messages. It appears that monitor is creating a malformed JSON message due to and unescaped\ in the manufacturer field "manufacturer":"<html>\r".

mosquitto_sub
location/first_floor/FDA50693-A4E2-4FB1-AFCF-C6EB07647825-10-8 {"id":"FDA50693-A4E2-4FB1-AFCF-C6EB07647825-10-8", "retained":"false", "version":"0.1.675", "confid","type":"APPLE_IBEACON","rssi":"-70","rssi":"-70","power":"-59"}Oct 30 2018 15:32:43 GMT+0000 (UTC)","manufacturer":"<html>

monitor.sh

{
        retain: false
        version : 0.1.675
        address : FDA50693-A4E2-4FB1-AFCF-C6EB07647825-10-8
        confidence : 100
        name : Undiscoverable Device Name
        timestamp : Tue Oct 30 2018 15:37:10 GMT+0000 (UTC)
        manufacturer : <html>
        type : APPLE_IBEACON
        rssi : -69 
        power : -59 
}

Home Assistant MQTT Debug

2018-10-30 08:38:09 DEBUG (MainThread) [homeassistant.components.mqtt] Received message on location/first_floor/FDA50693-A4E2-4FB1-AFCF-C6EB07647825-10-8: b'{"id":"FDA50693-A4E2-4FB1-AFCF-C6EB07647825-10-8", "retained":"false", "version":"0.1.675", "confidence":"100","name":"Undiscoverable Device Name","timestamp":"Tue Oct 30 2018 15:38:08 GMT+0000 (UTC)","manufacturer":"<html>\r","type":"APPLE_IBEACON","rssi":"-70","rssi":"-70","power":"-59"}'
2018-10-30 08:38:09 ERROR (MainThread) [homeassistant.helpers.template] Error parsing value: 'value_json' is undefined (value: {"id":"FDA50693-A4E2-4FB1-AFCF-C6EB07647825-10-8", "retained":"false", "version":"0.1.675", "confidence":"100","name":"Undiscoverable Device Name","timestamp":"Tue Oct 30 2018 15:38:08 GMT+0000 (UTC)","manufacturer":"<ht","type":"APPLE_IBEACON","rssi":"-70","rssi":"-70","power":"-59"}, template: {{ value_json['confidence'] }})

Also retain the monitor/......../status topic

I use

- platform: mqtt
  state_topic: 'monitor/Garage/D0:2B:20:xxxxxxxxx'
  value_template: '{{ value_json.confidence }}'
  unit_of_measurement: '%'
  name: 'gPhone garage'
  availability_topic: "monitor/Garage/status"
  payload_available: "online"
  payload_not_available: "offline"
  json_attributes:
    - id
    - name
    - rssi
    - version
    - manufacturer
    - type
    - timestamp
    - retained
    - confidence

as my MQTT sensor but when I restart Hass, all MQTT sensors are unavailable because the availability_topic isn't retained, so I have to restart al monitor services.
Btw I use the -x flag

Little usage help and missing mqtt messages of known devices

Hey Andrew,

I really appreciate your work here. I switched from presence to monitor but right now I don't get it how this is supposed to work.

I have a lot of different kinds of bluetooth devices (laptops, headsets, ...) but for me it'd be enough to "track" 4 phones. I started from scratch with monitor and just copied the content of known_static_address over to monitor.

de:ad:be:ef:fe:ed codegrau

right after installing and starting monitor service on my raspberries there are like hundreds of mqtt messages on each from unknown bluetooth devices (some of them are my laptops & stuff).

Maybe you could help me out here, how to use monitor.sh the right way. Do I have to add all these unknown devices to each and every raspberry in my flat? do i have to expect hundreds of mqtt messages for each visitor of my neighbors? Which parameters of monitor.sh are best for simply checking these four phones?

And BTW - I don't even get messages from my devices in known_static_addresses via mqtt... is that how it meant to be?

Can't discriminate between floors

I have two monitor nodes one on each floor. Both show 100% whenever my Galaxy 7 or my wife's Iphone 7 are home. I have separated the the nodes as far as possible from each other. How do I tell which floor each phone is on.

I also see that rssi is not reported in the mqtt payload.

Arrive/Depart Scans Timer

Hello @andrewjfreyer,

If one was to manually set the system to scan using either [topic]/scan/ARRIVE or [topic]/scan/DEPART, is it possible to reset the internal scan timer of the system?

What I mean is since I have mine set to scan every 120 sec, if send a scan using my system when its 60 secs in, it resets its internal timer and scans after another 120 secs.

Thanks

Apple Watch Confidence stay 0

Hi,

I added monitor, and it is running publishing to my mqtt broker. The iphones seems to work 100%, but out Apple watches stays on a confidence of 0.

{
"retained": "false",
"version": "0.1.482",
"confidence": "0",
"name": "ekke's iWatch ",
"timestamp": "Wed Aug 29 2018 20:09:23 GMT+0200 (SAST)",
"manufacturer": "Apple, Inc.",
"type": "Known Static MAC"
}

Any suggestions?

Error: The connection was lost.

First off, thanks so much for sharing this. Its exactly the type of solution i've been looking for.

I've followed all the instructions but im seeing an error when i run the monitor.sh script

0.1.675 10:40:46 am location/main floor/11:22:33:44:55:66
{
	retain: false
	version : 0.1.675
	address : 11:22:33:44:55:66
	confidence : 100
	name : Brodie's iPhone 
	timestamp : Wed Nov 21 2018 10:40:45 GMT-0600 (CST)
	manufacturer : Apple, Inc.
	type : KNOWN_MAC
}
Error: The connection was lost.

Here is my mqtt_preferences:

# ---------------------------

# MOSQUITTO PREFERENCES
#
# ---------------------------

# IP ADDRESS OF MQTT BROKER
mqtt_address=192.168.0.33

# MQTT BROKER USERNAME (OR BLANK FOR NONE)
mqtt_user=[REDACT]

# MQTT BROKER PASSWORD (OR BLANK FOR NONE)
mqtt_password=[REDACT]

# MQTT PUBLISH TOPIC ROOT
mqtt_topicpath=location

# PUBLISHER IDENTITY
mqtt_publisher_identity='main floor'

# MQTT PORT
mqtt_port='4884'

# MQTT CERTIFICATE FILE (LEAVE BLANK IF NONE)
mqtt_certificate_path=''

Latest beta 0.1.746 line 322: Unknown: command not found when lowercase mac adress

monitor.sh throws an unknown command when there is a lowercase adress known_static_addresses
Tryed to debug my Phone presence detection with this.

https://github.com/andrewjfreyer/monitor/blob/beta/monitor.sh#L322

0.1.746 04:00:35 pm [CMD-RAND]  41:A8:FC:A7:AD:9A SCAN_RSP -68 dBm (new device arrival trigger)
0.1.746 04:00:35 pm [CMD-INFO]  **** Started arrival scan. [x2 max rep] ****
0.1.746 04:00:35 pm [CMD-RAND]  53:95:B6:2A:5D:58 SCAN_RSP -71 dBm (new device arrival trigger)
0.1.746 04:00:35 pm [CMD-SCAN]  (No. 1) 94:65:2d:6a:eb:ef arrival?
monitor.sh: line 322: Unknown: command not found
0.1.746 04:00:43 pm [CMD-SCAN]  (No. 1) CE:CD:6C:5C:C1:D4 arrival?
0.1.746 04:00:52 pm [CMD-SCAN]  (No. 2) 94:65:2d:6a:eb:ef arrival?
monitor.sh: line 322: Unknown: command not found
0.1.746 04:01:00 pm [CMD-SCAN]  (No. 2) CE:CD:6C:5C:C1:D4 arrival?
0.1.746 04:01:08 pm [CMD-INFO]  **** Completed arrival scan. ****
0.1.746 04:01:08 pm [CMD-NAME]  94:65:2d:6a:eb:ef Oneplus5bt  OnePlus Technology Shenzhen Co Ltd
0.1.746 04:01:08 pm [CMD-NAME]  CE:CD:6C:5C:C1:D4 Unknown Name  Unknown
monitor.sh: line 322: Unknown: command not found
0.1.746 04:02:54 pm monitor/Mopidy/08:DF:1F:E7:66:9F

maybe an Idea what it could be that the confidence never goes over 0%

Using a small ble usb transmitter

Hello Andrew

Following a suggestion on the HA forum, I purchased a few small ble transmitters, with a view to trying the in a car as an arrival sensor. This is the hardware

I am having some issues with the script recognising them. In particular, it doesn't! Though, looking at the logs, my suspicion is that the powering on of a device does trigger a scan.

If I run (on a Pi, not a Pi Zero running monitor) the command
sudo hcitool lescan & \; sudo hcidump
then I get the output

LE Scan ...
98:7B:F3:49:BA:71 (unknown)
98:7B:F3:49:BA:71 ebeoo-49BA71
<other devices redacted>

(Note that the first MAC address returned does not have a name, whereas the second returns the name of the device.)

If, on the same Pi, I run
hcitool name 98:7B:F3:49:BA:71
then nothing is returned.

This makes me wonder whether the device reliably returns its name to the monitor script. Do you have any thoughts on this behaviour? What information can I supply to assist with any diagnosis?

(FWIW my suspicion is that the transmit power on these things is going to be too low to usefully use in my car anyway.)

Change topic pad for arrive/depart trigger

Since I still have problems with an iPhone 6s loosing connection at night...
I've made a sensor for arrive/depart:

- platform: mqtt
  state_topic: 'monitor/scan/arrive'
  value_template: '{{ value_json.identity }}'
  expire_after: 60
  name: Mqtt Aankomst

And I made 2 triggers from HA

  mqqt_arrive_trigger:
    sequence:
      - service: mqtt.publish
        data_template:
          topic: monitor/scan/arrive
          payload: "{'identity':'HA'}"

I want to change the topic path where the nodes are listening to/sending out, for depart or arrive scans.
So I can let HA decide to send the topic to the nodes
Node send monitor/scan/should_arrive_trigger -> Ha send monitor/scan/arrive

Graphics for Presence Comparison in README

Correcting HCI error

When running the script from the command line, I often see messages like these:

0.1.629 09:39:01 pm [ERROR] Correcting HCI error: Disable scan failed: Input/output error
0.1.629 09:39:11 pm [ERROR] Correcting HCI error: Invalid device: Network is down

What do they mean? What to do?

iPhone is going completely off radar....

I use 3 times a raspberry pi zero and a raspberry pi 3b to monitor some bluetooth devices.
I use them all with options -b -g -e -a -m
known_static_addresses:

D0:2B:20:E7:XX:XX iPhone1 #(iPhone8)
6C:8D:C1:B7:XX:XX iPhone2 #(iPhone6s)
C8:3B:BB:14:XX:XX vívosmartHR
E4:31:74:88:XX:XX vívofit 
5C:AD:CF:EB:XX:XX iPad1
F8:62:14:83:XX:XX iPad2
FD:BE:FE:17:XX:XX Forerunner735XT

With iPhone1 this all works

iPhone2 is going completely off the radar at night while we are in the same room

How can I debug this?

BTW:
And all the other bluetooth devices are always "confidence":"0"

Memory leak

I am seeing a gradual rise in memory usage.

The Pi it is installed on is a DietPi base image that only runs Monitor.

On boot this is what I see in htop:

After a while (you can see the up time, memory use by one of the monitor processes has risen significantly.

BTW, why are there so many processes?

I also note that the CPU use regularly maxes out.

iphone 7 strange behavior

I got everything installed and it is working wonderfully for my Android phone but something strange is occurring with my wife's iPhone 7. It has been indicating a confidence of '0' all day with the exception of (one and only one) brief moment when I turned on her bluetooth it went to '100' and then it returned to '0' quickly. I have not been able to recreate any reading above '0' since then.

Finally, I ran from command line with -g flag and things got more strange. iPhone was still at confidence '0' but now some 'Undiscoverable Device Name' and 'Unresponsive Devices' began to get logged to the MQTT topic. These devices were shown as GENERIC_BEACONS manufactured by Apple, had similar MAC addresses to each other, and had confidence of '100'.

I then switched to the Beta version to see if that would resolve anything. The iphone is still at '0' but the beacons did not return when run from the command line again.

I don't have a beacon of any kind in the house and I dont have any beacons set up in the configuration. Could these be coming from the iphone? Any ideas on how to go about resolving this? What information would be helpful?

This is an incredible app and will be great for me once I can work out the kinks.
Thank you for all your hard work.

Chris

andrewjfreyer / monitor Goto Github PK

monitor's People

Contributors

Stargazers

Watchers

Forkers

monitor's Issues

Recommend Projects

Recommend Topics

Recommend Org