Schedule Next Piston Run

#1

1) Give a description of the problem
I wrote this simple piston to control the lock on a doggie door, allowing it to remain unlocked when it is safe for the dogs to go outside on their own (we have foxes and coyotes around), and keeping it locked when it’s not safe.

2) What is the expected behavior?
The doggie door is to remain locked when any of the following are true: (1) either of our backyard gates are open; or (2) no one is home (i.e, mode is not HOME); or (3) it’s dark out. In reverse, the doggie door is unlocked when all 3 of the same things are true.

3) What is happening/not happening?
I noticed that when the piston runs, it sets a NEXT SCHEDULED time for the piston to run 24 hours later, It therefore appears to miss important events in the interim. As a webcore newbie, I’ve tried to read up on scheduling policies, but I must be missing something.

4) Post a Green Snapshot of the pistonimage

doggie%20door%20piston
doggie door piston.png1178×905 162 KB

5) Attach any logs (From ST IDE and by turning logging level to Full)
1/26/2019, 5:46:14 PM +54ms
+1ms ╔Received event [Home].time = 1548546375645 with a delay of -1591ms
+171ms ║RunTime Analysis CS > 16ms > PS > 122ms > PE > 33ms > CE
+174ms ║Runtime (43099 bytes) successfully initialized in 122ms (v0.3.109.20181207) (172ms)
+175ms ║╔Execution stage started
+193ms ║║Cancelling condition #9’s schedules…
+196ms ║║Cancelling condition #10’s schedules…
+197ms ║║Condition #10 evaluated true (1ms)
+202ms ║║Comparison (string) :bbc2bbf1ddc37b27b6454a9e3406cf61: is (string) :bbc2bbf1ddc37b27b6454a9e3406cf61: = true (2ms)
+204ms ║║Condition #11 evaluated true (6ms)
+238ms ║║Comparison (time) 63974259 is_after (time) 1548508200000 = true (8ms)
+240ms ║║Time restriction check passed
+242ms ║║Condition #12 evaluated true (36ms)
+255ms ║║Comparison (time) 63974297 is_before (time) 1548543480000 = false (9ms)
+257ms ║║Condition #13 evaluated false (14ms)
+258ms ║║Cancelling condition #9’s schedules…
+259ms ║║Condition group #9 evaluated false (state changed) (65ms)
+263ms ║╚Execution stage complete. (87ms)
+265ms ║Setting up scheduled job for Sun, Jan 27 2019 @ 4:58:00 PM CST (in 83505.682s)
+362ms ╚Event processed successfully (362ms)

#2

The only thing this piston could possibly know in advance is the sunrise and sunset times, so the schedule looks right to me. The lightning bolts in the left margin will also cause the piston to run thru the code from top to bottom when each of those events trigger.

#3

Hey there…
I know this is not what you are asking but I wanted to share something. I lived in an area with coyotes (with 2 dogs and 2 cats:)))) and I know the sutiation.

Smarthome concept is great but yet it’s on the very early stage of development and I personally would never trust a smart home (by itself) with very important stuff. When I first started i thought everything was going to be 100% perfect… Why shouldn’t it?? It’s Samsung behind it, It’s Amazon, it’s Google right?.. Wrong:)))
All those devices don’t really talk to each other all the time, sometimes never.

  • I have smart locks, but I would never put that on any form of automation.
  • Garage door, I have a zwave door opener but i would never add that to automation.
    so many things have to go RIGHT for us get expected results perfectly…

When i have signal issue and the light bulbs turn off late, who cares…
Or network is congested and sonos plays the wrong music… no big deal…
Or sometimes pistons execute but because of a mistake I made earlier, it messes things up.
Or new upgrade created unwanted results.
These are the situations that almost every user deals regularly.

So, with serious security stuff, (pet doors included) I would be triple careful…

EDIT : there are ofcourse workarounds, but it takes sometime to put them in practice.
For instance my front door locks it self IF left unlocked manually. But i realized later on that the lock is not actually sending any signal back to Webcore saying “ok ok i get it, i am locking…locking…and locked… thanks webcore I am good to go”
nope, webcore just send the command and turns around goes to other stuff LOL So many times I found the door unlocked for long periods of times.
So, NOW my piston waits about 15 seconds and asks the door (check status) are you locked or not??
If not locked, starts doing other stuff but I had to write all those (with help - without help)

I don’t mean to tell you what to do with your home, pls don’t get me wrong, I just wanted to share my thoughts as a fellow smarthome user…

#4

Good point, Ike.

Another thing to consider, if your dogs happen to be outside when the sun sets, they would be locked out of your house.

#5

When you say, “the schedule looks right”, does that mean you would expect this piston not to run for another 24 hours? That’s what I find confusing. Since some of conditionals could solve as TRUE regardless of the position of the sun, I don’t understand why webcore would delay running it again for a full day. For example, in the morning (before the 24 hours are up), when the sun rises, we’re home, and the outside gates are closed, I want the door to unlock. What am I missing?

Oh, and I love the corner case you guys pointed out about dog outside and then the sun sets. Mostly because it gives me an excuse to make the piston more complicated! :grin: Seems straightforward to add a condition that the doggie door has not moved in the last 10-15 mins (I have a sensor on the door flap that counts the number of times the dogs go out, so when my kids lie about it, presto, nailed.)

And, FWIW, I totally get the reliability issues. Points well taken. Trust me, I’m reminded of the poor reliability on a near daily basis. We use this as a convenience second-layer not a primary safety feature. Best thing for the coyote/fox problem has been Ring Neighborhood.

#6

I should start using pistons like that:))))) it gave me some ideas…:))))

I am glad it’s just a second-layer… Obvoiusly you know what you are doing…
When I see “User verification not started” sign, I assume that everyone is like me when I first started… :))))) :joy::joy::joy::cocktail::cocktail::cocktail:

#7

A schedule can only be made when webCoRE knows in advance something should happen. (like the predictable sunrise/sunset times). Things like doors opening or location changing, webCoRE has no clue if (or when) those events will happen.

If there is a lightning bolt in the left margin, those are events that webCoRE is subscribed to, or waiting for the event to happen. When it does, the piston will run top to bottom looking for true statements.

#8

My two cents:
Get your current ideas working well before ‘complexifying’ it, LOL
(It is much easier to troubleshoot when there is only one new element in play)

#9

I think I understand that in concept. What I don’t understand is why this particular piston would wait 24 hours to fire again (because, if it does, then it will miss critical events and actions).

Or maybe that’s my confusion, does the fact that a piston has a schedule with 23:59 on the clock mean that the piston won’t fire, even if an IF condition would otherwise be TRUE?

Sorry if I’m being dense.

#10

If you stood there opening and closing your door, your piston could fire a hundred times between now and the scheduled sunset

#11

Another way to look at it:

Many different events can trigger a piston, but only a small fraction of them will be “scheduled” in advance. (mostly time based)

#12

I’m sure if I’m being dense here, but…

I get what you’re saying in concept. What I don’t get is what it is specifically about this piston that would cause it to wait 24 hours. I had two theories:
(1) that it has something to do with “Time happens daily at Sunset”. But, because that’s part of an “or” statement, I would imagine the piston would run any in the event another OR clauses solves as TRUE; or,
(2) that it might have something to do with “Time is after sunrise and Time is before sunset”. But would that prevent the other Only When clause from executing?

And more importantly, I don’t understand how to change the piston to accomplish what I’m trying to accomplish. Help?

#13

Every single time a piston runs, it looks to see if any schedules need to be set in the future.

In your piston, there is only one event that is predictable.
Time happens daily at sunset <-- (on line 22)
There is absolutely nothing else that can be predicted, so the only schedule you’ll see is for the next sunset.

What you are overlooking is all the other lightning bolts in the left margin will also trigger the piston whenever those events happen.

#14

Actually, this is the behavior that I would expect. Yet it appears that the entirety of the piston goes to sleep for 24 hours because of that one “Time Happens At Sunset” condition. Which is definitely NOT the behavior I am looking for. If you can tolerate me more, let me ask two very specific questions:

  1. In the IF statement that includes “Time Happens At Sunset”, I would logically assume (dangerous, I know :grin:) that because the IF statement includes other conditions connected by an OR, Webcore would look to see if those other conditions are satisfied long before Sunset comes again. Is that not how Webcore works?

  2. Secondly, does the other “Only When” block (the one that fires only if the door flap is locked) also Wait for 24 hours per the piston schedule, or can it fire independent of the 24 hour wait period? I don’t want the second “Only When” block to go to sleep just because the first “Only When” block takes a little nap.

#15

A piston will only “go to sleep” if you decide to pause the piston

I am tied up the next 48 hours, so I will let someone else chime in for your other questions.

#16

Let’s try another way to describe the behavior: Anything with a lightning bolt will trigger as soon as that condition becomes true no matter what time of day. The only one of those it knows ahead of time is sunset. So, what you see as prescheduled is sunset. Everything else, it waits for whenever they become true and triggers immediately. It will not wait for sunset.

In the summary, you will notice there is a ‘next scheduled’ time to run but then also it will tell you how many events it is subscribed to which are additional opportunities to run. This is what @WCmore has been trying to explain.

The question for you is, are you seeing something different? Is this piston not firing when you expect it to? Don’t worry about what it says the schedule is, just tell us what it actually does.

#17

Thanks @guxdude. I was under the misperception that a preschedule meant that nothing in the piston would run until then. I now see why that was wrong, and now appreciate @WCmore’s earlier comments.

And yet, the piston still doesn’t work. I replaced the time-based logic (sunrise and sunset) with luminance logic that accomplished roughly the same thing (see below). The intention behind the piston seems simple:

  • When Door is Locked: IF X and Y and Z, then Unlock
  • When Door in Unlocked: IF X or Y or Z, then Lock

If didn’t unlock this morning at sunrise (despite the other conditions being TRUE). Then it unlocked midmorning when mode returned to HOME (I had been out for 10-15 mins). By 9pm this evening, I locked it manually because it didn’t lock automatically. I am clearly missing something basic. Could it be that I am using the “Only When…” improperly?

This seems really basic – why is it not working?

download
download.png1178×873 162 KB

#18

The combination of restrictions, triggers, and conditions could be causing issues. I suggest simplifying by moving the restrictions inside the trigger if statements. I.e.

If contacts open or mode changes or illuminance then
  If door is unlocked
    Lock
  Endif
Endif
If contacts stay closed and mode is home and illuminance then
  If door is locked
    Unlock
  Endif
Endif
#19

There’s no code for sunrise in this piston.

A few quick observations about lines 35-40:

temp
temp.jpg754×113 12.9 KB

Line 36 only happens once exactly one minute after the last door closes.

Line 40 is still quite dark. I would drop that line completely until you get all the rest of the logic tweaked.

temp

If the doors stay shut, and your location mode does not change, it might not lock.
(especially true if any lightbulb is visible from “Temperature Sensor 1”)

Again, not relying on lux at this point would be my recommendation.
It takes a few days studying the lux for your particular location for that line to be of any help.

#20

Couple of notes.
Lines that show a lightning bolt are places where the piston will trigger. There is no bolt on line 24 which means that changing light level won’t trigger the piston. If you change the comparison to “drops below” rather than “is”, that should create the trigger you are looking for.

The line 35 if block is only being triggered on contact staying closed for 60 seconds.
I’m not positive, but I think the “stays closed for 60 seconds” triggers the piston when the contact closes but pauses 60 seconds before running the rest of the code.

There is nothing triggering in this block based on arriving home or the light level rising. Same “drops below” advice as above.

You can’t have multiple triggers in an “and” block. The three will never trigger at the exact same time. I’d change that to an “or” block so any of the three will trigger the piston, but then enclose the locking code in another “if” block that checks that the value of all three are how you want them.