Remove the “,-99”. By default if you don’t tell the expire binding to do when it expires, it sets the item to Undef for you.
I assume you meant “UNDEF” instead of “Under”. But when I try to check for UNDEF in my Rules like eg.
if (myOneWireSensor.state==UnDefType.UNDEF) {
// some code here
}
I get an error:
n error occurred during the script execution: The name 'UnDefType' cannot be resolved to an item or type.
In Rules you test for Undefined using NULL
if(myOneWireSensor.state == NULL) {
// some code here
}
And yes, I mean Undef. If you read many of my posts you will find I have a terrible time seeing my phone’s missed autocorrections.
2 Likes
I love this binding. It made my virtual presence switches and rules so easy to handle. Well done.
Is there any plan to convert it to OH2 binding? I could not envision which function is missing or could be added but I do foresee people struggling to find this binding if not fully OH2. It would be a shame if this binding dies just because nobody made a 2 version of it…
Imho it works perfectly in OH2, what would be needed for you to make better for OH2?
nothing. It works fine out of the box.
The thing is: if you only load OH2 bindings (which the guided installation recommends) you will not be able to find it.
That’s all…
1 Like
Fair point
Plus if you have created an Item using for example Paper UI today and then want to use Expire on it tomorrow you have to delete it and recreate it using an .items file instead. Would be much nicer to just be able to add the Expire stuff using Paper UI as well.
1 Like
Not sure what you mean by “only load OH2 bindings”, but if you follow this process, the binding will be added to the normal distribution and thus be available out-of-the-box, just like any OH2 binding.
Sorry to resurrect an old post, but I am having trouble with the expire binding on OH2 and came across this. You seem to suggest that I can turn on DEBUG logging for a single package/binding. How can I do that? This would be super helpful in the future.
RTFM…
In my defense, I could swear that wasn’t there the last time I looked…
Thank you!
1 Like
Happens to me all the time. I could swear someone is adding stuff to that documentation! 
Just in time (and only to mess with you 
)
1 Like
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
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
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.
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).
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.
Hi,
great idea, but how can I use this with a paperUI-configured setup? I havn’t items-files…