Ah, o.k. so the user immediately sees the effect of pressing.
oh, what i could do is make the on/off announcement very fast, then it is clear what 0 and 1 mean, it is a simpler change and doesnt invite to your reaction of trying to click it too. So half a second or so in screen
Yes, but adding an ‘Is’ is really a big deal?
I’m currently integrating my 8 Devices into HomeAssistant. Maybe this Log-Entry is of interest to you:
Logger: bthome_ble.parser
Quelle: components/bthome/init.py:91
Erstmals aufgetreten: 14:38:34 (51 Vorkommnisse)
Zuletzt protokolliert: 14:43:48
BTHome sensor F1CB: BTHome device is not sending object ids in numerical order (from low to high object id). This can cause issues with your BTHome receiver, payload: 2d001f010f0015000901
BTHome sensor 049F: BTHome device is not sending object ids in numerical order (from low to high object id). This can cause issues with your BTHome receiver, payload: 2d001f010f0015000900
CC-RT-BLE 0640: BTHome device is not sending object ids in numerical order (from low to high object id). This can cause issues with your BTHome receiver, payload: 2d001f010f0015000902
Yes i noticed that too, is already fixed in the version I’ll deploy soon.
Thanks for the logs and feedback!
V2.01 released!
Better battery, many optimisations and some fixes.
» A connected thermostat uses less battery and answers faster. The radio now settles on one rhythm for the whole connection instead of stepping through three, chosen by measuring it through Home Assistant on a CSR8510, a Realtek RTL8761B, an Intel 8260/8265 (built in), a Broadcom BCM20702 and an ESP32-C3 running as an ESPHome Bluetooth proxy: a single request is answered in well under a second, and a burst of 20 in a few seconds. When Home Assistant (or anything else) speeds the connection up, the radio asks for its rhythm back about a second after things go quiet. Firmware updates still run at full speed«.
With FW 2.00 I experience a huge delay between setting a value on HomeAssistant in the debuezas-Integration and the the command being executed on the EQ3-device. With huge I mean several seconds, even minutes. I’m connecting the EQ3 via a ESP32 Bluetooth-Proxy.
Does FW 2.01 improve here, or do I have different problem?
Cannot confirm. I’m currently using a btproxy with firmware 2.00 and commands go through instantly using the dbuezas integration.
Can you send me your config-Yaml for the esp32, please?
I suspect a different problem, but do update to 2.01 and try it. It changes the Bluetooth connection settings to a better balance, and i did pick the values that give good performance at low consumption for all adapter chipsets i have, including and esp32-c3 as btproxy
You’re right, the problem was down to my ESP32 configuration. You need to set up 5 connection_slots for the Bluetooth proxy; otherwise, there are delays whilst waiting for slots to become free after connections have been terminated due to connection issues. With 5 slots, the commands reach the two EQ-3 devices without any delay.
V2.02 has a fix for pairing with bthome proxys
Does it improve pairing with PIN only or pairing without PIN too?
Only with pin.
Thank you so much for developing this custom firmware!
We have 10 eQ-3 valves in the house, with multiple esp32 bluetooth proxies (via ethernet), and had very mixed results the last winter. I’ve now flashed your firmware to three of the worst offenders (1x2.0.1, 2x2.0.2) and so far have totally stable connections to home assistant.
For reference: I’ve disabled the PIN for all three, had to do the cache_services: false workaround, and all three valves showed up in HA for the builtin and your custom integration a couple of seconds after the update. Since yesterday, I had no connection issues at all (before the valves became unavailable a couple of times a day).
What version of ESPhome are you using for BT proxies. I found versions above 26.01.5 poor connections. Gave up testing after 26.04.1
Im using 2026.9.1. Meanwhile I have 3 ESP-32 running, each of them proxying the connection to two EQ-3 devices.
You should try it with my firmware, i think the issue with stock and btproxys is that stock has some non compliant setting which the esp32 rejects, and that rejection also ends up cancelling the eq3 request to show down the radio communication interval. So the esp32 keeps trying to listen to the eq3 every 11ms forever and that hogs the wifi (which shares the antenna) and everything falls apart. That’s also btw crazy battery intensive for the eq3.
I think the Bluetooth improvement push in home assistant is what added the 11ms interval on connect, and that’s why it got bad in a specific version onwards
V2 fixes all of that, it’s compliant and uses fast speed but with a self relaxing setting that allows the eq3 to skip up to 10 windows if the line is silent, mambo jumbo good connection and battery efficient
Have updated 6 eq3 to new firmware. Waiting for 6th to be picked up by your integration eq3 thermostat. BThome has shown all 6.
Since 4 days 2 of my TRVs are unavailable. The bthome values are there.
ESPs are restarted and also plugged off. HA restarted, HAOS restarted, TRVs BT switched off/on.
No idea what to try else 