Bluetooth Dongle (added) how to scan for devices?

Configuration
9

@pepe59 @stevemann I think I found out why. The documentation may be a little lacking. I was expecting to be able to connect Home Assistant to any of my Bluetooth devices. If it’s a speaker, perhaps stream music to that speaker.

Apparently that may not be the case. I purchased a Govee bluetooth temp/humidity sensor and as soon as I turned the device on HA found the device and allowed me to setup. It appears that only devices that have “HA” support will appear in the list. Hopefully in the future we can see other Bluetooth devices similar to how ours phones can connect to many different speakers, etc.

3 Likes
10

Bluetooth is a family of protocols, which can make it confusing.

Automation almost always uses Bluetooth Low Energy BTLE which is very different from Bluetooth Audio (which has several profiles itself just to be even more confusing…).

The recent development work makes connecting software to Bluetooth easier, however this is currently for Bluetooth Low Energy devices. BTLE often works by broadcasting one-to-many without pairing - like shouting “I’m a thermostat and it is 20C” reguarly.

That’s why the device appeared - it was broadcasting BTLE Advertisement messages, the new integration noticed, checked it was supported, and added it.

The distinction between BTLE and BT was discussed by Nick on the 2022.08 release party video.

The Media player could in theory send audio to a conventional Bluetooth speaker (AD2P), but this is more dependent on the host operating system, and separate from BTLE.

8 Likes
11

@FloatingBoater ank you for that! That actually makes sense and explains a lot. I’ve purchased 5 of the Govee sensors now. Is there a list somewhere of what BTLE devices are compatible with HA so far? Just looking for different ideas, it’s been a little while since I’ve added some fundamental useful automations to our mix.

12

Curious to know about door locks? I picked this door lock up which connects to the tuya app but wondered if it would connect directly to HA.

1 Like
13

The key point here is the fondations for much improved BTLE support were only partly released in 2022.08 - there is a lot of work to be done by core and integration developers before the specifics of GUI and device support are settled.

Where is there a list of supported devices? My guess is only in the GitHub repositories - Use the Source, Luke! :slight_smile:

The best source I know for BTLE lock information is (again!) the 2022.08 release party video as bdraco (J. Nick Koston) demos support for Yale Access / August locks.

As locks are an actuator (not just a sensor), BTLE does need to pair. The video demo shows this process live, although the difference between general BTLE and HomeKit-specific protocols is hazy to me.

Tuya did get a bit of HASS fanfare with some form of contribution last year, but I get the impression that the relationship stalled with code maintenance. ISTR the Tuya integration was cloud-based, implying Wi-Fi only, rather than BTLE - and the Tuya Integration docs do ominously say “except the lock and remote platform”. No Tuya BTLE locks, then?

As for the linked lock - don’t ask an engineer about locks and expect a good answer! :lock: :slight_smile:
For a start, micro-USB on the rain-soaked insecure outside, and back-up keys on the inside seems backwards. Might be OK on an internal door, but in the UK such a lock would invalidate my home insurance. :grimacing:

1 Like
14

TL;DR - Supported BTLE devices with new-stye integrations are in GitHub with an explanation and plans in HACS

Basically, bdraco (J. Nick Koston) has created a set of BTLE foundations making it easier to create integrations for individual BTLE devices/ brands/ types (e.g. Bleak client + DBUS integration + BLE parser, etc).

Originally, he had a Passive BLE Monitor integration which lists lots of devices and can be installed from HACS. The current work is to create individual integrations for different devices using the new BTLE foundations.

The BLE Monitor docs hopefully better explain the list of devices that WERE supported, and shows the work-in-progress creating new integrations.

UPDATE: HASS 2022.11 includes more BTLE integrations

This process was originally written using 2022.08, before developers had started to add support for BTLE devices. 2022.11 now includes the Oral-B integration so several toothbrush devices are now supported without any set-up needed - detection is automatic.

These instructions may still be useful for contributors to gather and debug BTLE manufacturer_data to allow new devices to be supported with additional work from developers. :hammer_and_wrench: :mage:t2:

Sniffing BTLE with the new foundations - ADVANCED

I tried installing the Passive BLE Monitor from HACS, but removed it and instead used bdraco’s live demo on the 2022.08 video as a guide to change the new Bluetooth component log level.

  • Add a line into configuration.yaml to get access to the Logger Service:
# Get access to logger.set_level service following bdraco live demo
# https://youtu.be/m9gKFH8WlzY?t=3297
logger:
  default: warn
  • Restart HASS
  • Set Bluetooth logging back to debug
    • Developer Tools → Services → logger → YAML (change from warn to debug)
service: logger.set_level
data:
  homeassistant.components.bluetooth: debug
  • Terminal tail -f /root/config/home-assistant/.log
  • Watch for devices in the log, noting addresses and data
  • Set the logging back to warn to not fill up the uSD
    • Developer Tools → Services → logger YAML (change from back to warn)
service: logger.set_level
data:
  homeassistant.components.bluetooth: warn

By doing this, I was able to see my Oral-B toothbrush, which for no useful purpose has an App and broadcasts via BTLE:

2022-08-13 16:30:02.239 DEBUG (MainThread) [homeassistant.components.bluetooth] Device detected: DE:AD:BE:EF:00:00 with advertisement_data: AdvertisementData(local_name='Oral-B Toothbrush', manufacturer_data={220: b'\x03V\x05\x02 \x00\x0e\x04\x01.\x04'}) matched domains: set()

Why? Do you really need to ask? :slight_smile: :hammer_and_wrench: :mage:t2:

Kudos to Nick / bdraco for this work (and performing a live demo so I could follow his lead).

UPDATE: Release 2022.11 now includes the Oral-B integration which installs automatically when a supported device is detected.

2 Likes
15

Ok, now what?

I found my BT Temperature and humidity sensor:

2022-08-24 23:32:38.935 DEBUG (MainThread) [homeassistant.components.bluetooth] Device detected: A4:C1:38:43:0E:8E with advertisement_data: AdvertisementData(local_name='Govee_H5074_0E8E', manufacturer_data={60552: b'\x00\xd0\t\x19\x14d\x02', 76: b'\x02\x15INTELLI_ROCKS_HWPu\xf2\xff\xc2'}, service_uuids=['0000ec88-0000-1000-8000-00805f9b34fb']) matched domains: set()

And a couple of other unidentified devices:

2022-08-24 23:31:16.903 DEBUG (MainThread) [homeassistant.components.bluetooth] Device detected: FA:F8:C4:0A:00:81 with advertisement_data: AdvertisementData(manufacturer_data={76: b'\x12\x02\x00\x02'}) matched domains: set()

2022-08-24 23:32:35.864 DEBUG (MainThread) [homeassistant.components.bluetooth] Device detected: 4D:1A:93:11:6C:65 with advertisement_data: AdvertisementData(manufacturer_data={76: b'\x02\x15\x1c\xa9.#\xf0\x87M\xf7\xb9\xa2\xfdKqjK\xf6\x02\xe9\x00\x00\x03'}) matched domains: set()

Is there a way to identify the two unidentified devices?

16

Use a search engine to look for bluetooth mac address lookup.

Just like Ethernet and WLAN, BTLE devices have a 48-bit MAC address starting with a 24-bit manufacturer code.

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. :slight_smile:

1 Like
17

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.

18

So how do I add a Bluetooth device that comes up as a controller or keyboard so I can use the input to trigger stuff?

19

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…).

2 Likes
20

What about the one from hacs that’s says Bluetooth? Not the one that says passive Bluetooth.

21

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.

22

Is there any way to use that to use a Bluetooth keyboard to do stuffs as a trigger for an automation?

23

You can type and login to the HASS console (e.g. on a RPi4), but that’s not you’re asking for.

24

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?

image
image1000×1000 111 KB

image
image

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

25

This seems confusing and unnecessary. I’m gonna stick with ZigBee.

26

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.

27

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
28

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…