"changes to" or "is"

#1

1) Give a description of the problem
Designing a piston to notify me if the mailbox is opened, using a door contact.

2) What is the expected behaviour?
I should be notified when the mailbox is opened.

**4) Post a Green Snapshot of the piston!

download
download.png1178×466 41.5 KB

In the piston I used “is” but is that the best idea for what I want? Changed? Changes to? Changes from? Changes away from? Is? Ugh!

#2

Personally, I prefer triggers (a precise moment in time)
over conditions (vague stretches of time).

I’d probably use: Changes to open

… but there are occasions where I may use a condition, as you did…

#3

Oh I only threw the “is” in there so I’d have a complete piston to put here in the thread!

“Changes to open” it is, and thank you for the help!

#4

As a side note, in this situation since you only have one condition, webCore will treat it as a trigger so you should get the same end result. Notice the lightening bolt beside the ‘is’ statement. Just be aware that adding more triggers/conditions will affect the logic.

#5

Noted, and thank you!

#6

If we take your simple piston as an example, it will (by default) be run whenever a contact attribute event is received from your contact sensor, regardless of whether the comparison is ‘contact is open’ (condition) or ‘contact changes to open’ (trigger). This is because, if there aren’t any explicit triggers, pistons fall back to considering their conditions when deciding what events to subscribe to.

When the piston runs, ‘contact changes to open’ will look to see if the event that ran the piston uses the contact in question. If it does it will look to see if the event says the new state is ‘open’. It will then check its cache to see if it has recorded it being ‘closed’ last time it heard anything. If all those conditions are met, the comparison is true. So there are a few points to consider:

  • Events can sometimes get delayed. You might be responding to things that happened e.g. thirty seconds ago.
  • It is perfectly possible to receive two ‘open’ events in a row, without an intermediate ‘closed’, whether by design in the device handler, or by events getting delayed or lost and coming out of order. If that happens the comparison returns false.
  • If the piston runs for any other event, such as the ‘Test’ button in webCoRE, the comparison returns false. Only the contact event matters.

On the the other hand a ‘contact is open’ will go and check the SmartThings device object to see what the current value of the attribute is. If it is ‘open’ it will return true. Things to consider:

  • It doesn’t matter why the piston is running, the comparison only considers the state at the moment it is evaluated. That behaviour can be useful when things have got out of bonk for some reason. It can also be bad if you aren’t expecting the piston to run when it does.

It is horses for courses really. I tend to favour conditions unless I definitely need a trigger.