1) Give a description of the problem
Doesn’t seem to follow the logic that I’m trying to have it follow
2) What is the expected behavior?
based on light level, switches being off (harmony activities), time of day, motion and location mode it should be switching on accent lighting
3) What is happening/not happening?
never seems to trigger…?
4) Post a Green Snapshot of the piston
The issues appears to me that your first condition, to “turn on” does not have any triggers. You have all the right filters based on your description, but something has to actually trigger the piston to turn on.
Your turn off condition has the trigger covered (look at the red lighting bolt).
As @clsanchez77 mentioned, the ‘turn on’ part of your piston is missing a trigger. Click on the ‘with’ line and then the little ‘cog’ (gear) and change the “Task Execution Policy”, or TEP, to “Always Execute”. Then, after saving, you should see a lightning bolt - meaning it’s a trigger, on the left. See if that resolves your issue.
Aha! I’d never noticed the Trigger vs Conditions. Thanks for the education. I changed my first section to include Triggers vs conditions…
Pretty sure this should work… any other feedback?I don’t have color lights but I think the following still holds true… You shouldn’t need a ‘turn on’, followed by a ‘set level’ command. A “Set level” command will both turn the lights on and set the brightness level. Other than that, I think it looks OK to me.
This is correct, but I find that if you mix on/off devices with dimmer or color devices, then the Turn On statement is needed first and add no harm to the logic. I have many pistons where I have a mix of devices established in a single variable and greatly simplifies programming. The on/off devices ignore level and color statements, and dimmer devices ignore color statements without harm in issuing the statement unnecessarily. I’m sure resources are wasted but at the savings of not having redundant code. But otherwise, yes you would be correct based on my observations.
Still doesn’t seem to be triggering, which is really weird.
2/4/2018, 1:09:15 PM +282ms
+0ms ╔Received event [Mitchell Home].test = 1517767755281 with a delay of 0ms
+160ms ║RunTime Analysis CS > 17ms > PS > 64ms > PE > 79ms > CE
+162ms ║Runtime (44969 bytes) successfully initialized in 64ms (v0.2.102.20180116) (161ms)
+163ms ║╔Execution stage started
+176ms ║║Condition #8 evaluated false (7ms)
+178ms ║║Condition group #1 evaluated false (state did not change) (8ms)
+187ms ║║Condition #19 evaluated false (5ms)
+188ms ║║Condition group #14 evaluated false (state did not change) (7ms)
+190ms ║╚Execution stage complete. (27ms)
+191ms ╚Event processed successfully (191ms)
So I rebuilt the piston, somehow that corrected it. Was at a loss as to why the logic wasn’t being followed.
