Piston not firing - review please

#1

1) Give a description of the problem
Piston not firing

2) What is the expected behaviour?
When both presence sensors change to away: lights turn off, deadbolts lock, alarm arms.

3) What is happening/not happening?
Nothing!

**4) Post a Green Snapshot of the piston!

allaway
allaway.png1178×749 69.5 KB

I have a tile piston for both of us - the Presence Sensor Tiles and they both work - our phones are detected as away when we leave. I have ANOTHER Piston, called “one or both home” that does the reverse of this one - and that one works just fine!

#2

Change from ‘changes to not present’ to ‘are not present.’

#3

Ok, I’ll try that! I’ll have a chance to test it in a couple hours - have to go out and run errands. :slight_smile:

#4

You can create simulated devices for testing if you want instant gratification :slight_smile: @wcmore made a simple guide here.

#5

Everytime I see similar intentions, I feel like warning people and truly sorry about that.
Please do not trust your presence sensors for security related situations.
Actually don’t trust your smart home with security at all UNLESS you are personally seeing that doors are locked, alarm is activated etc.

I am not a persimist trust me:))) ST HOME tech is fairly new and at a very early stage. Signal drops, hub problems, communication problems etc are STILL very large part of the systems. Just like early times of cell phones (90s) 10 out of 5 calls wouldn’t go through.

At least create some form of fail safe, either manually cheking the systems on your phone, or another piston reporting you the status of your systems after all that stuff is done.

I have a piston that locks my door IF it’s not locked for 3 minutes. 10 out of 1 it will not lock the door.

Once again I know this is off topic and I’m sorry.

#6

Heh, yes, I see your warnings. Normally I don’t even arm my alarm during the day, and I normally DO lock my front door. VERY VERY rarely do I forget to lock the front door, and now and then after I let the dogs back in one of us has left the back door unlocked. This piston (and honestly, all of my pistons that involve door locks and alarms) is more of a doublecheck on us, but I do see your point. I’ll add a “notify by sms” at the end that’ll remind me to check the Dashboard

#7

I just noticed we had this conversation earlier… Sorry man:)))))
I’ll remember your name and won’t do it again :)))))

#8

Nope, no problem at all! I wouldn’t have done it for this if you hadn’t mentioned it.

Questions! If I want to send an SMS to TWO phone numbers, do I have to do the entries separately, or can I just separate the phone numbers with a comma.

I just discovered the “PUSH” notifications thing - I think I’d rather use that one, but the above question stands. :slight_smile:

#9

Yes that will do it…

“Store in messages” someting I’ve never used, i’m not sure but I ASSUME, it’s for storing the messages to be sent at a later time and/or for logging purposes (I’m just making it up FYI)

Did the piston work with @eibyer solution? It should.

#10

I’d second this.
You also need to think through what might go wrong with a sensor. My garage opens when I arrive home, however, if the presence sensor looses connection & then regains it, the garage door opens. As it did in the middle of the night. I’ve now build in 2 additional safeguards. 1 - dont open if in night mode, 2 - Use a variable to hold presence, and only set to away if the sensor is away for 5 mins.

#11

We have a winner! :slight_smile:

I left to pick up my SO, I got a couple blocks away, and my phone got an SMS: “House Secured - Check Dashboard because Smarthings is sometimes Dumb Things!”

I also get a notification from EYEZONE when my alarm changes status, independently of WebCOrE or SmartThings.

#12

This has been bugging me!

Is there a way you can simply explain the difference in how it works?

#13

The two presence sensors leaving at exactly the same time is slim to impossible which is what the event trigger ‘changes to not present’ is looking for. Instead we use the ‘are not present’ condition. When there are no triggers in the piston, conditions will act like triggers so each time one of the presence sensor leaves then that ‘are not present’ condition gets evaluated.

#14

OMG I get it!! Thank you!!

#15

I’m back! So - odd issue with this one… When one of us leaves the house and drives away (with the other one home)… This piston fires. I’ve tested - it’s either one of us leaving.

Thoughts?

#16

You should post your current piston and some logs so we can check it out.

#17

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?

allaway
allaway.png1178×727 66.5 KB

#18

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

#19

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)

#20

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)