Time Of Day problem with Dawn - always one day ahead

I have jython scripts that utilize the TimeOfDay.

I’m using the TOD Javascript to set the TimeOfDay item based on the etod metadata tag … everything works fine for my MORNING, DAYTIME, EVENING, NIGHT and SLEEP states … a few days ago, I added DAWN that uses astro:sun:local:night#end (DateTime) as the trigger. I have combed over the configuration, comparing it to MORNING which works and uses Sunrise …

The problem: The value for DAWN is always a day ahead so the comparison never happens.

I am probably doing something wrong, but looking for some ideas of what I might be missing. I’ve anxiously waited for 4:52AM to occur to check the logs three days now :slight_smile:


I don’t know if it actually works this way, but the end of a forthcoming Night which begins today, is usually tomorrow.
The binding offers a selection of ‘sunrise’ events for “today”, to which you can apply offsets as well. What are you actually after?

Thanks - I’m looking for the earliest event in the morning (before sunrise) that I will use to turn off my front sidewalk lights :slight_smile: … it looks like the channel “Night End Time” might not be working correctly (i’m sure @rlkoshak will correct me) … but I noticed that the channel “Morning Night End Time” looks correct (i.e. not a day ahead) so I can try that. it’s roughly the same time in the early morning.

I’m not really an expert in Astro. All I really know is about ten seconds after midnight Astro recalculates the event times for the current day. The docs don’t provide any further elaboration on how it calculates the times though.

All I do know is that I use RISE in my ToD Items and that’s working as expected.

Thanks Rich … it does appear to be broken, not sure if the person who wrote the binding can (or cares to) comment. Yes, there are many other ways to get to roughly that time (including a negative offset to sunrise). I’m pretty sure the Morning Night End will work, will report back tomorrow.

If it does appear broken then I’d file an issue. That’s the best way to get the attention of someone who can do something about it.

1 Like

Thanks Rich. I’ve read your “How to file an issue” and searched the openhab github for the Astro Binding but I’m not finding it …Can you direct me to the right place?

To repeat, if Night starts at 20:00 today it will end at 05:00 tomorrow. I’m not convinced anything is broken.
Otherwise you’d get end before start, which would be pretty weird.

Ok maybe it’s how I am thinking about the time … but it seems that any channel that is set for a time tomorrow, will never trigger. Clearly these are different depending on your location but still seems weird.

Morning Night Ends before Starts and its in the same Day (i.e. not tomorrow). Conceptually, Night Time does start today and ends tomorrow, so it is correct. (while Morning Night is also correct since it is in the same day) … so Morning Night should work for my case … just not sure how the TOD trigger will ever happen if you use those other cases as the time is recalculated at midnight when the channel has already moved to tomorrow.

Think you are muddling the state channels reporting calculated datetime, with the separate events channels.

Yes, I now agree the channel info is correct, just that the TOD script isn’t handling those cases. Might not matter to 99% of the people but might be worth noting. (If I am correct)

Rich will tell you the script is an example. It’s not going to work well in the Arctic.
But yes, time stuff is headache inducing when spanning dates.

1 Like

I was just the lucky one to pick an obscure time :slight_smile:

The Time of Fay library has no concept nor any care where the DateTimes come from. They can be hard coded, come from Astro, come from a calendar, the alarm clock on your Android phone, or anywhere else in the world. All it can do is look at the DateTimes and see if the time is in the future or in the past. If in the future it schedules the timer to transition to that time of day. If in the past it skips that time of day.

So what is happening here is the Astro binding is setting the DateTime Item to a DateTime of tomorrow. That’s in the future so it schedules the Timer. However, at midnight(ish), before the Night End time is reached, Astro recalculates Night End for the new day, which is again tomorrow. Time of Day sees the new Time and reschedules the Timer to the new time, which is again the next day.

There is no way to handle this within the Time of Day rule without making the Time of Day rule become inextricably tied to the Astro binding again. I don’t want to do that because the whole point of the generic JS and Python implementations is to not have it tied to anything specific. The DateTimes can come from anywhere.

So either:

  • the behavior of the Astro binding needs to change (which I agree with rossko, I don’t think it’s behaving incorrectly so this is unlikely)
  • the rule has to be rewritten to handle the Astro Night End Item as a special case which ties the rule to that binding and goes against my goals for the ToD rule
  • You’ll have to add a special rule to handle this one event.

There is nothing that says the Time of Day rule has to do everything. You’ve a special case here so write a rule to handle your special case. All you need to do is remove that DateTime Item from the TimesOfDay Group and then create a Rule that triggers on that Astro Event Channel that sends a command to the TimeOfDay Item.

Agreed. It all makes sense for the current implementation and probably not worth trying to handle these cases. Not sure if a note is warranted or if this thread will suffice for the next person. Thanks Rich!