Motion sensor sometimes not triggering piston

Levahj · 2020-11-29 07:13:34 UTC

Hi all. Having an issue where with a new GE Motion Switch in the bathroom, sometimes the motion sensor does not trigger the piston to turn on the lights. The motion is registering as an event in the hub and even in the Piston’s log, but it still does not fire the Piston. This happens about 20% of the time. Here are pics of the Piston and the Pistons log where in the log the lower event did not trigger the piston but the one higher up did. both circled in red. Any ideas why?

Pantheon · 2020-11-29 09:06:45 UTC

Do you have your log set to FULL? Can you turn TRACE on and post that?

WCmore · 2020-11-29 13:55:05 UTC

I agree with @Pantheon … Full Logs shines a much brighter light.

Personally, if this were my project, I would likely split the switch triggers in one piston, and the motion triggers into another piston. (using @globals to keep track between the two)

I would likely also convert the “ONLY WHEN” sections into indented IF blocks instead.
(because I do not want that variable checked until the trigger comes in)

Levahj · 2020-11-29 15:21:13 UTC

Cant seem to replicate the problem this morning. When it starts acting up again I will send the full log

Can you tell me why you would do it this way? Does it make it more efficient somehow?

Did not realize it worked that way but makes a lot of sense. It just is so much cleaner looking to do it this way but if it is less efficient then I will change it.

Not to muddy things up but I also have another issue. The “Wait 20 minutes” does not work as well. It starts the timer just fine from the tracing I can see but when the motion becomes inactive the waiting just stops. Anything look strange from the way I wrote that part?

Lastly, (and sorry for all the questions,) is there any way to open up the logging section so I can see, and send you, more data? when I go to full logging, you can only see a couple of events at a time.

Levahj · 2020-11-29 15:29:05 UTC

I can show you the log from the “Wait” not working. I changed it from Wait 20min to Wait 2min for debugging. It always stops the waiting once the motion comes inactive: Here is the log below. Essentially:

motion detected which turns on the light, sets the variables
On button gets physically pushed which changes the variables and starts the Wait
Motion then becomes inactive (which at this point hopefully should not do anything) and the Wait for some reason gets cancelled.

Logs

11/29/2020, 7:13:44 AM +635ms
+2ms ╔Received event [Bathroom Light & Motion].motion = inactive with a delay of 33ms, canQueue: true, calledMyself: false
+26ms ║RunTime initialize > 25 LockT > 2ms > rtDT > 1ms > pistonT > 0ms (first state access 22 4 21)
+29ms ║Runtime (9674 bytes) successfully initialized in 1ms (v0.3.110.20201015_HE)
+32ms ║╔Execution stage started
+39ms ║║Comparison (boolean) false is (boolean) false = true (1ms)
+40ms ║║Condition #83 evaluated true (5ms)
+42ms ║║Cancelling condition #43’s schedules…
+43ms ║║Condition group #43 evaluated true (state changed) (7ms)
+47ms ║║Comparison (enum) inactive changes_to (string) active = false (1ms)
+49ms ║║Condition #44 evaluated false (4ms)
+50ms ║║Cancelling condition #43’s schedules…
+52ms ║║Condition group #43 evaluated false (state changed) (8ms)
+59ms ║║Condition #101 evaluated false (4ms)
+60ms ║║Condition group #11 evaluated false (state did not change) (6ms)
+66ms ║║Comparison (boolean) true is (boolean) true = true (1ms)
+67ms ║║Condition #86 evaluated true (5ms)
+68ms ║║Cancelling condition #85’s schedules…
+70ms ║║Condition group #85 evaluated true (state changed) (7ms)
+76ms ║║Comparison (enum) inactive stays (string) inactive = true (1ms)
+78ms ║║Adding a timed trigger schedule for condition 87
+81ms ║║Condition #87 evaluated false (10ms)
+83ms ║║Cancelling condition #85’s schedules…
+84ms ║║Condition group #85 evaluated false (state changed) (13ms)
+90ms ║║Condition #65 evaluated false (3ms)
+91ms ║║Condition group #64 evaluated false (state did not change) (5ms)
+96ms ║╚Execution stage complete. (65ms)
+111ms ║Setting up scheduled job for Sun, Nov 29 2020 @ 7:15:44 AM PST (in 120s)
+113ms ╚Event processed successfully (112ms)
11/29/2020, 7:13:18 AM +278ms
+2ms ╔Received event [Bathroom Light & Motion].switch = on with a delay of 69ms, canQueue: true, calledMyself: false
+24ms ║RunTime initialize > 23 LockT > 1ms > rtDT > 1ms > pistonT > 0ms (first state access 21 4 19)
+27ms ║Runtime (9661 bytes) successfully initialized in 1ms (v0.3.110.20201015_HE)
+28ms ║╔Execution stage started
+37ms ║║Comparison (boolean) false is (boolean) false = true (3ms)
+38ms ║║Condition #83 evaluated true (6ms)
+39ms ║║Condition group #43 evaluated true (state did not change) (9ms)
+46ms ║║Cancelling condition #44’s schedules…
+48ms ║║Condition #44 evaluated false (7ms)
+49ms ║║Cancelling condition #43’s schedules…
+51ms ║║Condition group #43 evaluated false (state changed) (11ms)
+57ms ║║Comparison (enum) on receives (string) on = false (0ms)
+59ms ║║Condition #101 evaluated false (5ms)
+60ms ║║Condition group #11 evaluated false (state did not change) (6ms)
+66ms ║║Comparison (boolean) true is (boolean) true = true (1ms)
+67ms ║║Condition #86 evaluated true (4ms)
+68ms ║║Cancelling condition #85’s schedules…
+70ms ║║Condition group #85 evaluated true (state changed) (7ms)
+76ms ║║Comparison (enum) active stays (string) inactive = false (1ms)
+78ms ║║Cancelling any timed trigger schedules for condition 87
+78ms ║║Cancelling statement #87’s schedules…
+80ms ║║Condition #87 evaluated false (9ms)
+82ms ║║Cancelling condition #85’s schedules…
+83ms ║║Condition group #85 evaluated false (state changed) (12ms)
+89ms ║║Comparison (enum) on changes_to (string) off = false (0ms)
+90ms ║║Condition #65 evaluated false (5ms)
+91ms ║║Condition group #64 evaluated false (state did not change) (6ms)
+95ms ║╚Execution stage complete. (68ms)
+100ms ╚Event processed successfully (98ms)
11/29/2020, 7:13:17 AM +562ms
+2ms ╔Received event [Bathroom Light & Motion].motion = active with a delay of 33ms, canQueue: true, calledMyself: false
+21ms ║RunTime initialize > 20 LockT > 1ms > rtDT > 2ms > pistonT > 1ms (first state access 17 4 16)
+25ms ║Runtime (9637 bytes) successfully initialized in 2ms (v0.3.110.20201015_HE)
+27ms ║╔Execution stage started
+34ms ║║Comparison (boolean) false is (boolean) false = true (1ms)
+35ms ║║Condition #83 evaluated true (5ms)
+36ms ║║Cancelling condition #43’s schedules…
+38ms ║║Condition group #43 evaluated true (state changed) (7ms)
+43ms ║║Comparison (enum) active changes_to (string) active = true (1ms)
+44ms ║║Cancelling condition #44’s schedules…
+46ms ║║Condition #44 evaluated true (7ms)
+47ms ║║Condition group #43 evaluated true (state did not change) (9ms)
+49ms ║║Cancelling statement #45’s schedules…
+68ms ║║Executed physical command [Bathroom Light & Motion].on() (15ms)
+69ms ║║Executed [Bathroom Light & Motion].on (18ms)
+77ms ║║Executed virtual command [Bathroom Light & Motion].setVariable (2ms)
+85ms ║║Condition #101 evaluated false (4ms)
+87ms ║║Condition group #11 evaluated false (state did not change) (6ms)
+94ms ║║Comparison (boolean) true is (boolean) true = true (2ms)
+95ms ║║Condition #86 evaluated true (5ms)
+96ms ║║Cancelling condition #85’s schedules…
+98ms ║║Condition group #85 evaluated true (state changed) (9ms)
+104ms ║║Comparison (enum) active stays (string) inactive = false (1ms)
+106ms ║║Cancelling any timed trigger schedules for condition 87
+106ms ║║Cancelling statement #87’s schedules…
+108ms ║║Condition #87 evaluated false (9ms)
+110ms ║║Cancelling condition #85’s schedules…
+111ms ║║Condition group #85 evaluated false (state changed) (12ms)
+117ms ║║Cancelling condition #65’s schedules…
+119ms ║║Condition #65 evaluated false (5ms)
+120ms ║║Cancelling condition #64’s schedules…
+122ms ║║Condition group #64 evaluated false (state changed) (8ms)
+126ms ║╚Execution stage complete. (100ms)
+153ms ╚Event processed successfully (151ms)

Clear

Full

Levahj · 2020-11-29 16:04:16 UTC

I just got the initial problem to happen again - motion did not trigger the light on. Here is the full log. You will see the two triggers - Motion Active, then Motion inactive but the light not going on. As always, any help into why this is happening is much appreciated!

11/29/2020, 8:00:26 AM +524ms
+3ms ╔Received event [Bathroom Light & Motion].motion = inactive with a delay of 35ms, canQueue: true, calledMyself: false
+28ms ║RunTime initialize > 27 LockT > 1ms > rtDT > 3ms > pistonT > 1ms (first state access 23 4 23)
+31ms ║Runtime (9735 bytes) successfully initialized in 3ms (v0.3.110.20201015_HE)
+32ms ║╔Execution stage started
+40ms ║║Comparison (boolean) true is (boolean) false = false (1ms)
+41ms ║║Condition #83 evaluated false (6ms)
+43ms ║║Condition group #43 evaluated false (state did not change) (7ms)
+52ms ║║Condition #101 evaluated false (5ms)
+53ms ║║Condition group #11 evaluated false (state did not change) (8ms)
+61ms ║║Comparison (boolean) false is (boolean) true = false (2ms)
+65ms ║║Condition #86 evaluated false (7ms)
+66ms ║║Condition group #85 evaluated false (state did not change) (8ms)
+75ms ║║Condition #65 evaluated false (7ms)
+76ms ║║Condition group #64 evaluated false (state did not change) (8ms)
+80ms ║╚Execution stage complete. (47ms)
+83ms ╚Event processed successfully (81ms)
11/29/2020, 8:00:01 AM +314ms
+5ms ╔Received event [Bathroom Light & Motion].motion = active with a delay of 87ms, canQueue: true, calledMyself: false
+44ms ║RunTime initialize > 43 LockT > 14ms > rtDT > 2ms > pistonT > 1ms (first state access 27 20 23)
+48ms ║Runtime (9728 bytes) successfully initialized in 2ms (v0.3.110.20201015_HE)
+50ms ║╔Execution stage started
+65ms ║║Comparison (boolean) true is (boolean) false = false (3ms)
+68ms ║║Condition #83 evaluated false (11ms)
+71ms ║║Condition group #43 evaluated false (state did not change) (14ms)
+80ms ║║Condition #101 evaluated false (6ms)
+83ms ║║Condition group #11 evaluated false (state did not change) (9ms)
+90ms ║║Comparison (boolean) false is (boolean) true = false (1ms)
+91ms ║║Condition #86 evaluated false (5ms)
+93ms ║║Condition group #85 evaluated false (state did not change) (7ms)
+98ms ║║Condition #65 evaluated false (3ms)
+99ms ║║Condition group #64 evaluated false (state did not change) (6ms)
+106ms ║╚Execution stage complete. (57ms)
+110ms ╚Event processed successfully (109ms)

WCmore · 2020-11-30 00:57:32 UTC

Currently, each switch change, or motion change will run thru the piston, top to bottom, and execute anything not blocked by conditions. By keeping the two triggers separate, it gives you more control over the outcome.

The WAIT works, but the extra triggers you have placed can cancel the WAIT. You can either follow my earlier recommendation, or force that block TCP to Never.

Full logging affects the level of detail on FUTURE logs… Not previous ones.
(I recommend CLEARING logs each time you edit, since the old logs no longer apply)

See my earlier suggestion

orangebucket · 2020-11-30 22:38:38 UTC

As @WCmore has suggested, don’t hide the trigger on line 25 behind an ‘only when’ statement. You need that trigger condition to be evaluated every time the motion changes, not just when the ‘only when’ is true.

If onPhysically is true when the motion changes to inactive, the piston will not evaluate line 25 and so it will still think it is active (it works with the events it actually receives in the order it receives them so keeps its own record). If a following change of motion to active happens when onPhysically is false the ‘changes’ will be evaluated as false as active to active is not a change.

Levahj · 2020-12-01 01:46:27 UTC

Thank you @orangebucket and @WCmore for your inputs. Webcore is seemingly not all that intuitive as I thought. I think I should stay away from ‘only when’ as much as possible!

Levahj · 2020-12-01 05:45:58 UTC

If I instead put the ‘only when’ inside the if statement instead of in front of it, is that any different ? will that trigger event then be evaluated every time the motion changes?
Here is the example:

If motion changes to active
then
Only When OnPhysically is false
With bathroom light
Do Turn on

orangebucket · 2020-12-01 11:58:23 UTC

Yes that is fine as the piston will always run the ‘if’ statement.

I have to say the thing about the ‘only when’ and triggers is just a theory I have as I can’t read and understand the webCoRE source code well enough to see what is actually going on. However limited tests I have performed suggest I am either correct or close enough and it explains a lot of odd behaviour that has cropped up in this forum.

Restrictions, to give the ‘only when’ statements their formal name, have their uses but of late they seem to have featured rather a lot on this forum, and not for their positive contributions either. I have been a little surprised that they have appeared so frequently in ‘my first piston’ type posts given they are hidden by default.

WCmore · 2020-12-01 13:21:51 UTC

Many new users turn everything on in the options, which tends to confuse and needlessly complexify their pistons. My recommendation for most users (including myself) is to only check two of the options:

99% of all pistons can be created with only these two check marks in the options.
90-95% of all pistons can be created with only “Show variables” checked

Levahj · 2020-12-01 16:11:24 UTC

I think you hit the proverbial nail on the head with this theory. Explains in my case why the Piston saw the motion turn on but did not trigger the lights.

I get where you are coming from. I’m certainly not a new user, but I obviously dont know all the nuances of Webcore. But to be fair, there should be no difference on how the Piston runs if the ‘Only When’ is outside the triggering if statement or inside it, or you just use a plain old ‘and’ statement. I think a lot of new users ( and I as well though have been using WebCore in fairly simple Pistons for 2+ years) use the ‘Only When’ because it makes the Piston very easy to look at and makes it very logically laid out.
I love WebCore. Its so powerful. Andy originally built it and God bless that guy for all the hard work he and so many others have put in basically for free
.
I’m not knocking it, but there really should be no logical difference between:

Only When OnPhysically is false
if motion changes to active
Do turn on light

if motion changes to active
Only When OnPhysically is false
Do turn on light

if motion changes to active
and OnPhysically is false
Do turn on light

But the beauty of it all is that there is more than one way to skin a cat so I will be using ‘Only If’ a lot less now that you guys have taught me some new lessons

WCmore · 2020-12-02 01:31:38 UTC

I agree wholeheartedly. Which is why I drop the ONLY WHEN entirely, and write it like your third example.
(or, depending on the logic, I may indent:)

IF motion changes to active   <-- Trigger
Then
    IF OnPhysically is false  <-- Condition
    Then
       Do turn on light
    END IF
END IF