IS (for at least../for less than)

#1

I can’t understand why there is no option ‘for less than’ ‘for at least’ in the IS comparison.

For example I wan’t to alert with the lights when the outdoor temperature IS colder then the inside temperature for at (least 10 minutes) AND the door IS open (for at least 5 minutes).

I can’t use was, because it’s in the past and not true anymore when action needs to happen.

I won’t use a trigger like stay, but a condition, because the condition still has to stay true to add more conditions that can trigger. Like coming home.

Now I have to make a seperate piston with trigger stay and change a variable, that I use for my condition. This overcomplicates my pistondesign very much.

I probably could use ‘wait’ in my action, and set it to cancel upon change of condition. Though this still isn’t great. Some conditions like for example coming home need immediate response. It also makes it impossible to set different time variables for the conditions, unless I make my piston design even more complicated.

What am I missing? ‘IS for at least’ seems to me one of the most basic comparisons.
I really can’t get my head around it, that this isn’t integrated… but it is for WAS ?!

#2

Someone please correct me if I am wrong, but I believe the condition:
temp

is webCoRE’s way of saying:
IF Door has been continuously open for the past 5 minutes…
- or -
IF Door is open now AND Door has been open for the past 5 minutes

In other words, I think it applies to the present AND the past…
Once the door is closed, it should no longer be true.

It’s similar wording and logic for motion sensors:
temp

#3

Has been would implicate the condition is still true and is not an option that is available. It would be useful as an alternative for IS at least…

However it is not the same as was, that implicates the condition is not true anymore. It is completed in the past.

#4

I agree that the grammar is not perfect… but if you can overlook that, I think the code does what you want it to…

#5

no it doesn’t

example:

turn on the lights when home + was away for at least 5 min > means returning home in 5min to grab my keys and depart without triggering the lights. Leaving +5min would trigger the lights

is not same as turn on lights when when home + is away for at least 5 min > system does nothing because of conflicting modes.

The code handles WAS completly different as would IS do.

#6

I apologize. I have re-read your last post a half dozen times and I am not sure what you are asking…

If “home +” is a presence detector, then keep in mind that most presence sensors do not update instantly. (and rarely update if you are in your driveway) So the code "Home + was away for at least 5 minutes" might actually be 7 minutes if the device takes 2 minutes to register that you have left.

#7

I think this would accomplish what you are trying to do:

image
image.png1178×497 24.8 KB

You can also change conditions from AND/OR to “Followed by” so the triggers can evaluate true and have a condition evaluate true later without breaking your logic chain.

To do this, click on the AND found between the conditions/triggers you want to set-up, and click “followed by”.

image
image.png766×276 9.28 KB

Nested condition based on time of previous events not running
#8

Big thanks, this could be a lot of help. Will look into it. Will certainly solve some of the problems I experience building advanced logicblocks due to this missing passive condition.

#9

If you keep in mind that with ST everything is event based, the was verb implies a change event at which the “was open for at least 5 minutes” condition must be true. Obviously, the change implies that the door is now closed. So that “was” verb translates to “if the door closes after having been open for more than 5 minutes”. Makes more sense now? The “stay” trigger is different in that it actually generates its own time event - because it relates to future - you want to be notified when the door has stayed open for 5 minutes, not when it opens or closes. I tried to use grammar that keeps the notions differentiated. There are so many possibilities of triggering things that it’s hard to keep things super intuitive, sorry. What do you think the “was” should be called?

#10

I am aware of how WAS is functioning, calling it HAS BEEN would be an alternative that might be less confusing, since it implies more the finished nature of the action in the past.

However it is not the solution to my issue. I am missing the link between the trigger STAY and the condition WAS. This would be solved by adding a timer (at least or less than) to the condition IS. This event would become true and stay true when the set timer is completed or stay true until the timer has ended.

Consider there is a timer for the conditions in the past (WAS), there are for the triggers, but none for the continues present (IS). This makes no sense.

#11

Okay, let me try and understand what you are trying to do please?

Also, is and was are conditions, whereas stays is a trigger. The word has been kinda broke the naming convention of not having spaces in the keyword. So I used was instead. You can evaluate was at any time but it requires a triggering event. It’s just a way to measure the past. And if the device is the one triggering, was open for last 5 min will ignore that event and look at the history to figure out if the contact was in fact open for at least 5 minutes prior to the current event of closing. You can also use various functions in expressions like age([device:attribute]) or previousAge([device:attribute])

Please explain in plain English (not webCoRE terminology) what you are trying to achieve.

#12

Also, thinking of it, I believe neither was nor has been imply an action in the past that has finished. They both imply that the action started in the past, but make no reference as to when that action ended, or if it did end.

It was raining 5 minutes ago <<< could still be raining, right? No info

It has been a pleasure meeting you <<< hopefully that didn’t end either ;))

#13

That’s my problem with WAS, it indeed doesn’t imply that the event was finished or not.

It does with STAY. But it’s a trigger, I need a condition that does this trick.

The easy logical way would be to add ‘at least’ or ‘less than’ to the IS condition.

#14

What are you trying to do?

#15

You know you can combine an IS with a WAS, right?

if contact is closed and contact was open for at least 5 minutes…

#16

I would like to turn on the heat when door is closed for at least 20 seconds, in one simple condition without having to use workarounds.

If that simple thing works, I’m good.

#17

So why would ‘if door stays closed for 20s turn heat on’ not work?