BLE transmitter: auto enable/disable depending on home wifi SSID

[sibbl]

Is your feature request related to a problem? Please describe.
I want to use the BLE transmitting feature for presence detection at home. However, I want to turn of the BLE transmitter when leaving home to avoid being tracked.

Describe the solution you'd like
Just like in the location options, I'd love to have an enable/disable BLE transmitter automation in the app, depending on whether I'm in one of the selected HA zones. So when I'm in the zone "home", I want the BLE transmitter to be turned on. When I leave the zone, I want it to be turned off. The companion app should already have geofencing from GPS high accuracy features, so I think this should behave similarly.

Describe alternatives you've considered, if any

• I've considered turning off the BLE transmitter by sending a push notification via HA automations. However, this doesn't work reliably sometimes as the HA location doesn't update quick enough or I do have internet connection issues a few minutes after leaving home.
• I've tried to regularly rotate my BLE IDs. However, this isn't possible with out of the box HA capabilities and messes up a lot of automations as I need to reference the current values, which contain the BLE IDs of the current hour, in all parts of HA (automations and such).

Additional context
Especially thanks to the new shiny ESP32 bluetooth proxies, I assume a lot of users will implement presence tracking using BLE. They might enable their BLE transmitter for these reasons without knowing that they are identifiable everywhere by exposing the IDs outside their homes as well.

[dshokouhi]

• I've considered turning off the BLE transmitter by sending a push notification via HA automations. However, this doesn't work reliably sometimes as the HA location doesn't update quick enough

Just a FYI but the in-app automation you are requesting will also be subject to the same delay here, you may want to look at the zone events to see if they are even occurring or if you need to adjust your accuracy. The best data to go by is what gets updated with HA because zone events have no guarantee as to when they will trigger and can vary from user to user.

A better approach would be to use the Wifi connection sensor as that updates as soon as a state change is detected. Personally I would prefer to leave these types of automations in the hands of the user instead of the app as the amount of requests for things like this can pick up.

[pjv]

@dshokouhi When you say “leave these types of automations in the hands of the user” do you mean having the ability to create in-app automations, or automations written on the HA instance?

I am currently doing an HA-based automation to turn off and on the BLE transmitter based on the home zone and indeed it is not perfectly reliable due to a variety of things not least of which is that when leaving and entering home there is an inherent networking instability as the device is either connecting to or disconnecting from wifi vs. cell data (in my case there is also some additional delay in getting things going when leaving home because my connectivity when away is over zerotier so that also takes a second to re-connect when the mobile switches from wifi to cell data).

That network instability is why it seems like it makes sense to have this automation happen in the companion app and not being dependent on the connection to the HA server.

BTW, thanks for the suggestion about using the wifi instead of the zone to trigger this type of automation. I’ll experiment with using the wifi connection sensor instead of the zone event to see if that gives a more reliable automation trigger.

[dshokouhi]

When you say “leave these types of automations in the hands of the user” do you mean having the ability to create in-app automations, or automations written on the HA instance?

automations written in HA

I am currently doing an HA-based automation to turn off and on the BLE transmitter based on the home zone and indeed it is not perfectly reliable due to a variety of things not least of which is that when leaving and entering home there is an inherent networking instability as the device is either connecting to or disconnecting from wifi vs. cell data (in my case there is also some additional delay in getting things going when leaving home because my connectivity when away is over zerotier so that also takes a second to re-connect when the mobile switches from wifi to cell data).

try enabling "Mobile data always active" under developer options and there won't be a delay in switching between wifi and cell, this was enabled by default on my Pixel.

The issue I mentioned still stands, if you see a delay in a location update change as mentioned in the original post then this on device automation will also suffer from that same delay.

I may or may not be mistaken but I think the device needs to be online in order to get updates from Googles Fusion Location service which is what the app uses for geofence triggering. This will also be tricky even if possible because this feature will only be available to users who have access to play services despite this sensor being available to both flavors of the app. So that will increase the complexity here code wise. Not to mention if the device is not online it won't be able to send the state of the sensor back to HA until it is reconnected to the network.

Other things to consider, how will this work when bluetooth is off because bluetooth does not get enabled automatically. Although there is a command to enable/disable bluetooth this will stop functioning once the app starts to target Android 13 which is going to happen soon.

[pjv]

try enabling "Mobile data always active" under developer options

I just turned that on to test - thanks.

Other things to consider, how will this work when bluetooth is off because bluetooth does not get enabled automatically.

I have always assumed that if Bluetooth is disabled then BLE is also implicitly disabled.

So maybe the best way to avoid edge cases would be to have a variety of ways to enable and disable the BLE transmission when the device is or is not at home; via a zone, via a connection to a wifi SSID or BSSID, maybe even via a connection to a bluetooth device (this is a nice option in the enabling / disabling of high accuracy mode for the location sensor), or maybe some combinations. I can see how it could get hairy from a coding standpoint even not taking into account different devices and different flavors of android.

But it would be nice to be able to reliably start and stop the BLE transmitter based on whether the device is at home or not.

[dshokouhi]

So maybe the best way to avoid edge cases would be to have a variety of ways to enable and disable the BLE transmission when the device is or is not at home; via a zone, via a connection to a wifi SSID or BSSID, maybe even via a connection to a bluetooth device (this is a nice option in the enabling / disabling of high accuracy mode for the location sensor), or maybe some combinations. I can see how it could get hairy from a coding standpoint even not taking into account different devices and different flavors of android.

That will get very complicated and will result in more requests. For a setting like this to be enjoyed by all users maybe we should go by the Home WiFi SSID option like we do for the persistent connection. This will negate the need for relying on google services and work for all flavors of the app.

[pjv]

For a setting like this to be enjoyed by all users maybe we should go by the Home WiFi SSID option like we do for the persistent connection. This will negate the need for relying on google services and work for all flavors of the app.

For me that would work because my device is always connected to home Wifi when at home, so I’d be happy if I could set an option to turn on the BLE transmit when connected to home wifi and off when not.

I’m guessing that would probably cover most people. @sibbl would that take care of your use-case?

[MariusMueller]

I’m guessing that would probably cover most people.

I would be one of those "most people" 👍

[sibbl]

For a setting like this to be enjoyed by all users maybe we should go by the Home WiFi SSID option like we do for the persistent connection. This will negate the need for relying on google services and work for all flavors of the app.

Yes, such a solution would be great and I understand the benefits of it. Having the SSID (or even better a BSSID in the future) option would solve the issue perfectly.

[dshokouhi]

(or even better a BSSID in the future)

BSSID support for Home WiFi SSID was actually added a couple releases back :)

https://companion.home-assistant.io/docs/troubleshooting/networking?_highlight=bssid#setting-up-the-app

[cromefire]

Having this work with WiFi would be really great, notifications can be unreliable at best.

Is that WiFi functionality already extracted into a separate class/service/whatever? If so maybe I'll have a go at it in the next weeks if I ever find some time for it...

[dshokouhi]

Is that WiFi functionality already extracted into a separate class/service/whatever?

yup we have our own method for determining if user is on home wifi.

https://github.com/home-assistant/android/blob/master/common/src/main/java/io/homeassistant/companion/android/common/data/url/UrlRepositoryImpl.kt#L154

[pjv]

@dshokouhi any progress on this issue? Given that the companion app is tracking when it is and isn’t connected to home wifi, is there anything needed besides adding an option toggle in the BLE transmitter settings and then some code that turns off and on the transmitter on changes to the home wifi state when that option toggle is set to true?

This is a minor security issue (and battery usage issue) for my use-case because my home-grown HA automations that try to turn off and on the transmitter based on either the zone of the device or the wifi sensor (home wifi) are very unreliable and thus my phone is pretty much always broadcasting a trackable beacon even when away from home.

[dshokouhi]

No updates from me.

[bogorad]

For the time being, I just did it in Node-Red, but an autonomous (in-app) mode would still be highly preferable. For example, if there's no internet (for whatever reason) when I leave the house, the beacon will be transmitting.

[leccelecce]

Hi @dshokouhi I am keen to see this feature and prepared to try and send a PR; I am a Java developer but not familiar with Android app development so will need to get my head around the source.

If you do have any particular suggestions on approach to implementing this, would appreciate any pointers. I have found IBeaconTransmitter, TransmitterManager for creating a new preference, starting/stopping the transmitter. I've yet to work out the best way to detect a wifi BSSID state change and compare it to the "Home" BSSID. There is ServerConnectionInfo.kt.isHomeWifiSsid() but it's working out if it's reasonable to call this, and wear from.

[cromefire]

There is ServerConnectionInfo.kt.isHomeWifiSsid() but it's working out if it's reasonable to call this, and wear from.

Also don't know the technical details, but that definitely seems like a good idea so there doesn't need to be a second setting.

Also if you do it with BSSIDs, please make sure you can put multiple in there, many of us probably have multiple in there.

The other way is to use Zones, I think I found some class before that could just detect in which zone the user is, that could make it easier than with WiFi potentially.

[leccelecce]

Looks like the main application class does detect Wifi/Network state change events, which are passed to NetworkSensorManager. The guidance I need from an app dev is whether it's appropriate to "chain" the Bluetooth sensor off the wifi one (or any other, such as zones).

Also if you do it with BSSIDs, please make sure you can put multiple in there, many of us probably have multiple in there.

ServerConnectionInfo.kt.isHomeWifiSsid() is checking against a list of internalSsids so I think that function already caters for multiple which is great.

[pjv]

The other way is to use Zones, I think I found some class before that could just detect in which zone the user is, that could make it easier than with WiFi potentially.

I think that using Zones would lose some of the desired functionality for this feature. If your mobile currently lacks Internet connectivity it can’t know what Zone it’s in, what Zone it’s entering or leaving.

Otherwise it would work fine to use simple automations or node red flows on the HA server. I’ve tried this and it’s very unreliable.

For me the main point of having this is to have the lowest level, most reliable and dependency-free way of turning the transmitter off and on when the mobile device is either at home (connected to home wifi) or not at home.

[cromefire]

I think that using Zones would lose some of the desired functionality for this feature. If your mobile currently lacks Internet connectivity it can’t know what Zone it’s in, what Zone it’s entering or leaving.

Do Zones need Internet? I always was under the impression that the list of zones was synced to the device, but maybe I'm wrong.

[pjv]

@cromefire I could also be wrong about how it works on-device, but I think that Zone presence and changes are happening on the HA server rather than on the device. I think the device is just telling the server where it is (GPS wise) and the server is determining where those coordinates are in Zone space.

[dshokouhi]

I've yet to work out the best way to detect a wifi BSSID state change and compare it to the "Home" BSSID. There is ServerConnectionInfo.kt.isHomeWifiSsid() but it's working out if it's reasonable to call this, and wear from.

I think it would be reasonable to call that, the app already listens to the intents that get fired when a network state change is detected which happens when BSSID is changed too.

Also don't know the technical details, but that definitely seems like a good idea so there doesn't need to be a second setting.

This setup should still have its own setting separate from the apps URL switching but the logic can be shared

The other way is to use Zones, I think I found some class before that could just detect in which zone the user is, that could make it easier than with WiFi potentially.

The problem with zones is that the minimal version does not use them at all so might be best to use WiFi as minimal users have no way of getting GPS coordinates currently.

The guidance I need from an app dev is whether it's appropriate to "chain" the Bluetooth sensor off the wifi one (or any other, such as zones).

If you have to borrow code from another sensor then it may make sense to make the method common to both. Please keep in mind when developing that we support a minimal and full version of the app. The minimal version does not have location tracking and zone tracking will not work as a result

I think the device is just telling the server where it is (GPS wise) and the server is determining where those coordinates are in Zone space.

That is 100% correct

[leccelecce]

@dshokouhi many thanks for the prompt and helpful feedback. I've had a go at a PR #4277 but given this is my first development on any Android app, let alone HASS, I've almost certainly missed something - all comments welcome!

[leccelecce]

For anyone else tracking this, it's now live in the Android beta channel, and working fine for me (on a single-server setup).

[dshokouhi]

thank you for your contribution @leccelecce 🙏

[ostracizado]

I was checking the app and I can't seem to figure out how to define specific BSSIDs to a home network.
What's the procedure?

[jpelgrom]

I was checking the app and I can't seem to figure out how to define specific BSSIDs to a home network.
What's the procedure?

This is hidden in the online documentation as it's an advanced feature that may be confusing:

add a new SSID with the name BSSID: followed by the BSSID (for example: BSSID:1A:2B:3C:4D:5E:6F)

[ostracizado]

Hmm, it seems there's no need to change the name.

Just adding the SSID in "Servers & Devices > Home Network WiFI SSID", then in "Sensors (Manage Sensors) > Network Sensors (WiFi BSSID)" getting the current BSSID, seems to do the trick.

[bogorad]

this leaves the question of multiple BSSIDs (I have two APs, some people have 5-7), but I can live with just using SSID.

[ostracizado]

this leaves the question of multiple BSSIDs (I have two APs, some people have 5-7), but I can live with just using SSID.

It does work - I added three BSSIDs.
You simply have to repeat those steps I mention before for each one.