Still working perfectly fine 
1 Like
Thanks for confirming! I'm pretty sure I merged those changes and published them on HPM a while back, but I definitely appreciate bug reports.
1 Like
Hey @mbishop, been using this great app for awhile now and still works great, but I think I found a bug. If you import Jewish holidays, they import fine, but then after you hit done, you get this error:
Error: Invalid value for DayOfMonth (valid values 1 - 28/31): 33
I even deinstalled and reinstalled the app and could recreate the error. The Christian and US holidays work fine. Makes me wonder if one of the default Jewish holidays has the wrong day or month value maybe?
1 Like
Thank you for catching that! It's a bug that wouldn't have repro'd in previous years, but happens this year because Rosh Hashanah falls in October instead of September. (I was expecting LocalDate to handle the month rollover automatically, and apparently it throws an exception instead.)
Fix going up momentarily.
Hah pleasure to be of service!
Hey @mbishop, question for you.
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.
Also, you could consider using [PRERELEASE] Virtual Prestaging to manage the CT of bulbs that are off. 
[quote="mbishop, post:425, topic:96396"]
I
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?
Seems tricky.
Is HL set to monitor the override variable? Seems like that's all that's needed, at first glance.
RGB Device Selection > Advanced, albeit perhaps that top-level menu item needs a better name.
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.
1 Like
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.
1 Like
Yeah sorry I didn't share that part. I use RM to pause/resume the Mirror instance conditionally. Kinda hack to make Mirror conditional.
1 Like
Ah, I didn't realize RM could do that with Mirror instances! There you go, then.
1 Like
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!
2 Likes
