The known device is by Telink Semiconductor; the two others look to be unknown, possibly due to MAC address randomisation - devices send ever-changing “fake” MAC to avoid tracking.
The next steps towards a driver (if no one else has been there before you…) are all about logging lots of data under controlled conditions, writing custom code to look for patterns, and reverse engineering the undocumented data formats. You might get lucky poking about in GitHub and blogs for hints, or the format might be the same as several other devices.
Just remember to set debigging back to debug before your disk fills up.
I was able to get multiple BLE sensors integrated. I think, because this was my first time with BLE, that I was expecting a bunch of “around the house bluetooth” products to appear. Turns out that was not the case – but I’m just as satisfied with my new BLE temp sensors.
You can’t use controllers nor sound devices - the HASS integration is for Bluetooth Low Energy (BTLE), not Bluetooth.
Automation almost always uses Bluetooth Low Energy BTLE which is very different from “standard” Bluetooth Audio (which has several profiles itself just to be even more confusing…).
Most host operating systems (e.g. HASS OS on a RPi) will implement support for Bluetooth Human Interface Devices themselves, meaning keyboards and controllers may work, but at much lower level.
It seems some people have achieved using the bluetooth multimedia buttons that @yousaf465 mentioned without an integration (well, maybe the Keyboard Remote one?):
Interesting links thanks! I’d not seen “standard” Bluetooth HID remote buttons before.
From the description and tutorial you linked, they send key_code: 164 which suggests they are BT HID devices (“standard” keyboards) sending MUTE, in exactly the same way as a USB keyboard would.
Needing to connect down to the “host” OS console to get keyboard events does sound like the sort of integration that would only be available in HACS.
I don’t know for sure how the host OS console support for Bluetooth devices interacts with the new HASS Bluetooth integration, but it is very unlikely that two software stacks can connect to one radio.
This is the whole point of the new integration - one radio + stack is shared at the HASS OS level with several integrations. At a guess, the HASS Bluetooth stack takes over the whole radio, but (currently) only supports BTLE.
If this theory is correct, one radio = one Bluetooth driver as two would conflict (*):
|--- BTLE Integration 1
RADIO --- Host OS --- Docker --- HASS --- HASS Bluetooth driver -|--- BTLE Integration 2
* |--- BTLE Integration 3
|--- OS Bluetooth driver --- BT HID
New BTLE integrations seem to register with HASS for specific device IDs, and HASS lets each one know if a match has been found.
I bought a few of those for testing but decided they were not good candidates to build an integration for because:
They require an active connection
The range is quite limited
The battery life is about 1 month (that is a lot of battery replacement and excess waste, and its way too much maintenance burden)
If you want remotes that have a long batter life you are better off picking up a cheap or used Lutron Caseta hub on ebay/resale and some pico remotes since they are all integration local push and don’t use 2.4g radio bandwidth. The pico remotes have roughly 100x longer battery life (quoted 10 years) so even though its a bit more expensive up front you’ll replace ~120 less batteries over the same time period.
If you already have a working Zigbee setup you might try the TRÅDFRI Shortcut buttons as well but you aren’t likely to see the battery life longevity of the pico remotes with those, but it will certainly beat out the iTags
Thanks a lot for the info.
Yes, I do have a Zigbee network with many devices, including different TRADFRI models as well as Aqara.
However, this device (which isn’t exactly an iTAG, that works different, This one you turn on, has an active connection until you turn it off, auto turns off after x minutes of inactivity. The iTAG has an active connection always, as it’s used for tracking?), sends an inmediate command on press (since it doesn’t wait for double clicks or anything, while the other Zigbee buttons do causing a delay).
My original goal for this device was to connect to Windows for a Google Meet microphone mute switch. However, it says “driver error” in Windows.
On the other hand, I can already control Meet Mute through an input_boolean in HA (toggled by an Aqara WXKG01LM), so I thought I could connect this Bluetooth device and eliminate the Aqara’s delay (as it waits for double clicks, even though I’ve reduced that with Z2M setting hold_timeout to 1ms).
And the Tradfri is way too hard to click compared to Aqara & this Bluetooth one.
It sucks that this device connects & works perfectly with iOS, Android and Linux (it send volume up key in all), but not Windows nor HA.
I also find some confort in knowing it could be done with an integration, but I can’t even kid myself thinking I could build it myself.
On the other hand, are you able to understand why some people were able to connect those multimedia Bluetooth remotes on the threads I linked (258880 & 153825), following (I think) the same method without integration?
You can connect any device manually with the Bluetooth stack. It’s the keeping it connected, handling when to reconnect, and processing the data that needs an integration.
Some devices may present themselves as a keyboard which the os already has mappings for which makes it a bit easier but even then keeping it connecting can be tricky
But how do I get the Oral-B integration to work?
My setup is Homassistant OS inside a VM, so I don’t have a physical Bluetooth adapter connected, I just want to use one (or maybe multiple) esphome proxy.
As HASS 2022.11 now includes a Oral-B integration, my own Yellow + USB BT4.0 adapter detected my BTLE toothbrush and automatically installed everything needed:
This ADVANCED tutorial was written several releases before developers had started to use the new BT foundations, so is really to gather data on unsupported devices so they can be added.
Sorry - I don’t use VMs to avoid port mapping issues, and haven’t tried proxies.
N.B. The Yellow kit includes a RPi CM4 “Lite” which means it does not have BT nor WLAN radios. A cheap USB BT4.0 or BT5.0 dongle works with my hardware with automatic detection and setup.
thanks, i know about this integration, however i have no physical bt adapter… i want to use proxis only.
When I try to add this integration it fails because no bluetooth integration is setup…
My first assumption would have been that there was a chance the process taps into the HASS BT stack high up, so any source of BTLE data might work (e.g. local USB or remote proxy data all gets collated centrally into one API).
It works. I think for my quite old toothbrush there where dependecy updates of oralb-ble needed. Those came with homeassistant core 2022.11.2.
So it works without physical adapter
