Noticed a couple of my bulbs not activating by HL as expected so did some poking around to discover the offending bulbs have color prestaging activated (which I use separately to set color temperature throughout the day in support of a circadian rhythm. While the two automations never step on each other (I made sure of that previously), could it be true that HL wouldn’t turn on bulbs when color prestaging is activated? Does HL issue an ON command distinct from setColor?
Appreciate any advice on how to deal with this. I can imagine a couple workarounds.
This app follows the official guidance to assume that a non-zero Level implies turning the bulbs on, so it only sends on() commands to devices selected as additional switches. If you put the bulbs in as both RGB devices and switches to turn on, though, it doesn't look like I currently do any deduplication, so that would be a not-too-hacky workaround.
I can't promise it won't break at some point; I did have a branch in which I probed the "additional switches" for RGB and CT capabilities and included them in those sets if enabled. If I ever do that, though, just put a virtual switch in those fields and have it send an on() command when turned on.
This! Brilliant workaround, thanks. Always used that switch parameter just to set a flag that holiday lights were active so that I could prevent other automations from stepping on HL. But this use-case works great too. Or at least I'll find out this evening, I guess. Happy Valentines Day btw, lol.
I've looked this in the past but always preferred rolling my own using RM every few minutes throughout the day because then the bulb is are set at the right temperature when turned on. With vPrestaging, I always assumed it would create a delay in motion lighting or manual lights turned on because the hub has to configure the bulb and then turn it on. Or may the timing difference would be imperceptible. What do others think?
In my experience, yes, the bulb does cycle through whatever color it was previously on, but it's a fraction of a second as it's turning on. I don't find it particularly annoying, but YMMV. It's not as bad as waiting for the next general light adjustment in however many seconds.
Also, I recently added an option for HL to set a Hub Variable when a holiday is active, if you find that preferable to a virtual switch.
Curious what you mean by this. What I do is set the CT through the day so that whenever a light is turned on, the CT level is, worst case, 5 minutes old. So there's an imperceptibly small adjustment. Or maybe I'm misunderstanding your point.
Cool thx for the heads up. Always prefer hub variables to virtual devices.
Hey Mike @mbishop wonder if you have any advice for using HL in the following scenario.
Say I have an RGBW bulb that I routinely use in motion lighting or other automations that control the bulb’s level, RGB value, color temp, etc. Except on Holidays, I want HL to take over. At first I thought, no big deal, I’ll prevent the automation from running when HL is active. Straightforward. Except….
Much of my motion lighting uses an override flag that prevents the automation from running if for example a person turned it off through physical/manual intervention, which flips the override flag to ON which in turn deactivates the motion lighting temporarily.
But on a holiday if the bulb is turned off and the override is activated, HL will turn it back on at the next HL iteration. In such a scenario, is there a way to prevent HL from activating one or more of the bulbs in the HL instance?
Well I’ll be damned I never noticed that option duh.
Only issue is that I’d want the restriction to apply to a single device/bulb. Any reason I couldn’t create a second parallel instance of HL with all the same parameters, except this one switch?
Hey @mbishop, not to nag, but did you see the above follow-up? TIA...
Also -- as long as I've got you , can you help me understand the mode parameter? In the example below, I thought it would mean that HLs are active whenever the mode is Evening, even if it's before the start time or after the stop time, but it doesn't. How should we interpret this parameter?
Other than the hassle of keeping settings in sync, not really. But it might make more sense to have one HL instance, but include a virtual switch that passes commands to the real switch under certain conditions. (Virtual Prestaging can do this based on a switch, and I could probably add variable support if needed am exploring variable support in this PR.)
That's exactly how it should be interpreted. If it's not behaving that way, grab debug logs.
Given my setup, I'm thinking this advice is wise. So I'm using Mirror to pass commands from virtual to real, but it's not clear to me that I'm passing all the HL-triggered commands. Here's what is (green) and isn't (yellow) passed along. Would this work from HL? If not, I'll roll my own mirror in RM5.1 -- just want to make sure I know which commands will come out of HL. Thanks again.
That should work -- HL will send setColorTemperature() and setColor() commands to bulbs that support them, the latter of which will produce hue, saturation, and level events simultaneously. To turn off, it just uses off(), so switch will catch that.
I didn't see that Mirror has any ability to relay the commands conditionally, though, which is why I suggested Virtual Prestaging.
Been a while since I've posted in here, but that is a good thing. I just wanted to say your app has been working great for me (my last msg was in '22 about utilizing motion floods) and I just wanted to send my appreciation to you @mbishop . Thank you again!
I cant seem to get the driver loaded I am getting the following error.
No signature of method: Script1.definition() is applicable for argument types: (java.util.LinkedHashMap) values: [[name:Holiday Lighting, namespace:evequefou, author:Mike Bishop, ...]] on line 12
It looks like you might be trying to install the app as a driver. Holiday Lighting doesn't include any virtual devices; it's purely an app that interacts with your existing devices.
You might consider installing via HPM, since there are a couple of moving pieces to this one -- an app, a library, and a script that gets loaded to static files.
It's working!
Thanks Mike, I don't what I was thinking I thought it was a driver.
As far as the HPM I never used it I always loaded manually.
Its an option rich app. I only see a couple of requests. A variable update frequency. And maybe a variable fade in fade out. Otherwise its very cool.
Can you add presence sensors for a user specified duration to the non-holiday illumination trigger? This will allow us to have normal lighting when we pull up for 10 minutes to unload groceries, etc. Thanks!
