I couldn’t add a sleep at the top of the file. Maybe i used the wrong syntax (i am new to all this )
I did comment out ‘System started or’ like below:
val logName = "weather"
rule "Calculate time of day state"
when
//System started or
Channel 'astro:sun:local:rise#event' triggered START or
Channel 'astro:sun:local:set#event' triggered START or
Channel 'astro:sun:minus90:set#event' triggered START or
Time cron "0 0 6,23,0 * * ? *" // there is currently a bug where only one cron is triggered per rule so I've combined all three into one
then
Thread::sleep(1000) // make sure we are a tad past midnight to give Astro a chance to recalculate DateTimes for today
val long morning_start = now.withTimeAtStartOfDay.plusHours(6).millis
val long day_start = (vSunrise_Time.state as DateTimeType).calendar.timeInMillis
val long afternoon_start = (vEvening_Time.state as DateTimeType).calendar.timeInMillis
val long evening_start = (vSunset_Time.state as DateTimeType).calendar.timeInMillis
val long night_start = now.withTimeAtStartOfDay.plusHours(23).millis
val long bed_start = now.withTimeAtStartOfDay.millis
var curr = "UNKNOWN"
switch now {
case now.isAfter(morning_start) && now.isBefore(day_start): curr = "MORNING"
case now.isAfter(day_start) && now.isBefore(afternoon_start): curr = "DAY"
case now.isAfter(afternoon_start) && now.isBefore(evening_start): curr = "AFTERNOON"
case now.isAfter(evening_start) && now.isBefore(night_start): curr = "EVENING"
case now.isAfter(night_start): curr = "NIGHT"
case now.isAfter(bed_start) && now.isBefore(morning_start): curr = "BED"
}
if(vTimeOfDay.state.toString != curr) {
logInfo(logName, "Current time of day is now " + curr)
vTimeOfDay.sendCommand(curr)
}
end
Now my log doesn’t show the error anymore, strange isn’t it?
I hope you know what could cause this?
btw, what will be the consequences for commenting out what i did?
Rich, i think i found whats wrong.
When i comment out my item with:
{ channel="astro:sun:minus90:set#start" }
The rule starts working and i get the following a message in my log, which indicates to me that everything is working:
2017-06-20 13:55:53.018 [INFO ] [lipse.smarthome.model.script.weather] - Current time of day is now DAY
There seems to be a syntax problem with ‘minus90’ but i don’t know how to write it properly, do you perhaps have any clue?
And is this working for you on OH2? because that seems strange to me
I am on the OH2 snapshots
Commenting out the System started trigger stops the error because it stops the rule from firing when the system restarts or the rules file loads. This breaks the rule as your TimeOfDay Item won’t have a value, potentially for hours.
My example is a complete example, including the Things. As you see in the op, I define two Things, one named astro:sun:home and one named astro:sun:minus90. The trigger channel must match the names of the Things you have defined. If you did autodiscovery rather than defining your own things like my example you must change the names in the rule trigger to match your Things.
Rich,
i am truly sorry, i assumed (and didn’t read carefully) that my auto detected things were sufficient.
I added the minus 90 thing and for the others i used the auto detected things and everything seems to work now.
Thanks for your patience
One question i have, you seem to put a “v” infant of, for example: vSunset_Time and vTimeOfDay where on other places those “v”'s are missing, do these “v”'s have a purpose?
To tl;dr the posting sihui is its just a naming convention that I’ve evolved over time. Starts with a:
“v” indicates a value or a sensor
“a” indicates an actuator (i.e. something you can command)
“g” indicates a Group.
When I wrote the original pre-OH 2 version of the design pattern I had not yet adopted this naming convention. And even now I often try to remove them from my postings but I guess I was in a hurry this time and left them in.
For future reference of everyone looking at this Design Pattern, in the OpenHAB 2.0 Astro binding, you can define your offset in the astro.things file without making changes to your lat/long:
// Sunrise/sunset triggered 30 minutes before event
astro:sun:homeOffsetMinus30 [geolocation="1.234567890,-1.234567890",altitude=50,interval=60] {
Channels:
Type rangeEvent : rise#event [
offset=-30
]
Type rangeEvent : set#event [
offset=-30
]
}
// Sunrise/sunset triggered 30 minutes after event
astro:sun:homeOffsetPlus30 [geolocation="1.234567890,-1.234567890",altitude=50,interval=60] {
Channels:
Type rangeEvent : rise#event [
offset=30
]
Type rangeEvent : set#event [
offset=30
]
}
// Normal sunrise/sunset trigger times
astro:sun:home [geolocation="1.234567890,-1.234567890",altitude=50,interval=60]
astro:moon:home [geolocation="1.234567890,-1.234567890",interval=60]
if, for example, you define an offset for sunset, you cannot get an event from the actual sunset and your offset; you will need to define multiple Things
if you want the offset’s time as a DateTime you need to define a Thing using the lat/log offset. And because this Design Pattern requires both the event and the DateTime (in the System started rule) the offset is required.
Altitude I hardly knew you. I just noticed it was there a couple of weeks ago and now it’s gone. I’m not certain it ever really did much.
Note, altitude is still mentioned in the binding’s docs.
All Things require the parameter geolocation (as <latitude>,<longitude>,[<altitude in m>]) for which the calculation is done.
I like your design pattern to control heat and lights. You an me like to edit 6 and 23 in the rule file directly, however my girlfriend does not like this and would like to be able to alter it outside the rule through the sitemap. How can this be achieved? Especially tricky is the +15degree for the evening thing!
I would assume I could make two items called Number morningSetPoint and Number nightSetPoint and then in the rule, (Number) morningSetPoint.state instead of the 6 in your rule
Actually, I prefer to just set it and forget it. These values do not ever change in my set up, or at least change infrequently enough that there is no compelling need to provide a way to do so in the sitemap.
Unfortunately, you are asking for one of the harder things to do in OH. There are a ton of solutions and all of them are hacky. These are probably your two best bets.
Use one of the many Alarm Clock examples. This one is one of the more comprehensive.
Use the CalDav binding and put all your time periods into a calendar.
Yupp, I see that for most people, however I would like to have it in case I sell the flat, and I also tend to alter the day and night time for holidays such as summer, xmas and easter when we like to sleep in and get up later…
Can you modify things from rules? I.e adjust the longitude offset?
I don’t think so. I think the best you can do is see if the OH2 REST API supports making the change and pushing the change using the HTTP Actions.
And as for selling the house, I plan on just taking down the automation stuff before I put it on the market. Most of it is cobbled together DIY stuff I wouldn’t expect someone else to support.
One other thing you can do is expand the design pattern to include time of year and holidays.
There is an issue to add features that will make this sort of thing easier to manage but I think it is being worked with the Experimental Rules Engine.
Finally, when using the JSR223 add-on you have the full capabilities of Python or JavaScript to create additional capabilities in OH. There might be something that can be done there.
After all of that though, I think you will probably want to apply one of the alarm clock examples to your setup so you can change the times on your sitemap.
I haven’t looked into HABpanel in a long time. There might be a DateTime widget now you can use instead of separate setpoints and sliders for hour, minutes, seconds.
Interesting, this is where my set-up differs; it will be an integral part of the house… well documented in a wiki, with source code, and a fixed PC with all code and IDE to replace any microcontroller software; all QR-coded, etc.
Just today we had a discussion in the office whether the sort-of cobbled-together solution that I have for my house could a “solution” that could be sold to people who are not so much technically inclined.
My argument here is: If all is well documented, spare parts on a shelf for all components; it is as good as any other system. The commercial systems have usually a longer production life; however, in this day and age, even these cycles have been reduced… in my case, being pretty much in a rural area, expertise needs to be sourced from town, and the skills required for this domestic system are only to be found in the commercial space, which is reluctant to take on domestic work. Funnily enough, I have arranged for a back-up of me; a local IT support business; the guy understands Linux, SBCs, and to my surprise: openHAB. Hence, I have local support should I be hit by a truck, or another owner live in this house.
I reckon in another 5 plus years, home automation will have changed dramatically. E.g. self learning systems, based on on protocol and other standards…
But if course this is going to be your “forever home”. I’m currently in my “home until the kids moves out and I retire home”.
But it is also driven by my home automation philosophy of making sure everything works intuitively even when the automation is broken which naturally leads to the automation being a thin vineer over a traditional house.
But it also is influenced by the fact that I have a 20 year old house so it isn’t like I can build the house from the ground up like you are.
Also, at least in this market, home automation actually reduces the number of potential buyers. You should hear the controversies over stuff like solar panels. It’s insane sometimes.
Finally, I’ve put a lot of work into my home automation and about 80%of it is portable to a new house. Why rebuild it when I can just take it with me.
)
