no. i have no clue how to specify this inside the configuration files 
There’s an example in another thread showing the offset parameter and links to the updated docs:
To use config files only, I personally have:
astro.things:
astro:sun:local [ geolocation="55.0,-1.0", interval=900 ]
The linked example then gives astro.items including the syntax to define an offset (e.g. to display the times on a sitemap). I’ve not seen (yet!) a worked example of rules with an offset trigger but as the feature has only just been added to the Astro binding, there are several people hard at work researching just this point…
Good luck!
Oh no … don’t blame me … I’m just guessing. But I’m working on it … See messages on down in that other thread as we continue to try (or if someone takes pitty on us). If I get it working I’ll post something there for sure.
Found a solution. Have a look here: https://community.openhab.org/t/astro-binding-to-move-switches-at-sunset-sunrise/18750/21
Hi @davorf,
I recently wrestled with triggering astro events and it works with the following setup:
rule "Lights on at sunset"
when
Channel 'astro:sun:local:set#event' triggered START
then
logInfo("Sunset", "Sunset rule trigerred!")
postUpdate(Sunset_Event, ON)
end
Is that similar to what you have tried? (On OH2)
Hello!
My rule trigger looks exactly like that. The problem was hidden character between Channel and first quotation mark (I really don’t know how it got there), and it was shown only when I’ve opened rules file in Notepad++.
Best regards,
Davor
Hello @itheiss, @Ctrl-G, @UglyKidJoe and all the others out there. It would be a big help for everyone, if you could enhance the astro README.md with your findings.
You could enhance the descriptions or give more examples. Both would be great. You can either directly create a Pull Request for this file or create a simple Ticket proposing your changes. If you’ve got a nice set of configured items, rules and a sitemap arrangement around the astro binding, you could also post an article in the Tutorials & Examples category.
Thanks for giving back to the community! 
1 Like
when
Channel 'astro:sun:local:set#event' triggered START
then
I wonder about the choosen syntax for events…
To me the above feels a bit “on a different” level than other triggers used in rules. What I mean is that “normally” one creates items to hide these kind of details (the mapping to a particular channel of a particular thing).
It would have been more natural (to me at least) to define the following either in an .items file (or maybe in a new kind of .events file?):
Event SunriseEvent { channel = "astro:sun:local:set#event" }
and then use something along the lines of this in a rule:
when
Event SunriseEvent changed to START
then
or maybe
when
Event SunriseEvent triggered
then
Does anybody know why the choosen syntax was; eh… choosen?
Hi Thom,
I will gladly contribute to the documentation for this or any other bindings. Being relatively new to OH2 I can help identify where the documentation is thin as I mainly rely on step-by-step instructions, and if it’s not clearly written I would stumble.
Craig
I agree and I believe the answer is 1) nobody did define that item type yet and 2) the nature of this item is unclear as an event does not have a value at a given point of time. In OH1 the astro events were simulated by switches being switched on and back off immediately, which is a workaround.
The topic is discussed in this issue:
Feel free to take part in the discussion there 
Sounds good. The first step (after stumbling) should be to create a ticket. Noting down your idea for improvement is the most important step, working out the details can still be done later by you or also others. Is there any area you would like to get active? I can help with the details.
I think I’ve made a pull request on the Astro ‘readme’ file:
I’ll contribute to the documentation through each step of my journey. I wen’t straight to OH2 as a beginner, so my focus would be entirely on OH2 implementations. Hopefully this approach can help eliminate some confusion between the two architectures. I found this to be a bit tricky as a novice. I’ll be mindful about where I can help along the way.
In the OH1 binding, I never understood why the switch state wasn’t defined to mean “the sun is UP” – so it is in the ON state all the time that the sun is up, and OFF all the time that the sun is down. So it’s conceptually no different than any other binary state condition. And of course, altering it by time offsets, say, 30 minutes after sunrise, would just mean the switch is ON from thirty minutes after sunrise, all the time until the ending offset. Any rule triggering on Item IsSunUp changed to ON would catch the moment of sunrise. Every time the job doing the calculation is run, it simply updates the bound switches to whatever the correct state is. Simples!
1 Like
Regarding the different events you might want to check here: Explanation of eveningNight and morningNight
As you can see the idea was I believe to have the event of the sun passing the horizon as one distinguishable state rather than “The sun is up”. Why? I don’t know. I also had a rule to generate this state.
Regarding the events: not everything can be represented as a switch between states. It’s possible of course but not always meaningful. I believe more motivation is available in the respective PRs.
Maybe @kaikreuzer wants to say a few more things regarding events/triggers. Many, me included, are still not quite familiar with this silently arising new concept.
I am referring to this section of the code:
/**
* Publishes the item state ON/OFF for scheduled events.
*
* @author Gerhard Riegler
* @since 1.6.0
*/
public class ItemJob extends AbstractBaseJob {
@Override
protected void executeJob(JobDataMap jobDataMap) {
String itemName = jobDataMap.getString("itemName");
context.getEventPublisher().postUpdate(itemName, OnOffType.ON);
context.getEventPublisher().postUpdate(itemName, OnOffType.OFF);
}
}
So the Astro 1.x binding toggles a switch item, instead of putting it into the state that means “the sun is up” (for example). The point is that a rule can easily trigger on changed to ON, but subsequently other consumers would want to know the binary state of the sun. One can of course add a rule and another item to represent this, but I never understood the reason to treat the condition only as a trigger instead of a change in state, directly from the binding without needing a rule to achieve it. The same thinking in the 2.0 binding of using a Trigger channel seems to apply, but I’m not sure of that.
By the way, thanks for the link. My thinking is each of the entries in the table could be:
MorningNight ON 00:00
MorningNight OFF 04:00
Night OFF 05:02
AstroDawn ON 05:00
AstroDawn OFF 05:45
NauticDawn ON 05:45
NauticDawn OFF 06:27
...
Night ON 21:33
EveningNight ON 21:33
EveningNight OFF 00:00
Hello!
When loading openhab 2 in the log:
2017-03-10 15:38:18.782 [INFO ] [ding.astro.handler.AstroThingHandler] - Scheduled astro job-daily-sun at midnight for thing astro:sun:local
2017-03-10 15:38:18.822 [INFO ] [ding.astro.handler.AstroThingHandler] - Scheduled astro job-positional with interval of 300 seconds for thing astro:sun:local
2017-03-10 15:38:18.861 [INFO ] [ding.astro.handler.AstroThingHandler] - Scheduled astro job-daily-sun at midnight for thing astro:sun:local
2017-03-10 15:38:18.866 [INFO ] [ding.astro.handler.AstroThingHandler] - Scheduled astro job-positional with interval of 300 seconds for thing astro:sun:local
2017-03-10 15:38:19.554 [ERROR] [.astro.internal.job.AbstractDailyJob] - Unable to store Job : 'astro:sun:local.job-event-start-set#event', because one already exists with this identification.
org.quartz.ObjectAlreadyExistsException: Unable to store Job : 'astro:sun:local.job-event-start-set#event', because one already exists with this identification.
at org.quartz.simpl.RAMJobStore.storeJob(RAMJobStore.java:279)[106:org.eclipse.smarthome.core.scheduler:0.9.0.201703060943]
at org.quartz.simpl.RAMJobStore.storeJobAndTrigger(RAMJobStore.java:251)[106:org.eclipse.smarthome.core.scheduler:0.9.0.201703060943]
at org.quartz.core.QuartzScheduler.scheduleJob(QuartzScheduler.java:886)[106:org.eclipse.smarthome.core.scheduler:0.9.0.201703060943]
at org.quartz.impl.StdScheduler.scheduleJob(StdScheduler.java:249)[106:org.eclipse.smarthome.core.scheduler:0.9.0.201703060943]
at org.openhab.binding.astro.internal.job.AbstractDailyJob.schedule(AbstractDailyJob.java:105)[208:org.openhab.binding.astro:2.1.0.201703092339]
at org.openhab.binding.astro.internal.job.AbstractDailyJob.scheduleEvent(AbstractDailyJob.java:72)[208:org.openhab.binding.astro:2.1.0.201703092339]
at org.openhab.binding.astro.internal.job.AbstractDailyJob.scheduleRange(AbstractDailyJob.java:58)[208:org.openhab.binding.astro:2.1.0.201703092339]
at org.openhab.binding.astro.internal.job.DailyJobSun.schedulePlanetEvents(DailyJobSun.java:33)[208:org.openhab.binding.astro:2.1.0.201703092339]
at org.openhab.binding.astro.internal.job.AbstractDailyJob.executeJob(AbstractDailyJob.java:47)[208:org.openhab.binding.astro:2.1.0.201703092339]
at org.openhab.binding.astro.internal.job.AbstractBaseJob.execute(AbstractBaseJob.java:40)[208:org.openhab.binding.astro:2.1.0.201703092339]
at org.quartz.core.JobRunShell.run(JobRunShell.java:202)[106:org.eclipse.smarthome.core.scheduler:0.9.0.201703060943]
at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:573)[106:org.eclipse.smarthome.core.scheduler:0.9.0.201703060943]
2017-03-10 15:38:19.669 [ERROR] [.astro.internal.job.AbstractDailyJob] - Unable to store Job : 'astro:sun:local.job-event-end-set#event', because one already exists with this identification.
org.quartz.ObjectAlreadyExistsException: Unable to store Job : 'astro:sun:local.job-event-end-set#event', because one already exists with this identification.
at org.quartz.simpl.RAMJobStore.storeJob(RAMJobStore.java:279)[106:org.eclipse.smarthome.core.scheduler:0.9.0.201703060943]
The first and second lines are repeated twice.
Errors about events do not appear at every boot,
For the test, rebooted 3 times, 2 times error, 1 not.
Tried an astro to add through a file and through the paperUI. The result is the same.
astro.things:
astro:sun:local [geolocation="52.4546,103.8195", interval=60]
astro.items:
Group gAstro
Number sun_elevation "elevation [%.2f °]" <sun> (gAstro) { channel="astro:sun:local:position#elevation" }
DateTime sun_astrodawn "astrodawn[%1$tH:%1$tM]" <sunrise> (gAstro) { channel="astro:sun:local:astroDawn#start" }
DateTime sun_rise "rise[%1$tH:%1$tM]" <sunrise> (gAstro) { channel="astro:sun:local:rise#start" }
DateTime sun_noon "noon[%1$tH:%1$tM]" <sun> (gAstro) { channel="astro:sun:local:noon#start" }
DateTime sun_set "set[%1$tH:%1$tM]" <sunset> (gAstro) { channel="astro:sun:local:set#start" }
DateTime sun_night "night[%1$tH:%1$tM]" <moon> (gAstro) { channel="astro:sun:local:night#start" }
String season_name "season name [MAP(season.map):%s]" (gAstro) { channel="astro:sun:local:season#name" }
DateTime season_spring "spring [%1$td.%1$tm.%1$tY %1$tH:%1$tM]" <rain> (gAstro) { channel="astro:sun:local:season#spring" }
DateTime season_summer "summer [%1$td.%1$tm.%1$tY %1$tH:%1$tM]" <garden> (gAstro) { channel="astro:sun:local:season#summer" }
DateTime season_autumn "autumn [%1$td.%1$tm.%1$tY %1$tH:%1$tM]" <wind> (gAstro) { channel="astro:sun:local:season#autumn" }
DateTime season_winter "winter [%1$td.%1$tm.%1$tY %1$tH:%1$tM]" <climate-on>(gAstro) { channel="astro:sun:local:season#winter" }
Help get rid of errors.
Thank you!
Hi I have recently tried to upgrade from openhab1 to openhab2. After a while I finally made it. But still there are some issues regarding the astro binding:
- Offsets work for Event Channels but not for normal Channels
- Earliest/Latest does not work at all
My configuration:
astro.things:
astro:sun:now [ geolocation="51.434973,6.261548", interval=300 ] { }
astro:sun:before [ geolocation="51.434973,6.261548", interval=300 ] {
Channels:
Type rangeEvent : rise#event [
offset=-15
]
Type rangeEvent : set#event [
offset=-15
]
}
astro:sun:after [ geolocation="51.434973,6.261548", interval=300 ] {
Channels:
Type rangeEvent : rise#event [
offset=15
]
Type rangeEvent : set#event [
offset=15
]
Type start : rise#start [
offset=15
]
Type end : rise#end [
offset=15
]
Type start : set#start [
offset=15
]
Type end : set#end [
offset=15
]
}
astro:sun:afterlatest [ geolocation="51.434973,6.261548", interval=300 ] {
Channels:
Type rangeEvent : rise#event [
offset=15,
latest="08:00"
]
Type rangeEvent : set#event [
offset=15,
latest="20:00"
]
}
astro.items:
DateTime Sunrise_Time "Sunrise [%1$tH:%1$tM]" <sun> (PersistDaily) { channel="astro:sun:now:rise#start" }
DateTime Sunset_Time "Sunset [%1$tH:%1$tM]" <sun> (PersistDaily) { channel="astro:sun:after:rise#start" }
Today, both ‘astro:sun:now:rise#start’ and ‘astro:sun:after:rise#start’ show 5:26h AM which is in fact the time without any offset included.
I also defined some logging rules to see the event triggering with the following result:
2017-05-30 21:22:01.566 [INFO ] [pse.smarthome.model.script.fritzdect] - astro:sun:before:set#event SUCCESS
2017-05-30 21:37:00.049 [INFO ] [pse.smarthome.model.script.fritzdect] - astro:sun:now:set#event SUCCESS
2017-05-30 21:52:00.028 [INFO ] [pse.smarthome.model.script.fritzdect] - astro:sun:afterlatest:set#event SUCCESS
2017-05-30 21:52:00.032 [INFO ] [pse.smarthome.model.script.fritzdect] - astro:sun:after:set#event SUCCESS
Offsets are used but according to the definition ‘latest=“20:00”’ the ‘astro:sun:afterlatest:set#event’ should not occour at 21:52h but at 20:00h.
one addition:
via PaperUI I am able to maintain offsets only for range events but not for channels.
the latest/earliest cannot be entered at all. So the GUI does not offer me the functionality that I am trying to use via config files.
Is that not yet included in openhab 2.0? The dosumentation of the binding does not tell anything about this so I assumed that it should be in 2.0
Best regards
Alex
You can’t change settings through Paper UI when the setting is defined through a config-file, i.e. either use Paper UI to define the thing(s) or use the things-file to change settings 
I know that this is not possible. I just wanted to state that those options I wanted to use (and do not work) are not offered by the UI even if I setup everything via UI.