Well, I don’t want to have to do a mad recoding of my rules if we know for sure that eventually one day it will go away, even if that may be 2 years from now.
Well as you don’t know what any replacement will look like, you cannot write any rules at all.
You will not be forced to use OH3, if you are concerned about having to tinker in two years time.
There are still openHAB1 installs out there and working.
Kai said somewhere here the version after 2.5 will be OH3.
that’s a good point
Yes, and he still is not using OH3 today and Expire still will not go away in OH2 and no-one is quite sure what OH3 will look like and little time will be spent on nailing it down until a solid 2.5 release is achieved.
By all means use Rich’s JSR223 expire replacement as an introduction to new rules, but don’t feel you have to - and don’t expect that to be “the” way to achieve expire in OH3, or that they will still work without modification whether or not there is an expire feature in the framework.
I agree with rossko57. Expire will continue to exist as long as OH 2 exists. It may even be supported in OH 3, we don’t know yet what OH 3 will be and how it would be replaced.
I wrote the Expire Python code mainly as an interesting coding challenge. It can be used to buy you some time when/if the binding goes away but you should migrate to whatever replaces the Expire binding functionality when/if it becomes available and not rely on these Rules indefinitely. Since we have no idea what the replacement for Expire would look like there really isn’t much you can do now to prevent the rework in the future. So please continue to use Expire if it makes your life easier and when the time comes and Expire does go away, you have a stop gap that will let you take your time to migrate to the new approach.
And on a more generic note, do not put yourself into a situation where you are rushing to rewrite your Rules because of an update. Spin up a test environment to migrate little by little and only switch over to the new version when you are done. Take your time and be deliberate.
I’ll likely write a migration tutorial same as I did for the 1.x to 2.x transition which will outline this sort of approach too. I suspect it to be a much shorter tutorial though.
I followed that thread when it was active and I don’t think a resolution was ever come to as to what the best approach would be. Profiles feel like a good approach but they have some significant limitations:
- can only be used without a Channel and therefore cannot be used with virtual Items
- cannot be used with a Channel that already has a profile applied
Scott’s recommendation requires creation of a Rule at which point you may as well just use Rule Timers.
I tend to agree with Kai, that it probably needs to be implemented in core similar to how autoupdate is implemented. So it’s not clear whether the Profile will be merged in the first place, and if it is whether that will be an adequate replacement for Expire as several of the currently supported use cases would not work using profiles.
This is a point. Having the ability to recursively apply profiles would be great.
The next release will be OH 3.
With the 2.5 release build, our development master branch has now become 3.0.0. This means that there will most likely be no openHAB 2.6 runtime in future, while there will still be 2.x updates on the add-ons, though.
And they’re still not using OH3 right now. “Jam tomorrow” is great, but not for today’s meal. Not only that, you still don’t yet know what kind of jam it will be.
@rlkoshak - will the jsr233 version youve done here support item values for expire times? Also - mind helping knobs like me on how to install it?
It could but does not do so out of the box. It currently provides no additional capabilities beyond what the Expire1 binding provides. I’m not sure adding that feature is entirely appropriate. My intent for the JSR223 version was a stopgap for those who end up transitioning to OH 3 but are not yet ready to transition away from the Expire1 binding.
For installation see [beta testers wanted!] Jython addon w/ helper libraries (requires OH 2.5.x) to get Python installed and see https://openhab-scripters.github.io/openhab-helper-libraries/Python/Reference.html. Essentially you download the files, drop them into
$OH_CONF/. The folder structure checked in will put all the right files in all the right places. There is no special configuration required for the library so once you drop it in place it should work.
Brilliant - will give it a go - i am wondering if the existing binding v1 is causing me some grief with the zwave binding - only loose webs between some threads I’ve been across.
I saw the item value expiry on another jsr223 thread and have 99% of everything else I do controllable via sitemaps and items, went to expire due to the simplicity vs constant running timers I was doing but then lost the WAF on this. perhaps time for me to learn how to do this myself. Thanks for your help
I believe it’s time to revive this?
There is an Issue on GitHub and it is being worked on.
I believe you are talking about this?
@Kai it seems that expire has been brought into openHAB 3 per this Issue that has been closed.. Does something need to be enabled to turn it on? I have seen some OH3 docs but can’t find anything that talks about this. I migrated from stable to Milestone 4 -> 5. Still trying to figure it all out. Does look nice though. Great Presentation over the weekend by the way! Loving how it is all coming along.
I’m using it in oh3, on by default and supported in gui it seems.
Just define your items as you would in.oh2 with channel.expire reference
Documentation can be found here: https://next.openhab.org/docs/configuration/items.html#parameter-expire