Why didn't my lights come on?

#1

1) Give a description of the problem
The real problem is that even after reading the ‘Conditions & Triggers’ thread, I still don’t understand how they work. Why don’t pistons continuously look at conditions and act upon them once they become true?

2) What is the expected behavior?
The lights should have come on once I was home, even if I came home after the beginning of the condition range.

3) What is happening/not happening?
According to the log, it executed at sunset-15, saw that no one was home so it did nothing. The problem is that it scheduled the next execution for 11PM, so while I came home shortly after this executed, the lights did not come on. Why doesn’t the condition still apply? Do I have to use the condition in a While-Do loop with the presence condition nested inside? I don’t want to change the presence condition to a trigger (presence change) because if I get home just before the time range I still want them to come on.

4) Post a Green Snapshot of the pistonimage

download
download.png1178×720 64.5 KB
download
download.png1178×720 64.5 KB

5) Attach any logs (From ST IDE and by turning logging level to Full)
12/8/2017, 5:07:59 PM +73ms
+2ms
╔Received event [Home].time = 1512774480000 with a delay of -928ms
+95ms
║RunTime Analysis CS > 29ms > PS > 46ms > PE > 21ms > CE
+109ms
║Runtime (37797 bytes) successfully initialized in 46ms (v0.2.0ff.20171129) (106ms)
+110ms
║╔Execution stage started
+165ms
║║Comparison (time) 61679191 is_between (time) 1512775380000 … (time) 82800000 = true (23ms)
+166ms
║║Time restriction check passed
+168ms
║║Cancelling condition #10’s schedules…
+169ms
║║Condition #10 evaluated true (51ms)
+186ms
║║Cancelling statement #10’s schedules…
+199ms
║║Requesting time schedule wake up at Fri, Dec 8 2017 @ 11:00:00 PM CST
+215ms
║║Comparison (enum) not present is (string) present = false (3ms)
+217ms
║║Comparison (enum) not present is (string) present = false (1ms)
+219ms
║║Cancelling condition #11’s schedules…
+220ms
║║Condition #11 evaluated false (18ms)
+221ms
║║Condition group #1 evaluated false (state did not change) (104ms)
+223ms
║║Cancelling statement #2’s schedules…
+231ms
║║Skipped execution of physical command [Kitchen].off([]) because it would make no change to the device. (4ms)
+232ms
║║Executed [Kitchen].off (4ms)
+237ms
║║Skipped execution of physical command [Upstairs].off([]) because it would make no change to the device. (2ms)
+238ms
║║Executed [Upstairs].off (4ms)
+241ms
║╚Execution stage complete. (132ms)
+243ms
║Setting up scheduled job for Fri, Dec 8 2017 @ 11:00:00 PM CST (in 21120.685s)
+260ms
╚Event processed successfully (261ms)`

#2

I am home now and this didn’t work either. “Last executed: never - Next scheduled: 12/8/2017, 11:00:00 PM”

download
download.png1178×547 51.3 KB

#3

See the orange lightning bolt in the gutter next to your conditions? This means that the piston is subscribed to that device/attribute. It is watching the presence sensors presence and not present.

It looks like you forced a subscription to the time. I am guessing you have tried it without this forced subscription?

Is your goal to have the lights come on at -15 sunset but only if you are home?
And
If you weren’t home at -15 sunset then to turn on when you do arrive home?

#4

Yes, that is the goal. The way you phrased it makes me think I need separate pistons, this one which should work if I’m already home at -15 sunset and another that watches for the presence change event(s).

And yes, I forced subscription after I was already home after -15 sunset and the lights didn’t come on. I edited the piston and saved it before I posted the screenshot to the forum. Is there a good definition of “subscription” somewhere in the wiki? I see that term used a lot and I think I understand it in context, but I’m not 100% on it.

#5

One piston will work.

Time happens daily at -15 sunset
Then
If presence is present
Then
Turn lights on
End if
End time
If presence changes to present
And
Time is between -15 sunset and 11 pm
Then
Turn lights on
End if

Subscription basically means that webcore will pay attention to all events for that device:attribute. So if you subscribe to a contact sensors:contact then it watches for both open and close events. Even if your condition only checks if something is closed.

#6

I see, I see. -15 sunset is a one-time event that should make something happen, as is the presence change. I don’t have to try to make it monitor all times between when I want it on and off. I should have seen that when I was thinking of two separate pistons.

I’ll save my followup questions on subscription for another thread, if needed.
Thanks.