not only that it looks like any change of the lux causes the timer to reset and re-evaluate so if you got a wait timer for lets 2 minutes, after 1 minute there is a lux change it resets the wait timer for 2 minutes … with a static switch there is less chance for this to happen …
Then you need to use triggers…
Or use a simple piston with condition groups that have individual actions and OR those group to the moon and back 
exactly - but then the trigger looks like lux <= 25 - it goes to 25 and triggers … but then at 24 it should re-trigger at least from what I have seen … enlighten me … but to be honest this works …
The trigger will only be true oh c**p… you can’t, it will still go into Else…
Do this:
IF
(
Time is between blah blah
AND
whatever else conditions
) >>> when true { turn light on }
OR
(
Time is not between blah blah
OR
whatever conditions
) >>> when true { wait 5, turn off }
OR
(
Lux is over 40
) >>> when true { wait 3, turn off}
THEN [nothing]
ELSE [nothing]No, not yet, but I’m showing the individual actions in the main piston page
but wont this re-trigger if lux is 44 at one second and 42 at the next - the rule gets the input, evaluates, result is true and it should set the wait timer for 3 minutes … unless I misunderstood something - thats exactly the issue that I had … when I however had a static lux it worked just like that … thats what I mean …
Remember when I said use lux > 40 ? This was the exact reason… you set the timer to turn off when lux goes over 40, give it some slack room - you turn it on below 25, you turn it off over 40. You are uncertain in the 25-40 range so you won’t do anything. The IF actions you have control over, but the ELSE executes without you approving it. Use individual actions, this way you ensure that you have full control over execution of actions. You, after all, put the conditions in the IF
gotcha … basically the same what I do with the switch now …
v0.0.038.20160520 - Alpha test version - Displaying individual actions (when true) in the main piston page and showing action restrictions as per https://github.com/ady624/CoRE/issues/7
@Jonpho, for Wait to do something, you need to have tasks added after it. Each action can do a million tasks, you chain them up like Christmas lights All actions in a group start up at the same time: NOW. As they progress through tasks, if a task says WAIT, it adds a delay that it then applies to the following tasks. You added two different actions, one waits, the other one turns the light off. Move the Turn Off from the second action as a second task of the first action, so that you have:
ELSE
With Master Bedroom Light...
> Wait 5 minutes
> Turn off
Then it will wait…
dont worry, just realised what i’d done…hence deleted post
You answered this in an earlier post for me with a similar query…sorry to be so daft!
1 Like
That’s okay, we’re learning
1 Like
Glad you’re patient 
Seeing bug in latest version… here is what I’m doing and seeing:
Simple piston
Condition 1 - date & time, time between, select sunrise as first time, select custom time as second time.
When I select custom time I get put into a screen that shows “Condition #1” with no options to select.
If I select “done” I get an error about contacting the app developer
If I select the back arrow I get to the main condition group screen that shows
Condition #1: Time is between sunrise and null
I tried this several times and I get the same result. I’m running on an iPhone… latest version of IOS.
1 Like
agree, happens with me too
1 Like
Can’t help you, mine works just fine. Because I just fixed it in v0.0.039.20160520 - Alpha test version - Fixed an error where an incomplete (during building) time condition would fail due to next event calculation introduced in v0.0.036.20160520 ha ha ha
1 Like
fixed it. thanks again.
1 Like
v0.0.03a.20160520 - Alpha test version - Color support. Added all 140 standard CSS colors, plus 4 white light colors. Partially tested with Osram (Green is green and Crimson is crimson)
Word of advice: If you’ve been using color and it worked, you’ll need to revisit that task and redo the color. Added an extra parameter, color name. You can pick color by name, or you can enter the RGB code or you can enter the HSL trio. I haven’t had the chance to test it yet, but I have a feeling the ST documentation wrongly calls the L level under the Color Control capability. That is supposed to be Lightness. @Jim?
Forgot to mention one minor thing: random. Random color. Bottom of the list…
1 Like