Ghosts in the Machine?

[Morpheos]

1) Give a description of the problem
I have created a very simple piston to create two different lighting schemes with a Samsung button. As I’ve played with it, it always seems to trigger up to 3 different light changes during one execution using values that I may have previously used in a previous iteration of the piston. I have made sure I don’t have anything in the Smartthings app assigned to the button (I did very early on use the app to trigger a scene but have since deleted that behavior, and also the scene just to be safe) however it does appear to be landing on the settings that were in that scene. I can’t help feeling I’m missing some basic step as a few pistons I’ve been playing with lately seems to be exhibiting this simultaneous execution of multiple conflicting instructions and saving piston changes doesn’t always seem to take.

2) What is the expected behaviour?
I expect one execution of the light change.

3) What is happening/not happening?
Logs show one of the lights being changed 6 times! (based on level entries) in one execution and not landing on the current settings in the piston. Visually it lands on my current color / level settings briefly, then it changes to another color (salmon as in the piston, but then to blue, a color I was using previously). Judging by all the different level settings, they all look like older versions of the piston I was experimenting with, it’s as if every previous version of the piston i’ve saved is running at once. I have also tried rebooting the hub, just in case.

**4) Post a Green Snapshot of the piston![image|45x37]

5) Attach logs after turning logging level to Full
12/24/2020, 7:21:23 AM +207ms
+1ms ╔Received event [Office Master Button].button = pushed with a delay of 69ms
+56ms ║RunTime Analysis CS > 18ms > PS > 6ms > PE > 33ms > CE
+58ms ║Runtime (40547 bytes) successfully initialized in 6ms (v0.3.110.20191009) (56ms)
+59ms ║╔Execution stage started
+66ms ║║Comparison (enum) pushed gets (string) pushed = true (0ms)
+68ms ║║Cancelling condition #2’s schedules…
+69ms ║║Condition #2 evaluated true (5ms)
+70ms ║║Cancelling condition #1’s schedules…
+71ms ║║Condition group #1 evaluated true (state changed) (7ms)
+73ms ║║Cancelling statement #5’s schedules…
+84ms ║║Executed physical command [Desk Light].setLevel([100]) (6ms)
+85ms ║║Executed [Desk Light].setLevel (7ms)
+93ms ║║Executed physical command [Desk Light].setColor([[hex: #FFA07A, hue:5, saturation:100, level:74]]) (6ms)
+94ms ║║Executed [Desk Light].setColor (8ms)
+96ms ║║Cancelling statement #8’s schedules…
+107ms ║║Executed physical command [Office Cabinet].setLevel([100]) (5ms)
+108ms ║║Executed [Office Cabinet].setLevel (7ms)
+114ms ║║Executed physical command [Office Cabinet].setColor([[hex: #0000FF, hue:67, saturation:100, level:50]]) (3ms)
+114ms ║║Executed [Office Cabinet].setColor (5ms)
+117ms ║║Cancelling statement #11’s schedules…
+127ms ║║Executed physical command [Office Lamp].setColorTemperature([2800]) (6ms)
+128ms ║║Executed [Office Lamp].setColorTemperature (7ms)
+134ms ║║Executed physical command [Office Lamp].setLevel([100]) (3ms)
+135ms ║║Executed [Office Lamp].setLevel (5ms)
+137ms ║║Cancelling statement #14’s schedules…
+903ms ║║Executed physical command [PC].on() (763ms)
+904ms ║║Executed [PC].on (765ms)
+907ms ║║Cancelling statement #3’s schedules…
+955ms ║║Executed physical command [Office Celing Light].setLevel([15]) (44ms)
+956ms ║║Executed [Office Celing Light].setLevel (44ms)
+961ms ║║Comparison (enum) pushed gets (string) held = false (0ms)
+963ms ║║Condition #17 evaluated false (4ms)
+964ms ║║Condition group #16 evaluated false (state did not change) (5ms)
+966ms ║╚Execution stage complete. (906ms)
+967ms ╚Event processed successfully (966ms)

[orangebucket]

The logs show that the Desk Light is set to a level of 100% but setting the colour sets hue, saturation and level, which is how the level changes. I’ll defer to those that understand lights for that.

What they don’t show is the piston being responsible for another colour change two seconds later. So there has to be down to something else.

I do note that turning the ‘PC’ on creates the best part of a second delay before the Office Ceiling Light is then set to 100%. Could either of those activities trigger another automation somewhere?

[Morpheos]

OK, the plot thickens, since I realized many of the levels it was flipping between were old scenes I had tried, I paused the piston altogether and the button was still triggering old scenes so I deleted the button and re-added as a new device and now the scene goes to the right color but it’s toggling the level of the lights twice. I currently have the level set to 100, and it sets the level to 100, then to 40 every time I execute. Nowhere in my piston do I have it setting this light to 40%. I only have one other piston that affects these lights and I paused that one to be certain as well.

[Morpheos]

No, there aren’t any other pistons running on these lights. There is one other piston that turns these lights on when I turn on the Office Ceiling Light but I have disabled that one and there is no change in behavior of this piston.

[Morpheos]

OK, I think I solved the remaining mystery and sharing in case others run into this issue. These are Philips Hue bulbs and it appears that by setting a color, Philips also changes the level to some unknown value. By reversing the set color and set level so the level was last, I ended up with the right level.