Open buchbergerd opened 1 month ago
I have the same problem when i use mushroom card's
This is indeed a real bug. Is there any version where this works well? What's your workaround @buchbergerd
Unfortunately, I do not have a workaround @carlosbaraza. I just wait and hope (and try again after a pretty long time)
It can be a issue with the services in BT itself, since HA changed a lot in the last version it might be broken, if anyone can checkout this, with the last BT and HA version, and report back any errors etc. would be helpful :)
I downgraded to 1.5.1 and I don't seem to have the problem anymore. I have an scheduler that automatically changes the thermostats temperature. Also I have a virtual switch to disable the scheduler and a slider to set the target temperature of all the thermostats.
I would need to upgrade again and check if this works. I encountered the problem while doing a lot of work on the house setup and trying many thermostatic valves, therefore many things could have caused the problem.
One thing I realised is that automations by default have only one concurrent job, and when I change the slider to set the target temperature of my 6 better thermostats (controlling 15 total valves), my automation waits for all the better thermostats to change sync the target temperature with the 15 zigbee valves. This can take up to 5-10 seconds, which means that if I change the target temperature while it is running, it doesn't work, or if I enable concurrencies, then it creates weird race conditions.
Prerequisites
Thanks for your great work so far!
[ ] Model name of your Devices
Does not really matter, some china Zigbee TRV
[ ] Output from Home Assistant Developer Tools state e.g.
Description
I have a little Touch Panel with an ESP32, that I want to use to control the target temperatures. Therefore, I use MQTT to
To update the setting when the touch panel is used, I have an automation performing the action "Climate 'Set target temperature'":
The problem is, that Better Thermostat seems to get stuck from time to time. The trace timeline sometimes shows a runtume of e.g. 67.05 seconds. Sometimes, it works great and fast. I have seen this error message, too:
Steps to Reproduce
Expected behavior:
It should work great and fast all the time
Actual behavior:
See above
Versions
HA:
BT: 1.6.0
Additional Information
When using BT with the BT card in the Lovelace web interface, I don't see problems like this. It would be great, if BT responds to the action call in the same way and "hides" connection problems and retries (if any).