RM 4.0 "Delay" bug in 2.2.6

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:

and this one is triggered manually by 4 Dashboard buttons (virtual switches):

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.

@bcopeland @bobbyD @support

Looks like this issue affects RM4.1 too:

1 Like

@bcopeland @bobbyD @support

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?

Tagging Bruce Ravenel (@bravenel), who wrote RM.

1 Like

No, we have not been investigating this.

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.

1 Like

Most of the details can be found over here:

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.

Will do, it's possible that the Zen Thermostats are suddenly the issue*, but I don't use delays in any other rules.

*I replaced the batteries a couple of weeks ago so I'm ruling out dead batteries.

Here's the rule being triggered:

And fan on:
Screen Shot 2021-04-13 at 4.34.12 pm

manually cancelled by turning off the switch:

Fan off:
Screen Shot 2021-04-13 at 4.35.58 pm

I'll post back in 1 hour with the logs from auto off.

Well FK me, the time I'm watching the logs like a hawk it works perfectly! :rage:

Oh FFS, every time I run this rule (#2) with logging open ,the rule runs perfectly! :man_facepalming:

Got one, different rule this time:



and no set-point change sent to Thermostat:

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.

I cannot repeat the issue reported in my original post. Perhaps I did something wrong in the original rule.

I will watch for a reappearance but somehow I doubt it will happen again.


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?

it is on.

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.

I have a couple of rules that use the same Global variable, that's why it's updated by a standalone rule.

I'll try setting mode/setpoint in one hit and see what happens.

That doesn't explain why the stand-alone delay is not working?

I'm not convinced that it isn't working correctly. It appears to be in the logs you posted.