I 've had a set of routines that closed my west blinds to addressed PM glare. It has worked fine for a couple of years. It broke about the time that time that most of the children conversion took place (July 6-7). Since then I reconfigured the Zooz relay children that sense windows status and they are now generating the correct outputs. Shade closing is triggered by time of day (precondtion), luminance, ecobee temp (later changed to another sensor) and window status. I’ve manually deleted both time and changed temp to another sensor that caused the routine to trigger correctly. But with all things set up, it does not work. Any ideas?
It would be helpful if you post a screenshot of your routines?
2 Likes
Two of your triggers need to be set as perconditions, because it is unlikely that all 3 will change to your set points at the same time.
2 Likes
I think routine won’t trigger when all 3 conditions are met before the time period starts.
you can remove the precondition of time period and make a virtual device turn on at the time of 1:00 pm and turn off at 4:30 pm and use the virtual device as a condition “and” more when it is “On”
Or use virtual calendar virtual device with one local hour >= 1:00 pm and other local hour <= 4:30pm conditions instead of time period
2 Likes
Your Routine reads:
If between 1pm and 4:30pm
The Living room sensor changes and the lux is equal to or above 42lux
and
The window 3 open goes from on to off
and
The living room temp sensor changes and the temp is equal to or above 73
Then
Close the shade
You have 3 triggers that must be satisfied during the precondition (bounding condition) period for the Routine to execute. So, I can’t guess exactly what your intent is, but either you need to change the trigger conditions to “When any condition below is met” or change 1 or more of your triggers to preconditions.
I think there is a general confusion concerning preconditions vs triggers. Preconditions are merely a way to check on the state of something:
Is the door sensor open?
Is it 3:00pm?
Is the dimmer level 50%?
A Routine with just preconditions would never run and execute its Actions because there would be nothing to trigger a reason to evaluate the state preconditions. There needs to be a triggering event for that to happen:
Motion is detected
Water sensor detects a leak
Door lock unlocks
Once the triggering event happens, then all the preconditions are evaluated and if they are true, then the Action(s) are executed.
It doesn’t help that the way ST UI sequences the conditions doesn’t make it clear that “When this happens” and “all the preconditions are true” then "Actions will be executed. It makes me appreciate the UI layout of a tool like Sharptools where the event/trigger conditions are clearly distinct from the evaluation of bounding conditions based on state.
4 Likes
When any of the 3 conditions is met, then the true or false status of all the preconditions and all the conditions of the routine is checked.
Therefore, in these routines, time interval preconditions must be avoided, since if the all conditions have been met (true status) before the start of the period, the routine will no longer be triggered until one of the conditions becomes false and then returns to be true within the time period
All,
I appreciate the help from you and others, but I’m wondering if ST changed something about two weeks ago. So first of all, I can’t remove the precondition for the time. ST forces it in there. As to the rest of the things, my set up seems similar (this may be a different routine than before, but same use) to before, and it worked for at least two years. See my prior routine from pre conversion. Here is the old one:
Time ranges are always a precondition. You don’t have a choice. The other option is to use a virtual switch to represent the time interval, turning it on/off at the appropriate times and then using that virtual switch being on as a precondition.
What do you want to be the triggering event? The temp goes above 73 deg or lux goes above 42?
Seems to me that Window open status would be a precondition.
1 Like
In general, The window would be open/closed, so could be precondition, and as pointed out time is a fixed pre condition. That leaves light and temp. In summer, the temp will usually be at that level. In spring/fall/ winter, temp would usually trigger it. But until 2 weeks ago, time as precondition was enough for this to trigger properly. BTW all of my other routines are working as expected. And I have another set of blinds that trigger on time and light level only.
Hi @homeagain
These routines with period of time will be activated whenever one of the conditions changes to the value true and all others conditions are true too within the time period of the precondition.
Therefore it can be activated every day or not.
You can look in the history at what time the routine was activated and what change, at that same time are triggered it.
If it did not execute, check the history and you will see that in the precondition time period there is no change in the devices that trigger the routine as a condition.
In the case of the routine that has only one light sensor and it works well, that sensor, due to its physical placement or configuration, may report more frequently or due to smaller lux changes and any of these changes can trigger the routine within the time period.
To ensure that it will always trigger when conditions are met within the time period:
- Create a virtual device
- Create a routine that every day turn on the virtual switch at 1:00 pm
- Create a routine that turns it off every day at 4:30 pm or in the activate routine, select automatic shutdown after 3h and 30 min
- Delete the time period from your routine.
- In your routine add the condition (Not precondition): If virtual switch is activated.
This will mean that if your three conditions are already met before 1:00 pm, then when it is 1:00 pm the virtual switch will be activated and the 4 trigger conditions will be met and the routine will be executed.
The routine will only be activated when the virtual switch is activated, same as with a time period, but it will not be a precondition, which is not a trigger for the actions of the routines.
You can also use the virtual calendar device and create a routine similar to this
As to history, I’ve been forcing this closed for the last two weeks- but have confirmed input variables were all correct during the desired time. I’ve moved everything to trigger and created the virtual time event. If you think some should still be preconditions, let me know. Even if nothing else changes, this should trigger with the new time virtual device if the time precondition was the issue. We’ll see what happens today!
1 Like
The first one triggered correctly today with no preconditions. I’ve made the edits and will check over the next day. The reason for the logic change makes sense to me and makes me wonder if there was an undocumented change that happened two weeks ago.
Right, that makes sense. The use of a precondition to me is the different between:
- If at the start of your time interval your triggering conditions are true or if they become true during the time interval, then execute the Actions (precondition may not work).
vs
- If during your time interval your triggering conditions become true, then execute the Actions (precondition will work)
Which one to use depends on the use case. If I only want a light to come on with motion between sunset and sunrise, then a precondition time interval will be just fine. It’s the threshold triggering conditions where a precondition may or may not make sense.
1 Like
I don’t think there has been a change in the app’s routines in this regard.
It is a problem that has been discussed in many posts, because the use of time periods generates a lot of confusion for users, which are always previous conductions and do not trigger actions, they only validate them.
This means that sometimes they are activated and other times they are not.
As @h0ckeysk8er says in routines where you expect the change from false to true and vice versa to occur multiple times, such as a motion sensor or contact sensor turning on a light works perfectly, but if it’s used to detect temperature changes for example, than they are slow and also depend on the configuration of device reports, so they are not reliable, they may or may not work.
After an epiphany this am, I think I’ve figured out what is going on relative to my setup and use case last year, which was identical until two+ weeks ago. And now I agree the ST automation logic has not changed. I’m not sure why ST chose this approach, but that is another topic. So the short answer is that I’m using a Homeseer muti sensor in both the living room (this discussion) and in my office and I’ve discovered the lux sensor output has changed post edge. Both sensors are used to control window blinds. Since the EDGE conversion occurred, the homeseer module is now outputting Lux values approximately ~10X higher than before, which were less obvious as we are still relatively close to the solstice. I always thought the prior lux levels were low, but since I was just using them for control, they did not matter. I previously calibrated the automations to the lux trigger value I observed when glare (east) or overhead sun (west) occurred. So previously in the west windows, my main trigger was the much lower lux level, but I added time because the lux would be triggered from north sun (near solstice) early in the morning. The time precondition avoided that issue, so light levels triggered the shades to close during the pm only. In my office, I’d noticed the shades now close earlier in the morning to avoid glare but thought nothing of it. Now I know why and confirmed by looking at Lux level data over the last day. Now a year later with edge, the lux is always above my older set point, and thus the conditions are all true when the time hits and as you all have both indicated, there was no change using the precondition setting, and thus no trigger during the period. Removing the time precondition avoided this, but now time is the trigger, which was not the original intent. So I’ll recalibrate the sensor levels and that should put me back where I was. My office may take some time as exterior construction is screwing up light levels. I appreciate all of the input about using preconditions.
2 Likes
You may be interested in using the Virtual Calendar device to use the sun’s elevation angle and azimuth to trigger routines combined with lux.
Since these values vary with the date of the year, you can narrow it down by months as a precondition or condition
1 Like
I defiantly need to consider that. Do you have the link? May work for this current case, but probably not for my other case which has lots of reflections.
This link for driver,
- install Aplicaciones Virtuales Mc driver
- add new device in app
- virtual main device creator appears in hub room
- Select create Virtual Calendar.
- In preferences insert your local latitude and longitude rounded to 1 decimal
- in detail view insert your local hour to GMT hour offset.
All data will be calculated for your set location
I’ve added this and get the main virtual devices object, but nothing else. I tried it twice and i got a count of two devices, but nothing else. Am I doing something wrong?