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
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"
]
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)
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.
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.
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.
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:
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.