Occupancy state change not detected

#1

1) Give a description of the problem
State change is not being detected in a piston, but is in another one. I have one piston set up to increase the temperature when in heating mode if either my wife or I come home for lunch. I have another piston that is supposed to unlock the mudroom door if we come home. One triggers, the other does not. Why does only 1 detect the occupancy state change when they execute at the same time?

2) What is the expected behavior?
I am expecting a trigger of the state change of my phone or my wife’s phone to unlock a door. It does not detect the state change. I am also expecting a second piston to detect the state change and change the temperature. That works.

3) What is happening/not happening?
The occupancy state change is not detected in one of the pistons. Both pistons execute at the same time.

4) Post a Green Snapshot of the pistonimage

Piston not working

Unlock%20mudroom
Unlock mudroom.png1178×675 39.9 KB

Working piston

Temp%20Up
Temp Up.png1178×513 30.7 KB

5) Attach logs after turning logging level to Full

Log of piston not working
2/16/2021, 11:49:04 AM +938ms
+2ms ╔Received event [SAMSUNG-SM-G950U].occupancy = occupied with a delay of 90ms
+50ms ║RunTime Analysis CS > 20ms > PS > 11ms > PE > 19ms > CE
+52ms ║Runtime (38572 bytes) successfully initialized in 11ms (v0.3.113.20210203) (49ms)
+53ms ║╔Execution stage started
+84ms ║║Comparison (enum) locked is (string) locked = true (2ms)
+85ms ║║Cancelling condition #2’s schedules…
+86ms ║║Condition #2 evaluated true (29ms)
+102ms ║║Comparison (string) occupied changes_to (string) occupied = false (0ms)
+103ms ║║Cancelling condition #3’s schedules…
+104ms ║║Condition #3 evaluated false (17ms)
+105ms ║║Condition group #1 evaluated false (state did not change) (48ms)
+107ms ║╚Execution stage complete. (54ms)
+108ms ╚Event processed successfully (108ms)

Log of piston working
2/16/2021, 11:49:04 AM +925ms
+2ms ╔Received event [SAMSUNG-SM-G950U].occupancy = occupied with a delay of 77ms
+48ms ║RunTime Analysis CS > 23ms > PS > 6ms > PE > 18ms > CE
+51ms ║Runtime (37816 bytes) successfully initialized in 6ms (v0.3.113.20210203) (47ms)
+52ms ║╔Execution stage started
+68ms ║║Comparison (time) 42544983 is_between (time) 30600000 … (time) 57600000 = true (8ms)
+70ms ║║Time restriction check passed
+72ms ║║Condition #2 evaluated true (14ms)
+86ms ║║Comparison (string) occupied changes_to (string) occupied = true (1ms)
+88ms ║║Cancelling condition #3’s schedules…
+89ms ║║Condition #3 evaluated true (17ms)
+90ms ║║Cancelling condition #1’s schedules…
+91ms ║║Condition group #1 evaluated true (state changed) (34ms)
+94ms ║║Cancelling statement #4’s schedules…
+172ms ║║Executed physical command [Thermostat Heat Trigger Button].push1() (74ms)
+174ms ║║Executed [Thermostat Heat Trigger Button].push1 (76ms)
+177ms ║╚Execution stage complete. (126ms)
+178ms ╚Event processed successfully (178ms)

#2

Try moving the changes trigger so it comes first in the if. It needs to be executed every time the occupancy event happens otherwise it may not recognise the change.

#3

I’ll give it a shot, but both pistons have the state change in the second line and one of them does run.

#4

The point is that the changes to occupied trigger only evaluates as true if the piston is currently processing the occupied event and last time the trigger was evaluated it was running the unoccupied event.

If you look at the first piston, the changes to trigger is only evaluated when the door is locked. If it is unlocked the and condition must be false and the so webCoRE doesn’t bother to check the second condition (by default). So the trigger only works with what happened when the door was locked.

You can see it in the log:

+102ms ║║Comparison (string) occupied changes_to (string) occupied = false (0ms)

It is false because it doesn’t think there was a change.

The working piston is only taking notice of occupancy changes that happen between 8:30am and 4:00pm on weekdays. If you leave the house before 8:30am the trigger wouldn’t know about that and so when you came back at lunchtime the comparison would probably be with you going back to work the previous working day. If your routine changes that piston may well malfunction too.

#5

Ahhh, the last paragraph explains the logic. I didn’t realize that the occupancy change is dependent on what comes before it. It seems to me like they should be evaluated independently.

I changed both pistons to have the occupancy state change check first. I’ll check tomorrow to see if that solved it.

#6

Looks like that solved it. Both pistons returned a true value for the occupancy state change. Thanks for the help.