Piston not firing - review please

withay · 2019-06-21 18:24:53 UTC

Heh, well… Yes, that WOULD make sense, wouldn’t it? I’m posting the piston - I don’t have logs set for it - what level should I set it to for the next time it fires?

WCmore · 2019-06-21 18:45:54 UTC

I set logging to “FULL” for troubleshooting, and drop to “Minimum” once everything is running smoothly

withay · 2019-06-21 20:20:47 UTC

Ok, here are the logs for three events, I separated them with what made them fire:

This is when my SO (PERSON2) came home from being out. WOrking as it should.

6/21/2019, 3:29:50 PM +690ms
+2ms ╔Received event [PERSON2].presence = present with a delay of 107ms
+50ms ║RunTime Analysis CS > 27ms > PS > 8ms > PE > 15ms > CE
+53ms ║Runtime (37783 bytes) successfully initialized in 8ms (v0.3.10c.20190522) (50ms)
+54ms ║╔Execution stage started
+68ms ║║Comparison (enum) present is (string) present = true (2ms)
+70ms ║║Condition #2 evaluated true (9ms)
+71ms ║║Condition group #1 evaluated true (state did not change) (12ms)
+74ms ║║Condition group #4 evaluated true (state did not change) (1ms)
+77ms ║║Cancelling statement #5’s schedules…
+94ms ║║Executed physical command [Foyer Light].on() (11ms)
+95ms ║║Executed [Foyer Light].on (13ms)
+110ms ║║Executed physical command [Front Door Light].on() (11ms)
+111ms ║║Executed [Front Door Light].on (13ms)
+114ms ║║Cancelling statement #7’s schedules…
+142ms ║║Executed physical command [Front Door Deadbolt].unlock() (23ms)
+143ms ║║Executed [Front Door Deadbolt].unlock (25ms)
+147ms ║║Cancelling statement #9’s schedules…
+202ms ║║Executed physical command [Honeywell Security].disarm() (51ms)
+203ms ║║Executed [Honeywell Security].disarm (53ms)
+207ms ║╚Execution stage complete. (154ms)
+209ms ╚Event processed successfully (208ms)

And this is when I (PERSON1) left to go to the store, and it fired when it should not.

6/21/2019, 3:58:12 PM +479ms
+2ms ╔Received event [WITHAY].presence = not present with a delay of 99ms
+61ms ║RunTime Analysis CS > 31ms > PS > 14ms > PE > 15ms > CE
+63ms ║Runtime (37786 bytes) successfully initialized in 14ms (v0.3.10c.20190522) (60ms)
+65ms ║╔Execution stage started
+76ms ║║Comparison (enum) not present is (string) present = false (2ms)
+78ms ║║Cancelling condition #2’s schedules…
+80ms ║║Condition #2 evaluated false (8ms)
+90ms ║║Comparison (enum) present is (string) present = true (1ms)
+92ms ║║Condition #3 evaluated true (10ms)
+93ms ║║Condition group #1 evaluated true (state did not change) (23ms)
+96ms ║║Condition group #4 evaluated true (state did not change) (1ms)
+99ms ║║Cancelling statement #5’s schedules…
+119ms ║║Executed physical command [Foyer Light].on() (14ms)
+120ms ║║Executed [Foyer Light].on (16ms)
+136ms ║║Executed physical command [Front Door Light].on() (13ms)
+138ms ║║Executed [Front Door Light].on (15ms)
+141ms ║║Cancelling statement #7’s schedules…
+172ms ║║Executed physical command [Front Door Deadbolt].unlock() (25ms)
+173ms ║║Executed [Front Door Deadbolt].unlock (27ms)
+177ms ║║Cancelling statement #9’s schedules…
+232ms ║║Executed physical command [Honeywell Security].disarm() (51ms)
+233ms ║║Executed [Honeywell Security].disarm (53ms)
+237ms ║╚Execution stage complete. (173ms)
+239ms ╚Event processed successfully (238ms)

And then when I (PERSON1) came home from the store:

6/21/2019, 4:14:12 PM +140ms
+1ms ╔Received event [WITHAY].presence = present with a delay of 75ms
+47ms ║RunTime Analysis CS > 26ms > PS > 8ms > PE > 13ms > CE
+49ms ║Runtime (37785 bytes) successfully initialized in 8ms (v0.3.10c.20190522) (47ms)
+50ms ║╔Execution stage started
+63ms ║║Comparison (enum) present is (string) present = true (2ms)
+65ms ║║Cancelling condition #2’s schedules…
+66ms ║║Condition #2 evaluated true (9ms)
+68ms ║║Condition group #1 evaluated true (state did not change) (10ms)
+71ms ║║Condition group #4 evaluated true (state did not change) (1ms)
+74ms ║║Cancelling statement #5’s schedules…
+83ms ║║Skipped execution of physical command [Foyer Light].on([]) because it would make no change to the device. (3ms)
+84ms ║║Executed [Foyer Light].on (6ms)
+91ms ║║Skipped execution of physical command [Front Door Light].on([]) because it would make no change to the device. (3ms)
+92ms ║║Executed [Front Door Light].on (5ms)
+96ms ║║Cancelling statement #7’s schedules…
+104ms ║║Skipped execution of physical command [Front Door Deadbolt].unlock([]) because it would make no change to the device. (4ms)
+105ms ║║Executed [Front Door Deadbolt].unlock (6ms)
+109ms ║║Cancelling statement #9’s schedules…
+193ms ║║Executed physical command [Honeywell Security].disarm() (80ms)
+195ms ║║Executed [Honeywell Security].disarm (82ms)
+198ms ║╚Execution stage complete. (148ms)
+200ms ╚Event processed successfully (199ms)

WCmore · 2019-06-21 20:51:52 UTC

This section executed because:
+92ms ║║Condition #3 evaluated true (10ms)
(meaning your SO was still home)

It happened due to the following code:
temp

(notice the ‘#3’ at the very end matches your log)

withay · 2019-06-21 21:33:30 UTC

So you’re saying that the piston fires when one of the conditions changes, then the piston looks at the two conditions, and if one condition OR the other condition is true - the piston continues… Am I on the right track?

WCmore · 2019-06-21 21:51:19 UTC

You are correct. The trigger kicks everything off, and then the code dictates what happens next.

The tricky thing you may not have noticed is, triggers fire in both directions.

In other words, even though your code says “is present”, your piston will run top to bottom when either sensor changes to “present” OR “not present”.

What happens after that, depends on the rest of your code.

From a behind-the-scenes standpoint, when a piston subscribes to a Sensor’s presence, then any changes to that presence will trigger the piston. This concept carries over to all types of devices. (IE: “IF Switch changes to on” will also run when the switch changes to off, but will skip that block, and continue on with the rest of the piston (if conditions allow it))

withay · 2019-06-21 22:01:36 UTC

I’m going to have to think about this, I’m not sure how to go about making it work.

I also have a “leaving” piston that, when we BOTH leave, the piston does the lights/lock thing.

Now I’m wondering what actually happens when we both leave - which one fires, which one fires first, is the house locking or unlocking… LOL So confused! Not earth shattering if it is unlocked - as I know to look at my dashboard and look for a notification, etc etc, but I’d LIKE it to all work properly!

WCmore · 2019-06-21 22:14:29 UTC

Well, for what it’s worth, I try to make sure only one of my pistons executes when a presence sensor changes. This is because each piston with a lightning bolt next to a presence sensor, will execute from top to bottom when leaving OR arriving. Having more than one piston executing at each event means a higher chance of commands getting lost in all the commotion.

Personally, I would prefer only one piston executing at such events.

This can work, but the wording has to be specific.
(since both sensors will never exit/return at the same instant)

Personally, I would try to combine all your logic that you want to happen when someone arrives or leaves into one giant piston. With only one trigger, but as many conditions beneath as you like.

For those who want to tackle this by themselves, I normally recommend clients stall a few months before coding for presence sensors, since they can be some of the trickiest coding.

In my opinion, it really helps to have a solid grasp on webCoRE’s logic before diving in to a Presence piston.

ike2018 · 2019-06-21 22:22:08 UTC

How about this, this will make your piston a bit longer but might help…
Here are possible scenearios:
a) One of you leaves everything will be same, no ACTION in the house.
b) Both of you together or seperately out. Lock the doors etc.

IF sensor 1 changes to AWAY (lets say you just left)
WAIT 5 minutes.
Check the other sensor (to see if home or not, if not)
Do this do that…

The wait is just to make sure ST HUB had enough time to register the sensors…

You can create another IF block just for the second sensor…

something like this:

ike2018 · 2019-06-21 22:23:12 UTC

100% agree.
Presense sensors are very tricky.

withay · 2019-06-21 22:34:08 UTC

I can see that! Ok, thanks both of you. But I’m stubborn, and I want to learn, and I know the only way I’m going to learn is if I forge through it. Let me look at that example, and think this over, and come up with… Oh, something exciting! Forget cowbell, I need more bells and whistles!

withay · 2019-06-22 13:53:52 UTC

I’m still looking at this - what if I split this into two separate pistons? One for me "presence is ‘present’. And then a different piston for him? If we’re both away and both come home at the same time and one piston fires a few second/minute after the other - that won’t harm anything.

OR - Could I fit both of these on the same piston? "IF “present” then “lights”. Second “IF”: If “present2” then “lights”?

Would “Changes to” work in either of these scenarios, or stick to “present”?

withay · 2019-06-22 14:01:21 UTC

Huh. Ok. So what would be the actual trigger in my case?

I want action if BOTH of us leave.

I want NO action if ONE of us leaves and the other stays home.

I want action if ONE of us leaves and the other is NOT home.

I want action if either one of us or BOTH of us comes home.

I THINK I see how to create much of this - I’m not sure what the initial trigger should be.

WCmore · 2019-06-22 15:17:57 UTC

I am about to head out the door to work, but here is what I am thinking:

IF Sensor 1 or 2's presence change to present   <-- Trigger
Then 
    IF Sensor 1 or 2's presence is not present  <-- Condition
    Then 
        Do "Welcome Home" stuff  (Keep duration short, might be two back to back)
    ELSE
        Do "Everyone Home" stuff
END IF

IF All of Sensor 1 & 2's presence are not present  (Force subscription)
    Then do "Goodbye stuff"
END IF

Notice how each IF block is subscribed to the exact same devices & attributes.
(so really this piston has two triggers. Sensor 1 & 2’s presence)

Also, please be careful with the ELSE. If the wording is even slightly different, it will not work as expected.

withay · 2019-06-23 00:50:39 UTC

Thanks again! I’m going to try all this out. I need to run logs more. I noticed today that when we left, the house secured and stayed secured. When we came home, the house desecured (is that a word?), but then after we had been home 5 or 10 minutes… the “desecuring” happened again. Sigh. LOL I’m bound and determined to get this working!

WCmore · 2019-06-23 00:52:49 UTC

I admire your determination, I just wish you were learning with pistons that did not involve security or presence sensors…

withay · 2019-06-23 12:38:35 UTC

I understand. But I AM following up with looking at my dashboard every time, and getting alerts from a separate, non-Webcore/Smartthings source.

withay · 2019-06-26 19:09:50 UTC

HEE! Ok, so I’m looking at what you replied with in that other thread - I like!

He’s got a Pixel 3, I’ve got an iPhone Xs. Both of us connect through bluetooth to both our vehicles (a Jeep and a Ram). How would this work, please?

WCmore · 2019-06-26 19:36:07 UTC

My little trick uses Tasker, which works on Android devices. Tasker keeps track of events on the Android side, and then sends a command to execute a piston when the time is right. WebCoRE takes over from there.

(Tasker is to Android, what webCoRE is to SmartHomes… Mind-blowingly Powerful!)

withay · 2019-06-27 00:16:23 UTC

COOL! Is there an iPhone equivalent? I hope?