AstroBinding with custom channels


After searching in the documentation and forum I need a hint in the right direction:
I want to implement several different rules based on the astro binding but with different offset and earliest/latest configurations.
Basically it would solve my problem if there is a way to add custom channels based on existing astro binding channels.

Thank you for any help.
I hope, I did not miss something obvious.

You know that you can configure multiple Astro Things, and each event group of those Things can have its own offsets? e.g. you might have many astro:sun:xxxx:rise channels, each with a different earliest/latest/offset setting.

Thank you rossko57, that helped! Now it works!

I need also a little help on that.

If I look in the binding docu it tells me to add the latest at the channel property.
But where should I enter this in the design view,
Or in the code view?

My code view looks like that

configuration: {}

  • id: “1”
    thingUID: astro:sun:local
    event: START
    channelUID: astro:sun:local:set#event
    type: core.ChannelEventTrigger
    conditions: []

  • inputs: {}
    id: “4”
    type: application/javascript
    script: >
    var logger =
    Java.type(‘org.slf4j.LoggerFactory’).getLogger(‘org.openhab.rule.’ +


You seem to be a showing us a Rule. Can’t use that to do offsets.
Look for your Astro Thing and edit its channel.

This might help:

Thanks rossko57 and ubeaut,
I will check this later. Pause in homeoffice is over.

I tested the solution from ubeaut. And it looks that it is working.
One strange thing.
After I change the ‘earliest’ value, I can see the correct start-time in the items. In my case it was ‘sun-set , earliest 20.00’.
But on the normal sun-set time, 18:14, the blinds were closed. After that I manually moved them up again,
and at 20:00 they moved down again.

I will check whats happen today.
best regards

Channel config
Offsets: For each event group you can optionally configure an offset in minutes. The offset must be configured in the channel properties for the corresponding thing.

The minimum allowed offset is -1440 and the maximum allowed offset is 1440.

Earliest/Latest: For each trigger channel and start, end datetime value, you can optionally configure the earliest and latest time of the day.

e.g sun#set earliest=18:00, latest=20:00

sunset is 17:40, but earliest is set to 18:00 so the event/datetime value is moved to 18:00.


sunset is 22:10 but latest is set to 20:00 so the event/datetime value is moved 20:00.

Yes, I read this. But after I changed it, I was wondering why the blinds were moved twice.
One time at the original sun set and one time at the moved sunset.

I changed the setting at 16:00. So first move down was at 18:14, 2nd at 20:00

Set the START or END of the event trigger otherwise the rule will fire twice (START and END)

Already done. I set it to start. But also with start it happens two times.
My explanation. The original time is stored in the Kalender. After I changed the earliest value, a second entry was created.
So we will see what happens this evening

Most likely had no effect, until you reboot or next midnight.
But it is possible it scheduled a new event without removing the original schedule.
You might have ended up with START normal, and END with offset.

Many bindings are clumsy about handling in-flight Thing edits.

Examine your events.log for the times, look for astro events.

It’s not clear what you are looking at here.
Be clear about this - Astro binding has two types of channels, state channels and event channels, State channels can be linked to Items, event channels can trigger rules. They each have their own offset configuration. So applying an offset that shows up in a “Sunrise” Item will not affect sunrise event triggers by itself.

Ok this evening it works perfect. So maybe the reason was that all times were only calculated one time a day or the old entry was not overwritten. But now everything is OK

If I change the astro settings I restart Openhab so I don’t have to wait until midnight when it recalculates apparently.