Sorry - no idea about HACS.
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.
Is there any way to use that to use a Bluetooth keyboard to do stuffs as a trigger for an automation?
You can type and login to the HASS console (e.g. on a RPi4), but thatās not youāre asking for.
Hi!
Is that why I canāt seem to receive any event in HA from one of those generic Bluetooth remotes, despite getting it connected via bluetoothctl?
Described here: Bluetooth Button (Remote) support - #19 by antonio1475
It seems some people have achieved using the bluetooth multimedia buttons that @yousaf465 mentioned without an integration (well, maybe the Keyboard Remote one?):
Thank you
This seems confusing and unnecessary. Iām gonna stick with ZigBee.
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
1 Like
Hi!
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?
Thanks again, Iām learning a lot todayā¦
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
1 Like
thanks for your instructions on how to setup the logger for bluetooth component.
I got the message from log:
2022-11-07 12:24:44.832 DEBUG (MainThread) [homeassistant.components.bluetooth.manager] esp32-tester: 6C:EC:EB:3F:F1:CD AdvertisementData(manufacturer_data={220: b'\x01\x01\x05\x02\x01\x00\x00\x01\x01'}, tx_power=-127, rssi=-48) connectable: True match: {'oralb'} rssi: -48
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.
Thanks for your help!
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).
Your experience suggests notā¦ 
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
iāve bought 4 of them tooā¦ at moment it is not integrable, we will see in the next future, please keep me posted if you have any news about them 