Unfortunately it is not possible at least with YAML implementation. BLE Client requires MAC address when created and there can be max 3 of them, as mentioned in BLE Client — ESPHome
It is not possible to disconnect and connect to another device with same BLE Client.
I believe it supports multiple thermostats at the same time as it is PC based solution and doesn’t have limited hardware like ESP32. It will require that all devices are in range of PC’s Bluetooth dongle.
Thanks for @jumakki and @tuomassalo for the good work on this. I tested and got the ESP32 solution working.
I’m not a professional programmer but managed to make an early development version of a HA integration that currently as a hobby project. Currently it mostly reads values from the thermostat. I personally have only Ensto ELTE6-BT and ECO16BT available for test so please test other models as well.
I made the repo public so comments and pull requests are welcome! It seems that the Ensto thermostats are a bit temperamental when making the first pairing so it might take a few tries. Also the bluetooth range of Ensto devices is not very good / long. Please be patient since this is “just for fun”-project and not a professional work…
That’s awesome! Great work. I didn’t test it yet, but it looks good.
Hopefully Bluetooth proxy support will be also possible. I briefly tested something like that a year ago but couldn’t get connection working through proxy. I would need it as all my thermostats are not close to HA PC.
Pairing and connecting takes few tries also with ESP32 solution. It could be related to timing of messages. But not a big issue as retries don’t take much time.
I would actually prefer running this through a proxy as well. Now I have a secondary Raspi4 connected as remote… a bit complicated. My integration will not make connection through ESP32, it gives an error (something about the BLE security). The Raspi4 built-in BL works, which is a bit weird. It can probably be solved as your ESP32 solution works and connects ok so we know that the hardware is ok.
… but first we need more features like proper support for multiple thermostats etc.
My integration (hass_ensto_ble) has not been yet tested (at least by me) with multiple thermostats. However, it will generate unique sensor IDs for all thermostats so feel free to test it if you have the courage
I’m currently myself not running it in my production HA environment but in a separate test environment.
My personal goal with my integration is that it will support multiple thermostats but I just need to finish some more basic features first. I’m upgrading the integration all the time when I have spare time.
@BnW I made first tests with two Ensto BLE thermostats and the integrations seems to work (from v1.9.1 onwards) with multiple thermostats. You can control them separately. The only thing that doesn’t seem to work yet is the set_device_name service, since it doesn’t yet know how to name a thermostat out of multiple possible ones. I will get back onto that. The easiest solution is probably to create a name sensor for all paired thermostats and update the name using that.
Hmm. The set_device_time seems to set the time also for all the devices at the same time regardless of user input on the DateTime entity but that doesn’t really matter. I will fix that in a future release.
I’m happy to report that it was able to find and add one of my thermostats, using a generic x86-64 PC and a StarTech USBBT1EDR4 (Cambridge Silicon) BT adapter
Didn’t have time to make any automations / add the other device yet, but I’ll do that in the next couple of days.
Having run them both for a longer while, it looks like the other one will randomly drop for several hours and then sometimes it will return back by itself, but not always. Last night I managed to get it into a state where neither of them would re-connect back, no matter how many times I power cycled the thermostats or restarted HA.
Having said that, for the time they worked, they did work perfectly for my needs i.e. I was able to set them to boost for certain periods based on automations, and read back the temperatures.
But now they’re back running the previous schedule set via the app. I’ll investigate further when I have more time. Might just be that the BT connection is so weak from where the HA is, so I might try next with a dedicated instance running on RPi closer to the thermostats, and also to be able to debug it better.
One thing I noticed is that when I put the first thermostat into pairing mode, I only see that device in the discovered devices list, and am able to add it. But, when I add the second one, then I see both devices in the pairing list and have to figure out based on the MAC which one is the one that isn’t added yet. This is weird, as looking at the code, you seem to correctly be searching for the ones where PAIRINGFLAG=1. So don’t know why it is like this.
Probably a lot of this might just be because Bluetooth in general is so flaky, and especially on these devices I’ve never found it to be particularly trust-inspiring.
@BnW Thanks for the update! In my tests, the ECO16BT-J was a bit better in terms of bluetooth range but still very limited compared to many other devices. The thermostats inside heating units have very weak range, basically the BT radios are inside a huge metal heating unit so it’s no wonder… My main HA raspi is 15m away and behind two doors from the thermostats and they aren’t reliable. Only when I put a secondary raspi into the bathroom 3-4m away from the thermostat, the range is ok and connection reliable. So yes, the BT in these units is pretty flaky. Unfortunately there’s no way of detecting this properly with software. Maybe signal strength could be used at least to some extent.
One thing I noticed is that when I put the first thermostat into pairing mode, I only see that device in the discovered devices list, and am able to add it. But, when I add the second one, then I see both devices in the pairing list and have to figure out based on the MAC which one is the one that isn’t added yet. This is weird, as looking at the code, you seem to correctly be searching for the ones where PAIRINGFLAG=1. So don’t know why it is like this.
I noticed this too. My code doesn’t do this always though, I try to catch the bug when I have the time. Probably something to do with the config flow code and the different phases.