I have issue that BLE client is not recognizing Ensto (BLE server) when it is advertising with some ESP32 devices. Only connectionless BLE devices are found ok by ble tracker, but not the Ensto device as it is BLE server. Have tried all the tricks of advertising / pairing mode and factory reset etc. So I just don’t get “Found device” for Ensto termostats.
Seems that this is somehow ESP32 board specific, I use “AZDelivery ESP32 Dev Kit C V4”. Strange thing is that same code works with 2 other boards, but not working with the 5 other ESP32 board that I bought later. ESP32 is really close to thermostats (I have two Ensto installed, two more waiting) Only difference between working and not working ESP32 boards is (should be) that others have pin headers physically connected (https://www.amazon.de/gp/product/B07Z849GM6 vs. https://www.amazon.de/gp/product/B08BZGC22Q)
On ble client -documentation page there is following note: “Currently, devices connected with the client cannot be supported by other components based on ESP32 Bluetooth Low Energy Tracker Hub as they listen to advertisements which are only sent by devices without an active connection.” Can this be somehow configured other way around, so that this only listens to those connectionless BLE advertisements for some reason? Anything that I can do wrong / differently when loading firmware to ESP32?
I am quite new on BLE and ESPHome, any ideas how to further debug? Or should I just decide that those new ESP32 boards are defected and get new ones?
I ordered few ESP32 devboards for this usage and spend several hours trying to pair with my Ensto with no luck I could see several BT devices broadcasting on debug logs but none of my Ensto thermostats where among the ones.
“Glad” to hear that I’m not alone with this one. What board(s) are you using?
Maybe there is some low level bug on ESPHome libraries somewhere where it decides if BLE device is supported or not. Or maybe bug how new version of ESPHome initalizes new board (as those working ones are first flashed with old ESPhome version). Really not much idea. Hopefully someone has.
I powered off my ESPHome Bluetooth Proxy -device and now this new ESP32 board seems to find the Ensto! Maybe that is messing things, maybe getting in between of pairing the devices.
Still not keeping up the connection, but that seems to be same issues as @ISO-B had.
I noticed that Ensto sends advertisement messages only when there is no active client connected to it. Advertisements stop right after client connects. So make sure that Ensto’s app is not used at the same time. One way to see if device is really advertising is to use nRF Connect App. It is able to show advertising devices and other information. Devices can be filtered with MAC address. Note that Ensto might be listed as “bonded” device if it has been used with Ensto’s app. It might be needed to unbond first to show in “scanner”.
nRF Connect can also be used to read characteristics from Ensto if used at the same time as Ensto’s app is running. Ensto’s app has to do connection first and then nRF Connect can use same device connection to list and read characteristics and their values.
Bluetooth Proxy has an “active” parameter. Could be that it needs to be set to false, which should be the default value. Also esp32_ble_tracker has “active” parameter that needs to be false.
Ensto has a special client authentication process and it blocks clients which connect to it and read wrong characteristics. In theory it should only block the ESP32 that has Proxy on, but who knows. Maybe incorrectly connecting client is enough to stop Ensto from sending advertisements.
I have passive Bluetooth Proxy instances with default configurations near my single Ensto without issues.
My Bluetooth Proxy did have both of these active parameters on. I was using example configuration from git, where those are on so others might be using the same too. Good tip.
Anyways the connection with one esp32 board is stable. With others it now finds the Ensto advertisement (thanks to those scan_parameters changes), but for some reason does not keep the connection. I am planning to get esp32 board with wired Ethernet connections to test this, as Wifi and Bluetooth can interference each other (as mentioned link above).
I have noticed that connection to Home Assistant and/or Ensto keeps dropping frequently when I’m viewing the log output. Especially when viewed through Wifi. With USB it seems to be more stable. So I tend to close ESPHome’s log view after software update has completed. It used to be more reliable when there were less characteristics and sensors in the YAML and so less traffic. I’ll check if default logging could be reduced to make it more reliable for everyone. Also some less used characteristics and sensors, like led brightness could be disabled by default in YAML. I need to think about it…
“In case of connection issues, stop reading the logs” doesn’t sound like a logical advice
Thanks, I’ll change that also. It will give less time for Wifi but esp32_ble_tracker is anyway disabled after connecting to Ensto, so it should help with discovery but not affect normal usage.
Just installed Olimex ESP32-EVB -board with Ethernet and external antenna. Ensto-integration seems to be working great right away. Have been running few hours so far. So the problems I had are board specific and/or to do with wifi and ble not working nicely together.
I went and brought a new ESP32-CAM from nearby store. It has connector to external antenna as well in case I need it. With this unit, I didn’t have any issue - everything worked like a charm. The ESP32 boards from AliExpress seemed to have lousy wifi/bt module…
Now I’m struggling to get second Ensto thermostat on the same unit (I have 5 of those in my house). I tried duplicating sensors, globals, ble_client etc. as suggested by @jumakki but I just cannot get the data to be fetched from both units at the same time. Most propably I’m not able to configure the connection loops properly or something like that. Has someone created configuration for multiple thermostats and would like to share it?
Edit: Well… actually last comment in that ticket says that it is fixed in 2022.11.1. So I could try again if stability issues still exist or not when that issue is not blocking it anymore.
It might just be my configuration… I ran it with extended debug and it shows connections are established but it’s complaining that it cannot poll due service or characteristics is not found:
INFO -> 192.168.255.181
INFO Uploading /data/esp04/.pioenvs/esp04/firmware.bin (1719216 bytes)
Uploading: [============================================================] 100% Done...
INFO Waiting for result...
INFO OTA successful
INFO Successfully uploaded program.
INFO Starting log output from esp04.local using esphome API
INFO Successfully connected to esp04.local
[15:36:28][I][app:102]: ESPHome version 2022.10.2 compiled on Nov 17 2022, 15:34:50
[15:36:28][C][wifi:502]: WiFi:
[15:36:28][C][wifi:360]: Local MAC: 94:B5:55:FC:4B:D4
[15:36:28][C][wifi:361]: SSID: 'foobar-iot'[redacted]
[15:36:28][C][wifi:362]: IP Address: 192.168.255.181
[15:36:28][C][wifi:364]: BSSID: F6:92:BF:95:E9:D9[redacted]
[15:36:28][C][wifi:365]: Hostname: 'esp04'
[15:36:28][C][wifi:367]: Signal strength: -50 dB ▂▄▆█
[15:36:28][C][wifi:371]: Channel: 6
[15:36:28][C][logger:280]: Level for 'ensto': INFO
[15:36:28][C][logger:280]: Level for 'ensto.adv': INFO
[15:36:28][C][logger:280]: Level for 'ensto.receive': INFO
[15:36:29][D][ble_client.automation:048]: Connection established with d0:cf:5e:28:13:e2
[15:36:29][D][ble_client.automation:048]: Connection established with d0:cf:5e:28:13:e2
[15:36:29][D][ble_client.automation:048]: Connection established with d0:cf:5e:28:13:e2
[15:36:29][D][ble_client.automation:048]: Connection established with d0:cf:5e:28:13:e2
[15:36:29][D][ble_client.automation:048]: Connection established with d0:cf:5e:28:13:e2
[15:36:29][D][ble_client.automation:048]: Connection established with d0:cf:5e:28:13:e2
[15:36:29][D][ble_client.automation:048]: Connection established with 84:2e:14:f2:09:52
[15:36:29][D][ble_client.automation:048]: Connection established with 84:2e:14:f2:09:52
[15:36:29][D][ble_client.automation:048]: Connection established with 84:2e:14:f2:09:52
[15:36:29][D][ble_client.automation:048]: Connection established with 84:2e:14:f2:09:52
[15:36:29][D][ble_client.automation:048]: Connection established with 84:2e:14:f2:09:52
[15:36:29][C][ble_client:027]: BLE Client:
[15:36:29][C][ble_client:028]: Address: d0:cf:5e:28:13:e2
[15:36:29][C][ble_client:027]: BLE Client:
[15:36:29][C][ble_client:028]: Address: 84:2e:14:f2:09:52
[15:36:29][C][captive_portal:088]: Captive Portal:
[15:36:30][C][mdns:100]: mDNS:
[15:36:30][C][mdns:101]: Hostname: esp04
[15:36:30][C][ota:089]: Over-The-Air Updates:
[15:36:30][C][ota:090]: Address: esp04.local:3232
[15:36:30][C][ota:093]: Using Password.
[15:36:30][C][api:138]: API Server:
[15:36:30][C][api:139]: Address: esp04.local:6053
[15:36:30][C][api:143]: Using noise encryption: NO
[15:36:30][C][homeassistant.sensor:030]: Homeassistant Sensor 'external_temperature_sensor'
[15:36:30][I][ensto:173]: Connected to Ensto1 -> write factory reset ID
[15:36:30][W][ble_write_action:054]: Characteristic 1ECA4351-B264-4DB6-9C59-AF4341D6CE69 was not found in service F49CEFD5-209B-4531-99BD-89FE2909931A
[15:36:30][W][ble_write_action:054]: Characteristic CA3C0685-B708-4CD4-A049-5BADD10469E7 was not found in service F49CEFD5-209B-4531-99BD-89FE2909931A
[15:36:30][W][ble_write_action:054]: Characteristic 53B7BF87-6CF0-4790-839A-E72D3AFBEC44 was not found in service F49CEFD5-209B-4531-99BD-89FE2909931A
[15:36:30][W][ble_write_action:054]: Characteristic CCF1FE7B-D928-45B1-ABBA-7A915F2F0C64 was not found in service F49CEFD5-209B-4531-99BD-89FE2909931A
[15:36:30][W][ble_sensor:049]: No sensor characteristic found at service F49CEFD5-209B-4531-99BD-89FE2909931A char 66AD3E6B-3135-4ADA-BB2B-8B22916B21D4
[15:36:30][W][ble_sensor:049]: No sensor characteristic found at service F49CEFD5-209B-4531-99BD-89FE2909931A char 1ECA4351-B264-4DB6-9C59-AF4341D6CE69
[15:36:30][W][ble_sensor:049]: No sensor characteristic found at service F49CEFD5-209B-4531-99BD-89FE2909931A char CA3C0685-B708-4CD4-A049-5BADD10469E7
[15:36:30][W][ble_sensor:049]: No sensor characteristic found at service F49CEFD5-209B-4531-99BD-89FE2909931A char C1686F28-FA1B-4791-9ECA-35523FB3597E
[15:36:30][W][ble_sensor:049]: No sensor characteristic found at service F49CEFD5-209B-4531-99BD-89FE2909931A char 53B7BF87-6CF0-4790-839A-E72D3AFBEC44
[15:36:30][W][ble_sensor:049]: No sensor characteristic found at service F49CEFD5-209B-4531-99BD-89FE2909931A char CCF1FE7B-D928-45B1-ABBA-7A915F2F0C64
[15:36:30][W][ble_sensor:049]: No sensor characteristic found at service F49CEFD5-209B-4531-99BD-89FE2909931A char F366DDDB-EBE2-43EE-83C0-472DED74C8FA
[15:36:30][W][ble_write_action:054]: Characteristic F366DDDB-EBE2-43EE-83C0-472DED74C8FA was not found in service F49CEFD5-209B-4531-99BD-89FE2909931A
[15:36:30][W][ble_write_action:054]: Characteristic CA3C0685-B708-4CD4-A049-5BADD10469E7 was not found in service F49CEFD5-209B-4531-99BD-89FE2909931A
[15:36:30][I][esp32_ble_client:142]: Service UUID: 0x1801
[15:36:30][I][esp32_ble_client:143]: start_handle: 0x1 end_handle: 0x4
[15:36:30][I][esp32_ble_client:142]: Service UUID: 0x180A
[15:36:30][I][esp32_ble_client:143]: start_handle: 0x5 end_handle: 0x16
[15:36:30][I][esp32_ble_client:142]: Service UUID: 1D14D6EE-FD63-4FA1-BFA4-8F47B42119F0
[15:36:30][I][esp32_ble_client:143]: start_handle: 0x17 end_handle: 0x1d
[15:36:30][I][esp32_ble_client:142]: Service UUID: F49CEFD5-209B-4531-99BD-89FE2909931A
[15:36:30][I][esp32_ble_client:143]: start_handle: 0x1e end_handle: 0x50
[15:36:30][D][ble_client.automation:061]: Found characteristic F366DDDB-EBE2-43EE-83C0-472DED74C8FA on device 84:2e:14:f2:09:52
[15:36:30][D][ble_client.automation:061]: Found characteristic CA3C0685-B708-4CD4-A049-5BADD10469E7 on device 84:2e:14:f2:09:52
[15:36:31][I][esp32_ble_client:188]: auth complete. remote BD_ADDR: 842e14f20952
[15:36:31][I][esp32_ble_client:188]: auth complete. remote BD_ADDR: 842e14f20952
[15:36:32][I][ensto:1171]: Factory reset ID written -> Connected
[15:36:32][D][ble_client.automation:024]: Write type: ESP_GATT_WRITE_TYPE_RSP
[15:36:32][I][ensto.receive:745]: Temperature calibration value: 0.0°C
[15:36:32][I][ensto.receive:895]: Heating Power: 1450W
[15:36:32][I][ensto.receive:826]: Power consumption ratio: 0%, last hour: 0%
[15:36:32][I][ensto.receive:961]: Energy unit: currency=0 (), price=0.00
[15:36:32][I][ensto:1030]: Factory reset ID written -> Connected
[15:36:32][D][ble_client.automation:024]: Write type: ESP_GATT_WRITE_TYPE_RSP
[15:36:32][W][ble_sensor:121]: [ensto1_temp_calibration_characteristic] Cannot poll, no service or characteristic found
[15:36:32][W][ble_sensor:121]: [ensto1_heating_power_characteristic] Cannot poll, no service or characteristic found
[15:36:32][W][ble_sensor:121]: [ensto1_power_consumption_characteristic] Cannot poll, no service or characteristic found
[15:36:32][W][ble_sensor:121]: [ensto1_energy_unit_characteristic] Cannot poll, no service or characteristic found
[15:36:37][D][binary_sensor:036]: 'Ensto2 Boost status': Sending state OFF
[15:36:37][I][ensto.receive:789]: Boost: OFF, offset: 3.00°C, minutes left: 0
[15:36:37][I][ensto.receive:647]: Room: 17.3°C, Floor: 18.0°C, Target: 17.9°C
[15:36:37][D][binary_sensor:036]: 'Ensto2 Relay state': Sending state OFF
[15:36:37][W][ble_sensor:121]: [ensto1_boost_characteristic] Cannot poll, no service or characteristic found
[15:36:37][W][ble_sensor:121]: [ensto1_real_time_indication_characteristic] Cannot poll, no service or characteristic found
[15:36:47][I][ensto.receive:789]: Boost: OFF, offset: 3.00°C, minutes left: 0
[15:36:47][I][ensto.receive:647]: Room: 17.4°C, Floor: 18.0°C, Target: 17.9°C
[15:36:47][I][ensto.receive:826]: Power consumption ratio: 0%, last hour: 0%
Those were the symptoms with that ESPHome bug. It remembered characteristics only for one device at the time. Update to 2022.11.1 and it should work.
I am testing with a version with just real-time and boost characteristics with 2 thermostats and it has been stable for an hour now.
I can push it later today or tomorrow to separate branch
Updated and now it works. Not sure if my code modification is optimal since it took some while before “things stabilized” but after some loops I’m not receiving values from both of the thermostats!
Some stability issues are expected if there are too many characteristics. Also ble tracker needs to be disabled after both thermostats are connected.
I pushed an example with minimal characteristics to GitHub - jumakki/esphome-ensto at multiple_devices branch.
My thermostat and esp32 both “crash” from time to time. Sometimes connection stays good for multiple days and other times it only last for day or two.
Esp can’t get data from thermostat or if at least it wont send it to hass. Booting esp only results hass data changing to unavailable state. If I remember correctly I even reflashed esp onetime without it affecting to an problem. Thermostat works normally without esp connection as you would expect. Haven’t checked if I am able to connect with Ensto app when this is happening. Booting only thermostat won’t do anything. Esp still can’t get data from thermostat. Only thing that returns things back to normal is booting both esp and thermostat. I will try to remember check logs when this happens next time.
Using esphome v2022.10.0 and latest version(53cded78ed1deede42eeecdc32a607bdac7df8b0) of esphome-ensto.
Has anyone else run into similar problem?
Possible “solution”: Could this be avoided by closing connection between esp and thermostat and rebooting esp every day. Haven’t had time to test this yet
Bluetooth client code in ESPHome has had a lot of changes in recent months and hopefully is improving all the time. There are still some memory issues that developers are working on. It could be best to update to 2022.11.5, as at least 2022.10.1 and 2022.10.2 had some improvements.
But do not update to 2022.12.0, as it seems to be having some major issues with active connections. I updated to it yesterday and had disconnect last night. I was able to reproduce it by resetting ESP32. Log shows advertisements from Ensto, but it looks like it doesn’t even try to reconnect.
Edit: I think I was able to fix ESPHome 2022.12.0 incompatibility with latest changes. Edit 2: Disconnect again with 2022.12.0 even after changes.
I added reset switch to esphome-ensto code. Using automation to reset every day at 12:00 I managed to run without problems for 8 days. Yesterday connection to thermostat stopped working for couple hours before I noticed it. This time using reset switch managed to restore connection without need to power cycle thermostat.
I will update ESPHome to 2022.12.0 tomorrow but I am still going to keep resetting esp every day. Maybe adding automation for resetting esp if connection to thermostat is down for 5-10 minutes. That might help keeping connection as stable as possible.
I had a disconnect again late yesterday with 2022.12.0. I would recommend updating to 2022.11.5 instead.
Those first .0 versions might not be stable in general.
Just for information… I have had good experiences with Olimex esp32 boards (3 different types) with wired Ethernet connection. Much better than with azdelivery wifi boards that I have. Boards are about 10 meters away from thermostat in different room and still has been working without issues for month or so.
update: I have one esp32 on wifi and 3 on ethernet. The wifi one has now disconnected the ble connection ones a day durign last three days, when ethernet ones haven’t had issues (at least yet). Running latest esphome.
I could see several BT devices broadcasting on debug logs but none of my Ensto thermostats where among the ones.