I have built a nice dashboard that allows me to control every device and all automation of every room. Each room has a separate page on the dashboard.
My ultimate goal is to have a way to detect which room I’m currently in (actually, which room my phone or tablet running the HA App is), so I can show the appropriate room page when I enter the dashboard.
For now I’m investigating how to detect my current room.
I was thinking of placing some BLE Beacons around my rooms, and use the Beacon Monitor sensor provided by the HA App on Android to detect the nearest beacon and then associate it with a room somehow (even if with a series of IFs).
But whenever I try to enable the Beacon Monitor for my Mobile App device, it says that it will become available in 30 seconds and then it disables itself again.
Also, I couldn’t find any documentation about the Beacon Monitor.
Can you please point me towards some docs or give me some guidance on how to proceed?
that sensor requires permissions, you may have gotten a notification to grant it permissions, if not enable it in app. It takes about 15 minutes or so for the notification to arrive if enabling via server as the notification only arrives when the app does a sensor update check.
Unless you have a bunch of iBeacon receptors through the house and coordinate them to do triangulation, the accuracy of the movement tracking will be very unreliable. A beacon station may estimate that you are 2 - 7 meters away depending on configured transmit power, real transmit power, beacon interval, duration of the reception and a million other factors.
With room-assistant this is possible with a handfull of RPi’s, but that project is looking abandoned, although I have it working on a single Pi 0W almost without glitches. Over time I have learned to fine tune it so that it detects me properly about 9/10 times.
It seems to be very robust, but maybe too robust to my use case. I will definitely explore it in the future!
I’m building a custom card to redirect to a given URL (a view, for instance) based on a template value.
Using the Beacon Monitor and a few BLE iBeacons (more than 10 for my house) , I will be able to redirect the dashboard user (me, most of the time) to the appropriate view representing the room, an if it can’t determine correctly the room or it is stale, it is acceptable to keep in the default view or redirect to the last where I was detected.
Indeed some tuning on the beacons will be required, and maybe good positioning or multiple beacons on larger rooms, but this is acceptable.
it actually has a unique notification channel so you can alter its appearance separate from other notifications. Its required for foreground services to post a persistent notification to prevent the app from sleeping.
You can edit all the app provided channels in Settings > companion app > notification channels
We have just launched a new beacon gateway product that can be installed in each room and can scan for beacons. If the user is carrying a beacon, that would work. But it should also work if the user is carrying a smartphone and broadcasting a virtual beacon from that phone.
The beacon gateway is scanning/capturing target beacon info and sending that to the MQTT server on the HA. The next step is important: The user should first create a sensor for the data they want to capture (Bob’s Virtual Beacon) then ideally also create a smoothed version of that sensor (Bob’s Virtual Beacon Smoothed). This then smooths the RSSI data that the gateway reports to HA from the virtual beacon. Whatever automation the user wants to make should be based on this smoothed sensor rssi data. That step alone solves a ton of the problems relating to beacon signal accuracy and stability.
Last but not least, ideally the automation should be based on a threshold level for the smoothed RSSI sensor. So rather than a simple “if HA merely sees the beacon, then do this”, it would be “if HA sees beacon and the smoothed RSSI is greater than -62, then do this.” You can additionally add an exit automation with a different level of threshold than the entry level. For example, “if HA sees the beacon and the beacon is currently “in living room” state, and now the smoothed RSSI has dropped below -75 (beacon has left the room), then do something.”
Having two different thresholds for entry and exit removes the chance of a “red line of instability” where the beacon state might hop back and forth from “in” state to “out” state. (I’m now working on a new HA project for automatically opening and closing my garage door based a beacon in the car; two different thresholds are important for making sure the garage door does not close while the car is halfway in or out.)
Here’s a sample project with my HA-noob (me!) version of this concept:
Thanks for the heads up! It looks pretty good and opens up a whole range of possibilities.
If the gateway published the MQTT data formatted for MQTT Discovery that would allow HA to autoconfigure a device tracker, without having to manually create MQTT sensors in yaml. Just a thought.
I’m doing the same, but scanning my phone beacon with an RPi. Would prefer one of your gateways for ease of setup and maintenance.
Btw, I have a few BlueCharms and they work, well, like a charm.
Yikes, that MQTT Discovery documentation is cooooomplicated!
From what I read (and just barely understood), it seems like our BLE gateway MQTT reports should be able to be auto-discovered by the HA if they are renamed correctly and a couple settings are adjusted.
For dumb people like me, just copying and pasting the sensor setup from my example project seems a lot easier.
Thanks again for the tip. When I have more time, I might try to go through the auto-discovery process and, if it works, will write up some “normal IQ-level” instructions for others.
I guess it might work for simple “home” and “away” but from what I am reading, it would not capture the signal strength. Then you could not set up automations based on the signal strength, and you also could not do any smoothing of the signal strength. I think this would be missing 90% of the benefit of a good beacon automation system.
You can send signal strength and other extra info in the optional json_attributes_topic. Details: MQTT device tracker - Home Assistant. Every entity in HA can have optional attributes to capture arbitrary info that does not pertain directly to its primary state. You can specify pretty much anything in the attributes, ie:
OK, great. I stand corrected. I will try to do one of the auto-discovers to confirm that it works for our gateway. I can’t imagine why it wouldn’t but one never knows with this stuff!
Yeah, it’ll for sure take trial and error. Testing with the suggested mosquitto_pub tool might help, and also inspecting the MQTT broker directly using MQTT Explorer.
