Or check out a switch statement. That could save on lines of code
Seriously Can No One Help Me?!?! This is getting Frustrating
Change your primary triggers ‘changes to present / not present’ to conditions ‘IS present / not present’.
When the piston wakes up from the 30 second of 300 second waits, the presence sensor has no longer ‘changed’… this state reverts to standby (for want of a better word) after about 10 seconds, so this may be cancelling the flow of your piston.
Alternatively, set each element to ‘never cancel’ but that is rather long winded.
In regards to locking 3 times… how can a locked lock be locked again? What is telling you this is the case if you see no logs? Even if the device could lock twice, webCoRE has command optimisations to prevent this.
In regards to logs, your piston is too large, uses too much memory so webCoRE cannot spare memory for logs… consider splitting it into two, with global variables bridging the gaps.
I have command op off because the viper smart start doesn’t recognize state and my Yale Lock is finicky if its not all the way locked manually. So it beeps to tell me its already locked and ST states its receiving the lock command three times.
I originally had these at ‘is’ and all my presence pistons were doing this. I thought that each of the pistons were doing it to each other because of the is.
This is by far my largest piston and the only one that has these errors. I’m limited on the amount of commands i can send to the viper system so i have to fix it lol.
I would be very tempted to move the important lock sections to their own piston, and keep the “convenience code” separate.
Something like:
IF Presence sensor's presence is present
Then
Wait 300 seconds
Lock Door
END IF
IF Presence sensor's presence is not present
Then
Wait 5 seconds
Lock Door
END IF
That’s definitely an idea. The other code is just filler to remind me to set my heat or ac for the remote starter.
Fancy code is all fine and dandy, but I usually keep the important (crucial) commands in a piston as simplified as possible.
One other food for thought, all presence sensors I have ever seen will occasionally drop out sporadically. So even if you are sitting in your living room, your presence sensor may think you have left, and then returned a few minutes later. (Meaning your door could be unlocked for 300 seconds while you are sleeping etc)
Just a heads up.
I use tasker which only turns on to monitor while my phone is near my cars wifi. If its off the presence sensor wont move.
I use Tasker as well, but how do you tell webCoRE that Presence sensor 1 is Tasker?
I thought Presence sensors were either the App (using GPS), a device, or a keychain etc.
That’s all it really is. Its one of ST built in DTHs. It acts just like a switch. I have a vinli device in my car too, which doesn’t work in my rural area. it still creates a wifi hotspot though. so i use it as my near wifi to turn on and off the autoloc monitors. Im pretty sure i got most of my inspiration from your posts lol.
My entire phone now receives customized notifications for just about anything in my home. I have different sounds, leds and even built my own customized alarm clock using tasker and webCoRE.
Very cool. Once I linked up webCoRE to Tasker (and then eventually EventGhost on my PC), there is no limit as to the capabilities. It makes each ecosystem infinitely more powerful and capable.
It works in reverse as well, such as when my girl texts me, a certain light flashes pink for a few seconds.
I moved them all to is present then put them in ifs. i ran a test via the piston with trace on. The door tried to unlock twice before it ever got to the command to unlock the door lol.
Thank you all so much for your help. For weeks I’ve banging my head against the wall over this. The problem was in one of my get requests i had @guarddog13 “MLBTV” instead of “MLBTV”"" That seems to have fixed the problem. I don’t know why but it’s had flawless tests since i fixed that.
Or not as i watch it loop through commands again. arg
If the locking aspect is the only thing not working on this long piston, why not isolate it by moving the two blocks into their own piston?
IF Presence sensor's presence is present
Then
Wait 300 seconds
Lock Door
END IF
IF Presence sensor's presence is not present
Then
Wait 5 seconds
Lock Door
END IF
Not only does this prevent any other activity from tripping the piston, but it also makes troubleshooting a breeze.
Also, at the risk of stating the obvious, while you are testing, make sure you have no other pistons/routines/scenes programmed to lock the door. (again for isolation purposes)