This damn rules Api in the app has me pulling out my hair at times
How do I create an automation that opens a virtual sensor but is based on watts staying below set amount for x time duration?
I’m looking to
IF
Device watts stays below x amount for x duration
THEN
Switch on v switch
Seems simple enough but not with the current automation creator
The outline for this automation was to create an alarm in Amazon’s Echo to alert us about a freezer getting accidently switched off, kind off seemed like an easy automation to begin with until I tried
At time of writing I cannot see a way to set a duration period when creating an automation with power wattage included
There may be another way to do this but this is what I had to do to setup a simple automation based on watts used for a duration
Power sense plug attached to freezer
1 X virtual switch
1 x virtual open close sensor
Virtual switch
IF
Power sense plug power above 3 watts
THEN
turn on virtual switch
IF
Power sense plug power below 3 watts
THEN
turn off virtual switch
Virtual open close
IF
Virtual switch off
Duration period (user defined)
THEN
Turn on open close sensor
The virtual open close sensor can be seen in Echo and from there you can then set up a routine in Echo to suit
Upon application of input voltage, the time delay relay is ready to accept trigger signals . Upon application of the trigger signal, the relay is energized and the preset time begins. … Continuous cycling of the trigger signal at a rate faster than the preset time will cause the relay to remain energized.
Did you try the “remains” function in the Rules API?
That would help you do the automation directly instead of creating virtual devices. I think it’s worth the try.
There’s an example in the official repo where:
remains like that for 20 secondsLet me know if you have any doubts! 
What’s the difference between ‘was’ and ‘remains’ in Rules API?
SmartThings API documetation says
was: A condition that returns true if its evaluation would return true within the specified duration.
remains: A condition that returns true if its evaluation is true after the specified duration.
In the example, you used remains
I think was means it was true at some point within the last ‘duration’, whereas remains means it was true for all of the last ‘duration’ and still is. I’m only confident about remains though - was is just a guess because I can’t think of anything else it could mean.
It really isn’t clear, and changes is even worse. That talks about being true even though it can apply to a non-binary operand.
I see that a latching option has appeared for remains. That’s as clear as mud too.
Honestly, reading the API reference is like reading a 1980s printer manual translated from Japanese.
It also doesn’t help that the navigation on the web pages is seriously screwy on mobile browsers, and they completely lock up Chrome on a tablet.
@orangebucket is correct.
Remains checks if the value we set in the condition stays like that for the specified amount of time. For example, if a light lasts ON for 5 minutes, if we turn it off after 4 minutes, the condition would be evaluated as “false”.
Was checks the past states but it’s not a trigger by itself as we cannot check every minute if the amount of time passed matches the one specified. For example:
In this Rule, the flow is the following:
{
"name":"was test",
"actions":[
{
"if":{
"and":[
{
"was":{
"equals":{
"left":{
"device":{
"devices":[
"motionSensor-ID"
],
"component":"main",
"capability":"motionSensor",
"attribute":"motion"
}
},
"right":{
"string":"active"
}
},
"duration":{
"value":{
"integer":40
},
"unit":"Second"
}
}
},
{
"equals":{
"left":{
"device":{
"devices":[
"Switch1-ID"
],
"component":"main",
"capability":"switch",
"attribute":"switch",
"trigger":"Always"
}
},
"right":{
"string":"on"
}
}
}
],
"then":[
{
"command":{
"devices":[
"Switch2-ID"
],
"commands":[
{
"component":"main",
"capability":"switch",
"command":"on",
"arguments":[
]
}
]
}
}
]
}
}
]
}
The team is constantly working on improving the documentation, please, if you find more things confusing let us know.
We already reported some of the points you mentioned like “aggregation”, “sequence”, “changes”, “trigger” and the terminology difference. The last three have been addressed, please check the release notes and let us know if you find something strange in those changes.
We’ll make sure to get clarification on “remains”, “was” and “latching” in the documentation. For some points that are complex, a complete description is being added in the main doc of Rules
That is actually NOT what I expected it to do. I interpreted it as meaning the motion was active at some stage in the last 40 seconds and that description would miss a transition to active in that time.
My interpretation is not the same as the webCoRE ‘was’ which is true if at the point the piston was triggered the condition has been true for all of the defined amount of time and still is. If that is what the Rule is trying to do the documentation is not just misleading it is downright wrong. It would also be pretty much the same as remains.
A was, as I interpreted it, wouldn’t need to know anything about past states and wouldn’t be difficult to trigger off either (though the triggers wouldn’t be that useful).
It is essentially like changing true to false in a remains i.e. returning false when something remains false for a period of time.
In the example you would set was to true when motion became active, and set it to false after 40 seconds of it being inactive.
Yes, I noticed that yesterday. Thank you.
Certainly changes is clearer in explicitly saying it has to be a false to true transition. However there remains some confusion because when you showed ways of handling mirroring you demonstrated using changes with an operand that doesn’t have a boolean value such as a level or temperature attribute. It is counterintuitive that changes could be true for any change in a non-boolean operand but only a false to true in a boolean.
An issue with trigger is the auto value. The automation server might know what it is doing but we need to know too. It seems similar in net effect to the subscription setting for triggers and conditions in webCoRE but in webCoRE we get told which is which so we know what to expect and the UI also tells us. Unless it says something in the API reference (which is pretty much unusable at the moment) we don’t know which conditions will result in triggers.
@nayelyz I notice that was is now flagged as deprecated in the Rules API reference. I guess that solves that problem.
I have already commented that the description of changes doesn’t seem to allow for use with operand which doesn’t return true or false. I now see there is a changesOnly on some conditions. I think it is basically doing a similar thing to changes internally to the condition but the description is a little garbled. Would you mind adding that to the list of terms that could use some attention? Thanks.
In reading through the above, and trying to grasp the correct usage of the (now deprecated) “was” and “remains,” one thing I haven’t been able to write something like this:
IF
Switch A Turns ON (Trigger)
AND
Switch B Has been OFF for less than X Minutes (Condition)
THEN
Do Stuff
The condition has me stymied.
I’m just trying to do that in my head to avoid starting the washing-up.
In pseudo-code I am thinking
if
(switch A is on)
and
(switch B is off)
and
(not (remains for X minutes (switch B is off)))
Thanks … As I initially suspected, “remains” doesn’t work in this scenario, but “was” does. In fact, I found I could simplify it further to:
---
name: If Switch A Turns ON and Switch B Has Been OFF < X Time, Turn on Light D
actions:
- if:
and:
- equals:
left:
device:
devices:
- "{{Switch A}}"
component: main
capability: switch
attribute: switch
trigger: always
right:
string: 'on'
- not:
was:
equals:
left:
device:
devices:
- "{{Switch B}}"
component: main
capability: switch
attribute: switch
trigger: never
right:
string: 'off'
duration:
value:
integer: 30
unit: Second
then:
- command:
devices:
- "{{Light D}}"
commands:
- component: main
capability: switch
command: 'on'
Which suggests to me that perhaps “was” shouldn’t be deprecated, at least not in the absence of a better alternative for “looking back” on duration.
I had actually tried using “was” in the same way you had used remains, but in a slightly more complex scenario, like this.
IF
Switch A Turns ON (Trigger)
AND
OR
Switch B has been OFF for less than X Minutes (Condition)
Switch C has been OFF for less than X Minutes (Condition)
THEN
Do Stuff
…but that didn’t work until you suggested including the “AND Switch B is OFF.” Incorporating that bit of logic seemed to get the rule working as expected, though I’m still wrapping my mind arond why. Here’s the rule as it stands now:
---
name: If Switch A Turns ON and Either Switch B or Switch C Has Been OFF < X Time, Turn on Light D
actions:
- if:
and:
- equals:
left:
device:
devices:
- "{{Switch A}}"
component: main
capability: switch
attribute: switch
trigger: Always
right:
string: 'on'
- or:
- and:
- equals:
left:
device:
devices:
- "{{Switch B}}"
component: main
capability: switch
attribute: switch
trigger: never
right:
string: 'off'
- not:
was:
equals:
left:
device:
devices:
- "{{Switch B}}"
component: main
capability: switch
attribute: switch
trigger: never
right:
string: 'off'
duration:
value:
integer: 30
unit: Second
- and:
- equals:
left:
device:
devices:
- "{{Switch C}}"
component: main
capability: switch
attribute: switch
trigger: never
right:
string: 'off'
- not:
was:
equals:
left:
device:
devices:
- "{{Switch C}}"
component: main
capability: switch
attribute: switch
trigger: never
right:
string: 'off'
duration:
value:
integer: 30
unit: Second
then:
- command:
devices:
- "{{Light D}}"
commands:
- component: main
capability: switch
command: 'on'
Once again, thanks for the help.
I’m not sure I ever worked out exactly what the ‘was’ actually did. I think it was earlier in this thread that Nayely described what she understood it did and I couldn’t relate that to what the documentation said. I don’t think the Rules API ever truly looks backwards like a webCoRE ‘was’ (webCoRE actually looks back through the device event history).
I’m afraid that the API reference is particularly bad at explaining the Rules API. You have to already know what something does in order to understand the description.
I’m thinking it roughly equates to webCoRE’s age() function, which provides the length a time a device’s attribute has held a certain value, which to me is useful in defining conditions. “Remains,” on the other hand, looks forward and is only (to my mind) useful in triggers. But maybe that’s not right either.
The impression I have formed is that ‘remains’ has to become true in the lifetime of the piston. I have a wall light next to me that hasn’t been on for hours. So if I create a Rule now that says ‘light switch remains equal to off for 30 minutes’ I expect that to evaluate as false to start with. However if I turn the light on and off I expect that 30 minutes later it will evaluate as true and it will continue to evaluate as true until the light is turned on again.
I haven’t tested this, but I hope you’re correct, as it would be useful for conditions in that event.
