Hi OH Enthusiasts,
currently i control my rollershutters with a rademacher homepilot. There ist is very easy to define rules like “On Sunset+10 Minutes, Earliest 18:°° latest 22:°°”
I concentrate all logic currenty in OH. This allows me to do things like “but not if the door is open”.
I know about astro binding and cron rules. But how can i smartly combine them?
I could try to check every 5 min for reached condition. Uuugly.
I could write a rule at sunset, doing nothing before 6. A rule at 6, acting if sunset is over and a rule at 8, acting if sunset was not yet. Less ugly, but not blessed with inherent beauty.
Do you have smart ideas, how i could handle that?
My idea would be to use ‘helper items’ like
create a rule that sets the item 'its_morning* to ON at 6 and to OFF at 8.
Then you can create a rule liek
if sunset changed
OR its_morning changed
if sunset = OFF and its_morning = ON
SET rollerstutter to ON
or something like that.
But maybe there is a better way…
Take a look at this thread. Your solution could be based on that design pattern.
NOTE: I’ve added an openHAB 2 Astro 2.0 binding version at the end.
NOTE: I’ve added an openHAB 2.2 version to the end which avoids the deprecation warnings on getCalendar()
Another transfer of a Design Pattern from the
great big Design Pattern thread. I move them over to a new separate thread as I need to reference them in an answer to a question. NOTE: the rules have been extensively reworked to make them shorter and simpler.
Often in home automation one has certain rule…
Christoph, Robert: Thanks for your suggestions!
@gerrieg the longer i think the more i would wonder: Wouldnt the simplest way for such requirement to have upper/lower boundariess in the definition of Astro Binding?
Something like additional fields in the range event? Should be well enough hidden but still easy to use, While the logic will most likely be rather simpel there…
This can be implemented with parameters on the event. I will add it.
@gerrieg would be awsome!
Shall i add a feature request?
Thinking about the implementation i’m not sure about the exact behaviour.
Example for sunrise:
If the sunrise is before 18:00, should the event not take place or be moved to 18:00?
The same with latest, if sunrise is after 20:00, move to 20:00 or no event?
Exactly. sunrise is 17:40, but “earliest” is set to 18:00 so the event is moved to 18:00.
If the actual sunrise is 22:10 but latest is 20:00 the event is moved 20:00.
Easiest use case in the morning: i want to wake up typically at 7:00. So i want to open shutters at 7:00.
But its pointless to open while it is still dark outside, since i do not want to entertain (or frighten) the neighbors.
So: Sunrise ± some minutes earliest at 7:00.
Great! I’ll update tonight!
Well - in the snapshot it did not arrive yet…
now i see, the PR is not merged. What can i do to test?
Great news !! how can we configure and test it ? (not really sure)
Guys, can you help me out here please: Where do I need to add these earlest/latest statements please?
The Channels / Things are visible in the PaperUI, but as I understood, these parameters need to be added to the channel? How? Or are they to be used within a rule, like
rule "Rollershutters DOWN at civil dusk"
Channel ‘astro:sun:local:civilDusk#event’ triggered END latest 21:00
Thanks for pointing me in the right direction
At sun/moon things config page, you could edit each range event and set the earliest/latest in the channel config.
Hm, I can set the offset but not the earliest/latest paramater.
Clicking on the pencil icon for the respective event, there is only a field for the Offset
may your system is not up to date? im using snapshot and i got the new channel config abilities.
Well, apt-get update && apt-get upgrade does not fetch anything new, so I would assume I am? (stable version at least)
What can i do to test?
Michael, I’m scratching my head about the syntax of the new features in that PR.
Did you get to make it working and do you have any examples?
I’m interested in the datetime offset and the earliest/latest feature …