Please test the new Expire Binding

Add-ons Bindings
91

http://docs.openhab.org/administration/logging.html

log:set DEBUG org.openhab.binding.expire

1 Like
92

RTFM…

In my defense, I could swear that wasn’t there the last time I looked…

Thank you!

1 Like
93

Happens to me all the time. I could swear someone is adding stuff to that documentation! :smile:

94

Just in time (and only to mess with you :wink: )

1 Like
95

I really like the expire binding, however for some rare cases It would be awesome if you could pass the expire time to it. This way the WAF will be improved, because then we do not need to alter items file when we want to change the timer, but we can then change it with alexa, sitemap and so on. Idea as follows:

item file:
Number myTimer
Switch LightSwitch "Light" { myq="2", expire="45s,OFF,myTimer" }

somewhere in a rule:
number.postUpdate(115)

so if myTimer is undef or null then use 45s otherwise use the myTimer value

96

I like your idea, but it sort of breaks the rules about bindings referencing items in the item registry (myNumber in your example). Perhaps there is an elegant workaround?

Assuming there is such a workaround, could the bound item be associated instead with a String item, not a Number item, that takes the same syntax as the binding config string, like “115s” or “2h5m12s”? So no assumption about seconds being used? Also, if 45s in your example were replaced with an item name, and no optional third argument in the binding config string, then the expiration would be entirely dependent on the named item existing and having a state that was a valid expiration time. So your example would turn into:

String LightSwitchExpiration
Switch LightSwitch "Light" { myq="2", expire="LightSwitchExpiration,command=OFF" }

which, as defined, would do nothing until the item LightSwitchExpiration's state was a valid expiration time string like 1m55s.

1 Like
97

That seems awesome!!

then we just do like this:



rule "ExperiationTimer"
when
	Item myTimer changed
then
	LightSwitchExpiration.postUpdate(myTimer.state +"s")
end

The questions is then, lets say we use expire binding to make reminders for turning the fire extinguisher every month. Then the system goes down, how can we then persist that it is now 10 days left?

So one additional option might be to set a given date as an option,

Switch LightSwitch “Light” { myq=“2”, expire=“1509615740,command=OFF” }

where 1509615740 is the unix timestamp, so if we persist LightSwitch it will remember 1509615740 and not get reset.

98

Using the Expire binding for calendar events might be stretching it too far away from its main purpose (IMHO), where it’s concerned with acting some time after a command or state change. The existing Google Calendar service is already pretty good at this, but an easier-to-use solution would be a service running on your server that achieves a similar outcome without relying on Google Calendar, has a nice UI, etc. There might be work underway on this based on old discussions (I have no idea).

99

This would break the binding for OH 1.x but in a OH 2.x version I could see there being an input channel similar to how the Exec 2.x binding works. But it gets a little tricky if you don’t link that channel to an Item. I suppose you would have to set a default in the Thing definition and then if an Item is linked to the input channel then the binding would use that value.

More complication comes into play for Items that are already scheduled to expire and someone changes the input channel.

Hmmm, maybe this isn’t so elegant afterall.

I agree and there is work ongoing to add a scheduler into the core of ESH which is where this sort of capability properly would go.

@skatun, there could be work arounds to make something like this work where you set a DateTime Item that gets persisted and a System started Rule to reschedule the binding based on the amount of time from now to the DateTime. It isn’t pretty or elegant but it would work.

I believe the CalDav binding will work with OwnCloud’s calendar which would do this.

100

Hi,
great idea, but how can I use this with a paperUI-configured setup? I havn’t items-files…

101

It is a 1.x version binding. It can only be used with .items files.

102

Hi @rlkoshak, sorry for dredging up an old post but your suggestion is not working for me:

.items file:

 String myStringItem {expire="5s"}

.rules file:

...
if (myStringItem.state == NULL) {
	\\ match
} else {
	\\ no match
}
...

If I command the item myStringItem to some value and then wait 5s, the code always follows the else path.
If I display the state of myStringItem in the sitemap it shows ‘UNDEF’.

I am running OH 2.2 release version.
The only difference I see is that you were describing testing a Number item and I am testing a String item.

Has something changed?
What should I be using to test for UNDEF on String item?
Thanks

103

Either test for UNDEF or add {expire=“5s,state=NULL”}

104

With {expire=“5s,state=NULL”}
Then if (myStringItem.state == NULL) still does not evaluate to true
but if (myStringItem.state == "NULL") (note the quotes marking ‘NULL’ as string - does evaluate to true

Since my item is a StringItem and there is no way to tell the expire binding to use the NULL keyword rather than the “NULL” string.

However, using {expire=“5s”}
and if (myStringItem.state == UNDEF) does evaluate to true.

I will use this method, I just thought it was interesting that :
A) There is no way (that I can see) to set a string item to NULL using the expire binding
B) The syntax for checking for UNDEF is now different from @rlkoshak 's code posted in Aug '17

105

I have items declared with expire=“15m,NULL” and in the rule I check if itemname.state == NULL and that works well. Must be something else wrong. Can’t see what it could be though… But if you tell Expire to set it to NULL and then check the log, can you see what it’s actually set to?

1 Like
106

Doesn’t work for me:

String Item: String myStringItem {expire="5s,NULL"}

I send a command “hello world” to this item to trigger the expire countdown. Then 5s later in events.log:
myStringItem changed from hello world to NULL

The using this code:

if (expString.state == NULL) {
	resultString.postUpdate("yup")
} else {
	resultString.postUpdate("nope")
}

resultString is set to “nope”.

If I change the code to:

if (expString.state == "NULL") {
	resultString.postUpdate("yup")
} else {
	resultString.postUpdate("nope")
}

then resultString is set to “yup”.

According to what I am seeing the expire binding is setting the value of the String item to the String representation of NULL. If you are seeing something different with the exact same test then I don’t understand what I could be doing wrong.

107

Correct. The reason is that the StringType is the first listed accepted data type here and this code is used to parse the expire state. The best solution is to not specify any expire state in the binding config string (leave off the ,NULL) which defaults to UNDEF and just check for UNDEF in your rule (see code here for how default is set as described in the docs here).

1 Like
108

But how come it works for me when comparing with just NULL? Is this something that has changed recently (I’m on 2.2 stable)?

109

I don’t see where in your earlier messages a comparison with NULL (as opposed to "NULL") worked for String items. The Expire binding cannot use UnDefType.NULL as an expire state for String items because of what I explained/linked to earlier. Any item type can use UnDefType.UNDEF as an expire state by not specifying an expire state.

1 Like
110

Oh, my fault. No, the Item I’m using is a switch. Sorry for confusing the discussion :blush: