Why aren’t routine conditions checked when the routine is activated?
I mean, If I have a routine with a span of time precondition and a below or equal temperature condition and both conditions are met, why isn’t the routine starting once activated through the toggle button?
Is ‘the toggle button’ the enabled/disabled button?
My understanding is that Rules/Routines are completely event driven and don’t lookup information from the API. So conditions, including preconditions, only get updated because a subscribed to event has been received, and similarly stuff can only happen in response to an event.
I was really trying to make the point that, as far as I know, there isn’t really such a thing as a state check in Routines (or anything Rules based) in the same way there might be in script based automations. Routines subscribe to or schedule events for their input and issue commands as their output. They are constantly updating their internal state so when a triggering event occurs the Boolean value of all the other conditions or preconditions not dependent on that event is already established. They don’t need to check anything, they already know it (subject to having been enabled long enough).
That could be nonsense, of course, but it is how I see it, and it is consistent with how the old Smart Lighting app behaved. You could watch the logs to see the internal state of the automation constantly being updated in response to events, until a triggering event occured.
I don’t think you can create a Routine of preconditions in practice but you can certainly create an equivalent Rule directly. It won’t execute automatically but you can execute it manually.
It would be quite possible for automatically run Routines to have an execute button just as manually run ones (Scenes) do.
SmartThings has always looked at conditions as “filters” (their word) on the automation.
So for them, pre-conditions are filters which are applied after the routine is triggered by the other if event.
The automation subscribes to the if’s that are not preconditions. When one of those matches the automations trigger, it then applies the “filters“ by looking at the preconditions to see if it’s supposed to go ahead and run the automation.
So from that design standpoint, it makes sense, but I agree that the UI is not helpful. Other platforms present this type of architecture as an “only when” at the end of the action statement, rather than as something that looks like it’s somehow part of the trigger if.
Fair enough. I just try to describe it in a way that is “digestable” by those not overly familiar with the ST platform. So, while there may not be an actual state check when the event triggers, the state of the preconditions is already determined and serve as the boundary conditions for the triggering event(s).
Having to actively check each state of the filters when the if event occurs could add noticeable lag to the process right at the moment that the system is expected to act. So I understand that part of the design.
That said, an argument could be made for checking everything when a previously disabled routine is enabled or since you might have missed the triggering event while the routine was in the disabled state. But it can get tricky.
I’ve never been clear how default states for conditions are handled either. Maybe there is some checking going on, even if no actions are run.
Every time I think I have a handle on how Rules work I realise I don’t have the whole story. I have some Rules with nested ‘if … then … else …’ blocks that I’ve been running for a three years or so now and I’ve only just realised that the scope of ‘trigger events’ seems to be the immediately surrounding ‘if’. So if only a nested ‘if’ is triggered the top level one isn’t executed and nothing happens. Or something like that, or indeed not like that. Made me realise that perhaps there is a good reason why the Rules API hasn’t evolved as it was suggested it would.
Why is it absurd? Most any rule engine I’ve seen is based on triggering events, as in “hey something changed”. Take the example I posted previously. In Sharptools it plainly says “When any of the following state change or events occur:”. So none of their Flow conditions are considered unless there is a triggering event. And I’d dare to say their rules engine rules circles around ST Routines, but it’s built with the same premise that there needs to be an event in order to evaluate state/conditions/whatever-you-want-to-call-it.
Here is an alternative hypothetical situation. Supposing your Routine action is to turn on a heater. You enable the Routine and the conditions are met so the heater turns on. A short (or even long) time later the conditions are still met but you choose to turn the heater off. I suspect you wouldn’t expect the Routine to run and turn the heater back on again? So what is so special about the moment that the Routine was enabled?
Personally I’d say enabling a Routine shouldn’t cause it to execute.
In general I think there is an argument for being able to manually execute automations, but in the case of a Routine this still might not have the intended behavior until it gets itself in sync. Isn’t that what the device controls in the app are for though?
Suppose you have a routine with a time period precondition and a below or equal temp condition. If the temperature is below the specified temperature when the time period begins It won’t trigger the action unless there’s a change in the temperature, although you specified it should when it’s below that threshold. If the time period ends and the temperature hasn’t changed during that period the action won’t be executed a single time in spite of the fact that the temperature was below the specified threshold the whole period of time. Does this make any sense?
I think it does. That might be exactly what some users expect and/or want it to do, particularly bearing in mind they might not be using the condition with temperature. Such users may even be in the vast majority.
Could they better describe how they have chosen to have the ‘below or equal’ and related conditions behave when acting as a triggers. I think they could.
Could the same conditions be improved by giving users the option of having it potentially trigger the Routine with every attribute report? I think yes, ST may perhaps not be so keen.
If it were a case of imposing one or the other option on users, would I have chosen the other one? It would certainly have been my starting position in a discussion.
The last three points could also be applied to a discussion of whether time periods could actually be conditions that trigger the Routine at the start.
Is there an argument for a ‘Smart heating’ as well as a ‘Smart lighting’ that is more sympathetic to heating and cooling tasks than the general purpose Routines? Possibly.
I wanted to do smarter thermostats when we built this place in 2017 but the HVAC contractor said he’d invalidate the warranty on the system. Dunno why and didn’t want to get in a p*ssing contest with him. I really wish I had a couple of more sensors.