[Release] Holiday Lighting

[mluck]

Question for any other fan-users of this app...

We use Holiday Lighting (HL) with a bunch of RGB bulbs in our foyer. Works great! Also, long before HL existed, we created a simple rule in RM to turn lights on (white) at dusk and off when we go to bed, based on mode. It also works fine. The complicating factor, however, is that the non-holiday lighting just applies to a chandelier, whereas HL controls 8 -10 additional bulbs, including 3 LED strips.

You probably already figured out where this is going. The rule for non-holidays and HL don't know about each other, so there's no way for them to "take turns", which leads to unintended behavior.
And HL's "non-holiday illumination" feature assumes (I think?) that the same devices are being controlled whether it's a holiday or not.

I just put in a workaround to have HL activate one minute after RM does. Effectively, the chandelier turns on white, and then 60 seconds later the holiday fun begins. Not elegant, but I think it should work.

Wondering it anyone has any better ideas? Speaking of which:

@mbishop

If you want to do something more complex, designate a switch as your trigger; illumination mode will follow that switch's on/off.

Could this be my answer?

Or this?

[mbishop]

Do I count as a fan-user? Well, anyway, I have three thoughts that vary in complexity and how close they'll come to what you want.

The app does assume that all the RGB lights you selected plus any additional ones you've configured are intended to be used for illumination. There's no provision for leaving some out.

The first option I can think of is actually here:

Create a virtual switch, set it to be turned on whenever holiday lights are active (i.e. when HL expects to be sending colors to your bulbs on a semi-frequent basis), and then use that in your RM rule to bail out. If it's a holiday, the rule will leave the light alone; when the switch turns off, decide whether to turn it on for normal light.

Setting an idle illumination behavior (your second idea) might work, with the obvious caveat that it will be turning on all/most of the other lights you're using for holiday display at the same time. If you set the mode to CT, it will ignore any RGB-only bulbs, but otherwise will be turning everything on or off together. I don't currently have a mechanism for excluding the RGB bulbs from illumination mode, and it seems difficult to add one.

Third option: I've got a branch where I've been exploring making the "extra" illumination switches (things to be turned on in illumination mode) treated more on par with the selected RGB devices -- if they're RGB or CT, they get included with the selected mode; if they're dimmers, they get the level being used for RGB/CT; if they're switches, they just turn on as current. It should be relatively straightforward to extend the same change to the selector above, so that lights there are used for holidays and not illumination.

What you'd lose in that path is ordering. The RGB selection is a bit clunky because that selection preserves the order, which can matter for sequential. If I also pull in all the "other" switches, there are no ordering guarantees for them. Maybe that doesn't matter for you, in which case, you could just move all the lights you only want for holidays there.

That said, the drawback to any of these is that off() commands will get sent to any light HL thinks "belongs" to it when it changes modes. Your RM rule might just need to catch the light turning off and turn it back on if it's still supposed to be on. It's a bit opinionated that way; sorry.

[nclark]

Finally got around installing Holiday Lighting, got the preconfigured USA holidays and deleted anything non Canadian related.

Everything looks good, but wanted to edit the colors, but when I go to that page, I was getting a blank page with an ok button, that's it.

Checked the logs and found this error...

I installed the latest package from HPM this morning (December 20th).

[mbishop]

Hm, I'm not able to repro that on either of my hubs. All holidays? Just a particular holiday? Is there anything around that in the logs from this app that might indicate at what point it failed? (Turning on debug logging might help with that.)

[nclark]

Yes this is happening on every holidays including trying to create a new one.

Turned on debug, here are the logs from opening the app until I get to the blank page...

next logs are when I click on ok from that blank page.

I'll try to do a repair in HPM just in case something went wrong on the install.

UPDATE: Repair in HPM had no effect and I'm still having the same problem.

[mbishop]

The fact that it's not giving a line number makes me unsure it's an error thrown by my code, but it's rendering the debug statement at the start of the function and nothing else, so it's obviously getting into my code before it blows up.

Searching the forums, there are sporadic other instances of this exception that didn't refer to a line number; one resulted in a suggestion to reboot the hub. Might be worth a shot? Others seem similarly inconclusive.

If a reboot doesn't sort it, I'd try totally removing and re-adding the app.

[nclark]

ok did a reboot and this is what I'm getting now.

And the logs show this error...

[mbishop]

Ah, that's an error I can do something with, and a line that's been touched semi-recently. Got a repro -- the help text generation breaks with a frequency that's less than one minute. For the moment, change your setting on the previous page to more than 1 minute; I should have a fix pushed shortly.

So much for adding help text being an innocuous change.

Edit: Fix is published, so HPM update should find it.

[nclark]

@mbishop

For the moment, change your setting on the previous page to more than 1 minute

That was it. Thanks!

I was on track looking at the code. I see that when selecting seconds, the "FREQ_OPTIONS" (in the library file) uses fractions of minutes instead of seconds which threw the error I was getting when assigning it to an INT variable.

You know your code better, so of course you would find first

[mluck]

@mbishop

Do I count as a fan-user?

Absolutely not. The regulations in Chapter VI, Paragraph 5, Subsection 2(e) clearly stipulate that a developer cannot be a fan of his/her own work. Sorry man, you'll have to drool over something else.

@mbishop

I have three thoughts that vary in complexity and how close they'll come to what you want.

Kidding aside, thank you so much for the really thoughtful reply. All of these would work better than the workaround I tried. I just implemented the first of your 3 scenarios. Think it's gonna go great tonight and into the future. And it took about one minute to implement the change.

My foyer is a joyful green and red right now, thanks to you. WAF is very high indeed. (Why is always the little things?)

[nclark]

Could you add a button to stop info logging as well as the debug one. I had a tsunami in my logs yesterday night

[mbishop]

I don't see any logging at the info level. There's a lot of debug (yes, a LOT) and the occasional warn or error.

[nclark]

@mbishop

I don't see any logging at the info level

Sorry about that, I saw a flood of logs on the color light bulbs and now just realized after your comment that it's actually one of my bulbs that had info logging turned on. Sorry for that and assuming it was the app

[mbishop]

@mluck

My foyer is a joyful green and red right now, thanks to you. WAF is very high indeed. (Why is always the little things?)

Warms my heart. I'm glad it's working well for you.

Colored lights on the porch for holidays? Automatically opening the garage door when we get home? No, my wife's #1 favorite automation I've done is turning on the lights in the pantry when the pantry door opens. The first time I've built an automation and her response was, "Why didn't we do that years ago?"

[scoob8000]

I noticed a few times over the past few days that the light should be white and not in holiday mode after a active event. I finally saw what happens with my own eyes this morning on my way out the door.

Lights come on, bulb goes from color to white, then right back to color again. Reminds me of the bug earlier when if you had the color switch delay to less than a minute what was happening.

And I'm sorry, I still haven't got around to retesting the CT bulb thing I was PM'ing you about. I'll tinker with it over the long weekend.

Here's the log snippets.

app:9332022-12-22 07:34:00.430 AMdebugChecking if illumination is still triggered
app:9332022-12-22 07:34:00.251 AMdebugSetting color temperature to 2700K and level to 90%
app:9332022-12-22 07:34:00.250 AMdebugRGB-only devices: []
app:9332022-12-22 07:34:00.249 AMdebugCT-capable devices: [Porch Lamp]
app:9332022-12-22 07:34:00.247 AMdebugIllumination mode for triggered: Color Temperature
app:9332022-12-22 07:34:00.224 AMdebugIllumination triggered
app:9332022-12-22 07:34:00.223 AMdebugDetermine next light mode: holiday=true, illumination=true, triggered=true
app:9332022-12-22 07:34:00.212 AMdebugBegin illumination period after Porch sent on
app:9332022-12-22 07:33:40.335 AMdebugSetting [Porch Lamp] to [hue:33, saturation:100, level:90]
app:9332022-12-22 07:33:40.230 AMdebugSetting [['device':device0, 'color':['hue':33, 'saturation':100, 'level':90]]] in 0 seconds
app:9332022-12-22 07:33:40.228 AMdebugSublist: [['hue':33, 'saturation':100, 'level':90]]
app:9332022-12-22 07:33:40.226 AMdebugStarting from offset 1 (next is 0)
app:9332022-12-22 07:33:40.224 AMdebugSelected colors: [['hue':0, 'saturation':100, 'level':90], ['hue':33, 'saturation':100, 'level':90], ['hue':0, 'saturation':100, 'level':90], ['hue':33, 'saturation':100, 'level':90]]


dev:10432022-12-22 07:34:22.076 AMinfoPorch Lamp color mode is RGB
dev:10432022-12-22 07:34:22.073 AMinfoPorch Lamp color temperature was set to 6536°K
dev:10432022-12-22 07:34:00.369 AMinfoPorch Lamp color mode is CT
dev:10432022-12-22 07:34:00.366 AMinfoPorch Lamp color temperature was set to 2703°K
dev:10432022-12-22 07:33:22.063 AMinfoPorch Lamp color temperature was set to 2000°K

[mbishop]

Hm, almost looks like the next light update is in progress when the illumination trigger happens. If that's the case, it could happen any time, but obviously you have more chances to collide if lights are updating more frequently.

Maybe I should add a check to see if illumination is called for just before sending the command to the lights? I'll add that later today and send it to you to try.

[scoob8000]

Thanks. I wonder if it's made worse by these lights being on a hue bridge and having a little more of a delay and or the fact hubitat doesn't exactly know what state the bulb is in.

[mluck]

LOL. That gives me an idea.

Best app ever would be a WAF Predictor. You input a description of your intended use-case and the model would use AI to predict WAF with high accuracy. And the rules base would easy--the simpler and more trivial the idea, the higher the WAF.

[mbishop]

You can see if the version at https://raw.githubusercontent.com/MikeBishop/hubitat-holiday/colorRace/holiday-lights.groovy heads this off. However, taking a closer look at those timestamps, here's what I see folding them together:

• 7:33:40 - Colors are selected and the bulb is sent an RGB command
• 7:34:00 - Illumination is triggered and the bulb is set a CT command
• 7:34:00 - Bulb responds to the CT command
• 7:34:22 - Bulb responds to the RGB command

If there's a race condition in the app, this should help head it off. But there's a twenty-second gap between color and illumination, and twenty more seconds before the spurious color change -- that's not a race condition. If the commands going to your bulb can get substantially reordered before the bulb acts on them, and I'm not sure I can do anything about that. (Unless there was another app event setting color about 20 seconds after the end of the snippet you pasted?)

[scoob8000]

I'll give it a go.

Interesting though. I didn't really think about 20 seconds being that long I guess.

Nothing else controlling these bulbs/hue. Hue is pretty instant at changing colors, even from hubitat but maybe cycling every 30 seconds is too much and commands are stacking up somewhere maybe?

Another thought, is changing to CT and the temp/level multiple commands to send vs cycling color is just one? The bulbs logs really don't make much sense to me. In RGB mode it's still reporting CT values and hue in percentages. I'm using the built in integration FWIW.

[EDIT] I was able to re-create it again with the new code. I cranked the color cycle down to 15 seconds, waited for it to change color, counted off 15 seconds in my head and hit the switch that should make it go to white. On the transition from green to red it when white for the slightest bit of time in the transition.

Logs looks the same for the bulb, goes to CT mode, then a few seconds later back to RGB.

I'm going to bump that cycle timer back up to a minute and I bet it happens a lot less often.

[EDIT 2]
I just switched over to the Advanced hue integration since it seems like it handles the queuing of commands and state tracking better. Gonna bump the holiday rotation back to 30 seconds and see if the integration makes a difference.

[EDIT 3]
Still happens but not nearly as often. I did a test with the rotation at 15 seconds and I was able to recreate it, but not as easily as before.