Astro offset problem

Release: OH 2.1.0 Release Build

openhab> feature:list|grep -i astro
openhab-binding-astro1                      | 1.10.0           |          | Uninstalled | openhab-addons-legacy-2.1.0 | Astro Binding (1.x)
esh-binding-astro                           | 0.9.0.b5         |          | Started     | addons-2.1.0                |
openhab-binding-astro                       | 2.1.0            | x        | Started     | addons-2.1.0                | Astro Binding

I’m seeing a problem when the offset config for an astro thing doesn’t appear to work. The :set#event triggered START event happens at the same time as a separate thing without the offset.


astro:sun:minus [ geolocation="52.069778,1.170409,47", interval=60 ] {
        Type start : rise#start [
        Type end : set#start [
astro:sun:home  [ geolocation="52.069778,1.170409,47", interval=60 ]


DateTime vTwilight_Time "Twilight [%1$tH:%1$tM]"
    { channel="astro:sun:minus:set#start"}

DateTime vSunset_Time "Sunset [%1$tH:%1$tM]"
    { channel="astro:sun:home:set#start" }

The sitemap output:


2017-09-01 19:42:00.038 [ChannelTriggeredEvent     ] - astro:sun:minus:set#event triggered START
2017-09-01 19:42:00.128 [ChannelTriggeredEvent     ] - astro:sun:home:set#event triggered START

Any help appreciated, do I need to go to using a different location to get the time offset for the time being?


1 Like

I have Astro configured in PaperUI, and there I have to set the offset specifically for e.g. set#event. Not sure how you would do it in textual config, but I think that’s where the problem is.

I believe you can only provide an offset on the event, like @pacive mentions. If you need more than one offset event, you need more than one Thing, each with their own offset. If you are trying to offset the DateTime channels, like it appears you are trying to do here, you need to use the longitude trick. Adding 15 degrees to the longitude will subtract 60 minutes from the event.

So to get your 30 minute time before sunrise start you need to add 7.5 to the longitude. To get your 60 minute time before sunrise end, you need to add 15 to the longitude.

Thanks @pacive and @rlkoshak, I’ve added a further thing and modified the Type for the minus thing, and will wait and see what happens tomorrow…

astro:sun:minus [ geolocation="52.069778,1.170409,47", interval=60 ] {
        Type rangeEvent : set#event [
astro:sun:twilight  [ geolocation="52.069778,15.170409,47", interval=60 ]
astro:sun:home  [ geolocation="52.069778,1.170409,47", interval=60 ]


I’ll throw this in for another angle of attack. Astro binding is pretty flaky is some ways. I wanted a way to set some virtual switch items in a day/night fashion and a low-luminance detection mode so that my motion sensor in the Kitchen did not turn on the light every time I went in during the daytime BUT would turn on the light if it was a gloomy enough day that it was needed. I wanted my logical night to extend until an hour after sunrise and logical night to start an hour before dusk (my taste). (At the time I originally did this, event firing was a bit sketchy coming from Astro – do not know about now). I actually didn’t care that logical night/day occurred on the second, just needed to be “close enough for jazz”.

Switch	sw_Logical_Night
Switch  sw_Dark_Day

In theory the Astro MorningNightDuration value would tell me when sunrise should be ---- if it worked – it is supposed to be minutes from midnight to sunrise. It always returns zero. Likewise the Astro EveningNight Duration is supposed to be minutes from sunset to midnight. Except it returns the total minutes from sunset to the next sunrise – i.e. the whole of night time.

So my “close is good enough for my purposes” hack is this. There are 1440 minutes per day. Noon is therefore minute 720. Since daylight is evenly distributed around noon, if I subtract half the value of Astro’s DaylightDuration (which surprisingly DOES work), I’ll arrive at a number which is roughly around the minute of dawn. Likewise adding to 720 (the noon minute) half of DaylightDuration gives me a rough dusk minute.

I can apply whatever skew I want to that and compare to the current minute of the day and set my logical day/night.

Here’s the rule:

		System started or
		Time cron "0 0/5 * ? * *"   //Every five minutes
		var Number dlDur = DaylightDuration.state
		var Number niDur = NightDuration.state
		var Number dawnOffset = 60.0
		var Number duskOffset = -60.0
		var Number calcDawn = (720.0 - dlDur/2.0 + dawnOffset)
		var Number calcDusk = (720.0 + dlDur/2.0 +  duskOffset)
		var Number now_minute=now().getMillisOfDay()/(60000.0)
        if (sw_Dark_Day.state == NULL){  // first use
            logDebug("KITCHEN","Initializing Dark Day to OFF")
	if ((now_minute > calcDawn) &&  (now_minute < calcDusk))  {
		if (sw_Logical_Night.state != OFF) {
			logInfo("STATUS","Setting sw_Logical_Night to OFF")
            logInfo("KITCHEN","Kitchen Lux reading is: " + zz_lux_dsb05_demo.state)
            if (zz_lux_dsb05_demo.state < 200) {
			if (sw_Dark_Day.state != ON) {
				logInfo("STATUS","Setting DARK DAY mode ON ")
			} else {
				logDebug("STATUS","DARK DAY mode already ON")
            } else {   
		if (sw_Dark_Day.state == ON) {
			logInfo("STATUS","Turning DARK DAY mode OFF")
		} else {
			logDebug("STATUS","DARK DAY mode already OFF")
	} else {  //outside the calculated limits -- so it is Logical Night
		if (sw_Logical_Night.state != ON) {
			logInfo("STATUS","Setting sw_Logical_Night to ON and DARK DAY mode off")
1 Like

Nice work around. There have been a ton of fixes and such to Astro and that flakiness has gone away. I don’t know about the durations being zero though.

It still is 0 for MorningNightDuration and all night for EveningNightDuration.

Hi @bob_dickenson,

I’ve arrived at something similar, at least in terms of a method for Dark Days, and for closing curtains etc within the “DuskOffSet” period to prevent them closing/opening in changing light, especially around December/January.

I set up the things as described above in my previous post and have concluded that the only way the astro binding gives me the offset is to use the location hack.

It does leave me wondering, generally, what purpose the offsets within the rangeEvent (or others) are intended to serve - genuine question; is there a use case I’m missing?


It’s a really cool idea! For my better understanding, you don’t need astro things at all?
I have enough of restarting OH each 4-5 days due to recent astro bugs. Your solution is so logical, for simple sunrise/sunset firing.

You need the Astro value for Daylight Duration (which works) with Astro configured for your location.

The code snippet still contains a var declaration for NightDuration but it is actually not used at all. (Leftover from some testing.)

1 Like

Hi, just an update from my installation. Last friday i switched to the latest snapshot releases, many issues regarding astro binding already disappeared, i hope also the “weekly restart workaround” won’t be needed anymore.
Thaank anyway @bob_dickenson i’ll keep your suggestion for other automation rules.

No problem. It was a “workaround”.

I have the same problem, can anyone help? I want to use astro not openhab rules. Thanks!

I have the same problem.

I’m working through this myself too. As a possible work around, we could take the astro sun set time and just set a timer for the next day, as the daylight only changes a bit each day it’ll be very close. given there are 1440 minutes in a day, you just set the timer for 1440 minus how early you want it to fire. I’m new to OH so I’m not sure if this long of a timer is bad on the system, or if there’s a way to make it persist a reboot etc, but I’m going to try it out.

rule “Sunset CourtYard Dimmer On”
Channel ‘astro:sun:local:set#event’ triggered START
createTimer(now.plusMinutes(1410)) [ sendCommand(CourtyardDimmer, 45) ]

Not bad at all. It just uses a teeny tiny amount of extra memory. Nothing to worry about.

There isn’t. you will have to create a System started Rule and recreate the Timer.

But I believe the problem discussed in this thread have been fixed. The original post is from 15 months ago. There have been three official releases since then.

I recommend starting a new thread and clearly state the version of OH you are running, your configuration, and what your problem is.