FR: Integration with Bermuda

[agittins]

Howdy! I might have heard a rumour that you might be considering integrating support for Bermuda into your integration - I just wanted to reach out and let you know that the possibility sounds awesome, and if there's anything that would make that easier on the Bermuda side just let me know!

Bermuda creates a sensor to publish the Area name, and has attributes for the area_id.

Would it be useful if Bermuda pushed an event to the bus each time the area for a device changed?

Let me know if you have a "preferred" way to do things and I'll see what I can learn! 😅

[jseidl]

Hey @agittins! Thanks so much for reaching out! This feature is indeed what I intend to work on next so it's super cool that you pinged me in such opportune moment.

I did a quick survey on MA's Discord and seems that we have users that use Bermuda (such as myself, thanks for the great integration!), people who use room assistant, espresence and others. In order to keep open the compatibility, the way I'm thinking on implementing it is to let the user point out the sensor (like the bermuda sensor) and then say "compare [state/attribute xyz] to [area name/area id]" with a couple dropdowns (and a text input for the attribute name) and that should cover most of the folks.

I might abstract the complexity a bit by just asking "what's your sensor" and then have a dropdown for the platform (bermuda/room assistant) that auto-sets the other two (then hidden field).

What do you think? Is that a good path to follow?

[tbrasser]

I was thinking this approach is fine for 1-on-1 mapping between trackers and presence-indicating-entities (person/pet).

But for persons we might have multiple trackers (phone/watch/wallet/etc), so in those cases it might be beneficial to use (something like) person entities or at least some way to say "these trackers govern the presence/location of 1 person" (which cannot be in 2 areas at the same time)

[agittins]

Hey @agittins! Thanks so much for reaching out! This feature is indeed what I intend to work on next so it's super cool that you pinged me in such opportune moment.

Awesome! 😀

What do you think? Is that a good path to follow?

That sounds like a good, flexible way to do it. I'm not familiar with your integration yet so I'd think that whatever fits with the "MA Way" of doing things will be the way to go :-)

Another option could be to use labels, but then you'd probably still have to do a per-sensor check of how to handle sensors from different integrations etc.

I think a useful thing would be for you to have a reliable way for your integration to identify the source of any given sensor, so that it can make decisions about how to handle it or present options to the user. In that vein...

Currently Bermuda's area sensors have a device_class of bermuda__custom_device_class which is a nonsense I put in when first trying to get my head around stuff. Since there is no device class for Area, I think what I'll do is in the next release I'll change the area sensor to have a device class of bermuda_area_sensor, and sort of "lock that in" as a blessed way to identify a Bermuda Area sensor (at least until they implement an area class, if ever).

That way, if you choose to, you can easily identify that an area sensor comes from Bermuda (something like if sensor.device_class in ["bermuda_area_sensor", "bermuda__custom_device_class"]:), then you can automatically choose which processing logic to use on it rather than having to ask the user (eg, you can "know" that it will have a proper area_id attribute, the state will be the area_name, it has at best 1 second latency, it's based on bluetooth adverts, etc etc).

I'm guessing you'll just subscribe to updates from the entity registry and filter for the ones you're interested in. Does that sound reasonable? If there's anything else that would help MA to identify Bermuda sensors, or if it could benefit from access to some other info, just let me know!

[jseidl]

Alright, I've managed to squash the bugs (so far) on the next release so I'm already getting ready to work on this.

That sounds like a good, flexible way to do it. I'm not familiar with your integration yet so I'd think that whatever fits with the "MA Way" of doing things will be the way to go :-)

In short, when you create a "Magic Area Instance", you can either choose to create it for one of your existing areas or the so-called "Meta-Areas" that are kinda "groups" of the regular areas. In Magic Areas, you can specify if the area is interior or exterior. Meta-Areas will group those into a new Interior/Exterior Meta-Area (if you create them) and also a Global one which groups all areas. (Floors can be grouped that way too)

Magic Areas and Magic Meta-Areas allows the user to select which features (plugins) they want to enable. Some features are only available for regular areas, others for meta-areas and some for both. This "BLE tracking" functionality would be a feature.

My tenets for this feature are the following

• Support multiple BLE trackers: Bermuda, mqtt-room, etc
• Support multiple BLE tracking sensors (households may have multiple phones, watches, beacons etc)
• Not be repetitive to set up/easy of set up

I see BLE trackers are more of a "Global" thing, as in there isn't much area-specific configuration to be done, so I recon this would be a feature where you would enable in your "Global" Magic Meta-Area instead of in every single area where you want the BLE tracker to be considered. On the UI, user would enable the feature, then go to the options for that feature and select the entities to track and maybe the provider (Bermuda, mqtt-room) if the parameters diverge (i.e. one presents area name in state vs other in attributes only).

Magic Areas main sensor "Area State" tracks multiple binary_sensors, if their state is on, then the area is occupied. (oversimplification). My idea on implementing this BLE tracker is that whenever a regular Magic Area is loading, it checks if 1) you have a Global Meta-Area 2) you have the BLE tracker feature enabled. If so, it creates a dummy "BLE Presence" sensor in that area and uses it as presence source. This would create this sensor for an area even if you don't have a BLE tracker in that area. This sensor would be largely NO-OP but doesn't seem like it would be a problem.

The Global area instance is the one that tracks the BLE Tracker sensors (e.g. Bermuda sensor) and when the value of it equals the an area that we have a magic area instance for it, we force update (hass.states.set) to on, and when it doesn't, it sets it back to off. That avoid all the area instances individually tracking those sensors and lets the Global meta-area do the heavy lifting. This could be more frugal on resources. The downside is that you require users to create a Global meta-area, which isn't a huge deal.

With this approach, users only have to configure the feature once, and all the tracking stuff would work out of the box. @tbrasser, you that are most familiar with both integrations, what do you think?

@agittins this approach wouldn't need any updates on your side, but I'd also love your input as a dev on this one

[jseidl]

Alright folks, it's in the oven. Head over to the PR for more info!

[tbrasser]

@agittins in addition to above PR (that lets us assign ble trackers/beacons that will make areas active in magic_areas) would it be an idea to have the option in bermuda to sync the current area with the device its area? For example my plant sensors might move between areas, having this option would auto-update its home-assistant area (and with latest magic_areas beta, auto-reload magic_areas).

lmk what you think, I can open a FR in bermuda repo if you like it.