Outdoor Lighting Execution Problem

#1

1) Give a description of the problem
Piston executes when tested, but not on real-world conditions (time of day and weather). Sub-triggers (doors opening) only partially execute as intended (light level increases, but does not revert back after designated 15 minute “wait” time- no evidence of countdown timer set in the dashboard. I have a feeling I’m not properly understanding else vs. else if vs. separate “if” statements. My coding has always been sloppy and amateur, but have always been able to figure it out. I tried several structures of this. Can someone tell me what I’m doing wrong?

2) What is the expected behaviour?
Only when my holiday lighting virtual switch is off, My porch, side entrance and deck lights come on to 50%, 2700k when it is between an hour to sunset and an hour past sunrise OR weather conditions are poor. When any of the above conditions are in effect and my front, side entrance or deck doors are open, their corresponding lights increase to 100% for 15 minutes then revert back to 50%. I’d also like to incorporate the same “level increase” behavior for arrival of presence sensors, but it’s not in the code yet.

3) What is happening/not happening?
Whenever I test the piston, the lights will come on or off as coded based on time of day or weather conditions. However, they will not turn on or off by themselves in the same way without manual testing (you can see this in the log below, when lights had been on overnight and the piston was tested in daylight, clear weather) . In other words, they don’t come on before sunset or after sunrise. When doors are open during the specified conditions, level raises as coded (100%); when closed, I can’t remember if they stay 50% or revert back to 100%, but I never see any 15 minute countdown in the dashboard as coded.

4) Post a Green Snapshot of the pistonimage

image
image.png1178×2191 222 KB

5) Attach logs after turning logging level to Full
11/1/2019, 10:14:16 AM +704ms
+1ms ╔Received event [Home(1)].test = 1572617656701 with a delay of 2ms
+246ms ║RunTime Analysis CS > 27ms > PS > 61ms > PE > 158ms > CE
+250ms ║Runtime (49797 bytes) successfully initialized in 61ms (v0.3.10f.20190822) (247ms)
+251ms ║╔Execution stage started
+268ms ║║Comparison (enum) off is (string) off = true (3ms)
+271ms ║║Condition #1 evaluated true (14ms)
+273ms ║║Condition group #null evaluated true (state did not change) (17ms)
+345ms ║║Comparison (time) 36856984 is_between (time) 1572646800000 … (time) 1572608220000 = false (20ms)
+348ms ║║Condition #26 evaluated false (69ms)
+632ms ║║Comparison (dynamic) Sunny is_any_of (string) Cloudy, Rain, Cloudy/Wind, Fog, Heavy Rain, Light Rain, Cloudy, Rain Shower, Rain/Thunder, Rain/Wind, Showers Near, Shower/Wind = false (11ms)
+635ms ║║Condition #27 evaluated false (284ms)
+637ms ║║Condition group #25 evaluated false (state did not change) (357ms)
+638ms ║║Condition group #2 evaluated false (state did not change) (361ms)
+659ms ║║Comparison (time) 36857346 is_not_between (time) 1572646800000 … (time) 1572608220000 = true (13ms)
+661ms ║║Time restriction check passed
+663ms ║║Condition #29 evaluated true (21ms)
+677ms ║║Comparison (dynamic) Sunny is_not_any_of (string) Cloudy, Rain, Cloudy/Wind, Fog, Heavy Rain, Light Rain, Cloudy, Rain Shower, Rain/Thunder, Rain/Wind, Showers Near, Shower/Wind = true (9ms)
+679ms ║║Condition #30 evaluated true (15ms)
+681ms ║║Condition group #28 evaluated true (state did not change) (40ms)
+683ms ║║Condition group #5 evaluated true (state did not change) (42ms)
+686ms ║║Cancelling statement #7’s schedules…
+707ms ║║Executed physical command [Deck Light].off() (12ms)
+709ms ║║Executed [Deck Light].off (15ms)
+726ms ║║Executed physical command [Porch Light 1].off() (12ms)
+728ms ║║Executed [Porch Light 1].off (15ms)
+745ms ║║Executed physical command [Porch Light 2].off() (12ms)
+746ms ║║Executed [Porch Light 2].off (15ms)
+765ms ║║Executed physical command [Side Light].off() (13ms)
+767ms ║║Executed [Side Light].off (16ms)
+782ms ║║Condition #17 evaluated false (10ms)
+785ms ║║Condition group #16 evaluated false (state did not change) (12ms)
+797ms ║║Condition #19 evaluated false (8ms)
+798ms ║║Condition group #18 evaluated false (state did not change) (10ms)
+825ms ║║Comparison (time) 36857508 is_between (time) 1572646800000 … (time) 1572608220000 = false (16ms)
+828ms ║║Condition #40 evaluated false (25ms)
+830ms ║║Condition group #33 evaluated false (state did not change) (27ms)
+857ms ║║Comparison (time) 36857540 is_between (time) 1572646800000 … (time) 1572608220000 = false (17ms)
+860ms ║║Condition #50 evaluated false (24ms)
+862ms ║║Condition group #43 evaluated false (state did not change) (26ms)
+868ms ║╚Execution stage complete. (617ms)
+870ms ╚Event processed successfully (869ms)

REMOVE BELOW AFTER READING
If a solution is found for your question then please mark the post as the solution.

#2

Can anyone help?

#3

WebCoRE is an “Event-driven” system… Normally, we add triggers to our pistons, and each time that device’s attribute changes, the entire piston runs top to bottom, and executes anything not blocked by conditions.

In your case, notice the six lightning bolts in the left margin. When any of those devices changes, the piston will execute, starting from the top.

Currently, there is no trigger for sunrise or sunset, so this piston will never run at those times. (unless the door happens to open or close then)

Another food for thought… With so many triggers in this piston, and each has a different WAIT period… It is really asking for trouble… What if one door is currently in a WAIT period, and then another door is opened?!? It starts the code all over from the very top.

Whenever possible, I only use one (or less) trigger per piston. This gives you much more options and control of the path.

To clarify:

  • My goal is never to put everything into one piston for my visual benefit…
  • My goal is always to code efficiently so the SmartHome has the smallest amount of code to process at each trigger.

In your case, if Sensor 1 was the trigger, then there’s no need to process Sensor 2 and Sensor 4’s logic…

Personally, I would make one piston per Contact Sensor. This lets you grow & expand that sensor over time much easier. (times of day, who is home, outside weather, etc)

I would also recommend a new piston for Sunrise… and another piston for Sunset. These two pistons will also grow complex and evolve over time, and will have much less issues if kept separate…

Pro Tip

Once each sensor is in it’s own piston, here is a solid structure that works well:

IF Sensor's contact changes to open          <-- Trigger
Then
    IF Time is between X & Y                 <-- Condition
    Then
        Set level to 100%
    END IF
END IF

IF Sensor's contact stays closed for 15 min  <-- Trigger
Then
    IF Time is between X & Y                 <-- Condition
    Then
        Set level to 50%
    END IF
END IF

This method uses no ELSE blocks, and does not need a WAIT… The second IF will restart the timer anytime the door’s contact changes.

#4

Thanks. I’m pretty sure I understand that and will try it out and update. I think I was trying to be efficient for “me” by making one piston that controls “outside lights,” rather than thinking what is most simple and convenient for the controller.