litinoveweedle
commented
4 months ago Hello, thank you very much for opening issue.
Just for future reference, why this is happening. First the WARNING message Already running comes from the HA native script entity. As default climate_template schedule script to run in mode_action Single. This is also visible in your configuration:
mode_action: single
This means, that is script is still running and if executed again, it will raise this warning message and will not start. This is as per HA specification. So this is HA native function, which is outside of the climate-template reach.
I personally use climate-template to handle my boiler, which has very very very slow interface as the Siemens OZW webserver needs tens of second to write value and another tens of second to update the read value in HA. So in my case, there is pretty long window of script execution and i meanwhile script is executed again (for whatever reason) I will get Already running warning. In such case I should probably use different mode_action, the best is probably:
mode_action: queued
I some special cases, like the one you described - when the update of the value by script is read by the template and cause described loops, we can probably expect such change to happen and at least not fire the script again, if we already running script with the same attributes value. This can theoretically cause some divergence between the real device and the climate_template. This would be caused by the need, to update internal value of the attributes before starting first script run, so if the script is triggered second time (even before first is finished) we see, that it would be called with the same value and do not run it. But what will happen, if the first script execution will fail later and the managed device attribute is not updated? The value in climate template is already updated and even if you try to re-trigger the script run with the same attribute value, it will not start again. This means, that if the execution of the script fails, your climate_template and managed device attribute will not be in sync, until the attribute will not change its value again, causing script to be run.
So far I implemented this as it very simple logic. You can try it in the latest climate.py of the development branch. This should solve most obvious case of the loop as you reported.
I would like to explore also other possibility - when executing script create first "expectation" for the updated value, but do not update internal climate_template attribute. Only when update will be received from template in under configurable timeout time, update internal attribute value. I would also allow to re-trigger script run, if the expectation is not fulfilled before timeout. In case script will be re-triggered during the timeout with different attribute value we will need to add new expectation to the list and allow for the new script to be queued to be executed after first script finishes. In such case we shall set mode_action to queued and max_action parameter to some reasonable value to limit the queue size. I would like to explore this logic, but probably in the different development branch.
CV8R
dmatik
The problem
State changes from the climate device triggers the climate service again which causes loops, races and general hassles. I have had to disable the template devices because I am unable to turn off the climate device. The device tries to turn off, but heat mode is set again and the unit stays on, continues to loop.
Below is an example where the set point was changed on the AC units panel, resulting in triggering the setpoint service.
I believe this issue is related https://github.com/jcwillox/hass-template-climate/issues/14
Below is an example of trying to turn the unit off from heat mode using the template - note it triggers the "Already running"
Shall I create a new issue in your repo for this?
What version of Template Climate has the issue?
No response
What version of Home Assistant are you running?
No response
What type of installation are you running?
None
Example YAML snippet
Anything in the logs that might be useful for us?
No response
Additional information
No response