Please test the new Expire Binding

Add-ons Bindings
121

@rlkoshak Rich, how would you see a couple of things using DP.

First, using a group hierarchy ie Home, Main Floor, Mudroom.

All rooms are “assumed” by the system to be vacant because no activity.

A light in the Mudroom is turned on, and an event should propagate up so that the Main Floor and Home would switch to an “occupied” state. That way, any event in any part of the home will keep the Home in an occupied state.

This becomes useful say when at sunset, you would like certain lights inside your home turned on but only if you are home.

But, also imagine the opposite, when the home is vacant. If someone approaches the house and an outdoor motion sensor sees that person, you could have that event turn on an inside light (often nice when coming home to a dark house or to scare away a trespasser). The problem in this scenario, is turning on that inside light will change the status of the home from vacant to occupied. So we then need a way to “lock” that state of the home while turning on that light so there is no change in occupancy.

Another scenario, say the security system is armed “AWAY”. In this instance, the Home would be set to vacant, this event would propagate to all the different rooms, and appropriate actions would be taken ie turn off lights, music, change temp etc.

As I mentioned above, I have done that before, but this looks daunting in openHab especially since the DSL offers essentially no debugging or test environment.

Mike

122

If it is night and the light was turned on by a Rule you know not to change the occupancy switch for that room.

Just send an OFF command to the Group that contains all the Items that indicate occupancy.

You will probably want to draw out a state diagram to make sure you don’t have any incompatible state transitions. You can easily end up in a situation where a state transition event changes and you end up in two incompatible states.

For a setup this complex you will probably want to use a bunch of proxy items so you have some control over how the events propigate.

123

Can I use the Expire Binding for a duration of a year? I have a thing that needs to be replaced once a year. I’d like to put a reed switch on it so that when it opens the expire bound switch turns on. Then after a year the switch turns off… sending me a notification.

Also, does anyone know what’s the max duration of the expire binding?

124

Google Calendar no good?

125

The expire timers don’t survive a restart/reboot.

126

Good point. Also the documentation for the binding says that “The Expire binding accepts a duration of time that can be made up of hours, minutes and seconds” which kinda makes me think it’s not made for really that long periods. I’ve never used it for anything longer than 15 minutes.

edit: I checked the source. If the time doesn’t match the pattern “(?:([0-9]+)H)?\s*(?:([0-9]+)M)?\s*(?:([0-9]+)S)?” it will throw an exception.

1 Like
127

why not set a persisted date item with the date the reed switch opens. Then, have a cron rule checking every week whether the date item is a year old.

1 Like
128

An other alternative to the suggestions by @greg and @dan12345 you can use a Timer and persisted date Item.

See Design Pattern: Encoding and Accessing Values in Rules for how to set your DateTime Item or Individual Alarm clock for each Day of week, with adjustable duration if you want to adjust the date from your sitemap.

Then you just need a System started Rule:

var Timer yearLongTimer = null

rule "Reset timer"
when
    System started
then
    yearLongTimer = createTimer(new DateTime(TimerItem.state.toString), [ |
        // do stuff when timer expires
    ])
end

Then you don’t have to poll and the event will occur exactly at the right time.

Note, you can use this same approach for Expire based timers, however, when OH restarts and you have a System started rule to reset the Expire timers, the time starts over so if you had a timer about to go off after 5 minutes, OH restarts and this System started Rule runs, it would reset the Expire binding to the full five minutes.

That often doesn’t matter but in this case it would. You could have OH running for 6 months and then it restarts and now the Expire timer would get reset for another year.

129

@greg I think the google calendar idea is a great solution. I’ll definitely check into it if I have other uses for it. Seems unnecessary to use it for just this one situation.

@sihui @DanielMalmgren Thanks for informing me of that. I thought expired items survived a reboot since I have persistence set up.

@dan12345 Good suggestion. However, I want to keep the cron rules to a minimum.

@rlkoshak This sounds like the way to go. Would you explain why I need the system started rule? The way I read it… the timer will be reset every time the system restarts. Is this correct?

Thanks

130

Correct. Like the Expire binding, Timers will not survive a reboot of OH so you need to use persistence to save the time you want the Timer to go off and a System started Rule to recreate the Timer when OH restarts.

131

Got it… I had to read the system started rule a few times to get it. Thank you

132

I gave it some thought and decided to go with the cron to check every Friday. @rlkoshak I looked at the referenced threads… to be honest I don’t understand any of it :expressionless: Wish I did! I would like to understand more about the nuts and bolts, if you will, about programming, but don’t know how or where to start.

I have an idea about what I want to do… would you all kindly check this out >> [SOLVED] Thermostat Rule Help (gpio, dht22, exec binding, things, items, rules)

Any suggestions on what I’m doing wrong would be greatly appreciated! Thanks