So I have Hubitat that I run on the weekends only and shut off during the week.
When I leave I set the mode to away
When I power on the device the sunset event does not work the first day. On startup I set the mode to day. IS there a programmatic way to force the sunset to be re calculated?
These were the events
The 2023-06-11 02:25:13.318 PM event is the return after device powerup.
One thing I tried was installing a NTP client and delay the switch to day until the time is correct. But that still did not generate a scheduled job for evening.
Its a camper at a season site. I shut down the electronics to protect them from poor power. Yea I am a bit of a nerd. But its where I get to spend time just trying new things.
Ah I see. I believe the hub schedules events for the next day’s sunrise and sunset at a specific time each day (or maybe at night).
@bertabcd1234 might be able to speak to that.
I have figured out that if I go into mode manager and just click the update everything gets corrected. So I thought I may be able to just duplicate that post request. But here must be a simpler way.
I suppose one solution would be for Mode manager to not schedule a single occurrence but make it daily. Sure in one week it would technically be off but would then correct itself evey day when it runs.
It may be helpful to show your Mode Manager setup -- the actual app UI, not the App Status page. Particularly if you have "Before" offsets, I could see this being a problem if the hub is offline for multiple days. That could be the problem, or maybe you're dealing with a problem for actual sunrise/sunset event generation with the hub being offline for multiple days. But I don't think I've seen that reported as a problem before, so I suspect it's something else, and this would help figure that out.
I have tried using the time table option but there was no change in this behavior.
To me the fact that there is a timeHandler that appears to be scheduled but has no time is a problem. It is almost like on boot once the proper time is set it goes through the events and looks for expired scheduled jobs and removes the time but not the job.
I believe the issue is that your offset is sunset-50, which is calculated at some time (this used to be shortly after midnight, but I think it changed at some time--or maybe that was something else?) and causing problems because your hub was off when whenever that calculation was supposed to be made was.
It is likely that the "Set mode at system startup based on time table" option (bottom of your screenshot) would help with this problem. Other workarounds would be using sunrise itself or sunrise plus a postive offeset -- this issue is particular to the negative side, which has to rely on a scheduled job set some time prior rather than the event itself.
I have tried the time table it did not change the behavior. Positive offset would not work. I use sunset minus a give time to rurn on lights. Since days get shorter the offset from sunrise would not work. From what I can see in the mode manager pattern it sets the new time when the sceduled job runs. And since the hub is shut down that never happens. And on power up the stale event is cleared. Going to to mode manager and just hitting update corrects the scheduled job. But that defeats the purpose of a automation system:)
It seems odd that that option wouldn't (unless maybe it didn't have the sun time calculated correctly by then -- NTP catchup, possibly?). I'd be curious what Logs say on startup when you see unexpected behavior and have that option enabled.
Otherwise, it seems like you might want to use something besides Mode Manager for at least this, given the current behavior. You can have a rule triggered by "Location event" of "systemStart," and do whatever you want there--say, check if the time is between sunset-X and Y and set the mode to Z if so (and leave the rest in Mode Manager).
Another option, of course, is just to not shut down the hub. It should last quite a while on a UPS, being fairly low-power. We could also ask @bravenel for more about the specifics of when Mode Manager schedules these jobs or if the "Set mode at system startup based on time table" option should really be able to handle this, as I initially suspected it should...
I do set the mode to Day on startup the screenshots above are the state of the scheduled job and the events right after the startup. I do use the same logic at home and do not have issues, but it is on all the time. The time is not correct when switched to Day so I can try moving that call after the time is set. I will see if that resolves it. Let you know in a week.
So changing that call did not work. But doing a http post did solve the issue. I just sent formAction=update&id=385 to installedapp/update/json where the id is the mode manager