Possible Bug - Rule Machine Mode Restrictions

Hi,

I have four rules that are supposed to control the heating in our lounge. One rule for each mode. The rules do not seem to be evaluating the 'mode' restriction automatically after a mode change in the hub. i.e When we arrive home in the evening, the hub disarms the alarm and switched to evening mode but the "Heating - Lounge (Eve) 21deg" rule in not evaluated and still shows as restricted. To enable the tile I need to open it and then click [Done].

Here is the configuration of the rule:

Does anyone have any ideas? Have I missed something?

Cheers

Tim

Restricted rules are "frozen in time". Their conditions are not evaluated at all, even after they become unrestricted (unless one of the conditions of the rule changes).

One option would be to create a rule that triggers a rule evaluation of those rules when the mode changes.

Trigger
Mode Change

Action
Evaluate the conditions of rule (all of the modes since the ones that are restricted won't run anyway).

Should get the job done for you.

Obviously this example is just for trigger and action syntax as I don't have the other rules you use setup.

Just use the mode test as another condition in your rule.

I thought about that too, but it appears it has actions for both true and false, so wouldn't using mode as a condition cause false actions when potentially unwanted?

Hi, what I am seeing is that the rules are not even becoming unrestricted. (the app list still shows them and restricted) even after a mode change.

That must be a bug right?

Or have I misunderstood? Are rule restrictions not re-evaluated automagically?

Tim

Originally I had the mode defined in the conditions of the rule, but this led to intermittent processing of the rule.

Really ironic thing is that this morning the hub correctly unrestricted the ā€œHeating - Dayā€ rule, but last night it didnā€™t unrestrict the ā€œHeating - Eveā€ or ā€œHeating - Nightā€

A bit intermittent.

Tim

Sometimes the app list will show a rule as restricted but if you open the rule it will update the UI correctly. The app status (restricted/true/false/paused) is part of the new UI and doesn't always update on it's own, it doesn't affect the rule working though.

What shows in the Apps list can be misleading and not reflect the true condition of the rule with respect to it being restricted or not. Perhaps that feature should be removed.

A rule can only update that display when it runs. It runs when an event for it occurs, or when it is opened in the UI. Otherwise, it does not run when, for example, a restriction period begins or expires. Restrictions are tested when it runs from an event. So, the display can be wrong at other times.

I think I've talked myself into removing the Restricted red text from the Apps list, since you and others find it misleading, and reach the wrong conclusion about what is going on with the rule.

1 Like

I definitely think you should remove it, or find another mechanism for it to be correct. It is definitely confusing for end users when it says restricted, but it's not. It's only useful if it's correct, and if it can't be made correct it should be removed.

It could be made correct by creating subscriptions for restrictions events for the sole purpose of updating the display. Personally, I don't like this approach.

What I don't know is if people will still be confused about the restrictions they set up, and their rule not running as a consequence of being restricted.

Fair point. No obvious answer here. Maybe a helper app external of the RM rule itself?

Maybe just always show text stating that the rule has restrictions set? That seems useful to me. I too have noticed that the rules I have restrictions on, don't always show that they are restricted.

I find very useful to be able to know when a rule is restricted, if ti can be made to work properly. When you have a lot of them you can glance at the status. Even better, a global rule overview in a separate page, with a time chart, for rules restricted by time.

Iā€™m all for it working correctly as currently designed. Seeing that a rule is not able to run is much better than just guessing if it can run or not.

This however doesnā€™t address the issue of the rule not running that I am experiencing.

Last night the lounge has been cold. The temperature reported my the Netatmo was below the trigger threshold, the doors were shut, the hub in ā€˜Eveā€™ yet the Hub didnā€™t instruct Tado to turn on the radiators until I had re-Opened the rule. Once that was done the radiators heated up.

Is it something to do with automatic mode changes from Mode Manager because they seem flaky too. A mode change triggered by arrival / departure or manual intervention seems to work correctly, but a sunset mode change doesnā€™t always work.

Itā€™s getting a little boring now itā€™s very cold.

Tim

As discussed above, if you are using Mode Restrictions without putting the mode in as a condition of the rule, it's not going to work. Restrictions coming and going do not cause the rule to be evaluated or a trigger to be fired. Only conditions and trigger events do that. In your original post above you mentioned the rules not firing upon mode becoming Evening. Did the conditions become true then? Or were they possibly true before the restriction? Rules only fire upon a change of rule-truth, so if it was true before, and is still true, nothing will happen. You can force the evaluation to happen in a number of ways, including putting the mode as a condition instead of as a restriction. That way, when it's a different mode, the rule would be false, and then it would become true when the mode changes to Evening. That would fire the rule and turn on the heat.

When the modes were in the conditions there was intermittent triggering. This was a previous

I will remove the restrictions and re-Instate the mode as a condition again to retry.

Tim

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.