[Deprecated] Design Pattern: Time Of Day

Now that you have changed the code a bit, are you still seeing the DateTimes being populated correctly?

In particular is evening_start being populated correctly?

It might be the case that Astro is the root of the problem.

I haven’t checked that yet, but it is like back to normal. It has changed to EVENING when it should. I don’t know what happened, I haven’t changed anything…
I’ll keep watching that it is correct or not… if not I will debug the whole rule…

Look in your logs around midnight for statements from the Astro binding indicating that it is calculating the new times for the new day. If you don’t see those then Astro isn’t calculating the times and this will definitely break the Rule. There was a bug along these lines in Astro awhile back. I thought it got fixed but I am not certain of that.

Thanks!
So it has worked for a day, after posting my previous comment. Now I have changed nothing (just rebooted my server) and the problem is back.

I can see Astro events at midnight, but just these two lines (and that the rule has ran):

2018-11-23 00:00:30.133 [INFO ] [thome.binding.astro.internal.job.Job] - Scheduled Astro event-jobs for thing astro:moon:local
2018-11-23 00:00:30.177 [INFO ] [thome.binding.astro.internal.job.Job] - Scheduled Astro event-jobs for thing astro:sun:local
2018-11-23 00:01:10.015 [INFO ] [marthome.model.script.DayState.rules] - Calculating time of day...
2018-11-23 00:01:10.076 [INFO ] [marthome.model.script.DayState.rules] - Calculated time of day is AFTERNOON

But I also have another Astro Thing which stores the offset times (like Afternoon time). I couldn’t see it there.
Searching through the log for the Thing it seems that the previous day that Thing also got ‘Scheduled events’, today not. So it’s like something brakes that Thing, but only that one. Is that somehow possible?
What should I try? Anyway, if it didn’t calculate the new times, shouldn’t the rule use the previous (last) calculated value? Why this can break the rule?

Thanks!

This was a reported problem but I thought it got fixed. Perhaps not. I can’t find the thread where this was discussed. It was exactly this behavior though. Some Astro Things would update but not all of them. Sometimes all would get updated. I wish I could find it again. @Dim, I have a vague recollection that you saw this problem. If so, do you remember if we found a work around?

1 Like

(I think that) I found the thread: Astro binding does not trigger: has no future executions anymore

Trying to find the PR that fixed the issue… this is old though. @rkrisi is on OH 2.4.0 M6… this shouldn’t happen

and maybe: https://github.com/eclipse/smarthome/issues/3809

1 Like

Your search skills are better than mine. I did think this got fixed, but the behavior was exactly as rkrisi describes. Odd.

1 Like

Ooops… we may have another regression here: https://github.com/eclipse/smarthome/issues/6107

1 Like

Never thought of this, I was sure that maybe I messed up something because, prior to M6 it didn’t had any problem. However as I can see, it won’t change anytime soon (maybe if someone implements an alternate scheduler).

Ps.: So it seems that after running it for a few hours, the problem is gone and it starts working “automatically”. Really have no clue what can cause this.

The problem only occurs a few seconds after midnight. The problem is sometimes not all of your Astro Things get recalculated for the new day. When they don’t get calculated, the tests in the Rule above fail because one or more of your start times is still yesterday, not today.

But only that one or two start times will be wrong. All the rest of them will be correct. So one would expect the Rule to work when the next time period starts.

Ahh, now I understood it! Forgot that this not only gives HH:MM but a full date. (Maybe because I can only see the HH:MM in PaperUI).
Should I file an issue or it is not worth it? Others commented that this is hard to be reproduced/find the bug…

It’s probably best to go add a comment to the issue Dim posted a link to above. This is a regression (i.e. is was fixed and now is broken again) if it is caused by the same root problem.

Thanks for your help! I made a comment about this.

Hmm, it seems that not just happen after restart… it has been running for days now, it was okay a few hours ago, now when some rules didnt get executed I started looking what can cause this. It was afternoon again…
Any recommendations for a workaround?

Ps.: My bad, openHab exited itself…

Is this issue is solved in M7? I see that most of the issues are closed, but there are no merges associated with that issue?

I’m sure now that I always get this always afternoon problem at midnight…

I don’t know. If this is truly a regression then this is a problem that has been fixed but then reintroduced at some point.

But you can see that the issue that Dim linked to is still Open meaning it hasn’t been fixed.

I have been using M7 for days now, and it seems for me that the bug is gone!

3 Likes

Hi I think I am having the same problem - I’ve used the rules exactly as posted at the top of this post and I am not getting the changes from Morning to Day to Afternoon correctly. Do I need to upgrade something, I am on OH2.3 on Windows.

Thanks

2018-12-12 00:01:00.115 [vent.ItemStateChangedEvent] - vMorning_Time changed from 2018-12-11T06:00:00.000+0100 to 2018-12-12T06:00:00.000+0100
2018-12-12 00:01:00.117 [vent.ItemStateChangedEvent] - vNight_Time changed from 2018-12-11T23:00:00.000+0100 to 2018-12-12T23:00:00.000+0100
2018-12-12 00:01:00.119 [vent.ItemStateChangedEvent] - vBed_Time changed from 2018-12-11T00:00:00.000+0100 to 2018-12-12T00:00:00.000+0100
2018-12-12 00:01:00.125 [ome.event.ItemCommandEvent] - Item 'vTimeOfDay' received command BED
2018-12-12 00:01:00.126 [vent.ItemStateChangedEvent] - vTimeOfDay changed from NIGHT to BED

2018-12-12 06:00:00.123 [ome.event.ItemCommandEvent] - Item 'vTimeOfDay' received command MORNING
2018-12-12 06:00:00.137 [vent.ItemStateChangedEvent] - vTimeOfDay changed from BED to MORNING

2018-12-12 16:52:59.898 [vent.ChannelTriggeredEvent] - astro:sun:home:set#event triggered START
2018-12-12 16:52:59.898 [vent.ChannelTriggeredEvent] - astro:sun:local:civilDusk#event triggered START
2018-12-12 16:52:59.899 [vent.ChannelTriggeredEvent] - astro:sun:minus90:set#event triggered START
2018-12-12 16:52:59.901 [vent.ChannelTriggeredEvent] - astro:sun:local:set#event triggered END
2018-12-12 16:52:59.901 [vent.ChannelTriggeredEvent] - astro:sun:home:daylight#event triggered END
2018-12-12 16:52:59.901 [vent.ChannelTriggeredEvent] - astro:sun:minus90:daylight#event triggered END
2018-12-12 16:53:00.009 [ome.event.ItemCommandEvent] - Item 'vTimeOfDay' received command DAY
2018-12-12 16:53:00.011 [vent.ItemStateChangedEvent] - vTimeOfDay changed from MORNING to DAY

The Asto binding is not generating the event for sunrise.

This was a known bug in OH 2.3 that hit some people which theoretically should be fixed in 2.4. Try the 2.4 milestone release or wait until next week for 2.4’s release (assuming they stick to schedule).

Yes I didn’t see this error in M7. Now M8 works as it should! So you should upgrade to it.