Period of time-condition seems to prevent a routine from triggering

I’ve set up a routine that checks kid’s room temperature from a sensor and turn on the space heater of the temp is below the lower threshold and turns it off if it’s above the upper threshold between 3pm and 8am next morning.

But on numerous occasions, this routine doesn’t get triggered even if the room temp is below the lower threshold.
If I change the precondition to a specific time of day - 3pm, for example - rather than a period of time, I think the routine gets triggered without failure.

What makes the “period of time” precondition more iffy than the “specific time of day” precondition? Any fix to ensure proper execution of a routine with a “period of time” precondition?

In routines, the condition that triggers the execution of the routine is not the precondition.

What triggers the execution is a change of state of the device that meets the condition. In this case it is a change in temperature that occurs in the period of the precondition.

When you choose a fixed time, it is not a precondition, it behaves like a condition and when that time arrives it triggers the execution of the routine and checks the status of the temperature and if it meets the condition it executes the action.

If you choose a period of time as a precondition, if the state change in temperature does not occur in that period, which meets the temperature condition, the action will not be executed.

1 Like

That I understand.

But in my case, the temperature definitely changes, and yet the routine that should be triggered by the temperature change does not kick in.
It’s definitely the precondition that is throwing off the routine. As part of trouble-shooting, I created the same routine without the precondition, and it gets triggered when the temperature drops below the threshold.

Why would the same routine fail to trigger when there is a precondition of specified time window that is met anyways?

Does it matter that my temperature sensor executes locally and the zigbee plug executes through the cloud?

I have had that problem with the old meross integration, that the states with smartthings were out of sync or my plugs were offline time to time and some automations were not executed correctly. It hasn’t happened to me lately.

You can also view the history of routines and scenes and see if execution is triggered. Then checking what action the switch or socket performed

I’m having the same problem. If I have a automation with e.g., sunrise to sunset time period along with a location e.g., when I’m gone more then 5 min from home in the “if” , the automation will not run.

It’s to turn my lights on and open door when I get home. It’s an all wifi system, no hub.

If I remove only the time period then the automation always runs and everything works.

It seems that when I first set up the automation it worked with the “if” time period but then stoped.

I tried replacing sunset to sunrise with specific times e.g., 7 am to 7pm but that does not work either.

Amy thoughts?

I think you are describing using the ‘home after being away for five minutes’ condition. Have you tried removing the ‘after being away for five minutes’ option to see what happens?

How does your departure and arrival time relate to the time range? Do both happen within that time interval?

With Routines it isn’t clear how they map onto Rules, and nor is it clear how the Rules do their comparisons. As an example, ‘after being away for five minutes’ could be looked up in the device event history (as webCoRE does for a similar comparison), but it could also be something the Rule itself determinines by starting a count up timer on departure.

I’m doing this is the Smarthings app. Everything used to work earlier this year.

The problem is not the "home after being away for five minutes’ condition. That’s always worked fine. The problem occurs when I try to have that conditions run either during the day only or night only. I have two automations. One that runs only during the day when I return home: opens the door but does not turn on lights. The second automation runs only when I return at night: opens door and turns on lights.

As long as I don’t add the day or night condition before the home away condition everything works when I return home after being away for 5 min: door opens and lights turn on (since I don’t have a time condition I run the automation that always turns on the lights).

When the time condition is present the entire automation does not run. If I remove it, everything works.

I’ve removed and redone the automations several times. The result is the same: with the time condition everything works. With the time condition nothing works.

Is there a way to go deeper with Smarthings? I’m new.

Thanks.

@rperi Can you please post screenshot of your automation

If I keep the time precondition the automation never runs. If I remove it, then it’s fine. ThIs the one for when I arrive home during the day.

I was curious as to whether it was the combination of ‘after being away for five minutes’ and the time restriction that was the issue, or whether the time restriction caused the issue regardless.

I had also been wondering if you were departing outside the time restriction and arriving inside it.

It is well worth flicking through the developer documentation.

Hello, I have the same problem. When I make a routine. I did 3 tests.

Test 1 has no function
Test 2 has no function
Test 3 works

is it a common problem, is there a solution?

I have the exact same issue. Did you find a solution?

As an alternative I’ve used two smartplugs, one plugged into the other. The one plugged into the wall is programmed to turn on and off at a specific time; the second one uses an automation linked with the temperature sensor.

With the Virtual Calendar Mc driver you can do an automation like this:

IF:
Precondition:

Precondition:

  • Sensor temperature or Weather temperature = , >= or <= X (25°)

Virtual calendar:

  • Local Hour <= (0950) maximum hour of the period in the precondition

THEN:
Send notification

Link to thread Virtual Calendar Mc

The usual issue with time periods in Routines is that there isn’t a scheduled activation at the beginning and end of the time period that would pick up existing true conditions. Many users find this counter-intuitive and I find it surprising that this hasn’t been addressed by making it optional behaviour.

The other common issue is that a condition like ‘temperature is greater than or equal to 30’ can be implemented in more than one way. I rather suspect it has been set to only trigger the Routine when there is a transition from false to true. Something like that anyway. The public Rules API is still being refined so the reference documentation doesn’t tell the whole story, and it is rather vague in places.

I think there are a couple of other points worth bearing in mind if you really want to use Routines. Firstly using multiple Routines to achieve a goal is perfectly reasonable. Secondly, and this could be complete horse poo but it works for me, don’t think of them like scripts being run top to bottom when triggered (like in webCoRE). Consider the conditions as entities that update independently and a trigger as just a decision point on whether to activate the payload.

@Francois_Parent , only for clarify how I think the app routines work:

  • All routines need an activator or trigger condition for all other conditions to be executed or checked.

  • A period of time is not an activation or trigger condition, it is like a previous condition, its is checked only when the activator or trigger changes state.

  • A fixed time is an activator, when it changes from the second before the fixed time to the exact fixed time, the verification of the rest of the conditions is triggered or activated.

  • The temperature comparison is an activator or trigger, as long as it is not marked as a precondition. Only when there is a change in temperature, which generates a new event, the comparison of the rest of the conditions is triggered or activated.

  • In Routine with a time period and a temperature comparison as a trigger, it will only trigger if there is a temperature change that meets the condition and that change occurred within that time period.
    If the temperature change that meets the condition occurred 1 sec before the start of the period or remains unchanged value throughout the period, the automation will not be executed.

  • In the Routine that I recommend, the trigger is the local Hour <= X, in the virtual calendar.
    The temperature and time period check are preconditions and are not triggers.

  • In this way, every minute there will be a change of state in the Local Hour <= X condition and the rest of the conductions will be checked every minute.

This guarantees that if the temperature meets the condition within the set period, it will send you the notification or execute what you tell it.

2 Likes

That sounds great but I don’t understand where you put your driver to download? Is it in this shared channel at the beginning of the thread? In there, there is nothing I can see exept from the name and description of the channel. Am I doing something wrong?
I would love to use it with my vacuum robot so it vacuums when I’m gone but not before 10am and not after 9pm so it won’t bother the sleeping neighbors under my apartment. (I imagine it to be a bit annoying being woken up by daily scratching on the ceiling at 7 am).

Hi @Binero,

Yes is in the beginning if the thread.

@Mariano_Colmenarejo I don’t know what I’m doing wrong. I tried multiple browsers and tried open it with my phone via mobile data (I thought maybe it’s my workplace’s network that prohibits it.) And I deactivated any kind of ad block but still, all I can see is the channel information and the headline for “My Hubs” (But it’s empty).

There is no button to enroll to Channel?

No. Nothing. Maybe I need to try again when I’m home. But I don’t see it being different there :frowning: