Garage Door Presence based opening with device definitions and case switching

Jason_Meudt · 2020-10-25 13:29:15 UTC

1) Give a description of the problem
No problem, but rather a logic check of the piston. I am venturing out to use device definitions and case switching.

2) What is the expected behaviour?
When either of the two defined presence sensors arrive, based on who arrives, open the respective garage door(s).

3) What is happening/not happening?
I have not implemented this piston, but wanted to get a logic check from someone

4) Post a Green Snapshot of the piston

5) Attach logs after turning logging level to Full
10/25/2020, 8:22:22 AM +561ms
+1ms ╔Received event [Home].test = 1603632142561 with a delay of 0ms
+53ms ║RunTime Analysis CS > 22ms > PS > 7ms > PE > 23ms > CE
+55ms ║Runtime (43291 bytes) successfully initialized in 7ms (v0.3.110.20191009) (53ms)
+57ms ║╔Execution stage started
+84ms ║║Condition #2 evaluated false (22ms)
+85ms ║║Condition group #1 evaluated false (state did not change) (24ms)
+89ms ║╚Execution stage complete. (33ms)
+90ms ╚Event processed successfully (90ms)

Jason_Meudt · 2020-10-25 14:48:03 UTC

So, in actually testing out the piston, we have some issues…

Here are the relevant logs that show the failure at #7.

10/25/2020, 9:35:58 AM +217ms
+2ms ╔Received event [Dawn].presence = present with a delay of 114ms
+51ms ║RunTime Analysis CS &gt; 23ms &gt; PS &gt; 6ms &gt; PE &gt; 21ms &gt; CE
+53ms ║Runtime (43275 bytes) successfully initialized in 6ms (v0.3.110.20191009) (51ms)
+54ms ║╔Execution stage started
+68ms ║║Comparison (enum) present changes_to (string) present = true (0ms)
+69ms ║║Cancelling condition #2's schedules...
+70ms ║║Condition #2 evaluated true (12ms)
+71ms ║║Cancelling condition #1's schedules...
+72ms ║║Condition group #1 evaluated true (state changed) (14ms)
+99ms ║║Comparison (enum) present was (string) not present = false (19ms)
+100ms ║║Condition #7 evaluated false (23ms)
+101ms ║║Condition group #6 evaluated false (state did not change) (24ms)
+139ms ║║Comparison (enum) present was (string) not present = false (24ms)
+141ms ║║Condition #7 evaluated false (34ms)
+142ms ║║Condition group #6 evaluated false (state did not change) (35ms)
+144ms ║╚Execution stage complete. (91ms)
+145ms ╚Event processed successfully (145ms)
10/25/2020, 9:04:43 AM +915ms
+1ms ╔Received event [Dawn].presence = not present with a delay of 48ms
+37ms ║RunTime Analysis CS &gt; 16ms &gt; PS &gt; 5ms &gt; PE &gt; 15ms &gt; CE
+39ms ║Runtime (43286 bytes) successfully initialized in 5ms (v0.3.110.20191009) (37ms)
+40ms ║╔Execution stage started
+53ms ║║Comparison (enum) not present changes_to (string) present = false (0ms)
+54ms ║║Condition #2 evaluated false (10ms)
+55ms ║║Condition group #1 evaluated false (state did not change) (11ms)
+57ms ║╚Execution stage complete. (18ms)
+58ms ╚Event processed successfully (58ms)

Here is condition #7

Jason_Meudt · 2020-10-25 15:11:37 UTC

In looking at my own logic, it would appear that I confused the interaction of $device and {$device}…

I moved the condition for being gone for 3 minutes further up and changed the device declarations all to {family}.

Barring a further exit, if anyone can spot check this…

orangebucket · 2020-10-25 20:00:15 UTC

Looking at the piston, it seems the actions you need to take for D arriving are independent of those for J and you could easily use two separate pistons.

Given that, and bearing mind only one device will ever return true to ‘changes to’ at a time, I’d be tempted to exploit the variable $currentEventDevice to help you focus on the specific device that triggered the piston.

Jason_Meudt · 2020-10-26 11:44:42 UTC

I took your advice on the 2 distinct pistons… For the local variable ‘family’, would the piston listed above be the confusion in condition #7 and thus the stopping point? Your reference to the variable change makes me think that by using the global $currentEventDevice variable, would the limit in #7 be narrowed down from 2 sensors to a single check?

For my own knowledge, why is #7 failing with the current implementation?

orangebucket · 2020-10-26 13:03:15 UTC

I’m not really sure, or indeed at all sure. The type of comparison (‘any of’ or ‘all of’) doesn’t show when you use a variable. If it were ‘all of’ then when D arrives it would require her to have been away for at least three minutes and it would also require J to also have been away for three minutes and still be considered as away. So ‘any of’ would seem more suitable. However if J has been away for three minutes when D arrives that would mean the check for a false arrival wouldn’t actually be effective. So it doesn’t seem a totally robust comparison.