Need to check closed state across number of devices


#1

1) Give a description of the problem
I am creating a gateway between Smartthings and Ring: I hardwired a Ring door sensor to a Mimolite switch.
Lets say I have 3 doors and 1 lock in Smartthings.
If ANY of the doors/locks are opened/unlocked then turn the Mimolite ON. This in turn will make the Ring door sensor think it is opened. This part is not the problem.
But ONLY if ALL the doors/locks are closed/locked then turn the Mimolite OFF. For example, lets say that 2 doors are open and one of them is closed, the Mimolite should not be turned off until all the doors are closed.This is the piece I cannot do.

2) What is the expected behavior?
Only once the last door is closed/locked should the Mimolite be turned off.

3) What is happening/not happening?
As soon as the first door closes, the Mimolite is turned off.

**4) Post a Green Snapshot of the piston

5) Attach any logs (From ST IDE and by turning logging level to Full)
|+2ms|╔Received event [Door/Window Sensor].contact = closed with a delay of 124ms|
| — | — |
|+10119ms|║RunTime Analysis CS > 18ms > PS > 10085ms > PE > 16ms > CE|
|+10121ms|║Piston waited at a semaphore for 10032ms|
|+10123ms|║Runtime (38824 bytes) successfully initialized in 10085ms (v0.3.105.20180628) (10120ms)|
|+10124ms|║╔Execution stage started|
|+10159ms|║║Comparison (enum) closed changes = false (1ms)|
|+10162ms|║║Cancelling condition #6’s schedules…|
|+10163ms|║║Condition #6 evaluated false (32ms)|
|+10174ms|║║Condition #11 evaluated false (8ms)|
|+10175ms|║║Cancelling condition #1’s schedules…|
|+10176ms|║║Condition group #1 evaluated false (state changed) (46ms)|
|+10179ms|║╚Execution stage complete. (55ms)|
|+10180ms|╚Event processed successfully (10180ms)|
|2/17/2019, 10:52:31 PM +612ms|
|+1ms|╔Received event [Door/Window Sensor].contact = closed with a delay of 110ms|
|+85ms|║RunTime Analysis CS > 18ms > PS > 50ms > PE > 17ms > CE|
|+87ms|║Runtime (38746 bytes) successfully initialized in 50ms (v0.3.105.20180628) (85ms)|
|+89ms|║╔Execution stage started|
|+120ms|║║Comparison (enum) closed changes = true (1ms)|
|+123ms|║║Cancelling condition #6’s schedules…|
|+125ms|║║Condition #6 evaluated true (29ms)|
|+126ms|║║Cancelling condition #1’s schedules…|
|+127ms|║║Condition group #1 evaluated true (state changed) (32ms)|
|+131ms|║║Evaluating switch with values [[i:2:null:0, v:[t:dynamic, v:closed, vt:string]]]|
|+136ms|║║Comparison (dynamic) closed is (string) open = false (2ms)|
|+140ms|║║Comparison (dynamic) closed is (string) closed = true (2ms)|
|+144ms|║║Cancelling statement #14’s schedules…|
|+492ms|║║Executed physical command [Ring Alarm Gateway].off() (344ms)|
|+493ms|║║Executed [Ring Alarm Gateway].off (346ms)|
|+497ms|║╚Execution stage complete. (409ms)|
|+499ms|╚Event processed successfully (499ms)|


#2

I would delete lines 34 thru 39 here, and create a new piston with only one IF block. Something like:

IF ALL of Contacts 1, 3, 4, 5 and 6 are closed
Then
    Turn off Sensor 2
END IF

This block will not work inside your current piston. It needs to be in a new piston.

Basically, let your current piston handle the Turn on, and let the new piston handle the turn off


#3

OK, initial testing shows this to be working. Please feel free to critique :grinning:


#4

Lookin’ good!
The only thing I might change is the entire ELSE block _(lines 38-51)_can be reduced to one command:

With Contact Sensor2, Turn on

(unless you want different things to happen on open vs unlock)


#5

If you only want to react to these two event values and ignore anything else, you can change the switch to ‘fall through’ and then eliminate the first with. Or just make it an if statement and ‘or’ the two conditions since there are only two cases.


#6

Coding philosophy question for you @WCmore. Why create the second piston? My first thought would be one of the two following methods.

If {Doors} or {Locks} changes
if any of {Doors} or {Locks} is open
Turn on sensor
end if
if all of {Doors} and {Locks} is closed
Turn off sensor
end if
end if

Or

if Any of {Doors} or {Locks} is open
Turn on sensor
else
Turn off sensor.
end if

Thinking about this, I may have answered my own question, but I’d still like to hear your philosophy.


#7

Thank you all for your thoughtful consideration and input. I really appreciate it!

I think for now I will keep at as-is even though you have pointed out I can reduce it further. But I am still considering how I can build it out with more capabilities.


#8

Generally speaking, I use ELSE very sparingly, and usually when there is only one condition attached to it.

An ELSE with multiple triggers often brings unexpected results.
(if any of them turn false, then ELSE is executed)

Of course, now that I have some coffee in me, I see that is exactly what the OP wants to happen, so I think your examples and piston “be0d” resolves that nicely.