Kind of. There's an event that fires at sunrise/sunset, but then you can't do a negative offset from it. Or you can fetch the current day's times and schedule for a specific time.
There's also an event that fires with the next day's sunrise/sunset times that I can listen to, and I do, but that doesn't help when the settings have changed and I need to schedule fresh. I could maybe tuck them in state and prefer them over what the API returns....
Based on just the last few days, when I left for work (0550) they were already off. Sunrise this morning was 0625 (using LunSol Cal app to verify). I don't know what time they have actually been turning off. Normally they are still on when I go to work. I turned logging on this morning, so I don't think I'll see anything until tomorrow.
I'll double check them later today. I pulled them from GPS logger app and set them manually almost two years ago. I haven't had any issues with sunrise/ sunset with the event engine cog.
Hm, that's a bigger difference than there should be, yes. Can you check when the app has scheduled events? Maybe turn on debug logging and see why it's choosing to schedule then?
Ill take a look at it this afternoon.
Couple things.
When Importing holidays, if you try to import United States and Christian together, only united states will be successful, Christian will fail, but then will work when you try to do it by it self. I assume Jewish would have the same issue.
When naming the instance, is that for the whole schedule of holidays/displays? or just a particular holiday ? When I went back and tried to Name it, it deleted my instance all together and I had to set it up again.
Thanks -- I'll try to repro these. The name is for the app instance, in case you want a different instance controlling a different set of lights on a different config.
I did have one time during development where the app disappeared from the app list, but was still there when I hit the URL for it. It reappeared when I gave it a name. I wasn't able to reproduce that to figure out why, though.
Well, they kicked on at the right time. I did catch a couple error logs for you
I'll check back in the morning to see what time they shut off at
Okay, line 897 is getting a value from the frequency drop-down -- I don't handle no selection. Marking that required is the simplest fix. Not selecting a value will only have affected you if you selected a color scheme that changes (e.g. random or sequential) -- the lights will have stayed the same color all night.
I've fixed that and a few other bugs, including one that would break offsets from sunrise/sunset, in https://github.com/MikeBishop/hubitat-holiday/pull/1. I've also got hopefully-better handling of the events for sunrise/sunset times, but since I don't have a way to simulate that event, I'll have to wait for sunrise to see if I did it properly.
I'll merge it if it handles sunrise properly; if not, I'll update and test again at sunset. Feel free to test the file from that branch on your side as well.
Humm, nope, no changing schemes. Just two bulbs, red and blue steady. I think the Stock scheme for independence day is Red, white and blue, I didn't change that. But since I'm only using it on two bulbs, (red and Blue) could that have caused it ?
I've never tried to update from Github , hopefully I did it right and will have something for you in the morning.
Stock is random selection among red/white/blue. Pick a value in the drop-down, and you'll hopefully see them change periodically.
I hadn't even noticed the "how to rotate" selections before. I also went ahead and took the white out . Here is how its set now.
As near as I can tell it looks like the sunset/ sunrise is a bit more dialed in, thought there was an error right at sunrise. Here are some logs for last night. I didn't stay up all night to verify they were on or that the colors were rotating. I did check a few times through the night as the dogs woke me up. I can verify they were on until at least 0330. The next time I looked was after sunset (0625) and they were off. As for the random changes, I can't completely confirm, but I watched for a little bit after I set it up and never saw them change. I don't think it was actually happening (though the logs look like it was supposed to be happening if I understand them correctly. Not really an issue for me, as I most likely wouldn't use it. I just tried to set it up to test for others
So what I see in the logs is:
I'd already found that my attempt to catch the event didn't quite (my own sunrise logs), but I now have a better approach when I get a moment to make the change.
Okay, I just pushed a new commit on that PR -- I think it's working properly now. It gets the next sunrise and sunset from the location events history for initial scheduling, then relies on the events after that.
If it behaves overnight for me, I'll merge in the morning.
IM pretty sure after I took that screen shot I switched it to random. Ill double check when I get a chance.
I thought I had that set for 10 minute (or at least to change every 10 minutes) .
I probably won't use that setting myself in the future. I'm just trying to test it out so it works for others if they decide to use this app. Minor bugs over all, but I'm really glad you did this!! Very welcome addition!
Just to be clear, there are two things you had left blank that I wasn't handling as well as I should:
I thought I had set it to random and update every 10 minutes. sat up for a bit but never noticed it change. I'll double check that and see what its set at. Honestly, I cant remember at the moment.
** EDIT **
Just checked, had it set to random and update every 5 minuets. Is there another setting I missed I needed?
I did not even see this, but I also cant test it, as these bulbs aren't on any kind of sensors at all.
If you're seeing the doLightUpdate calls in your log, it's running periodically.
The way color selection works, in brief, is that if there are not enough colors configured to at least cover the lights (say, three colors for four devices), then the color list repeats until it's long enough (six colors for four devices). Then, if random was selected, the list is scrambled before being applied.
So for three colors and four lights, you'll never have more than two of the same color. However, with only two colors and two lights, there's a 50/50 shot any given cycle picks the same colors as before, so the changes will be less obvious. (If you choose "sequential" with only two colors, they'll alternate every time.)
On the illumination side, you can also configure a switch that flips them to white, but it's not restricted to the interval and doesn't need the scheduled task -- if the switch turns on, they'll stop holiday lighting and go white as long as it's on. Holiday lights resume when it turns off.
Ahh with only two colors and two lights that may well explain it. When I got home from work last night I did sit in the truck a bit until I visually verified it was working.
As for sunrise, it looks like they did shut off pretty close to on time this morning, but with some errors:
Could this also be set so that if a lock is Manually unlocked or garage door opens it would switch to white them back when relocked and / or motion stops?
You got me thinking I may go ahead and put a motion /lux sensor out front (guess in need those hue outdoor sensors after all). Using the motion sensor would cover anything happening in the drive way. My use case would be if someone unlocks the front door or opens the garage door to leave, it would switch to white until relocked/ closed/ motion stops. which ever happens last.
The toInstant() bug was fixed yesterday,I think. The current version from that branch should address it, or you can wait until I merge it shortly and go back to main.
Easy enough to add lock unlocked as another trigger; I'll look at that soon.
My garage door also exposes itself as a contact sensor, so I'd assume that's already possible if yours does too. If not, I can look into that device type as well.
Edit: Merged bugfixes; for lock support, see https://github.com/MikeBishop/hubitat-holiday/pull/3.
Download the Hubitat app
