Astro binding to move switches at sunset/sunrise

I can’t fully answer why you are having the problem but I do notice the following:

  • the channel names are different between your sunrise and sunset rule trigger names. One references home which does match your Things and the other matches local which is different from your Things.
  • 4.0.8 is not a valid OH version number
1 Like

@rlkoshak Thanks! I don’t know why I did not see that. I changed local to home, hopefully that was the error.
I am actually using openhab 2.1.0, my bad, but 4.0.8 is what typing in ‘version’ returns in the openhab console… strange.

That’s the version of the Karaf server upon which OH runs.

Ah, that makes sense. Thank you. With the name (local -> home) everything is working great now

rule "example trigger rule"
Channel ‘astro:sun:home:rise#event’ triggered START


This will give an ON with no duration, means it will switch to OFF right after the ON.
I you need a steady ON/OFF you can use the above rule and use a proxy item.

As some have maybe seen, i moved forward to OH2. Right now i update Astro and have one issue regarding Sunset events. Previously i did it like this:

Switch MySunset_Event {astro=“planet=sun, type=set, property=end, offset=15”}

Now my questions:

  • Does such an item still exist to reference it later in a rule to switch on another item?
  • Or is the Rule above the way to go forward with OH2?
  • With the rule above, do I have any issue with this “going on with no duration”…if in the rule i want to switch on a device simply when sunset has come?

Best Regards,

Offsets and earliest/latest events have to be defined in the channel, either in the things file or via PaperUI:

You may create those items, take a look at the Design Patterns:

Don’t fully understand this, but I don’t think you will have any issues …

The duration is mainly a concern for when people want to have a switch that remains ON for the full sunset time so they can check the sunset state and do something different in other rules.

The time of day design pattern shoes how to use the events, DateTimes, and how to keep track of the time of day without letting your rules with duplicated if(now.isAfter(sunrise) && now.isBefore(noon)) statements.


hm, i tried now to set an event via channel astro:sun:local:set#start. As to me it looked the most promising to what i want to reach…a trigger when sunset starts. Did not trigger. So I had a second look and saw that in the docs its stated to use the following channel: astro:sun:home:rise#event

Will do the same analog for set event. but my question is - in order to use events I have to use this “range event” channel. It does not work to simply make use of another channel like the one for set_start (?)


Event is the only channel that can be used to trigger rules. I am not entirely certain whether event corresponds with start our end but I think it’s.

It depends on how you did configure your astro things: if you got them through autodiscovery the are usually named

astro:sun:local and the corresponding channel needs to be astro:sun:local:rise#event.

If you defined it manually either through text files or via GUI, it can have different names, in my case for example:
so the corresponding channel trigger needs to be


In my PaperUI I see:

However, this rule never gets triggered:

rule "Zonsopgang - nachtverlichting uit"

    Channel 'astro:sun:local:rise#event' triggered START 
	logInfo("Astro","De zon komt op. Goedemorgen.")
    sendCommand(KNX_GV_Nachtverlichting_4_2_0, OFF)

So I guess I got the naming correct, but it still doesn’t work. Any idea?

Try to find out if the trigger does not work or the sendCommand does not work.

What does your events.log tell you? If you have something like

2017-08-27 06:32:00.145 [ChannelTriggeredEvent ] - astro:sun:local:rise#event triggered START

in your log your trigger works.

What does your openhab.log tell you?

If you have something like

2017-08-27 06:32:00.141 [INFO ] [.eclipse.smarthome.model.script.Astro] - De zon komt op. Goedemorgen.

in your log, again, your trigger works fine.

If your trigger works fine, try


The problem is really with the trigger, not the rule.

  • “astro:sun:local:rise#event triggered START” is not in events.log;
  • The loginfo I have in my rule does not put anything in openhab.log;

Then check via karaf if your astro binding is in state “active”

In Karaf I see:

openhab> feature:list|grep -i astro
esh-binding-astro                           | 0.9.0.SNAPSHOT   |          | Started     | openhab-addons-2.2.0-SNAPSHOT |
openhab-binding-astro                       | 2.2.0.SNAPSHOT   | x        | Started     | openhab-addons-2.2.0-SNAPSHOT | Astro Binding
esh-binding-astro                           | 0.9.0.SNAPSHOT   |          | Started     | addons-2.2.0-SNAPSHOT         |
openhab-binding-astro                       | 2.2.0.SNAPSHOT   | x        | Started     | addons-2.2.0-SNAPSHOT         | Astro Binding
openhab> bundle:list
178 | Active   |  80 |     | Astro Binding

So I guess that is fine?

No, it’s not.
You have two or even more bindings started, but not one of them is active.
You screwed up your setup!
Delete any astro bindings you may have in your addons folder, then install the astro binding through PaperUI and make sure it is “active”, not started.
Also make sure you don’t have any bindings loaded in your addons.cfg.

Edit: okay, did not see the last couple of lines (too much beer this evening :grinning: ).
If only ONE binding is active it should be fine. But why do you have so many astro bindings installed?
Clean up your installation, then it should work …

The only way I installed the Astro binding was via PaperUI. I don’t have any custom .JARs in the /addons folder. So I don’t know why I have multiple entries.

Anyway, this is what I have done now:

  • I uninstalled the Astro binding via PaperUI;
  • I remove the “local sun” and “local moon” things via PaperUI;
  • I stopped OH;
  • I uninstalled the offline add-ons (apt-get purge openhab2-addons). Not sure why I installed them in the first place.
  • I deleted the /tmp and /cache folder;
  • I started OpenHab;
  • Somehow I notice the local sun/moon where back (status Uninitialized). I tried to remove them again, but they remain in status “Removing”;
  • I installed the Astro binding via PaperUI;
  • My things are now in status “online” (despite removal attempts);
  • I was now able to remove them successfully (I guess you first need to remove things and then uninstall the binding - makes sense);
  • Using “search for things” I’ve found the new “local moon” and “local sun”;

My openhab.log shows:

2017-08-28 09:24:23.910 [INFO ] [ding.astro.handler.AstroThingHandler] - Scheduled astro job-daily-moon at midnight for thing astro:moon:local
2017-08-28 09:24:23.911 [INFO ] [ding.astro.handler.AstroThingHandler] - Scheduled astro job-daily-sun at midnight for thing astro:sun:local
2017-08-28 09:24:23.993 [INFO ] [thome.binding.astro.internal.job.Job] - Scheduled Astro event-jobs for thing astro:moon:local
2017-08-28 09:24:24.208 [INFO ] [thome.binding.astro.internal.job.Job] - Scheduled Astro event-jobs for thing astro:sun:local
2017-08-28 09:25:34.378 [INFO ] [stro.discovery.AstroDiscoveryService] - Evaluated Astro geolocation: latitude: 5X.XXXX, longitude: 5.XXXX

Karaf shows:

openhab> bundle:list
START LEVEL 100 , List Threshold: 50
 ID | State    | Lvl | Version                | Name
202 | Active   |  80 |     | Astro Binding


openhab> feature:list|grep -i astro
esh-binding-astro                           | 0.9.0.SNAPSHOT   |          | Started     | addons-2.2.0-SNAPSHOT   |
openhab-binding-astro                       | 2.2.0.SNAPSHOT   | x        | Started     | addons-2.2.0-SNAPSHOT   | Astro Binding

So the duplicate entries have been removed.

So now I’ll have to wait untill the sun sets before I can check if the trigger is now triggered correctly (the values in items were already populated correctly before).

Great clean up, good luck!

Thanks, but unfortunately the rule did not trigger. :-/

What the f**k? Sorry, no more ideas. There were some astro binding issues fixed with the latest snapshot, maybe you try do get that new snapshot working …