what version are you running? on what device?
Currently latest Beta but this was occurring with latest master as well. Running a Pi Zero W.
Thanks for the quick reply.
Unfortunately itâs not working still.
When I start the service with -b only, it finds the tag MAC and UUID at 100 confidence, but when I take out the battery, the UUID slowly goes down to 0 but the MAC stays at 100.
Also, when I start the service with the battery already out, the UUID starts at 0 but the MAC goes straight to 100.
This part is normal, for now at least. Many beacons do not broadcast their UUID on every advertisement, so we have to wait until we can find an association between a MAC address and a UUID.
Thanks for the note. Iâll continue testing.
Just to clarify, the UUID works well. It starts at 0 when the tag is without battery or out of range. The MAC goes to 100 confidence no matter if the tag is present, out of rage, in an RF blocking bag or has itâs battery pulled when Monitor is started.
When watching the terminal window, moments after the tag is turned on, Monitor sees itâs MAC and UUID and reports; it just doesnât ever expire the MAC when the tag is turned off. The UUID does slowly go down after some time.
I can also confirm that the Google Home Device Tracker that takeâs the Tagâs MAC (but doesnât work at all with the 2 iPhones we use here) is working correctly with this tag.
Also, this isnât a big deal for me as I can easily use just the UUID; just figure you should know that the MAC isnât working as expected with this tag.
Thanks again!
Appreciate that. It sounds like the MAC address broadcast by your beacon is a public address?
Just a couple things I wanted to give a heads up to. Personally I have stopped using the Availability topics. For ME anytime I would send a restart command the retained value from the MQTT server would not kick in. the sensor would say unavailable and eventually would get values. This messed up a lot of my automations. Essentially kicking them off twice.
Furthermore I have changed my depart script. I dont really want to restart everytime, just when the values arent matching. Here is what I am currently testing? (hopefully this code is correct. ) This is the scripts section.
mqtt_depart:
sequence:
- delay: 00:00:10
- data_template:
topic: location/scan/depart
service: mqtt.publish
- delay: 00:00:20
- data_template:
topic: location/scan/depart
service: mqtt.publish
- delay: 00:00:30
- data_template:
topic: location/scan/depart
service: mqtt.publish
- delay: 00:00:40
- data_template:
topic: location/scan/depart
service: mqtt.publish
- delay: 00:00:20
- service_template: >
{% if states.sensor.benji_bedroom.state | float != states.sensor.benji_living_room.state | float %}
script.mqtt_restart
{% elif states.sensor.bridget_bedroom.state | float != states.sensor.bridget_living_room.state | float %}
script.mqtt_restart
{% else %}
script.do_nothing
{% endif %}
mqtt_restart:
sequence:
- data_template:
topic: location/scan/restart
service: mqtt.publish
- delay: 00:00:40
- service_template: >
{% if states.sensor.benji_bedroom.state | float != states.sensor.benji_living_room.state | float %}
script.mqtt_notify_fail
{% elif states.sensor.bridget_bedroom.state | float != states.sensor.bridget_living_room.state | float %}
script.mqtt_notify_fail
{% else %}
script.do_nothing
{% endif %}
do_nothing:
sequence:
- delay: 00:00:01
mqtt_notify_fail:
sequence:
- service: notify.benji
data:
title: Sensor Mismatch
message: Your sensors are missmatched after a restart
Thanks for the continued updates to this useful script. I too agree that the HA availability topics are ⌠in need of work.
I have a similar need and am exploring the idea of using both. Room-Assistant doesnât do phone detection well, but Monitor seems to supplement that. I was debating about using a Bayesian sensor per room. Curious how you progressed with this.
To be honest I could not find an easy way to do that, and I am still looking for a simpler way.
Hey benjimatt,
I like it!
First off, Iâm just getting my programming hands wet so Iâm not sure if the following is correct but Iâll give it a shotâŚ
I see 1 problem with your script⌠The reason for having multiple Pi Monitors is to get better coverage in our homes.
For example, in a situation with 2 Monitors and 2 Devices being monitored, Monitor A might see Device A as 100% confidence, while Monitor B Might see Device A at 0% confidence.
So, if the owner of Device B leaves the house while the owner of Device A stays home (while having different confidence percentages when it happens), the mqtt_restart
script would fire.
I assume you are doing the restart & mismatch notification because you are running Monitor with the -trd
tag and sometimes, after the 4 depart
messages, one of your monitor instances will still show >0 confidence even though youâve left?
Why not just have it restart if any of your devices show confidence thatâs neither 0 nor 100?
What do you think of this instead?:
- service_template: >
{% if states.sensor.benji_bedroom.state | float in(range(1,100)) %}
script.mqtt_restart
{% elif states.sensor.benji_living_room.state | float in(range(1,100)) %}
script.mqtt_restart
{% elif states.sensor.bridget_bedroom.state | float in(range(1,100)) %}
script.mqtt_restart
{% elif states.sensor.bridget_living_room.state | float in(range(1,100)) %}
script.mqtt_restart
{% else %}
script.do_nothing
{% endif %}
It just checks if any of your sensors confidence level is between 0 & 100.
That should work no?
I know that it doesnât account for if one of Device Bâs 2 sensors (device still home) has a confidence between 0 & 100; but usually, confidence goes from 0 to 100 or back pretty fast.
Actually⌠Now that I wrote that all, Iâm curious as to why you want to restart the script. Is it because of the -trd
tag? And that it gets stuck at a confidence between 0 & 100 when youâre leaving sometimes?
If thatâs the case, why not have more delays and repeats?
Anyways, let me know if the above code works for you.
Thanks for the suggestion, couple things, first off my python and jinja2 are pretty poor lol and I basically just started using templating to try to condense my scripts and automations. I basically only code in .Net or Powershell.
Realistically I use two Pi Zeroâs for accuracy not range. 1 Pi can basically reach my entire apartment. The problem is that I donât want some of my automations going off in case of the sensor either failing OR falling in value. This is actually the reason I am using âTRD. By default this script will do its own depart to see if the user has left the area or not (I forget the interval). This doesnât work for me because my GF lets her devices die sometimes and she has no desire to change the way she lives lol.
I let Andrew know this and he added triggers for depart and arrive. So the only time my depart sequence triggers is if the device restarts OR I sent a depart trigger. For my house when the door opens I send a script.turn_off to the Mqtt_depart script and when the door closes the script starts. I did this part just in case im toward the end of the script and I walk back in the house. It cancels and then starts again.
You are correct about the Values, the issue is that ive been with this project for a long time and it has become better and better with each Beta release. There was a time where my values would get stuck and the only way to recover was with a restart. Andrew eventually implemented the location/scan/restart which allowed me to restart all nodes with one Mqtt topic!!
Ok back to the mqtt_depart script. Where I live is pretty close to the elevator and for the most part I wait maybe 60 seconds. Sometimes I wait much longer (this is the reason for so many delays). My door is really really close to the elevator so the Monitor instances still pick me up when I am at outside of the apartment. You must remember that these instances count down from 100. So if I am toward the end of the depart script and im further from one sensor than the other , one may have me at 100 whereas the other has me at 0 but I may still be at the elevator. Either way Yes if I want to simplify it I could technically go off of the Occupancy sensor that I have which is the MEAN of both sensors. Unfortunately I have had 2 Piâs fail and it was probably my crappy sd cards (who knows). This makes my values stay at 50 percent and essentially never get to 100 for the Mean of both sensors. Maybe based on your suggestion I can change it to
- service_template: >
{% if states.sensor.benji_bedroom.state | float in(range(1,100)) or states.sensor.benji_living_room.state | float in(range(1,100)) %}
script.mqtt_restart
{% elif states.sensor.bridget_bedroom.state | float in(range(1,100)) or states.sensor.bridget_living_room.state | float in(range(1,100)) %}
script.mqtt_restart
{% else %}
script.do_nothing
{% endif %}
(actually I just made the change, that honestly makes more sense thanks) .
just in case you are curious (its nothing special and far from all my files but may give you an idea of how im doing everything)
Ah yes. As I was writing it, I was starting to realize that the time was the reason you did this.
I actually use a version of your script from reading this thread (I also am very close to the elevator in my building) so thank very much for that!
Question (or suggestion) though⌠why not add a few more depart & delay in your mqtt_depart
script? Just to make sure that youâre out for sure? Then you can add the availability topics back in since youâll be restarting less.
test the availably topics and you will see why I dont want to use them anymore lol.
maybe if I change my automations a bit it would work.
right now I have a Benjis_home script and a benjis_not_home. When the availability topic is offline HASS will not look at the retained value on the MQTT server. No fault of andrew I think its HA that needs to change.
So I would restart and once the sensor came back it would activate the automation again
its possible I was doing something wrong. But test itâŚmaybe I just missed something
Can this project detect my carâs Bluetooth?
wow, i did it. read through every freaking post in this thread.
seems iâm in the group of people whoâs phones (android, LG G7 ThinQ) donât send out random BLE advertisements. Iâve tried pairing with a bluetooth speaker which didnât work. My phone has also been paired with a FitBit and my truck. Next step is to try pairing with a BLE tracker, I have one for my dog that is out of batteries.
Since it was suggested in about 100 posts in this thread, Iâve switched to the beta branch. But now it seems that sending an mqtt message to monitor/scan/ARRIVE doesnât do anything, and it worked before.
The behavior_preferences file in this beta is considerably different than before (and the documentation)
# ---------------------------
#
# BEHAVIOR PREFERENCES
#
# ---------------------------
#MAX RETRY ATTEMPTS FOR ARRIVAL
PREF_ARRIVAL_SCAN_ATTEMPTS=1
#MAX RETRY ATTEMPTS FOR DEPART
PREF_DEPART_SCAN_ATTEMPTS=2
#SECONDS UNTIL A BEACON IS CONSIDERED EXPIRED
PREF_BEACON_EXPIRATION=180
#MINIMUM TIME BEWTEEN THE SAME TYPE OF SCAN (ARRIVE SCAN, DEPART SCAN)
PREF_MINIMUM_TIME_BETWEEN_SCANS=15
#ARRIVE TRIGGER FILTER(S)
PREF_PASS_FILTER_ADV_FLAGS_ARRIVE="0x1a"
PREF_PASS_FILTER_MANUFACTURER_ARRIVE="Apple"
#ARRIVE TRIGGER NEGATIVE FILTER(S)
PREF_FAIL_FILTER_ADV_FLAGS_ARRIVE="NONE"
PREF_FAIL_FILTER_MANUFACTURER_ARRIVE="Google|Samsung"
I noticed the one post above about playing with the filters but I really didnât understand it too well. Because Iâm on an android should I be removing âGoogleâ from the Pref_fail and move it to the pass?
Should I be adding in those previous behavior_pref fields that are documented?
edit: think I was having an issue with MQTT. Did a reboot of my pi and itâs responding to MQTT arrive message now. Still looking for feedback on my other questions about the behavior_pref file
and iâm getting this error in my logs, anything to be concerned with?
./support/btle: line 204: pdu_type: command not found
and another edit since my phone isnât broadcasting randomly. I should try and trigger the arrive scan manually correct? The depart scan wonât do anything if the phone isnât above 0 confidence correct?