Since upgrading to all versions of 2.2.6, I've been having persistent issues with "delays" not working correctly or at all. I have 2 examples, one is cancellable, the other isnt:
This rule is triggered automatically by environmental conditions:
1/
These rules worked perfectly for many months prior to 2.2.6 and have continuously failed since.
Rule 1 will turn the heat on but fail to set the Temp to 20c after 5 seconds so the setpoint stays at the previous setpoint (eg 14c for overnight). Rule 2 will turn the AC fan on but fail to turn it Off again once the timer expires. The VS is turned off, but not the AC Fan.
However, if I turn on the fan for 1 hour (via the Dashboard VS) wait for it to turn on, and then turn it off (via the Dashboard VS), it will cancel. It just won't turn off when the timer expires.
Gents, Im a touch surprised not to hear from you? Im still seeing random delay failures on short duration delays (eg less than a minute) and consistent failures on long duration delays (1-9 hours).
I realise this isnt impacting everyone, but it would be nice to hear you are investigating?
How about showing some logs to substantiate what you say is failing? Screenshots only. Turn on Action logging in RM. After the delay starts, look at the App Status page for the rule at the bottom where it shows Scheduled Jobs. See if that looks right and comports with your expectations.
I'm not able to reproduce any of the problems reported in that other thread. So, please show a screenshot of logs that demonstrate the failure you think you have. There were no changes made to RM in 2.2.6 wrt how delays are handled. It is possible that some platform related change could be a cause, but until we have a reproducible failure, there is nothing we can do to figure out what your problem is.
When there is a complex set of actions on a device, it is often not possible to separate what the app does from what the device does or doesn't do. The app is always blamed, but not always the cause. Something like delays are used by thousands and thousands of apps without any issue. So, odds are pretty good there is a device issue involved. The only way to tell is to look at logs. Does the app execute the expected actions at the expected time. That's the first step to troubleshoot what is going on.
That's a pretty complicated log. The rule appears to be running twice in a row, why? Please turn on event and trigger logging also, so that is clear as well. From what I can see in this, the delays are happening as expected, so you need to point out where you think they are failing.
Not sure, I used your private Boolean suggestion from months ago to prevent rules from running when already active, but it doesn't seem to work very well (a per rule option to prevent this sure would be nice).
For now I've removed the 2nd trigger, it was mainly there as backup.
One thing I noticed from the logs is the in-rule delays are ignored. Maybe I'm using them wrong?
Why to you set the thermostat twice in a row? Once setting mode to heat and then later setting mode heat and setpoint? And, why the delays in this rule?
I did that to improve reliability for my battery powered Thermostats, I wake it up with the mode and then wait a few seconds before sending the temp set-point.
The first 5 second standalone delay was intended to wait for the Day_Max_Temp variable to be updated by another rule that triggers at the night mode change over.
Seems like extra unneeded complexity, since you are triggering both of those rules from Night Mode. But, to each his own.
If sending mode wakes up the thermostat, wouldn't the second command wake it up also? It actually fails if you send mode and setpoint in a single command? That's unfortunate. Were it not for that you wouldn't need any of the delays.
