Emulated Fade Color Temperature action not working

fixed
#1

I built a piston that updates the white color temperature of a tunable white LED bulb based on the current ambient light levels outside as measured by a NodeMCU ESP8266 device hooked up to an Adafruit color sensor.

It works just fine if I use the ‘Set Color Temperature’ task but it’s very abrupt as there is no fade. I noticed the task called “Fade Color Temperature…” but it just doesn’t work at all unfortunately.

Here is the logs, first for the Fade Color Temperature (which does not do anything), and then using Set Color Temperature which works fine:

Fade Color Temperature event log:

+1ms	╔Received event [NodeMCU1 (colorTemperature1)].colorTemperature = 3201 with a delay of 413ms
+184ms	║RunTime Analysis CS > 22ms > PS > 46ms > PE > 117ms > CE
+195ms	║Runtime (37109 bytes) successfully initialized in 46ms (v0.2.0e5.20170812) (193ms)
+196ms	║╔Execution stage started
+213ms	║║Comparison (integer) 3201 changes = true (1ms)
+215ms	║║Condition #12 evaluated true (8ms)
+217ms	║║Condition group #1 evaluated true (state did not change) (10ms)
+223ms	║║Evaluating switch with values [[i::32d37b8cba6f053831867ae6061de516::colorTemperature, v:[t:integer, v:3201, d::32d37b8cba6f053831867ae6061de516:, a:colorTemperature, i:null, x:false, vt:string]]]
+231ms	║║Comparison (integer) 3201 is_inside_of_range (integer) 1 .. (integer) 2699 = false (4ms)
+239ms	║║Comparison (integer) 3201 is_inside_of_range (integer) 2700 .. (integer) 6000 = true (4ms)
+243ms	║║Cancelling statement #8's schedules...
+299ms	║║Executed physical command [null].setColorTemperature([100]) (28ms)
+300ms	║║Executed virtual command [SYLVANIA Smart RT5/6 Tunable White].fadeColorTemperature (40ms)
+305ms	║╚Execution stage complete. (109ms)
+316ms	╚Event processed successfully (316ms)

Set Color Temperature event log:

+2ms	╔Received event [NodeMCU1 (colorTemperature1)].colorTemperature = 4052 with a delay of 131ms
+242ms	║RunTime Analysis CS > 25ms > PS > 56ms > PE > 161ms > CE
+253ms	║Runtime (36509 bytes) successfully initialized in 56ms (v0.2.0e5.20170812) (249ms)
+254ms	║╔Execution stage started
+273ms	║║Comparison (integer) 4052 changes = true (1ms)
+276ms	║║Condition #12 evaluated true (9ms)
+277ms	║║Condition group #1 evaluated true (state did not change) (12ms)
+284ms	║║Evaluating switch with values [[i::32d37b8cba6f053831867ae6061de516::colorTemperature, v:[t:integer, v:4052, d::32d37b8cba6f053831867ae6061de516:, a:colorTemperature, i:null, x:false, vt:string]]]
+293ms	║║Comparison (integer) 4052 is_inside_of_range (integer) 1 .. (integer) 2699 = false (4ms)
+302ms	║║Comparison (integer) 4052 is_inside_of_range (integer) 2700 .. (integer) 6000 = true (3ms)
+306ms	║║Cancelling statement #8's schedules...
+805ms	║║Executed physical command [null].setColorTemperature([4052]) (489ms)
+806ms	║║Executed [SYLVANIA Smart RT5/6 Tunable White].setColorTemperature (491ms)
+812ms	║╚Execution stage complete. (559ms)
+823ms	╚Event processed successfully (823ms)
#2

@ady624 just wanted to check in about this

#3

Anyone around to help with this? @webCoRE_Minions ?

The problem I see from the logs is that no matter what the code says, it’s always trying to set the color temperature to 100 which is a non-sensical value.

Executed physical command [null].setColorTemperature([100])

#4

This looks like it could be a copy-paste error in the implementation of fadeColorTemperature. When fading level, infrared level, hue, saturation, and color temperature all of the start and end values are pinned within the range 0 to 100. This can be patched in webcore-piston.groovy, it looks like the range should be 1000 to 30000 as used in vcmd_adjustColorTemperature.

#5

I posted a code fix for this earlier today. You’re welcome to save and publish the same edit in your SmartThings Developer copy of the webCoRE Piston smart app until @ady624 gets a chance to review and publish the fix. Lines 2564 and 2565 were edited to use 1000 rather than 0 for the minimum and 30000 rather than 100 for the maximum as shown:

-    startLevel = (startLevel < 0) ? 0 : ((startLevel > 100) ? 100 : startLevel)
-    endLevel = (endLevel < 0) ? 0 : ((endLevel > 100) ? 100 : endLevel)
+    startLevel = (startLevel < 1000) ? 1000 : ((startLevel > 30000) ? 30000 : startLevel)
+    endLevel = (endLevel < 1000) ? 1000 : ((endLevel > 30000) ? 30000 : endLevel)
#6

I’ll put that in, but I won’t do the pull request, it’s complicated, easier for me to update my code in ST and then publish next time. Thank you for doing the investigative work and figuring out the fix :smiley:

I’ve republished the piston code with the new changes, same version, just update.

#7

Great, thanks! I just like to keep the pull requests in my local clone. @freakintoddles it looks like this should fix the problem for you once you update to the latest webCoRE version.

#8

Great! Thank you for finding/fixing this issue!