Then it turn off the computer for the night, as it’s a dev box, not meant to run 24/7. I turned on the computer around noon, on the day after. When I check the event log later the same day, here is what I found:
MorningNight ended at 5ish PM and then down at 6ish PM?
Is there an event queue for Astro that it can only “pop” one event after another? I thought which event to trigger is based on time, not position of the queue?
Astro generally calculates stuff for the day ahead just after midnight. Changes you make may not be effective until next day.
The above statement was in the forum.
Maybe because you turn it off it doesn’t calculate properly? Just a suggestion.
Quite possibly related but maybe not a direct fix for this - install MapDB as the secondary persistence layer. RRD (the default persistence) doesn’t handle strings, whereas (IIRC) MapDB and most others like InfluxDB/MySQL/etc can. Whatever you do, I’d recommend keeping RRD as the default though, from my experience, as it works incredibly well with OH3 requiring no additional config.
Yes, it also schedules the jobs at the same time as well. As it states here in the Thing handler code:
/**
* Schedules a positional and a daily job at midnight for Astro calculation and starts it immediately too. Removes
* already scheduled jobs first.
*/
However the thing I am not sure is after it schedule the jobs, will it re-align the events. So sunset doesn’t get trigger at 12AM. I will leave the computer on and monitor the event after midnight, that should tell me if the issue would resolve itself.
To aid understanding, can you clarify if you got the expected dusk events after the unexpected dawn events shown?
It does look like a behind the scenes state machine. But I feel it isn’t.
In your openhab.log for boot time, you should see evidence of Astro setting itself up for the (rest of the) day ahead. Usually a couple of scheduled jobs. Confident the system time was accurate at that point?
There shouldn’t be any re-aligning to happen.
Example, reboot at 13:00.
Astro calculates today’s dawn for 09:00
We hope the code is smart enough not to schedule any event, as the time is already past.
Next dawn not calculated until midnight.
If you look at the state channel holding dawn DateTime, it always points to today’s calendar date, not tomorrows or next dawn.
Weird stuff happens at high latitudes, where there may not be a dawn at all today. So I suppose you should also check Astro is picking up correct lat/long at boot time.
Thank you all for all the info. I think I know why. After @rossko57 suggested to check the log during boot up, as the Astro should calculate events during boot, I realized openhab wasn’t rebooted after the computer rebooted.
The reason is openhab is in a VM. When I shut the host down, the VM went into suspended state instead of shut down. So when I rebooted the host, the VM just resume state.
Astro calculate events based on current time + ms. So when VM come out of suspend, the calculated seconds will be out of sync with the actual time, hence the events firing at incorrect time.
It’s all good now. I will shutdown the VM before shutdown the host, so that will ensure Astro calculate at boot.
