Design Pattern: Time Of Day

Tags: #<Tag:0x00007f014d19aa28> #<Tag:0x00007f014d19a8c0> #<Tag:0x00007f014d19a758>

(Rich Koshak) #61

True but there are some limitations:

  • 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.

(SiHui) #62

Let me rephrase it: the altitude TAG is gone, not the altitude parameter. Just the way to configure it has been changed :slight_smile:

It only gives better results for the radiation channel.

(Kim Skatun) #63

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

(Rich Koshak) #64

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.

  1. Use one of the many Alarm Clock examples. This one is one of the more comprehensive.

  2. Use the CalDav binding and put all your time periods into a calendar.

(Kim Skatun) #65

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?

(Rich Koshak) #66

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.

(Max G) #67

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. :slight_smile:

(Hakan Tandogan) #68

Nice :smile:

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.

(Max G) #69

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…

(Rich Koshak) #70

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. :grinning:

(Hakan Tandogan) #71

Really? In which area are you living? Admittedly, I am not currently planning to put my house on the market so I don’t know what potential buyers would be saying, but hoping that I would sell to young(er) people, I would expect them to be a bit techno-happy…

At least, I assume everyone will want a facebook-enabled house by this time next year :stuck_out_tongue:

Eeeexactly my plan :smile:

(Max G) #72

Well, unfortunately, Rich is right… I am building a passive house in Qld, Australia; nobody knows what it is, is sceptical about the ventilation (HRV), finds double-glazing ridiculous; cannot believe that heating/cooling will cost less then $100 per year; and the list goes on… what a world we live in?!
Since I have no intent to sell, and plan to come out in a coffin, I don’t give a rats who owns it next. All this nonsensical ‘compliance’ to please others; no; life is too short… :slight_smile:

(Rich Koshak) #73

I live in an area that:

  • far from the young and hip technology areas of the state
  • most of the population is military, military contractors, and the like (i.e. conservative)
  • property values are going up faster than average so there are lots of investment buyers opposed to people looking for a home
  • there is a history of bad experiences, particularly with the solar water heaters installed in the 70s and 80s that leaked and became a major liability and the companies went under that makes people very hesitant to accept any modifications to a home that can’t be supported by the average electrician and plumber

I’ve thought of the idea of getting into the home automation business. But I’d have to make too much from it starting from day one to afford health insurance it just isn’t feasible. And I haven’t found a way to make it work as a side hustle.

(trumee) #75

I get the following messages in the log in OH2:

17-09-01 07:04:00.062 [INFO ] [Manager$ExpressionThreadPoolExecutor] - Expression '0 4 7 1 9 ? 2017' has no future executions anymore
2017-09-01 07:04:00.063 [INFO ] [Manager$ExpressionThreadPoolExecutor] - Expression '0 4 7 1 9 ? 2017' has no future executions anymore
2017-09-01 07:04:00.063 [INFO ] [Manager$ExpressionThreadPoolExecutor] - Expression '0 4 7 1 9 ? 2017' has no future executions anymore

(Rich Koshak) #76

Well, 07:04:00 on September 1, 2017 has passed so this cron expression will never fire. If you want something to fire repeatedly (e.g. every morning at 07:04:00) use:

"0 4 7 * * ? *"

(trumee) #77

I am using the following cron along with your rules:

Time cron "0 0 7,22,0 * * ? *" 

So these 'future expiration ’ messages only come up when the rules are re-started and otherwise harmless?

(Rich Koshak) #78

Well, they are informational, not errors or warnings so they are not reporting something that is necessarily wrong. If the triggers continue to work as expected I’d say you can safely ignore the messages.

(Udo Hartmann) #79

year in Time cron is optional. Changing the trigger to

Time cron "0 0 7,22,0 * * ?" 

should suppress the messages

(trumee) #80

I have the following warning at startup. And coincidentally, the EVENING never comes.

2017-09-02 18:23:26.379 [INFO ] [el.core.internal.ModelRepositoryImpl] - Validation issues found in configuration model 'astro.rules', using it anyway:
The value of the local variable evening_start is not used
2017-09-02 18:23:26.381 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'astro.rules'

The items are

String TimeOfDay "Current Time of Day [%s]"
DateTime Sunrise_Time "Sunrise [%1$tH:%1$tM]" { channel="astro:sun:local:rise#start" }
DateTime Sunset_Time "Sunset [%1$tH:%1$tM]"  {  channel="astro:sun:local:set#start" }

and rules are

val logName = "weather"

rule "Calculate time of day state"
  System started or
  Channel 'astro:sun:local:rise#event' triggered START or
  Channel 'astro:sun:local:set#event' triggered START or
  Time cron "0 0 7,22,0 * * ? *" // there is currently a bug where only one cron is triggered per rule so I've combined all three into one
  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(7).millis
  val long day_start = (Sunrise_Time.state as DateTimeType).calendar.timeInMillis
  val long evening_start = (Sunset_Time.state as DateTimeType).calendar.timeInMillis
  val long night_start = now.withTimeAtStartOfDay.plusHours(22).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(evening_start):       curr = "DAY"
        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(TimeOfDay.state.toString != curr) {
    logInfo(logName, "Current time of day is now " + curr)


Any idea where the error is?

(Rich Koshak) #81

The error in the log is just a warning. But it is complaining that evening_start is definitely but not used.

So there must be typo somewhere in the switch statement.

Load the rule into Designer and see if it complains about something.

Double check that evening_start is spelled identically everywhere it to used.