Save Matching Devices

#1

I have a piston that saves changed alarm contacts to a variable; I then parse the list to see what is open. It was working fine while testing until it stopped working for 20 minutes. I wasn’t sure why the piston stopped working
until I opened a different contact than the one I was using to test with for that time. Once I did that the variable started populating again.
Possible bug or is there some initialization I need to do on each trigger of the piston?

Log of failing runs. You can see line 23 evaluates as false but the first log line shows the contact trigger as open.

+1ms +Received event [DSC Kitchen Nook Right].contact = open with a delay of 126ms
+149ms ¦RunTime Analysis CS > 32ms > PS > 74ms > PE > 44ms > CE
+152ms ¦Runtime (49455 bytes) successfully initialized in 74ms (v0.2.102.20180116) (150ms)
+153ms ¦+Execution stage started
+159ms ¦¦Cancelling statement #29’s schedules…
+163ms ¦¦Executed virtual command wait (0ms)
+164ms ¦¦Waiting for 2000ms
+2169ms ¦¦Executed virtual command setVariable (1ms)
+2174ms ¦¦Executed virtual command setVariable (1ms)
+2187ms ¦¦Comparison (enum) closed is (string) closed = true (2ms)
+2189ms ¦¦Condition #8 evaluated true (10ms)
+2201ms ¦¦Comparison (string) notready is (string) ready = false (2ms)
+2203ms ¦¦Cancelling condition #9’s schedules…
+2204ms ¦¦Condition #9 evaluated false (14ms)
+2212ms ¦¦Comparison (string) notready is (string) forceready = false (2ms)
+2214ms ¦¦Condition #36 evaluated false (8ms)
+2215ms ¦¦Cancelling condition #35’s schedules…
+2216ms ¦¦Condition group #35 evaluated false (state changed) (25ms)
+2217ms ¦¦Cancelling condition #2’s schedules…
+2218ms ¦¦Condition group #2 evaluated false (state changed) (40ms)
+2312ms ¦¦Comparison (enum) open changes = false (2ms)
+2322ms ¦¦Condition #23 evaluated false (103ms)
+2323ms ¦¦Condition group #22 evaluated false (state did not change) (105ms)
+2327ms ¦¦Cancelling statement #6’s schedules…
+2335ms ¦¦Calculating (string) Current state + (string) true >> (string) Current state true
+2340ms ¦¦Current state true
+2342ms ¦¦Executed virtual command log (3ms)
+2345ms ¦+Execution stage complete. (2192ms)
+2346ms +Event processed successfully (2346ms)

Piston. You see the RED test fail at 100 ms even though the contact triggered the event.

bug
bug.jpg1231×1019 199 KB

#2

It is tricky using a global device variable as a trigger because the device is never actually stored with that piston. So it probably worked when you weren’t using a global device variable or using a device that was already called upon in that particular piston.

Fix it by either using a local device variable or calling the device itself as the trigger

#3

There are about 30 devices in that global and it’s used other places. To circumvent what you suggest is happening could be to assign the global to a local in the initialisation or am I still puddling around in the same pond? The only way is to actually get the triggers reliable is to manually assign all the devices in a local variable?

#4

I have several pistons that use global device variables as triggers, and they work quite reliably, but there is an important caveat. If the devices assigned to the global variable are ever edited or changed, the piston(s) that use that global device variable must be opened and saved again. Only in this way will the piston subscribe to all of the proper devices.

The reason for this subscriptions only occur at the time the piston is saved. Once running, the piston will never independently recheck the global device variable to see if any additional subscriptions should be added or removed. That’s why using a global device variable as a trigger can be tricky, and why @c1arkbar and others suggest alternative approaches.

#5

I’ve actually never tried this out but the idea has come to my mind before. Would be interesting to note if it works or not.

Thanks @bthrock for explaining more thoroughly