Thank you! I do (and did) see that in the paper UI. Even so I don’t have an example on how to reference this event vs. the non offset events. Also having a predefined number (there are 13 ?) is probably not the way to go either as I don’t see that working for vast population that we all hope end up using openHAB. It could easily be a limitation of the UI as it stands currently and the devs trying to get something out there that we can use (or more probably I’m just not very smart) but it seems to be a limitation that will bite us sooner rather than later. In any case, thank you for the info. I might set something up with this once I learn more … but I’m really hoping for some textual config. Perhaps Kai will have info along this line – or at least some alternative.
I did just find Defining Channels though and that may be more what I’m looking for.
Great that offsets finally become available. Thanks for your link too, Bruce! Would be great if you can “duplicate” a channel in Paper UI though (and then set properties individually).
In addition to the sample rules I will provide my easy solution for a light which switches on at 6am and goes off a couple of minutes after sunrise completes. If sunrise is already completed by 6am, the light will not go on at all.
import org.joda.time.*
import org.openhab.core.library.types.*
var Timer tMorningLightOff
rule "ruleMorningLightOnAndOff"
when
Time cron "0 0 6 ? * MON-FRI"
then
var DateTime dtSunRiseEnd = parse(astroSun1AmsterdamRiseEndDateTime.state.toString)
if(now < dtSunRiseEnd){
sendCommand(hueMediumGlobeDimmer, 30)
tMorningLightOff = createTimer(dtSunRiseEnd.plusMinutes(15)) [|
sendCommand(hueMediumGlobeDimmer, 0)
]
}
end
In an attempt to solve this problem in a way that I actually understand, I thought, I know … I’ll just be create multiple locations that I can reference all along the same latitude. If the longitude that I reference is 15 degrees apart from my own, then the sunset times of the other location will be an hour different (360 degrees / 24hrs per day = 15 degrees per hour).
Warning (Danger Danger) - The below is not tested as of this post! Use at your own risk.
So in my things file (sanitized in this example below for my protection) I now have:
astro:sun:home [ geolocation=“45.000000,-80.000000”, interval=60 ]
astro:moon:home [ geolocation=“42.000000,-80.000000”, interval=60 ]
Then if I want to turn on a light, say 60 mins before sunset I can simply:
// Stairwell Lights On at Sunset - 1 hour.
rule "Stairwell Lights On - Sunset - 1 hour"
when
Channel 'astro:sun:minus60:set#event' triggered START
then
sendCommand(swStairway, ON)
end
It looks like this should work out well until I can figure out how to do the offsets in a file. In the end I might not want them there but I don’t understand how to use them as they are - or even how to reference them if I define them.
So I’ve done the above and initially I got an exception in my logs. Touching the file fixed that and now I see a new Channel in PaperUI that wasn’t there before:
OK, I’ll probably have to wait a couple of days for that PR to filter down to the Docker image on DockerHub. Now that the Docker image build is working again it should not be long. Thanks!
I’m probably telling you something you already know, but if you take @itheiss example (slightly modified by me and therefor probably wrong) and then also duplicate it as below … you could do:
// 30 mins prior to sunsest
Thing astro:sun:homeMinus30 [ geolocation="xx.xx,yy.yyy", interval=60] {
Channels:
Type rangeEvent : set#event [
offset=-30
]
}
// 45 mins prior to sunsest
Thing astro:sun:homeMinus45 [ geolocation="xx.xx,yy.yyy", interval=60] {
Channels:
Type rangeEvent : set#event [
offset=-45
]
}
That should work for that … now for my soapbox …
All this “Thing” generation seems repetitive and resource intensive (it’s not like your going to need a trigger to occur on the nautical sunrise minus 30 mins on every additional astro thing you create). – Kind of going off the tracks here to possible system changes … and … Maybe should bring in @ThomDietrich here.) I think that we need some way to DEFINE a new range event (trigger channel?) at least in this example, based on an existing thing(s) above but possibly modified with parameters as in
NOT A WORKING EXAMPLE
// 30 & 45 mins prior to sunsest
Thing astro:sun:home [ geolocation="xx.xx,yy.yyy", interval=60] {
Channels:
Type rangeEvent : set#event : minus30 [
offset=-30
]
Type rangeEvent : set#event : minus45 [
offset=-45
]
}
END OF NOT A WORKING EXAMPLE
Where the “minus30” entry and the “minus45” in the above gets added to the list of available triggers (trigger channels?). Enter as many different ones as you would want. The good news is that more items that you don’t need aren’t added like they are when you define and entirely new astro ‘thing’. Then maybe one could reference it as in:
YET ANOTHER NON-WORKING EXAMPLE
rule "example trigger rule"
when
Channel 'astro:sun:home:set#event#minus30' triggered START
then
...
end
END OF YET ANOTHER NON-WORKING EXAMPLE
as the "#minus30 is simply added to the channel?
Thoughts? Maybe I should put this somewhere else? Am I missing something? Is this information anyone would want?
