Astro binding issue?

Tags: #<Tag:0x00007f21367da1c8>

(Ingo Theiss) #66

no. i have no clue how to specify this inside the configuration files :disappointed:

(James Derrick) #67

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: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!

(Bruce Lichius) #68

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.

(Ingo Theiss) #69

Found a solution. Have a look here:

(Craig) #70

Hi @davorf,

I recently wrestled with triggering astro events and it works with the following setup:

rule "Lights on at sunset"
	Channel 'astro:sun:local:set#event' triggered START
	logInfo("Sunset", "Sunset rule trigerred!")
	postUpdate(Sunset_Event, ON)

Is that similar to what you have tried? (On OH2)

(davorf) #71


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,

( ) #72

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 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! :tada:

(Kjetil Asdal) #73
	Channel 'astro:sun:local:set#event' triggered START

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:

	Event SunriseEvent changed to START

or maybe

	Event SunriseEvent triggered

Does anybody know why the choosen syntax was; eh… choosen?

(Craig) #74

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.


( ) #75

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 :wink:

( ) #76

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.

(Craig) #77

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.

(John Cocula) #78

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!

( ) #79

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.

(John Cocula) #80

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 {

    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

(Sergey M) #81

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([106:org.eclipse.smarthome.core.scheduler:]
	at org.quartz.simpl.RAMJobStore.storeJobAndTrigger([106:org.eclipse.smarthome.core.scheduler:]
	at org.quartz.core.QuartzScheduler.scheduleJob([106:org.eclipse.smarthome.core.scheduler:]
	at org.quartz.impl.StdScheduler.scheduleJob([106:org.eclipse.smarthome.core.scheduler:]
	at org.openhab.binding.astro.internal.job.AbstractDailyJob.schedule([208:org.openhab.binding.astro:]
	at org.openhab.binding.astro.internal.job.AbstractDailyJob.scheduleEvent([208:org.openhab.binding.astro:]
	at org.openhab.binding.astro.internal.job.AbstractDailyJob.scheduleRange([208:org.openhab.binding.astro:]
	at org.openhab.binding.astro.internal.job.DailyJobSun.schedulePlanetEvents([208:org.openhab.binding.astro:]
	at org.openhab.binding.astro.internal.job.AbstractDailyJob.executeJob([208:org.openhab.binding.astro:]
	at org.openhab.binding.astro.internal.job.AbstractBaseJob.execute([208:org.openhab.binding.astro:]
	at org.quartz.simpl.SimpleThreadPool$[106:org.eclipse.smarthome.core.scheduler:]
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([106:org.eclipse.smarthome.core.scheduler:]

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:sun:local [geolocation="52.4546,103.8195", interval=60]


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(]"						(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!

(Alexander F) #82

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:

  1. Offsets work for Event Channels but not for normal Channels
  2. Earliest/Latest does not work at all

My configuration:


astro:sun:now [ geolocation="51.434973,6.261548", interval=300 ] { }

astro:sun:before [ geolocation="51.434973,6.261548", interval=300 ] {
        Type rangeEvent : rise#event [
        Type rangeEvent : set#event [

astro:sun:after [ geolocation="51.434973,6.261548", interval=300 ] {
        Type rangeEvent : rise#event [
        Type rangeEvent : set#event [
        Type start : rise#start [
        Type end : rise#end [
        Type start : set#start [
        Type end : set#end [

astro:sun:afterlatest [ geolocation="51.434973,6.261548", interval=300 ] {
        Type rangeEvent : rise#event [
        Type rangeEvent : set#event [


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.

(Alexander F) #83

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

(Udo Hartmann) #84

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 :slight_smile:

(Alexander F) #85

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.