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.
.things:
astro:sun:minus [ geolocation="52.069778,1.170409,47", interval=60 ] {
Channels:
Type start : rise#start [
offset=-30
]
Type end : set#start [
offset=-60
]
}
astro:sun:home [ geolocation="52.069778,1.170409,47", interval=60 ]
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.
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:
when
System started or
Time cron "0 0/5 * ? * *" //Every five minutes
then
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
sw_Dark_Day.sendCommand(OFF)
logDebug("KITCHEN","Initializing Dark Day to OFF")
}
if ((now_minute > calcDawn) && (now_minute < calcDusk)) {
if (sw_Logical_Night.state != OFF) {
sw_Logical_Night.sendCommand(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 ")
sw_Dark_Day.sendCommand(ON)
} else {
logDebug("STATUS","DARK DAY mode already ON")
}
} else {
if (sw_Dark_Day.state == ON) {
logInfo("STATUS","Turning DARK DAY mode OFF")
sw_Dark_Day.sendCommand(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) {
sw_Logical_Night.sendCommand(ON)
sw_Dark_Day.sendcommand(OFF)
logInfo("STATUS","Setting sw_Logical_Night to ON and DARK DAY mode off")
}
}
end
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.
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.
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.
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”
when
Channel ‘astro:sun:local:set#event’ triggered START
then
{
createTimer(now.plusMinutes(1410)) [ sendCommand(CourtyardDimmer, 45) ]
}
end
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.
