Piston Didnt Run until Test

#1

1) Give a description of the problem
I have a piston which didnt trigger, but when I went to look at the logs and hit test it triggered as it should. Logs show that the conditions evaluate as expected.

2) What is the expected behaviour?
Between Dec 1 and Dec 30th or Jan 1-10 and between 18:00 and 23:00 Christmas lights come on.

3) What is happening/not happening?
Triggers/subscriptions didnt take effect until the Test button was clicked

**4) Post a Green Snapshot of the piston!

h2raw
h2raw.png1178×795 37.1 KB

5) Attach logs after turning logging level to Full
02/12/2019, 18:55:09 +468ms
+0ms ╔Received event [Home].test = 1575334509467 with a delay of 0ms
+112ms ║RunTime Analysis CS > 27ms > PS > 64ms > PE > 21ms > CE
+115ms ║Runtime (43838 bytes) successfully initialized in 64ms (v0.3.110.20191009) (113ms)
+117ms ║╔Execution stage started
+132ms ║║Calculating (string) Dec 01 + (string) 2019 >> (string) Dec 01 2019
+136ms ║║Calculating (string) Dec 01 2019 + (string) >> (string) Dec 01 2019
+143ms ║║Calculating (string) Dec 31 + (string) 2019 >> (string) Dec 31 2019
+146ms ║║Calculating (string) Dec 31 2019 + (string) >> (string) Dec 31 2019
+153ms ║║Comparison (datetime) 1575334509593 is_between (string) Dec 01 2019 … (string) Dec 31 2019 = true (4ms)
+155ms ║║Condition #2 evaluated true (31ms)
+156ms ║║Condition group #1 evaluated true (state did not change) (33ms)
+159ms ║║Cancelling statement #6’s schedules…
+167ms ║║Executed virtual command setVariable (1ms)
+174ms ║║Comparison (boolean) true is (boolean) true = true (1ms)
+176ms ║║Condition #9 evaluated true (6ms)
+178ms ║║Condition group #8 evaluated true (state did not change) (7ms)
+187ms ║║Comparison (integer) 18 is_inside_of_range (integer) 18 … (integer) 23 = true (3ms)
+189ms ║║Condition #11 evaluated true (8ms)
+190ms ║║Condition group #10 evaluated true (state did not change) (10ms)
+193ms ║║Cancelling statement #14’s schedules…
+201ms ║║Skipped execution of physical command [Christmas Lights].on([]) because it would make no change to the device. (3ms)
+202ms ║║Executed [Christmas Lights].on (5ms)
+419ms ║║Skipped execution of physical command [Patio Lamps].on([]) because it would make no change to the device. (213ms)
+420ms ║║Executed [Patio Lamps].on (215ms)
+425ms ║╚Execution stage complete. (309ms)
+427ms ╚Event processed successfully (427ms)

#2

Currently, your piston will not trigger by itself unless your global variable @IsChristmas is acted upon somewhere else. Do you have another piston or routine that changes @IsChristmas?

#3

@Pantheon is correct, as seen by the single lightning bolt in the left margin.
That line is the only thing that actually fires up this piston.

Here is how I might achieve this:

pic

This checks the “day of year” every day in Jan & Dec, but only touches the light from Dec 1st to Jan 10th.
(the code above will even work accurately on leap years)

#4

@WCmore, you stole my thunder. I was waiting for his answer to my question before I posted what would have been nearly the exact same pseuo-code. :smile:

#5

Sorry about that… I didn’t mean to step on your toes…

#6

I think I know this answer, but why the 1 second Wait?

#7

It might not be needed, but I often add a tiny wait before calculating on a variable that I just set.
(just in case there was a tiny delay or hiccup)

To me, reliability is always more important than speed…

#8

:+1:

#9

Hi guys thanks for the prompt reply.

In answer to your question, bIsChristmas is only read by another piston, it’s not set anywhere else than here.

Is there a guide that defines where how subscriptions latch onto events as it’s something I’ve never has completely clear. All my other pistons work as I’ve always expected them to though!

#10

Anything subscribed to, will have a lightning bolt in the left margin.

For example:

ϟ IF Switch changes to on  <-- Trigger
      Then do stuff
  END IF

The part to keep in mind though is, the piston will fire & run top to bottom when the switch changes to on OR off. Of course, if the switch is off, then that block will return ‘false’, so it will be skipped… but the rest of the code will continue…

For example:

execute
   ϟ IF Switch changes to on  <-- Trigger
         Then do stuff
     END IF
     Drain the pool  <-- Outside the IF block
end execute

In this case, turning the switch ON or OFF will both drain the pool… but the ‘stuff’ only happens when the switch changes to ON.

#11

By the way, one of the reasons why this is not treated as a trigger:

pic

is because math is only calculated once the piston is already running…

#12

To explain your piston a little…and @WCmore may be able to explain this better…

Your piston has only one trigger…
h2raw%20edit

The ONLY time your trigger is going to fire is when @IsChristmas’s value is changed. And when that happens, your piston will run from top to bottom, every time.

When you pushed the TEST button, it forced your piston to run from the top. That set your variable @IsChristmas to true and thus executed the “Turn on.” Otherwise, your trigger will never fire your piston unless that global variable is acted upon externally.

#13

Well put.

#14

This might help you : https://community.webcore.co/t/conditions-and-triggers-the-difference/164

For what it is worth, many of us here still struggle with the difference. :slight_smile:

#15

Thanks to all who contributed here! This is great and will hopefully help others too. I will refactor the piston and share back here shortly.

#16

Heres what I ended up with.

3j2o
3j2o.png1178×1093 114 KB

#17

Lookin’ good!! :+1:

#18

I see you’re one of “those people” who keep your lights up all year. :stuck_out_tongue:

#19

Haha, I certainly am not! The peanut plug which powers up the outdoor light sockets on the front of the house is left in place though as it’s a strategically placed ZigBee repeater for the devices at the front of the property.

No I’m the smart ass who put small hooks in and painted them white on my 2nd Xmas there. I wasn’t clipping lights up ever again. I can get them up and down in about an hour now