search

dbuezas / eq3btsmart

59 stars 9 forks source link

[Fix Released] ESP32 BTProxies not working. #4

Closed andrei-micu-ro closed 1 year ago

andrei-micu-ro commented 1 year ago

Hello,

Got a problem where the thermostats are not visible through ESP Home Bluetooth Proxy integration. The Thermostats were successfully paired using the BT from the server, communicated, all good. I them moved them away (only reachable through the ESPHome bluetooth_proxy) and they became unavailable.

I only have the "bluetooth_proxy:" added to the esphome yaml and use the Wemos D1 Mini (Wifi & BT). The BT Proxy works as other BT sensors connect and work.

I tried also adding the esp32_ble_tracker without any luck.

wjarka commented 1 year ago

Same for me. Were getting "No backend with an available connection slot that can reach address" after I removed the Bluetooth dongle from my Pi :)

andyxpert commented 1 year ago

Extra details:

bleak.exc.BleakError: No device found for address 00:1A:22:16:BA:58

and then

Traceback (most recent call last): File "/usr/local/lib/python3.10/site-packages/bleak/backends/bluezdbus/client.py", line 171, in connect reply = await self._bus.call( File "/usr/local/lib/python3.10/site-packages/dbus_fast/aio/message_bus.py", line 358, in call await future asyncio.exceptions.CancelledError

Caused by

File "/usr/local/lib/python3.10/site-packages/bleak/backends/bluezdbus/client.py", line 170, in connect async with async_timeout.timeout(timeout): File "/usr/local/lib/python3.10/site-packages/async_timeout/init.py", line 129, in aexit self._do_exit(exc_type) File "/usr/local/lib/python3.10/site-packages/async_timeout/init.py", line 212, in _do_exit raise asyncio.TimeoutError asyncio.exceptions.TimeoutError

From ESP: esp32_ble_client:036]: Found device at MAC address [00:1A:22:1A:88:81] [17:27:46][I][esp32_ble_client:058]: Attempting BLE connection to 00:1a:22:1a:88:81 [17:27:50][I][esp32_ble_client:188]: auth complete. remote BD_ADDR: 001a221a8881 [17:27:50][E][esp32_ble_client:190]: auth fail reason = 0x50

Keep up the good/great work ! Keep on improving the code. Cheers

dbuezas commented 1 year ago

@andrei-micu-ro

and use the Wemos D1 Mini (Wifi & BT) Isn't the d1 mini an esp8266? (No Bluetooth)

dbuezas commented 1 year ago

@andyxpert it may well ve that you have the Firmware>1.20, in which case you need to pair it with the esp first. I haven't tried this yet, but it may ve enough to hold the device button pressed for 5 seconds or so, and then adding the device in HA (make sure no other Bluetooth adapter is on) Please write again with the result, if that doesn't work I'll take a deeper look :)

wjarka commented 1 year ago

Is there an easy way to check the firmware version btw?

andyxpert commented 1 year ago

No result, tried with different configs in esp (esp32_ble_tracker and bluetooth_proxy both with active true), doesn't seem to work. added verbose logging in esp, will paste below.

[19:26:38][V][bluetooth_proxy:026]: Proxying packet from CC-RT-BLE - 00:1A:22:17:01:0F. RSSI: -77 dB
[19:26:38][VV][api.service:334]: send_bluetooth_le_advertisement_response: BluetoothLEAdvertisementResponse {
  address: 112241082639
  name: 'CC-RT-BLE'
  rssi: -77
  service_uuids: '3E135142-654F-9090-134A-A6FF5BB77046'
  manufacturer_data: BluetoothServiceData {
  uuid: '0x5201'
  data: 'EQ0816664'
}
}
...
[19:26:38][I][esp32_ble_client:058]: Attempting BLE connection to 00:1a:22:17:01:0f
[19:26:38][V][esp32_ble_client:123]: [00:1a:22:17:01:0f] ESP_GATTC_DISCONNECT_EVT, reason 62
[19:26:38][VV][api.service:344]: send_bluetooth_device_connection_response: BluetoothDeviceConnectionResponse {
  address: 112241082639
  connected: NO
  mtu: 23
  error: 62
}

I'll post if something changes

dbuezas commented 1 year ago

@wjarka

Is there an easy way to check the firmware version btw?

Yes, either:

dbuezas commented 1 year ago

@andyxpert did you try what I said about pairing?

andyxpert commented 1 year ago

Yes, but nothing happens. I think esp can't pair with the thermostat, think it only works for passive ble devices, as it shows in the log above that it does send messages to homeassistant, but when pairing it somehow doesn't Maybe esphome will have a release with active connections fixed ?! It is fairly recent for them also to allow active bt proxy

dbuezas commented 1 year ago

You are right... I must have made a mistake during testing then. I do remember the esp discovering it, but I guess when I connected, it used the bluetooth adapter in my HA machine :/ 

    @api_error_as_bleak_error
    async def pair(self, *args: Any, **kwargs: Any) -> bool:
        """Attempt to pair."""
        raise NotImplementedError("Pairing is not available in ESPHome.")
dbuezas commented 1 year ago

I corrected the readme. If you find any way to downgrade the firmware to pre v1.20 let me know. That should actually work.

wjarka commented 1 year ago

@dbuezas I will continue here, because this issue is actually Bluetooth Proxies ;).

I adopted the proxies to ESPHome. Unplugged the Bluetooth Dongle from Pi (so I am only left with Bluetooth Proxies).

Logs from ESPHome show nothing useful (potentially logging level too high).

In HA, I got this:

bleak.exc.BleakDBusError: [org.freedesktop.DBus.Error.UnknownObject] Method "Connect" with signature "" on interface "org.bluez.Device1" doesn't exist
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
...
bleak_retry_connector.BleakNotFoundError: EQ3 Gościnny - /org/bluez/hci0/dev_00_1A_22_14_B6_A2: Failed to connect: [org.freedesktop.DBus.Error.UnknownObject] Method "Connect" with signature "" on interface "org.bluez.Device1" doesn't exist
: The device disappeared; Try restarting the scanner or moving the device closer

I am not sure if by device it means Bluetooth dongle or the thermostat. But it almost seems like your implementation tries to always connect to the thermostat through the same BT adapter?

wjarka commented 1 year ago

Then I restarted Hassio and got three different errors for three different thermostats. Logs below:

FIrst

> custom_components.dbuezas_eq3btsmart.python_eq3bt.eq3bt.BackendException: Can't find device

Second

bleak_retry_connector.BleakConnectionError: Sypialnia - 00:1A:22:14:AF:20: Failed to connect: No backend with an available connection slot that can reach address 00:1A:22:14:AF:20 was found

Third

bleak_retry_connector.BleakNotFoundError: EQ3 Rurkowy - 00:1A:22:14:B7:75: Failed to connect: Timeout waiting for connect response

I hope that helps.

dbuezas commented 1 year ago

I think this may be because the btproxy is not yet connected to HA. The component should sooner or later switch to the BTProxy, and then you will get a different error :/

dbuezas commented 1 year ago

Thanks for the experiments btw

wjarka commented 1 year ago

If I should just create a new issue, let me know ;).

wjarka commented 1 year ago

I think this may be because the btproxy is not yet connected to HA. The component should sooner or later switch to the BTProxy, and then you will get a different error :/

I can disconnect it tomorrow and wait longer and see what happens. But first I want to make sure it's warm in the house, so don't want to leave it disconnected for the night ;). Let me know if checking that would be useful :)

wjarka commented 1 year ago

And maybe that first message is useful. :)

And actually... one of the Bluetooth Proxies may have just connected to a thermostat. This showed up in ESPHome logs:

[19:39:41][D][esp32_ble_client:036]: Found device at MAC address [00:1A:22:14:B6:A2]
[19:39:41][I][esp32_ble_client:058]: Attempting BLE connection to 00:1a:22:14:b6:a2
[19:39:44][I][esp32_ble_client:142]: Service UUID: 0x1800
[19:39:44][I][esp32_ble_client:143]:   start_handle: 0x100  end_handle: 0x151
[19:39:44][I][esp32_ble_client.service:057]:  characteristic 0x2A00, handle 0x111, properties 0x2
[19:39:44][I][esp32_ble_client.service:057]:  characteristic 0x2A01, handle 0x121, properties 0x2
[19:39:44][I][esp32_ble_client.service:057]:  characteristic 0x2A02, handle 0x131, properties 0x2
[19:39:44][I][esp32_ble_client.service:057]:  characteristic 0x2A03, handle 0x141, properties 0x8
[19:39:44][I][esp32_ble_client.service:057]:  characteristic 0x2A04, handle 0x151, properties 0x2
[19:39:44][I][esp32_ble_client:142]: Service UUID: 0x1801
[19:39:44][I][esp32_ble_client:143]:   start_handle: 0x200  end_handle: 0x220
[19:39:44][I][esp32_ble_client.service:057]:  characteristic 0x2A05, handle 0x211, properties 0x22
[19:39:44][I][esp32_ble_client:142]: Service UUID: 0x180A
[19:39:44][I][esp32_ble_client:143]:   start_handle: 0x300  end_handle: 0x321
[19:39:44][I][esp32_ble_client.service:057]:  characteristic 0x2A29, handle 0x311, properties 0x2
[19:39:44][I][esp32_ble_client:142]: Service UUID: 3E135142-654F-9090-134A-A6FF5BB77046
[19:39:44][I][esp32_ble_client:143]:   start_handle: 0x400  end_handle: 0x430
[19:39:44][I][esp32_ble_client.service:057]:  characteristic 3FA4585A-CE4A-3BAD-DB4B-B8DF8179EA09, handle 0x411, properties 0xa
[19:39:44][I][esp32_ble_client.service:057]:  characteristic D0E8434D-CD29-0996-AF41-6C90F4E0EB2A, handle 0x421, properties 0x1a
[19:39:44][I][esp32_ble_client:142]: Service UUID: 9E5D1E47-5C13-43A0-8635-82AD38A1386F
[19:39:44][I][esp32_ble_client:143]:   start_handle: 0xff00  end_handle: 0xff07
[19:39:44][I][esp32_ble_client.service:057]:  characteristic E3DD50BF-F7A7-4E99-838E-570A086C666B, handle 0xff02, properties 0x38
[19:39:44][I][esp32_ble_client.service:057]:  characteristic 92E86C7A-D961-4091-B74F-2409E72EFE36, handle 0xff05, properties 0x8
[19:39:44][I][esp32_ble_client.service:057]:  characteristic 347F7608-2E2D-47EB-913B-75D4EDC4DE3B, handle 0xff07, properties 0x2
wjarka commented 1 year ago

But when updating temperature, I don't think it uses it to communicate. I am not sure how to verify that

wjarka commented 1 year ago

Also got a few of those:

[19:54:44][D][esp32_ble_client:036]: Found device at MAC address [00:1A:22:14:B6:A2] [19:54:44][I][esp32_ble_client:058]: Attempting BLE connection to 00:1a:22:14:b6:a2 [19:54:45][W][esp32_ble_client:089]: connect to 00:00:00:00:00:00 failed, status=133

andyxpert commented 1 year ago

Hmm, reopened, so there is something you can do directly in HA component to alter/control the esphome communication with the thermostat ? Interesting, i thought the issue was in esphome after we validated that it works with BT natively (yesterday) In any case, thumbs up ! Consider releasing more often (after each meaningul change) as it's faster to update from HA than replacing files from Git... Specifically now when winter is coming and we all need our climate

dbuezas commented 1 year ago

We could try to find out if BTProxies work on old firmwares at least:

  1. Get the Thermostat firmware version (remove batteries, add again, and it shows it briefly)
  2. Update to v1.0.1 of this component (it fixes the characteristic handle issue in BTProxy)
  3. Enable debug level logs in the component: in configuration.yaml 
    logger:
default: warning
logs:
custom_components.dbuezas_eq3btsmart: debug
  4. Add the BTProxy and remove the Bluetooth dongle from the computer
  5. Restart HA
  6. Check both HA and BTProxy logs
  7. Post findings :)
wjarka commented 1 year ago

I haven't followed the full instruction yet. Just installed 1.0.1 and now I have this:

[22:02:52][D][esp32_ble_tracker:264]: Starting scan...
[22:02:52][W][bluetooth_proxy:110]: Error writing char/descriptor at handle 0x430, status=5

However, after this, it seems to update very fast which with this specific thermostat may mean that it actually used the proxy. But I will need to see tomorrow if it still happens when I unplug the dongle ;)

andyxpert commented 1 year ago

Nothing new, nothing interesting... Same lack of connection when visible only to esp32.

[Kitchen Thermostat] Broken connection [retry 1/1]: Kitchen Thermostat - 00:1A:22:17:01:0F: Failed to connect:
[Kitchen Thermostat] Error updating, will retry later: Kitchen Thermostat - 00:1A:22:17:01:0F: Failed to connect:

but i also have this:

[Kitchen Thermostat] Failed paring: Pairing is not available in ESPHome.

Hope it helps

wjarka commented 1 year ago

Nothing new, nothing interesting... Same lack of connection when visible only to esp32.

[Kitchen Thermostat] Broken connection [retry 1/1]: Kitchen Thermostat - 00:1A:22:17:01:0F: Failed to connect: [Kitchen Thermostat] Error updating, will retry later: Kitchen Thermostat - 00:1A:22:17:01:0F: Failed to connect:

but i also have this: [Kitchen Thermostat] Failed paring: Pairing is not available in ESPHome.

Hope it helps

I got those messages too, but then it worked. But again I don’t know if it fell back to the dongle or actually worked through proxy. Will play with it tomorrow and report back.

andyxpert commented 1 year ago

It's most probably through the dongle.

i got this eventually:

21:25:25][V][bluetooth_proxy:026]: Proxying packet from  - 00:1A:22:1A:88:81. RSSI: -77 dB
[21:25:25][D][esp32_ble_client:036]: Found device at MAC address [00:1A:22:1A:88:81]
[21:25:27][V][esp32_ble_client:181]: ESP_GAP_BLE_SEC_REQ_EVT a
[21:25:27][V][esp32_ble_client:096]: [00:1a:22:1a:88:81] ESP_GATTC_CONNECT_EVT
[21:25:27][V][esp32_ble_client:086]: [00:1a:22:1a:88:81] ESP_GATTC_OPEN_EVT
[21:25:27][I][esp32_ble_client:188]: auth complete. remote BD_ADDR: 001a221a8881
[21:25:27][E][esp32_ble_client:190]: auth fail reason = 0x50

But still not working in HA. Brought in range of Dongle, it appeared and works, then moved far away (so it's ESP only) and when I set a temp it says:

This error originated from a custom integration.

Logger: homeassistant.core
Source: custom_components/dbuezas_eq3btsmart/python_eq3bt/eq3bt/bleakconnection.py:70 
Integration: dbuezas EQ3 Bluetooth Smart Thermostats 
First occurred: 12:03:00 AM (1 occurrences) 
Last logged: 12:03:00 AM

Error executing service: <ServiceCall climate.set_temperature (c:01GFVJW7D49DJFWA2TAXEHCAZB): entity_id=['climate.kitchen_thermostat'], temperature=29.0>
Traceback (most recent call last):
  File "/usr/local/lib/python3.10/site-packages/bleak/backends/bluezdbus/client.py", line 171, in connect
    reply = await self._bus.call(
  File "/usr/local/lib/python3.10/site-packages/dbus_fast/aio/message_bus.py", line 358, in call
    await future
asyncio.exceptions.CancelledError

During handling of the above exception, another exception occurred:
...
bleak_retry_connector.BleakNotFoundError: Kitchen Thermostat - 00:1A:22:17:01:0F: Failed to connect:

sooooo still not working, though you must be on the right track as ESP connects (somehow) to the Thermostat

dbuezas commented 1 year ago

Then I just need the firmware version. If any of you has v<1.20 and it still doesn't work, then it may not be pairing after all and maybe something can be done

wjarka commented 1 year ago

The one I tested yesterday was 1.20.

I will check the other ones and follow the full instructions today :)

wjarka commented 1 year ago

Alright, all of mine are on 1.20.

I followed the full process.

As you will see in Hassio logs - at some point I removed one of the thermostats. To that point - there was almost nothing in the logs. No idea if that triggered something or it was just a coincidence.

Hassio Logs (Removed)

Unfortunately I can't post ESP logs because the browser tab got reloaded and it disappeared 🤦. However, nothing new there compared to what I posted yesterday. It was just more thermostats visible (but it's because one of the proxies was disconnecting a lot yesterday due to a backup battery failure).

andrei-micu-ro commented 1 year ago

I'm on the latest firmware (1.44 I guess), so pairing may be an issue.

Also, you see 2 ESPs (one called "bluetooth-extender-kitchen" and another called "bluetooth-extender-raul") - the kitchen one has the ESP as such: esp32_ble_tracker: scan_parameters: interval: 1100ms window: 1100ms active: true bluetooth_proxy: active: true

while the other (...-raul) only has the bluetooth proxy: bluetooth_proxy:

just to see both scenarios, and also because if I add the esp32_ble_tracker and make the bluetooth_proxy active a BLE thermo sensor stops sending data after a while... the only way to make it work consistently is to disable the bluetoth_proxy active config. Don't know why...

Anyway, some details from the HA log below:

2022-10-21 08:26:11.774 DEBUG (MainThread) [custom_components.dbuezas_eq3btsmart.config_flow] Discovered eQ3 thermostat using bluetooth: BluetoothServiceInfoBleak(name='CC-RT-BLE', address='00:1A:22:17:01:0F', rssi=-78, manufacturer_data={0: b'\x00\x00\x00\x00\x00\x00\x00\x00\x00'}, service_data={}, service_uuids=['3e135142-654f-9090-134a-a6ff5bb77046'], source='bluetooth-extender-kitchen', device=00:1A:22:17:01:0F: CC-RT-BLE, advertisement=AdvertisementData(local_name='CC-RT-BLE', manufacturer_data={0: b'\x00\x00\x00\x00\x00\x00\x00\x00\x00'}, service_uuids=['3e135142-654f-9090-134a-a6ff5bb77046']), connectable=True, time=234112.633661717), CC-RT-BLE
2022-10-21 08:26:11.776 INFO (SyncWorker_7) [homeassistant.loader] Loaded xiaomi_ble from homeassistant.components.xiaomi_ble
2022-10-21 08:26:11.798 DEBUG (MainThread) [custom_components.dbuezas_eq3btsmart.config_flow] Discovered eQ3 thermostat using bluetooth: BluetoothServiceInfoBleak(name='CC-RT-BLE', address='00:1A:22:1A:88:81', rssi=-90, manufacturer_data={0: b'\x00\x00\x00\x00\x00\x00\x00\x00\x00'}, service_data={}, service_uuids=['3e135142-654f-9090-134a-a6ff5bb77046'], source='bluetooth-extender-kitchen', device=00:1A:22:1A:88:81: CC-RT-BLE, advertisement=AdvertisementData(local_name='CC-RT-BLE', manufacturer_data={0: b'\x00\x00\x00\x00\x00\x00\x00\x00\x00'}, service_uuids=['3e135142-654f-9090-134a-a6ff5bb77046']), connectable=True, time=234130.244776951), CC-RT-BLE

and then 

2022-10-21 08:26:11.957 DEBUG (MainThread) [aioesphomeapi.connection] bluetooth-extender-raul @ 192.168.0.7: Got message of type <class 'api_pb2.BluetoothLEAdvertisementResponse'>: address: 112241082639
name: "CC-RT-BLE"
rssi: -92
service_uuids: "3E135142-654F-9090-134A-A6FF5BB77046"
manufacturer_data {
  uuid: "0x0000"
  data: "\000\000\000\000\000\000\000\000\000"
}

2022-10-21 08:26:11.965 DEBUG (MainThread) [aioesphomeapi.connection] bluetooth-extender-kitchen @ 192.168.0.250: Got message of type <class 'api_pb2.BluetoothLEAdvertisementResponse'>: address: 108539158555677
rssi: -56
service_uuids: "0xFE9F"
service_data {
  uuid: "0xFE9F"
  data: "\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000"
}
manufacturer_data {
  uuid: "0x00E0"
  data: "\000\017\312;\225\217"
}

and then some actual data

2022-10-21 08:26:12.167 DEBUG (MainThread) [aioesphomeapi.connection] bluetooth-extender-kitchen @ 192.168.0.250: Got message of type <class 'api_pb2.BluetoothLEAdvertisementResponse'>: address: 132756308469441
rssi: -99
manufacturer_data {
  uuid: "0x0075"
  data: "B\004\001\200\216x\275\274\233\246\301z\275\274>\n\277\001\000\000\000\000\000\000"
}

not sure it's from the thermostat as I also have a few other BLE devices which may hook-up to the bluetooth proxies...

also this may help:

2022-10-21 08:26:11.950 DEBUG (MainThread) [homeassistant.components.bluetooth.manager] MJ_HT_V1 (58:2D:34:39:BA:10): Switching from bluetooth-extender-kitchen[True] to 5C:F3:70:A6:D2:33[True] (new rssi:-81 - threshold:6 > old rssi:-89)

It switched correctly from the bluetooth proxy (esp) to the built-in BT Dongle - that's a different Thermostat in a different room with no ESP, so it makes sense :)

I'm updating the ESP (from 2022.10.0b10 to the stable 2022.10.0) now and will post any findings if anything's worth mentioning... Hope it helps.

PS: andrei-micu-ro and andyxpert - both are me :D just different devices...

dbuezas commented 1 year ago

EspHome discord thread for BTProxy pairing:

https://discord.com/channels/429907082951524364/1032935050158800916/1032935051861688370

andrei-micu-ro commented 1 year ago

the discord channel seems empty... or maybe I'm doing something wrong...

wjarka commented 1 year ago

the discord channel seems empty... or maybe I'm doing something wrong...

Join their server first: https://discord.gg/KhAMKrd

andrei-micu-ro commented 1 year ago

I'm such a noob when it comes to Discord... thanks, all fine now :D

andrei-micu-ro commented 1 year ago

now that I read the discord discussion... another idea could be to add the "setPin(pin)" method before the "begin" call when connecting to the BT device (via proxy) and have the device pins mapped in a config file as they're pretty static (unless you change batteries and need to re-pair them). Would that work as a workaround just to test it out ? alternatively you could push your changes in a branch so that NabuCasa implements the GATT bonding in ESP.

I'm almost about to start reading the ESP code, install the Espressif locally and start building my own ESP image with the pins hardcoded :) but I'll try to refrain from this as good progress is happening here.

wjarka commented 1 year ago

EspHome discord thread for BTProxy pairing:

https://discord.com/channels/429907082951524364/1032935050158800916/1032935051861688370

So do you think it’s because of pairing?

dbuezas commented 1 year ago

Haha, go for it! In this case, it seems like the pin isn't even needed (at least for the fw version I have). It only needs the confirmation, and the client storing the generated auth data (encryption keys I guess)

wjarka commented 1 year ago

now that I read the discord discussion... another idea could be to add the "setPin(pin)" method before the "begin" call when connecting to the BT device (via proxy) and have the device pins mapped in a config file as they're pretty static (unless you change batteries and need to re-pair them). Would that work as a workaround just to test it out ? alternatively you could push your changes in a branch so that NabuCasa implements the GATT bonding in ESP.

I'm almost about to start reading the ESP code, install the Espressif locally and start building my own ESP image with the pins hardcoded :) but I'll try to refrain from this as good progress is happening here.

If you do and it works - let us know :). But yeah, I’d rather see an out of the box solution ;)

wjarka commented 1 year ago

Haha, go for it! In this case, it seems like the pin isn't even needed (at least for the fw version I have). It only needs the confirmation, and the client storing the generated auth data (encryption keys I guess)

The funny thing is - I don’t remember pairing those on my Pi. I did on the old one, but not here.

dbuezas commented 1 year ago

So do you think it’s because of pairing?

Yes, I'm fairly sure. I fixed the bug for "start_notify", and now it fails while writing in the same way as it failed in linux before pairing.

dbuezas commented 1 year ago

To confuse things further, it is not a "give me the right pin" kind of pairing, but the "should we pair" one, which only exchanges some data without a pin. In case you wonder, this is still kind of secure because it guarantees no one else can send commands without pairing via button first

andrei-micu-ro commented 1 year ago

saw in the logs that by default it sends the RSSI and some generic empty Data without pairing but then sends a bunch more after pairing (or after the handshake)

dbuezas commented 1 year ago

Oh, i couldn't find a way to detect if the device is paired in python, this may be useful to show something to the user

dbuezas commented 1 year ago

Now I'm touching EspHome code. No success yet

andrei-micu-ro commented 1 year ago

Same here... not much luck with EspHome codebase. Also the discord comments seem to approve that it's deeper than one layer/component. Changes as far as I see things are needed in:

I would give it a rest for now as I think NabuCasa guys and the contributors are aware of this scenario and will handle it properly. Let's not forget that Bluetooth Proxy is a new feature and that the Active configuration was just added. I'm sure in a few releases it'll be fixed.

On a different topic, there may be an easy way to flash the Esp board with a custom firmware done in Arduino - the BT stack is way simpler. I will give it a few tries just out of curiosity. The problem here is integration with HA... as it's not out-of-the-box like with EspHome. An MQTT approach could work though.

dbuezas commented 1 year ago

https://github.com/arendst/Tasmota/issues/16775

Tasmota has a working controller

dbuezas commented 1 year ago

(for older fw version)

wjarka commented 1 year ago

arendst/Tasmota#16775

Tasmota has a working controller

According to this post - 1.20 should work just fine without pairing. At least if I understood correctly

dbuezas commented 1 year ago

Tasmota fixed newer versions https://github.com/arendst/Tasmota/issues/16775

dbuezas commented 1 year ago

I was cleaning the logs in the thread a bit (there was way to much stuff) and saw this in @andyxpert 's log:

[21:25:27][I][esp32_ble_client:188]: auth complete. remote BD_ADDR: 001a221a8881
[21:25:27][E][esp32_ble_client:190]: auth fail reason = 0x50

I think this is exactly where it breaks. Authentication failed. I believe this is because esphome doesn't configure the BLE client to handle pairing at all.