Cool binding, and It’s pretty nice to use for controlling movement of Foscam cameras. I’ve tested it and it works. I have just one issue. Is there any option to put time in milliseconds? If not, is there any chance to put this feature?
1 Like
The duration format could be expanded to allow fractional seconds (like 3.333s), but the implementation would have to be changed more extensively in order to achieve the greater precision. Plus, since the expiration posts either an update or command, there is some further latency with the message bus that probably can’t be overcome or predicted, so the millisecond accuracy you are after may not be achievable. Despite all that, well tested pull requests with no ugly side effects are always welcome! 
Second that. Use case: say, duration of external PIR controlled lighting depending whether someone is home or not.
If this ‘substitution’ were done by specifying a String Item, it could have the same format perhaps, which might also allow the end action to be tweaked?
Would need some thought about what happens to the existing running timer at the moment the string is updated. (Perhaps nothing, until the next reschedule?)
Is there a way to configure items created by PaperUI, i.e. not by the .items file?
This is a way cool feature! I understand, it’s not yet part of the package, but how can I install the binding? still copying the jar from the dropbox-link?
Thanks!
The Expire binding is installable in OH2 build 651 from the Add-ons list (possibly earlier builds, too). Being a 1.x binding, you have to add it to your .items files like this for example:
Number Sensor "Sensor [%.1f]" { expire="5m", other bindings... }
If you are using an OH2 build prior to one that includes installing the binding, you can get the latest from CloudBees.
1 Like
Hi!
I’m interested in setting alarms, would it be possible to have a dynamic timer for this:
Switch EggTimer { expire=“7m,command=OFF” }
I don’t want to hardcode 7m, I want to use a SetPoint to choose the time myself (I know this can be done with regular rules, so not asking how to do it, more if it can be integrated in the expire binding). My wife and I have a totally different understanding on how long eggs should be boiled.
Also there seem to be some sort of demand for alarm / alarm-clocks in general.
For instance I would like to set an alarm, again using rules with setPoints would work but require some code. It would be nice to be able to set alarms with the type “7m” as well as 07:53.
I know this has been done with the help of JSR223 in Openhab1.
Looks nice with the Expire binding will use it for some of my z-wave devices!
Regards, S
The Expire binding currently has no way of getting its expire time dynamically, or to expire at a specific wall clock time. Some thinking would have to be done to determine if those features are appropriate for this binding, or if some other mechanism would be more appropriate outside of what is already possible with rules. There are arguments for and against expanding the binding in those directions.
One approach that might make sense that is possible now is to have multiple items, each with a different fixed expire duration, and you could choose among them which duration you want to use. You could even group them under a Group:Switch:OR(ON, OFF) item and have a rule trigger when the group is ON or OFF.
3 Likes
I think a good addition to this plugin would be ‘idle’, so if an object receives no state updates for a certain amount of time it will go to the specified state.
I think you are describing something the binding does, unless I misunderstand you. Examples:
String Str "Str [%s]" { expire="1m,idle" } // changes item state to word "idle" after 1m of no updates or commands
Number Num "Num [%d]" { nest=">[thermostats(Office).temperature_f]", expire="30m" } // go to Undefined state after nothing for thirty minutes
Switch Sw "Sw [%s]" { zwave="3", expire="10m,command=OFF" } // turn light off after ten minutes
Close, but not exactly. With { zwave=“3”, expire=“10m,command=OFF” } you can specify the expired state, but any state update value other than ‘OFF’ will reset the timer. With { zwave=“3”, idle=“10m,command=OFF” } you specify the ‘expired’ state but ANY state value update resets the timer.
Let me give a better item example… I record iBeacon RSSI information… lets say any value from -1 to -100. If I don’t receive a RSSI update after 5 minutes (the beacon was taken away) I set the state to 0. So my item would look like this: RSSI_Data { mqtt="<…", idle="5m,command=0 }
Something like this should work I think:
Number RSSI_Data "RSSI_Data [%d]" { mqtt="<..", expire="5m,0" }
Not the difference between 0, state=0 and command=0: The first two mean the same thing, to update the state of the item, the last one means post a command to the item. Normally a sensor is receiving updates but it makes no sense to “command” a sensor to do something.
This goal could be addressed very nicely.
Since there is no need to use the item registry if all you are doing is posting a state update to an item you know is a String item, then let me propose the Transform binding:
String TemperatureAlert "Temp Alert [%s]"
Number Temperature "Temp [%.1f °C]" { zwave="12", transform="TemperatureAlert=SCALE(comfort.scale)", expire="30m" }
comfort.scale:
[..17[=Cold!
[17..23]=Comfortable
]23..]=Hot!
So it takes every state update on the item it’s bound to (Temperature), puts it through the given transformation, and if the transformation doesn’t fail, posts a string update that is the result of the transformation to the named String item (TemperatureAlert). If the transform fails, it posts an Undefined update to the named item. While it’s different from specifying min and max in the binding config string, it opens up all transformations as candidates for updating a String item with the result of the transformation.
@ben_jones12 or others, any thoughts?
One counter-argument I can see already is that the binding does not relieve much effort compared to using a rule to achieve the same outcome:
Number Temperature "Temp [%.1f°C]" { zwave="12", transform="TemperatureAlert=SCALE(comfort.map)" }
means the same thing as
rule UpdateMyString
when
Item Temperature received update
then
val oldString = Temperature.state.toString
val newString = transform("SCALE", "comfort.map", oldString)
TemperatureAlert.postUpdate(
if (oldString != newString) new StringType(newString)
else UNDEF
)
end
5 Likes
Just wanted to register my appreciation for this binding. I implemented a garage door opener using a Wemo switch and Digital-loggers ac power control relay. Using the the Wemo binding in conjunction with the Expire binding, it was trivial to implement a virtual momentary switch in Openhab2 to open/close the garage door. Any time I can save the effort of implementing a new rule I’m happy.
3 Likes
Yeah I can see how this would be useful, but not sure it really solves the alert/alarm problem, at least not in an easy-to-use manner. I think this expire binding is an example of how useful they can be, if they are kept simple and easy to understand.
IMO trying to leverage the alert idea off a transform binding will not be super-intuitive and therefore cause problems for others trying to implement.
I could be completely wrong however!
I’ve been thinking about this for a while and seeing this posting jogged my memory. Has an issue been generated to talk about pulling the transform out of the binding and let it be generically applied to any Item regardless of the binding or channel it is attached to?
For example, from memory the Mobus binding doesn’t support transformations (could be wrong, long term memory may be faulty). However, I’ve helped several users set up a proxy Item and rule to achieve the same result that could have been achieved if Mobus simply allowed use of a transformation.
Basically what I’m thinking is taking your transform binding idea and applying it to the Item it is bound to instead of a separate Proxy Item.
I fear this probably isn’t possible in OH 1.x given I suspect changes to core are required and am not sure how applicable it is to OH 2 with its channels.
But this could free the users from needing to create a bunch of one liner rules to do stuff like round up a number or the like. It also allows user to assign channels/binding configs to Items Types they are not intended for.
For example, I have some Items bound to the online channel on Network. The Network binding requires these Items to be Switches. However, if I could apply a transform to the ON/OFF (e.g. map where ON=OPEN and OFF=CLOSED) I could use Contacts which is a more appropriate Item type for this.
It may not be worth the effort and I can see how it might add a bit more complexity to an already complex area. Its just a thought.
@ben_jones12 @rlkoshak I agree with both of you that ease of use – clear concepts, fills a need, concise configuration and excellent documentation – are extremely important, and override most other concerns, like trying to look smart, being either too cryptic or too verbose, trying to convert users into Java programmers, solving problems no one has, etc. 
I think the Expire binding is the right kind of building block, but there’s also the argument that, if, for example, the new rule engine evolves into something incredibly easy to use, is fast and reliable, and solutions are easily shared and dropped into it, then that alone can address a whole range of needs in a general way, instead of building lots of discrete, disjoint pieces here and there to fill needs.
To round up use cases like alerting, transformations and related “massaging” of inputs to actions and outputs, and see how the new rule engine can be made to address them clearly and simply, should have a high return on the effort. In other words, don’t wait for pieces to come down from on high, and then complain that they don’t fill needs! (Not that I’m saying anyone does this, but it’s very easy for things to work out that way.)
Is there a role for the openHAB Foundation in all of this roadmap thinking? Sorry I’m out of the loop to know myself.
My current understanding is that the roadmap is outside the scope of the foundation. It gets complicated also because there are really two roadmaps, one for ESH and one for openHAB.
That being said, having a published roadmap, if even at a high level, would be useful to the community. @kai, is there a roadmap written down anywhere already beyond trolling through the Issues on GitHub? A very cursory look through the ESH site didn’t reveal one to me.
Hi, i stuck with cron rules, it stops spontaneously works, this problem force me to switch from OH1 to OH2.
May be problem in my rules, but OH designer do not see any.
In log nothing unusual.
Is that approach will not use cron?
Switch expireTimerSwitch1m { expire="1m,command=ON"}
rule "Sensors"
when
Item expireTimerSwitch1m received command ON
//Time cron "0 * * * * ?"
then
//my rule
...
expireTimerSwitch1m.sendCommand(OFF)
end