I use 3 times a raspberry pi zero and a raspberry pi 3b to monitor some bluetooth devi

Do the vivosmart devices advertise as beacons? <p dir="

iPhone is going completely off radar.... about monitor HOT 10 CLOSED

andrewjfreyer commented on June 15, 2024

iPhone is going completely off radar....

from monitor.

Comments (10)

andrewjfreyer commented on June 15, 2024

Are you actually monitoring for beacons as well? If so, there's no need to use the -b or -g flags as these features (when not in use) will merely slow down your existing system. I'd suggest setting some of your raspberry pis to trigger only... you look like you are scanning very frequently.

Do the vivosmart devices advertise as beacons?

from monitor.

gieljnssns commented on June 15, 2024

Do the vivosmart devices advertise as beacons?

I don't think so, how do I check this?

from monitor.

andrewjfreyer commented on June 15, 2024

Run monitor from the command line, manually, with the -g flag

from monitor.

andrewjfreyer commented on June 15, 2024

Please update and reopen this issue if phones are still not shown.

from monitor.

gieljnssns commented on June 15, 2024

I didn't find the time to check this

Do the vivosmart devices advertise as beacons?

I've updated to 0.1.666
when I run monitor -g, I get

0.1.666 06:01:41 PM [CMD-RSSI]	FD:BE:FE:17:E4:xx Undiscoverable Device Name RAND RSSI: -86 dBm (Fast Motion Departing, changed -86)
0.1.666 06:01:41 PM [CMD-RAND]	FD:BE:FE:17:E4:x ADV_IND -86 dBm
./support/data: line 40: warning: command substitution: ignored null byte in input
..........
0.1.666 06:03:25 PM monitor/Boven/FD:BE:FE:17:E4:xx
{
	retain: false
	version : 0.1.666
	address : FD:BE:FE:17:E4:xx
	confidence : 29
	name : Forerunner735XT
	timestamp : Thu Sep 27 2018 18:03:24 GMT+0200 (CEST)
	manufacturer : <html>
	type : GENERIC_BEACON
	rssi : -85
}
....
0.1.666 06:03:59 PM monitor/Boven/FD:BE:FE:17:E4:xx
{
	retain: false
	version : 0.1.666
	address : FD:BE:FE:17:E4:xx
	confidence : 5
	name : Forerunner735XT
	timestamp : Thu Sep 27 2018 18:03:59 GMT+0200 (CEST)
	manufacturer : <html>
	type : GENERIC_BEACON
	rssi : -85
}
....
0.1.666 06:04:34 PM [CHECK-DEL]	FD:BE:FE:17:E4:xx expired after 173 (0 bias) seconds
0.1.666 06:04:34 PM monitor/Boven/FD:BE:FE:17:E4:xx
{
	retain: false
	version : 0.1.666
	address : FD:BE:FE:17:E4:xx
	confidence : 0
	name : Forerunner735XT
	timestamp : Thu Sep 27 2018 18:04:34 GMT+0200 (CEST)
	manufacturer : <html>
	type : GENERIC_BEACON
}

when I turn on the bluetooth Fram my forerunner
and when running monitor -b I get

0.1.666 06:01:40 PM [CMD-RAND]	FD:BE:FE:17:E4:xx ADV_IND -92 dBm
./support/data: line 40: warning: command substitution: ignored null byte in input

For the iPhone that is going off radar;
I will test with 2 raspberry monitor.sh -e -a -m -t and 2 with monitor.sh -e -a -m

I will report back.....

from monitor.

andrewjfreyer commented on June 15, 2024

Looks like you have identified at least one bug. Your manufacturer should not be , so clearly your manufacturer cache file is corrupted.

And it looks like the Forerunner device is reporting as both a public device and a random device. That's unconventional... haha. This shows that we should include the FD:BE:FE:17:E4:xx device in our known_beacons file.

from monitor.

andrewjfreyer commented on June 15, 2024

Another user confirmed that placing a forerunner's address in the known_beacons file appears to clear this error. Closing for now.

from monitor.

gieljnssns commented on June 15, 2024

Now I scanning 2 raspberry with monitor.sh -e -a -m -t -b and 2 with monitor.sh -e -a -m -b
Still no Garmin device detected, also those 2 iPads are always confidence : 0

But my biggest problem is my wife's iPhone;
now using

- platform: min_max
    name: "mPhone BT thuis"
    type: max
    round_digits: 0
    entity_ids:
      - sensor.mphone_boven
      - sensor.mphone_keuken
      - sensor.mphone_living
      - sensor.mphone_waskot

iPhone min-max:

This image is from the node in our bedroom (uses monitor.sh -e -a -m -b):

She is in that room from the green arrow until now

This is my iPhone (iPhone1):

from monitor.

andrewjfreyer commented on June 15, 2024

How far, spatially, are you raspberry pis from one another? It sure seems like these settings will cause a ton of 2.4GHz interference for an ordinary-sized house of a few thousand square feet.

Also, the -t flag is an invalid flag on its own, so if you have updated your script, neither of these instances are likely reporting. Do you mean -td? Do you mean -tda? Do you mean on the other instances to include -tr?

from monitor.

gieljnssns commented on June 15, 2024

Sorry for the delay...
Maybe my pis where to close to each other, so I only have 2 of them, one on each side of the house.
The one on the entrance is running /home/pi/monitor/monitor.sh -e -a -tr
The one in the garden is running /home/pi/monitor/monitor.sh -e -a -tad
But I still have problems with the iPhone 6S 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/arrive? -> Ha send monitor/scan/arrive

from monitor.

iPhone is going completely off radar.... about monitor HOT 10 CLOSED

Comments (10)

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent