"Funny" problem with an esp32 acting as a bluetooth proxy (light bulb)

I have been trying for a few days now to add a bluetooth bulb that I have had for several years and that works with the Hao Deng mobile application.

Since I use HAOS in a VM and my host PC does not have a bluetooth card, I installed ESPHOME on an ESP32 and configured it as a bluetooth proxy.

I was able to confirm that it works well by very easily adding a Govee bluetooth thermometer.

In fact, it was so simple that I simply brought the thermometer closer to the desk and I saw it appear in “discovery” without me having to do anything.

Concerning the famous bluetooth light, pretty much the same thing happened except that rather than recognizing it as a bluetooth light, it is recognized as… a… keg level monitoring monitor.

So in the discovery section, I have a nice “Kegtron KT-100 27E2” that is ready to be configured. I also verified that it was not a neighbor’s product by comparing trying to configure it as a keg and comparing the mac address of the bulb in Hao Deng and in homeassistant.

I tried all sorts of things like disconnecting the bulb from Hao Deng, resetting it to factory settings, trying to manually add the “bluetooth” and “LED BLE” integration via the “integration” menu of home assistant and each time I have a message like: “No devices found on the network” and “No unconfigured Bluetooth adapters were found. There are 0 ignored adapters.”

I don’t know how home assistant came to the conclusion that it was a Kegtron product, but I would like some help to force him to understand that it is not that and ideally letting him choose another option would be the right one this time, but otherwise I am open to other solutions requiring manual configurations to yaml files.

I am new to home assistant, but I am a .net developer enthusiastic about technology for several years so I am not afraid to get my hands dirty :wink:

This is how I did the proxy part :

# Enable Bluetooth Proxy
esp32_ble_tracker:
  scan_parameters:
    active: true
    
bluetooth_proxy:
  active: true

Thanks for your help and see you soon.

I think I made too big a post for what it is.

My problem: My ESP32 bluetooth proxy and HA detect my Wifi bulb as a Keg monitor “Kegtron KT-100".

How to make it understand that it is rather a bulb and hypothetically make it try the Bluetooth or LED BLE integration instead?

Thx

Your post is not too long.
Most readers/helpers prefer descriptions like this because it often rule out certain extra tests that otherwise needs to be done.

Regarding your problem, then I can not help much other than saying that some vendors now and then take a firmware from another product and then just do some fiddling to get the basics working. This lowers the need for a firmware developer, so the products can be sold cheaper, and the product work in the vendors environment, because they know the kinks.
When it is introduced to HA then it is suddenly not in the vendors confined environment anymore and then the chaos starts.

1 Like

Thanks for your answer!

I understand what you’re saying. It also makes sense from an economic and efficiency point of view.

I would have hoped that there would have been a relatively easy way to alert HA that he was wrong.

When I think about it, this kind of correction mechanism, if it exists, would not be specific to Bluetooth devices.

I added the “integration” tag and put it in the “Third party integration” category.

Maybe it will attract more attention :wink:

The problem for HA is that it now have two devices with the same identity, but with different functionality.
The question is which one to choose.

1 Like

So this is how it works?

A manufacturer informs HA or enthusiasts determine that certain features are associated with a manufacturer’s product and it gets added to home assistant?

Is there a way to reach to these people or force a second option into my HA instance?

I feel like a software as open as HA should have this kind of mechanism?

I think some is stored in the Zigbee device’s identity that it will transmit to a Zigbee coordinator at pairing, which is then read by HA and used as the identity.

Take a look at the Discovery section here.