Need help getting astro sun offset to work

I’m trying to get the sun rise and sun set event offsets to work. I’ve

  • read through as many of the related forum posts as I can
  • made sure the offsets are on the event channel
  • made sure my rules are triggered from the event channel
  • tried to configure the binding in the UI and tried to configure the binding with a things file
  • restarted openhab after setting or changing offsets

Nothing I’ve done has induced the rule to fire at any time other than the exact sunrise or sunset time.

I’m

  • running 5.1.0.M2 inside a docker image
  • Using a definition like this:
astro:sun:local-offset-file [ geolocation="XXXX,YYYY", interval=60 ] {
    Channels:
        Type rangeEvent : rise#event [
            offset=60
        ]
        Type rangeEvent : set#event [
            offset=-60
        ]
        Type start : rise#start [
            offset=60
        ]
        Type end : set#end [
            offset=-60
        ]

}

And a UI-based rule configured like this:

configuration: {}
triggers:
  - id: "3"
    configuration:
      event: START
      thingUID: astro:sun:local-offset-file
      channelUID: astro:sun:local-offset-file:rise#event
    type: core.ChannelEventTrigger

Not sure if I”m doing something wrong, or if there’s a bug somewhere.

Any help would be appreciated.

I suspect there needs to be a separate Thing for each offset. This is working for me.

// Used to close blinds before sunset
astro:sun:SunsetOffset [ geolocation="xxxx.yyyy"] {
    Channels:
        Type rangeEvent : set#event [
            offset=-15
        ]
}

// Used to open blinds 30 minutes after sunrise
astro:sun:SunriseOffset[ geolocation="xxxx.yyyy"] {
    Channels:
        Type rangeEvent : rise#event [
            offset=30
        ]
}

Rules

// Close blinds at 15 minutes before sunset
rule CloseBlindsRule
when Channel "astro:sun:SunsetOffset :set#event" triggered START
then gBlinds.sendCommand(OFF)
end

// Open blinds 30 minutes after sunrise 
rule OpenBlindsRule
when Channel "astro:sun:SunriseOffset:rise#event" triggered END 
then gBlinds.sendCommand(ON)
end
1 Like

Have just one astro sun thing / channel without any offset. Link it to a DateTime item.

Then in your rule, you can specify an offset for a DateTime trigger.

Have just one astro sun thing / channel without any offset. Link it to a DateTime item.

Then in your rule, you can specify an offset for a DateTime trigger.

Would that work with a negative offset though?

I have these Thing definitions and DSL rule triggers which have been working fine for me for years now - similar to @JimH’s posting above.

Thing   astro:sun:mornings          [ geolocation="xx.xxxx,xx.xxxx, interval=60 ] {
    Channels:
        Type rangeEvent : rise#event [
            offset=-10
        ]
        Type start : rise#start [
            offset=-10
        ]
}

Thing   astro:sun:civillduskendevenings  [ geolocation="xx.xxxx,xx.xxxx, interval=60 ]  {
    Channels:
        Type rangeEvent : civilDusk#event [
            offset=-10
        ]
        Type end : civilDusk#end [
            offset=-10
        ]
}

With the following DSL rule triggers

when
	Channel "astro:sun: mornings:rise#event" triggered START
then

…

when
	Channel "astro:sun:civillduskendevenings:civilDusk#event" triggered END 
then

and the additional Thing rise#start and civilDusk#end definitions assigned to items so that the actual times can be displayed in my sitemap, e. g.

So apart from me using civilDusk instead of sunset, everything should work the same.

1 Like

Thanks for the link to this recent commit @jimtng !

Just for clarification - as I am also using earliest and latest, which I didn’t put in my example above, am I correct in assuming that these are currently still only possible through the Thing definition?

Channels:

        Type rangeEvent : rise#event [
            offset=-10,
            earliest="06:30",
            latest="8:30"

        ]

Type start : rise#start [
            offset=-10,
            earliest="06:30",
            latest="8:30"

        ]

Putting them in separate files doesn’t work for me. The start/stop items show the same thing (that the offset doesn’t affect anything).

I’ll try the time item thing as a workaround, but I’d still like to know why the offsets don’t work on the channels.

Could it be the rule trigger you are using?

I’ve never created rules in the UI, but my DSL rule, which does work correctly, is being shown in the UI rules as

configuration: {}
triggers:
  - id: "0"
    configuration:
      event: END
      channelUID: astro:sun:civillduskendevenings:civilDusk#event
    type: core.ChannelEventTrigger
conditions: []
actions:
…

so no thingUID, but generally also no hyphens in the name - the same for @JimH’s working solution.

I updated them to be:

astro:sun:SunriseOffset [ geolocation="X.X,Y.Y", interval=60 ] {
    Channels:
        Type rangeEvent : rise#event [
            offset=60
        ]
}
astro:sun:SunsetOffset [ geolocation="X.X,Y.Y", interval=60 ] {
    Channels:
        Type rangeEvent : set#event [
            offset=-60
        ]
}

And removed the thingUID from the rules, but no change in behavior.

It is so easy via MainUI, why bothering with text files?

Take the Range Event Channel, klick on Configure Channel:

Make your settings, in this case latest is 21:05 (for summertime) and if the Channel triggers before that add 20min, for today in Germany this would be 16:48 (for wintertime)

Rule Triggers:

DSL: Channel 'astro:sun:shutterkitchen:set#event' triggered START or
JS: triggers.ChannelEventTrigger("astro:sun:shutterkitchen:set#event", "START"),

If you want to display those times you need the set#start Channel from the Starting Time and make the same adjustments, then link that Channel to a DateTime itemtype.

DateTime ShuttersCloseKit { channel="astro:sun:shutterkitchen:set#start" }

I started with the main ui; it didn’t work there; read some posts somewhere suggesting a file; tried it there and it didn’t work there either. It doesn’t seem to make a difference where I configure it, it always triggers at the exact sunrise or sunset start time instead of offset.

Double check your rules trigger, for your setup you would need:

DSL: Channel 'astro:sun:shutterkitchen:rise#event' triggered START or
JS: triggers.ChannelEventTrigger("astro:sun:shutterkitchen:rise#event", "START"),

(Sorry, I don’t know the trigger for MainUI, I am using text files except for Things …

Yeah, the yaml for my rules trigger in the UI is in the original post.

Then I am out of ideas. This works for me since 10 years, my first time with openHAB.:sweat_smile:

You did install the Astro binding???

Lol. Yeah. The events fire. They just always fire at the regular time not the offset one.

I did this post years ago:

But unfortunately it is a victim of the missing pictures in posts that happened this year.

I have the same issue, the offsets doesn’t seem to have any effect (configured through mainUI in my case), either on the DateTime channels or the event channels.

I set up a test instance using latest milestone and have the set channels configured like this:

  - id: set#start
    channelTypeUID: astro:start
    label: Start Time
    description: The start time of the event
    configuration:
      offset: 60
  - id: set#end
    channelTypeUID: astro:end
    label: End Time
    description: The end time of the event
    configuration:
      offset: 0
  - id: set#duration
    channelTypeUID: astro:duration
    label: Duration
    description: The duration of the event
    configuration: {}
  - id: set#event
    channelTypeUID: astro:rangeEvent
    label: Range Event
    description: Range event
    configuration:
      offset: -60

I would expect the set#start to report a later time than set#end, and the events to be scheduled earlier, but when reinitializing (either by deactivating/activating the Thing, restarting the binding or restarting OH) I still get the same results as with no offset:

09:39:27.598 [DEBUG] [ro.internal.handler.AstroThingHandler] - Scheduled Event job astro:sun:5285c39a4b/set#event/START in 21737404ms (at 2025-11-23T15:41:45)
09:39:27.601 [DEBUG] [ro.internal.handler.AstroThingHandler] - Scheduled Event job astro:sun:5285c39a4b/set#event/END in 22035400ms (at 2025-11-23T15:46:43)
09:39:27.610 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'Astro_Sun_Set_Start_Time' changed from NULL to 2025-11-23T15:41:45.992+0100 (source: org.openhab.core.thing$astro:sun:5285c39a4b:set#start)
09:39:27.612 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'Astro_Sun_Set_End_Time' changed from NULL to 2025-11-23T15:46:43.714+0100 (source: org.openhab.core.thing$astro:sun:5285c39a4b:set#end)

Found the issue I think. If you configure an offset, you MUST also configure earliest and latest, to a time before resp after the offset time could occur, otherwise the offset will fail to apply. This is a bug IMO, will report an issue on github.

1 Like

Double check the following:

You need to do the same settings for offset/earliest/latest on the Start Time and the Range Event Channel.
The Start Time Channel needs to be linked to a DateTime itemtype and is not used for triggering, just for displaying:

DateTime ShuttersCloseKit { channel="astro:sun:shutterkitchen:set#start" } 

The Range Event Channel is used to trigger the rules via a Channel trigger:

Channel 'astro:sun:shutterkitchen:set#event' triggered START

Another Astro Thing shows the Time without an offset:

So for the rollershutter closing time it is exactly the +20 minutes like defined in the setup:

This is on 5.1.M2.

I inspected what happens in the debugger, the issue is here and here. If “latest” is not configured, the original time of the event is used (i.e,. before the offset was added), which causes the offset to be reset.

Just noticed there may be another issue also when using negative offsets, will investigate this more.

Update: for this the bug is in this method (the same as for the latest applies also if “earliest” is not configured), but also, if the default “00:00” is configured, the configuration will be ignored, again returning the original time of the event (before applying offset). So if using negative offsets, setting “earliest” to “00:01” works around the issue.

Update2: the bug was introduced in this PR.