Grouping contact sensors to set status of virtual contact sensor

[GRClark]

1) Give a description of the problem
The area of line 54 seems to be the problem as all the other virtual contact sensors are reporting correctly according, but unsure why this part isn’t working since I’m pretty sure it’s setup the same way for each virtual sensor.

2) What is the expected behavior?
There’s two window contact sensors and one door contact sensor that I’m trying to group together and have a virtual contact sensor report the status of them.

3) What is happening/not happening?
The virtual contact sensor reports incorrect status - have verified in device history and the piston is sending the incorrect status so it must be something that’s wrong about my piston.

4) Post a Green Snapshot of the piston

5) Attach any logs (From ST IDE and by turning logging level to Full)
.1/7/2018, 10:54:02 AM +741ms
+21ms ╔Starting piston… (v0.2.101.20171227)
+490ms ║╔Subscribing to devices…
+548ms ║║Subscribing to Living Room Window (Left).contact…
+564ms ║║Subscribing to Living Room Window (Right).contact…
+580ms ║║Subscribing to Bedroom Door.contact…
+613ms ║║Subscribing to Front Door.contact…
+628ms ║║Subscribing to Downstairs Contacts.contact…
+644ms ║║Subscribing to Upstairs Contacts.contact…
+659ms ║║Subscribing to Home Contacts.contact…
+677ms ║║Subscribing to Living Room Windows.contact…
+939ms ║╚Finished subscribing (477ms)
+987ms ║Comparison (enum) closed is (string) closed = true (6ms)
+1070ms ╚Piston successfully started (1070ms)
1/7/2018, 10:50:01 AM +577ms
+3ms ╔Received event [Tall Pines].test = 1515340201572 with a delay of 3ms
+511ms ║RunTime Analysis CS > 27ms > PS > 401ms > PE > 82ms > CE
+520ms ║Runtime (43032 bytes) successfully initialized in 401ms (v0.2.101.20171227) (514ms)
+523ms ║╔Execution stage started
+577ms ║║Comparison (enum) closed is (string) closed = true (4ms)
+589ms ║║Cancelling statement #3’s schedules…
+789ms ║║Executed physical command [Living Room Windows].close() (188ms)
+790ms ║║Executed [Living Room Windows].close (193ms)
+792ms ║║Condition #2 evaluated true (248ms)
+794ms ║║Condition group #1 evaluated true (state did not change) (253ms)
+807ms ║║Cancelling statement #11’s schedules…
+842ms ║║Executed physical command [Upstairs Contacts].open() (32ms)
+843ms ║║Executed [Upstairs Contacts].open (32ms)
+844ms ║║Condition #8 evaluated false (48ms)
+845ms ║║Condition group #7 evaluated false (state did not change) (49ms)
+860ms ║║Cancelling statement #17’s schedules…
+896ms ║║Executed physical command [Downstairs Contacts].open() (32ms)
+897ms ║║Executed [Downstairs Contacts].open (34ms)
+898ms ║║Condition #14 evaluated false (51ms)
+899ms ║║Condition group #13 evaluated false (state did not change) (51ms)
+921ms ║║Cancelling statement #23’s schedules…
+975ms ║║Executed physical command [Home Contacts].open() (49ms)
+976ms ║║Executed [Home Contacts].open (50ms)
+978ms ║║Condition #20 evaluated false (76ms)
+979ms ║║Condition group #19 evaluated false (state did not change) (78ms)
+992ms ║╚Execution stage complete. (472ms)
+1000ms ╚Event processed successfully (1001ms)
1/7/2018, 10:49:13 AM +645ms
+3ms ╔Received event [Tall Pines].test = 1515340153640 with a delay of 3ms
+212ms ║RunTime Analysis CS > 28ms > PS > 110ms > PE > 73ms > CE
+217ms ║Runtime (43032 bytes) successfully initialized in 110ms (v0.2.101.20171227) (211ms)
+220ms ║╔Execution stage started
+271ms ║║Comparison (enum) closed is (string) closed = true (3ms)
+282ms ║║Cancelling statement #3’s schedules…
+475ms ║║Executed physical command [Living Room Windows].close() (183ms)
+476ms ║║Executed [Living Room Windows].close (187ms)
+478ms ║║Condition #2 evaluated true (237ms)
+480ms ║║Condition group #1 evaluated true (state did not change) (241ms)
+493ms ║║Cancelling statement #11’s schedules…
+525ms ║║Executed physical command [Upstairs Contacts].open() (29ms)
+526ms ║║Executed [Upstairs Contacts].open (31ms)
+527ms ║║Condition #8 evaluated false (45ms)
+528ms ║║Condition group #7 evaluated false (state did not change) (46ms)
+547ms ║║Cancelling statement #17’s schedules…
+581ms ║║Executed physical command [Downstairs Contacts].open() (31ms)
+582ms ║║Executed [Downstairs Contacts].open (32ms)
+584ms ║║Condition #14 evaluated false (52ms)
+585ms ║║Condition group #13 evaluated false (state did not change) (54ms)
+601ms ║║Cancelling statement #23’s schedules…
+637ms ║║Executed physical command [Home Contacts].open() (33ms)
+638ms ║║Executed [Home Contacts].open (33ms)
+640ms ║║Condition #20 evaluated false (51ms)
+641ms ║║Condition group #19 evaluated false (state did not change) (54ms)
+655ms ║╚Execution stage complete. (438ms)
+662ms ╚Event processed successfully (662ms)’

[c1arkbar]

Instead of changes to try using is/are on all your statements.

[GRClark]

woot! That fixed it. I have always overthought stuff like this wondering which ones to use because they all seem to say the same thing just in a slightly different way, but assumed they’d give me the same outcome. Obviously I’m wrong. Should I go change the rest of the piston to use is/are too? Probably hu?

[c1arkbar]

Yes I would change them all

[GRClark]

I’d gone ahead and did that, but unfortunately now the other two areas of the piston are not working and reporting incorrectly. They actually sent the wrong status to those two contacts sensors. Would you mind taking another look?

[c1arkbar]

Could you be more specific about what areas you are talking about? Also any logs would help

[GRClark]

Ill post some logs in the morning, but just checked what parts work and it’s line statement starting on line 70. Would it.be caused by me using the same virtual se soda that I had just set he status of to then be used to set the status of a keyed virtual sensor? Maybe those sensors aren’t updated In time before the piston moves to the next statement…? It’s not a big deal to go in and just all the devices individually - just trying to learn from my mistakes.

[GRClark]

[c1arkbar]

Is there a reason for the on events in the bottom? These might be disrupting operation

[GRClark]

Had plans of passing the variables to other pistons in the future, but taking them out now. I’d thought this was working now, but nope. Maybe this will help.

[GRClark]

Everything is working now - thanks for your help!