Help to trigger v switch after power off duration

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

2 Likes

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

1 Like

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:

  1. IF the dim value of Switch1 changes to a number less than 25
  2. and remains like that for 20 seconds
  3. The Switch2 is turned OFF

Let me know if you have any doubts! :smiley:

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.

1 Like

@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:

  1. IF Switch 1 is turned on
  2. AND have passed at least 40 seconds since the last “active” event from the motion sensor.
    Note: the current value could be “inactive” depending on how much time you set for the “clear time” parameter, I’ve seen 20 or 30 seconds are very common. Receiving a new “active” event restarts this timer
  3. THEN turn off Switch 2
{
   "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

1 Like

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.