Ok, I think I have it figured out. Your last ELSE statement was not going to execute the way you wanted (it wouldn’t matter what time of day it was, if occupancy was greater than 0 it would set your SHM to stay and execute associated commands.
I think this covers what you were after now. I removed the WAIT 10 minutes and replaced it with a “@occupancy remains unchanged” to account for it.
ahh, I like it… I think that’s what I was after. Also going to throw in:
Everyday at 7:00am
if @Occupancy is greater than 0 {
execute piston Lights 100%
Set SHM to disarmed
Set location mode home }
With Cams {
do Turn off }
I’ll do some testing with it today. Thanks!
Looking good!
Since your disarm at 7:01am command is the same as your “occupancy rises” command for disarming… you can just add that as another condition to the same actions like this:
I don’t think that’ll work… That’ll disarm everything even if @occupancy is zero (for example, out of town for a few days).
You got it!
If you want to get rid of that comment, click on the “@occupancy rises” item, then click the gear cog at the bottom of the dialog box. Then you’ll see the Comments section and can wipe that out.
I’ll do some testing over the next couple days. The logic is there and it looks good, so we’ll see.
If it works good, I’ll be sure to post it in the examples category.
Thanks again!
So to test this, I adjusted the times… It didn’t fire, any ideas? Attaching logs:
2/1/2018, 4:30:12 PM +796ms
+2ms ╔Starting piston… (v0.2.102.20180116)
+249ms ║╔Subscribing to devices…
+277ms ║║Subscribing to Home.:3812ddc8dfef41be8ba1c5fbeab505ff:.@Occupancy…
+595ms ║║Subscribing to Party…
+596ms ║║Subscribing to Deck Cam…
+597ms ║║Subscribing to Driveway Cam…
+598ms ║║Subscribing to Front Porch Cam…
+599ms ║╚Finished subscribing (362ms)
+624ms ║Comparison (dynamic) 1 changes_to (integer) 0 = false (0ms)
+637ms ║Comparison (dynamic) 1 rises = false (1ms)
+641ms ║Comparison (time) 59413435 happens_daily_at (time) 25260000 = false (1ms)
+643ms ║Cancelling statement #60’s schedules…
+646ms ║Requesting time schedule wake up at Fri, Feb 2 2018 @ 7:01:00 AM EST
+652ms ║Comparison (dynamic) 1 is_greater_than (integer) 0 = true (2ms)
+672ms ║Comparison (time) 59413459 is_between (time) 59340000 … (time) 25200000 = true (7ms)
+673ms ║Time restriction check passed
+675ms ║Cancelling condition #46’s schedules…
+679ms ║Comparison (dynamic) 1 stays_unchanged = true (0ms)
+683ms ║Comparison (dynamic) 1 is_greater_than (integer) 0 = true (1ms)
+692ms ║Comparison (enum) off is_not (string) on = true (2ms)
+693ms ║Cancelling condition #43’s schedules…
+713ms ║Setting up scheduled job for Fri, Feb 2 2018 @ 7:01:00 AM EST (in 52246.492s)
+728ms ╚Piston successfully started (727ms)
Hmm… first thought for that one is we probably need @Occupancy to change, but then stay unchanged for a minute after that.
Does that throw a wrench into things for your implementation?
Well I’m curious as to why it’s not working… There’s 4 restrictions on that IF statement, and every one is TRUE… so shouldn’t it execute?
So it does work if something triggers the @occupancy variable… Wife just got home and it kicked on a 1minute timer to go into armed/stay mode
There’s a quick workaround for it.
Make a Group in that IF statement, and put “@Occupancy remains unchanged OR Time Occurs Daily at 11:30pm”. Leave the other 3 the way they are. That way it’ll trigger at 11:30 at night and any time occupancy changes between the hours of 11:30 and 7am.
It’s working correctly, just not the way it feels like it would. The way a piston verifies something hasn’t changed is like this:
@Occupancy changes
Your piston sets a timer for 1 minute (or 10 minutes in the final implementation) in the future
Your piston wakes up and sees if @Occupancy has changed in the time above
If not, it evaluates true. If it has, it evaluates false.
What we’re missing is that first change to kick it into action. That’s what the time happens daily at 11:30pm will do (or you can set it to something close to now to test it).
Make sense?
Yep, makes sense… Like so: (?)
| +472ms | ║Setting up scheduled job for Thu, Feb 1 2018 @ 11:31:00 PM EST (in 24288.95s), with 1 more job pending |
|---|---|
| +485ms | ╚Piston successfully started (485ms) |
I’m going to adjust those times in a minute and do some testing by forcing the presence sensors into various states…
Stay tuned…
