[SOLVED] Astro offset earliest not correct after DST change

As of March 31st, in the Netherlands we have change our clocks for 1 hour. Somehow my astro-binding gets the wrong offset. I’ve created a binding with the Sunset start setting earliest 20:00. Before the DST change, it shows 20:00. Now today it show 21:00 (and it should be today at 20:07).
If I removed the offset, it shows the correct sunset (20:07).

Is this a bug? I run OpenHAB 2.5M1 on a raspberry pi 3B+

How does your Thing look like ?

This is my thing configuration.

I’m a bit confused. Did you create your Things via Paper UI ? And the corresponding Channels too ? I have to say that I’m not experienced in that, as I’m creating my SetUp via Text-Files and using Paper Ui as Administration Tool.

But I think that your Items always will only have the real Time of your Sunset or Sunrise or whatever. And your Screenshot shows not the Thing but a Channel.

With your Range#Event Channel you can trigger a Rule to start at a given TimeEvent (Sunset +/- Offset + earliest/latest).
So I will explain it from my point of view.
astro.things is:

Thing astro:sun:local     "Sonnen Daten"    [geolocation="48.xxxxxx,9.yyyyyyy,502", interval=300]
Thing astro:moon:local    "Mond Daten"      [geolocation="48.xxxxxx,9.yyyyyyy,502", interval=300]
                                        

Thing astro:sun:stowing   "Offset -180"     [geolocation="48.xxxxxx,9.yyyyyyy,502", interval=300]{
  Channels:
    Type rangeEvent : set#event [
      offset=-180,
      earliest="19:40"
    ]
  }

Thing astro:sun:stowing1   "Offset 200"     [geolocation="48.xxxxxx,9.yyyyyyy,502", interval=300]{
  Channels:
    Type rangeEvent : noon#event [
      offset=200,
      earliest="13:00"
    ]
  }

As you see there are four different Things in use. The two “normal” ones which are used to create and link to the .items File(or created/linked in Paper UI) and two with offset.
Is it possible that you are mixing your “normal” sun and moon things with the offset-things ?

So my next question is, where can you see the Sunset-Start Time ? Basic UI/Classic UI/Paper UI-Control ?
And an additional question: Are you using Rules ?

For better understanding it would be better to see your Setup (.items /.things/ .rules) and some words and/or screenshots what the goal should be you want to reach.

Cheers, Peter

Sorry for any confusing. It’s my first post :wink:
Inspired by the DP of @rlkoshak, Time of Day, I have 2 things of the Astro-binding, 1 for the real sunset/sunrise and the other for an off-set sunset. Both created in Paperui. On the channel “astro:sun:local-offset:set#start” of the latter thing, I’ve set the earliest sun-set at 20:00 (just as in my screenshot). I created two items
DateTime Sunset_Time “Zonsondergang [%1$tH:%1$tM]” (Astro) { channel=“astro:sun:local:set#start” }
DateTime Sunset_Offset_Time “Zonsondergang (offset) [%1$tH:%1$tM]” (Astro) { channel=“astro:sun:local-offset:set#start” }

for debugging purposes. The first is the “normal” sunset, the latter is the offset (at least 20:00h or later).
Till the change of summertime (DST), it works perfectly. For example the sunset was last week around 19:04, the first item gives my 19:04, the second one 20:00. Just as it suppose to do.
But after the DST (last Sunday), the items state 20:07 and 21:00. The last item (offset) supposes to give the same time as the normal sunset (because 20:07 is at least 20:00).

The rules I use are irrelevant, I suppose, because the items are already not correct. All things/channel settings are done in PaperUI, the rest in files.

Hopefully makes this it a little bit clearer. I think it’s a bit strange, because before the DST change, it has worked. That’s why I think maybe this is a bug.

Regards,
LJ

No problem at all. I’m still a beginner so therefore I have to ask a bit more to understand your problem. And when testing it seems to be a problem to me too.
In the past I always thought that it is not possible to use DateTime Items with offset values. But if Rich says it works, it will work.
Now when I try to test your SetUp I was astonished. I got the same result as you, when using “set#start”-Offset. But when using “rise#start” -Offset it works.
Here are the results:
astro.things

Thing astro:sun:stowing1   "Offset 200"     [geolocation="48.xxxxxx,9.yyyyyyy,502", interval=300]{
  Channels:
    Type rangeEvent : noon#event [
      offset=200,
      earliest="13:00"
    ]
    Type start : rise#start [
      offset=90,
     earliest="13:00"
    ]
    Type end : rise#end [
      offset=90
    ]
    Type start : set#start [
      offset=90,
      earliest="23:50"
    ]
  }

astro.items

......
DateTime              Sunset_Time                     "Sonnenuntergang [%1$tH:%1$tM]"                                       <sunset>                  (gAstro)      {channel="astro:sun:local:set#start"}
DateTime              Sunset_Time_Test                     "Sonnenuntergang Test[%1$tH:%1$tM]"                                       <sunset>                  (gAstro)      {channel="astro:sun:stowing1:set#start"}
DateTime              Sunrise_Time                    "Sonnenaufgang [%1$tH:%1$tM]"                                         <sunrise>                 (gAstro)      {channel="astro:sun:local:rise#end"}
DateTime              Sunrise_Time_Test                    "Sonnenaufgang Test[%1$tH:%1$tM]"                                         <sunrise>                 (gAstro)      {channel="astro:sun:stowing1:rise#start"}
....

Basic UI - Result

So you are right and I am wrong. Now for me it seems to be a bug too. I will tinker with it for the next days and give you a reply about the results(if I find some).

Cheers,
Peter

Good news!!
When I logged in to the Shell with Putty, I saw that an update is present. I installed it via Openhabian-Config and made a restart of openHAB.
And that’s the result:

Testing-SetUp was:
astro.things

..... only offset-Thing
Thing astro:sun:stowing1   "Offset 200"     [geolocation="48.xxxxxx,9.yyyyyyy,502", interval=300]{
  Channels:
    Type rangeEvent : noon#event [
      offset=200,
      earliest="13:00"
    ]
    Type start : rise#start [
      offset=90,
     earliest="13:00"
    ]
    Type end : rise#end [
      offset=90
    ]
    Type start : set#start [
//      offset=90,
      earliest="23:50"
    ]
    Type end : set#end [
      offset=90
//      latest="23:50"
    ]
  }

astro.items

....
DateTime              Sunset_Time                     "Sonnenuntergang [%1$ta, %1$td.%1$tm.%1$ty,  %1$tH:%1$tM]"            <sunset>                  (gAstro)      {channel="astro:sun:local:set#start"}
DateTime              Sunset_Time_Test                "Sonnenuntergang Test[%1$ta, %1$td.%1$tm.%1$ty,  %1$tH:%1$tM]"        <sunset>                  (gAstro)      {channel="astro:sun:stowing1:set#start"}
DateTime              Sunset_Time_Test_End            "Sonnenuntergang Test End[%1$ta, %1$td.%1$tm.%1$ty,  %1$tH:%1$tM]"    <sunset>                  (gAstro)      {channel="astro:sun:stowing1:set#end"}
DateTime              Sunrise_Time                    "Sonnenaufgang [%1$ta, %1$td.%1$tm.%1$ty,  %1$tH:%1$tM]"              <sunrise>                 (gAstro)      {channel="astro:sun:local:rise#end"}
DateTime              Sunrise_Time_Test_End           "Sonnenaufgang Test End[%1$ta, %1$td.%1$tm.%1$ty,  %1$tH:%1$tM]"      <sunrise>                 (gAstro)      {channel="astro:sun:stowing1:rise#end"}
DateTime              Sunrise_Time_Test_Start         "Sonnenaufgang Test Start[%1$ta, %1$td.%1$tm.%1$ty,  %1$tH:%1$tM]"    <sunrise>                 (gAstro)      {channel="astro:sun:stowing1:rise#start"}
String                Season_Name                     "Jahreszeit [MAP(astroDE.map):%s]"                                    <season>                  (gAstro)      {channel="astro:sun:local:season#name"}

As you I’m running OH2.5M1, so the result for you should be the same. If you need additonal information or Item-Set/Rule-Set, don’t hesitate to give a reply.

Cheers,
Peter

Yes indeed!
I just updated and the problem is solved.
Thank you

No problem. It was a pleasure for me to help and to learn simultaneously from you and of course from @rlkoshak even it was a very, very long post about that DP :sweat_smile:
Cheers, Peter

Hi there, this isn’t fixed and I’m experiencing the same problem during all DST switches. It affected me in OH2.4 last October, and now under OH2.5 during today’s DST switch.

I’m using it for the blinds and the civilDawn event with:
offset: -15
earliest: 07:45
latest: 08:33

configured in the PaperUI. Now, due to my latitude, effectively the blinds open 07:45 all year round, except for +/- 2 weeks around December 21st, so I could just switch to a time-based event.

But I think I can surmise what is going on here. The Earliest and Latest times probably get internally stored as some DateTime object with a timezone attached. So on my still running OH instance that would be 07:45 CET, and well, technically that is the time that they opened this morning, except I’m in CEST now, and them opening at 08:45 wall clock time isn’t what was intended.

So the code is technically correct, but unhelpful.

A restart of the OH instance will of course fix this, as the process will then start up in the CEST timezone and base all calculations off of that.

My fix now is to try with these cronjob entries that should do the trick, but it’s still a bug.

# In Mar/Oct, restart OH _if_ the timezone has changed compared to yesterday (DST switch)
21 3 * 3,10 7   root    test `date +%%Z -d "1 day ago"` = `date +%%Z` || service openhab2 restart

Problematic logs:

# grep "astro.*civilDawn" events.log.7 events.log
events.log.7:2020-03-28 07:45:00.010 [vent.ChannelTriggeredEvent] - astro:sun:10587c17:civilDawn#event triggered START
events.log.7:2020-03-28 07:45:00.013 [vent.ChannelTriggeredEvent] - astro:sun:10587c17:civilDawn#event triggered END
events.log:2020-03-29 08:45:00.006 [vent.ChannelTriggeredEvent] - astro:sun:10587c17:civilDawn#event triggered START
events.log:2020-03-29 08:45:00.011 [vent.ChannelTriggeredEvent] - astro:sun:10587c17:civilDawn#event triggered END

Note that 2020-03-28 is CET and 2020-03-29 is CEST, basically.

@ljsquare please don’t restart your OH instance today and let me know what happens tonight :slight_smile:

I don’t think any github issue was created for this.