You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the solution you'd like
The Android Companion has a sensor for the total number of connected Bluetooth devices that then lists the names of the connected devices as an attribute. I saw someone asking on Facebook
if a Bluetooth device connect/disconnect could be used for an automation. Currently you could do it for the connect via Shortcuts (although it isn't clean), you cannot get disconnects this way apparently. Use cases seem pretty numerous like connecting to hands-free in car, exercise equipment, or any other accessory where the connection essentially means you are doing a thing.
To be vaguely in keeping with the idea that attributes should be static, one solution for iOS might be to have a sensor whose value is a comma-delimited list of connected devices. BUT this feels horrid from a UX POV as to do anything useful requires templating and checking current assumed states HA side.
A nicer idea might be to register a new sensor sensor.mobile_app_device_name_bluetooth_EAAccessory.name for each bluetooth device (can check via protocolString) we've seen (checking the EAAccessory for dupes), this sensor would be a simple connected/disconnected boolean and the attributes could be the useful info manufacturer info from EAAccessory.
Slight caveat: My reading of EAAccessoryManager and connectedAccessories is that we get the connected devices only not the paired but disconnected too. Not a big deal.
Double bonus points: A quick google seemed to throw up suggestions that the above notifications should include power cable connects/disconnects. If that's right, we definitely want to consider using those as an update trigger (this is a common request that we currently work around with shortcuts).
The text was updated successfully, but these errors were encountered:
Unfortunately neither the Bluetooth APIs nor the Accessory APIs are useful for this. Using Bluetooth directly requires that we talk to particular services, none of which are standard (despite being documented as being standard) and reliable to exist on devices (for example, none of my Bluetooth audio devices expose the standard 'power' state). The accessory/MfI APIs require we explicitly opt into certain protocols that external devices support, but there is no standard for it.
Describe the solution you'd like
The Android Companion has a sensor for the total number of connected Bluetooth devices that then lists the names of the connected devices as an attribute. I saw someone asking on Facebook
if a Bluetooth device connect/disconnect could be used for an automation. Currently you could do it for the connect via Shortcuts (although it isn't clean), you cannot get disconnects this way apparently. Use cases seem pretty numerous like connecting to hands-free in car, exercise equipment, or any other accessory where the connection essentially means you are doing a thing.
EAAccessoryManager
seems to let us do everything we might want to here.To be vaguely in keeping with the idea that attributes should be static, one solution for iOS might be to have a sensor whose value is a comma-delimited list of connected devices. BUT this feels horrid from a UX POV as to do anything useful requires templating and checking current assumed states HA side.
A nicer idea might be to register a new sensor
sensor.mobile_app_device_name_bluetooth_EAAccessory.name
for each bluetooth device (can check viaprotocolString
) we've seen (checking theEAAccessory
for dupes), this sensor would be a simple connected/disconnected boolean and the attributes could be the useful info manufacturer info fromEAAccessory
.Slight caveat: My reading of
EAAccessoryManager
andconnectedAccessories
is that we get the connected devices only not the paired but disconnected too. Not a big deal.Bonus points: By registering for connect/disconnect notifications are we able to come out of background long enough to send an update HA (more update triggers the merrier)?
Double bonus points: A quick google seemed to throw up suggestions that the above notifications should include power cable connects/disconnects. If that's right, we definitely want to consider using those as an update trigger (this is a common request that we currently work around with shortcuts).
The text was updated successfully, but these errors were encountered: