Light color temp fade and level fade not executing together

#1

1) Give a description of the problem
My bathroom light is supposed to fade up color temperature and level, but only color temperature fade is executing.

2) What is the expected behaviour?
If the bathroom light has been off at least one minute (bathroom was vacant) and bathroom motion detects motion, the baseline humidity variable sets as the baseline bathroom humidity. If humidity rises above 10% of baseline (someone takes a shower), the light will fade up color temperature and level in 3 minutes.

Notes:

  • The “@Shower_Brighten_Last_Run” global variable functions to make sure that only the first shower of the day triggers the light adjustment.

  • The “@Bathroom_Shower_Brightened” variable is a global variable that another piston uses to determine how long lights should stay on with no motion. Don’t want to be in a long shower and have lights turn off.

  • Motion-dependent lights on/off is handled by another piston and uses the above global variables. I can post an image of that piston if folks think it might be causing problems.

3) What is happening/not happening?
Everything works as expected, but only the color temperature fades up. Level remains the same. At one time, I had each action listed together, and neither executed. When I broke them out seperately as in this script, the color temp works but not the level.

**4) Post a Green Snapshot of the piston

image
image.png1178×1086 123 KB

5) Attach logs after turning logging level to Full

7/10/2020, 9:03:03 AM +784ms
+2ms ╔Received event [Bathroom T/H].humidity = 85 with a delay of 181ms
+154ms ║RunTime Analysis CS > 21ms > PS > 79ms > PE > 54ms > CE
+156ms ║Runtime (44341 bytes) successfully initialized in 79ms (v0.3.10f.20190822) (154ms)
+157ms ║╔Execution stage started
+166ms ║║Comparison (enum) on is (string) on = true (1ms)
+167ms ║║Condition #87 evaluated true (7ms)
+168ms ║║Condition group #null evaluated true (state did not change) (8ms)
+176ms ║║Condition #83 evaluated false (6ms)
+177ms ║║Condition group #82 evaluated false (state did not change) (7ms)
+183ms ║║Comparison (dynamic) is_different_than (integer) 10 = true (2ms)
+184ms ║║Condition #165 evaluated true (5ms)
+185ms ║║Cancelling condition #1’s schedules…
+186ms ║║Condition group #1 evaluated true (state changed) (7ms)
+191ms ║║Calculating (decimal) 73.0 * (decimal) 1.1 >> (decimal) 80.30000000000001
+194ms ║║Comparison (integer) 85 rises_above (decimal) 80.30000000000001 = true (1ms)
+195ms ║║Cancelling condition #32’s schedules…
+196ms ║║Condition #32 evaluated true (9ms)
+203ms ║║Comparison (integer) 30 is_less_than (integer) 100 = true (1ms)
+205ms ║║Condition #4 evaluated true (8ms)
+211ms ║║Comparison (enum) on is (string) on = true (1ms)
+213ms ║║Condition #3 evaluated true (7ms)
+218ms ║║Comparison (integer) 2700 is_less_than (integer) 3300 = true (1ms)
+220ms ║║Condition #5 evaluated true (6ms)
+224ms ║║Comparison (string) :675146c749c8e4db65e77ab157337138: is_not_any_of (string) :caad9e6b791381bd3e120b2cf3958464:,:2f3b451d2866c5b1b88d8ec02497e63f: = true (2ms)
+225ms ║║Condition #155 evaluated true (5ms)
+226ms ║║Condition group #1 evaluated true (state did not change) (39ms)
+228ms ║║Cancelling statement #6’s schedules…
+250ms ║║Executed physical command [Bathroom Light 1].setColorTemperature([2700]) (13ms)
+286ms ║║Executed virtual command [Bathroom Light 1].fadeColorTemperature (50ms)
+288ms ║║Requesting a wake up for Fri, Jul 10 2020 @ 9:06:04 AM EDT (in 180.1s)
+299ms ║╚Execution stage complete. (142ms)
+308ms ║Setting up scheduled job for Fri, Jul 10 2020 @ 9:03:09 AM EDT (in 4.961s), with 37 more jobs pending
+315ms ╚Event processed successfully (315ms)

#2

Your log is too short… there are still 37 more jobs pending.

I would clear the logs, and run a fresh test… Allowing it to run at least 6.5 minutes.

#3

Longer logs would be more diagnostic, albeit tedious, but …

If the humidity continues to rise while the fades are in progress, wouldn’t the ‘rises above’ return false and cancel the scheduled tasks used by the fades?

I think the Task Cancellation Policy needs to be set to Never Cancel on the two actions containing the fades.

#4

True, but even that would have showed in the logs… (if they were long enough, LOL)

#5

Yes. The logs would certainly be diagnostic and the interesting bits would be near the top. Just as well, as if the fade appeared complete and there were 37 scheduled tasks they would get quite long.

#6

Ah yes, good point… Sometimes only a handful actually needs to be looked at. In this case, perhaps the initial trigger, and the final log (with error) might be enough.

Of course, you know that when I say “need”, I don’t really mean “need”.
(however, a good log is a useful tool that should be a part of learning how to troubleshoot a piston, so I do not regret mentioning that before the “obvious” answer)

#7

Yeah, sorry folks. I don’t really know how to run a test that allows for the fades to be triggered because of the humidity trigger and hub mode restrictions (can’t really run a real-world “test” shower when my daughter is napping in the afternoon or at night due to time of day hub mode restriction (only in the AM)). I’m still sort of a noob when it comes to diagnostics- maybe I’m missing something about how to run a test. My daughter is also a toddler so I’m a little time-strapped to dig through 37 scheduled events.

I’ve never messed with cancellation policy and I’ll try that out to see if it makes any difference- but why would the color temp fade execute to completion and not the light level? Wouldn’t the humidity increase cancel them both?

Thanks for your help with this everyone.

#8

In a nutshell, “Fades” are basically loops… Sending commands out every few seconds.

If another trigger comes in during that process, some conditions may be re-evaluated.
(although normally, a fade is non-stoppable)

I would try setting Task Cancellation Policy to Never on the WITH blocks (lines 43 and 48)

This should (hopefully) force it to keep on chugging along, even if the humidity changes during those 6 minutes.

#9

Just edited the TCP for both fade actions to “never cancel tasks” and “allow multiple schedules.” We’ll see if that does anything…

#10

Also, to make testing easier, you can temporarily set line 33 to a different number,
(ideally, one greater than current)