Wow, impressive amount of effort, all in the pursuit of recovering from an impending loss of basic product functionality for no actually sensible reason! It seems tragic that you have developers pitted against users, where the developers take away your functionality for ideological reasons, and users have to cobble together workarounds. In the commercial world, such an abuse of users would have killed off the software company in preference to its competitors. All the while, in an alternate reality, you could instead have developers and users working together to solve real-world challenges instead of recovering from self-inflicted wounds. Seems tragic, but also further validates my old decisions.
Best of luck to you users, and may your efforts cease “expiring!”
No, all in pursuit of learning and experimenting. And even if Expire were going away for sure, which is in no way a done deal, I would have done the above. I personally do have problems with the 1.x bindings. They are keeping me from moving my Items to the JSONDB where, based on my experience, everything loads much faster and much more reliably without the startup timing issues that have existed since OH 1.6. so this was one user solving a personal problem and sharing the solution with the community. Is that not how FOSS supposed to work?
Still looking for someone to volunteer to maintain the compatibility later though. In the commercial world you can pay someone to maintain it. In the foss world you don’t have that leverage. Would you chain every developer to any code they have ever released for life? I certainly would release a longer if code if that were the case.
Users either need to be flexible and adjust with the changing sets of developers, priorities, and inconsistent quality and advancement of the product or they need to go buy a commercial product where those qualities are easier to control. In a pure volunteer project like openHAB, there is no other option.
I think it’s great you are still finding interesting projects. I just think it’s unfortunate that you have to operate with a worry that you will lose functionality that people have relied on for years, and set out to reinvent it with tools that, hopefully, you won’t also lose someday.
The threat of breaking the assumed contract of not stripping old functionality by removing the 1.x features, is the “Brexit” of openHAB. Should we/shouldn’t we sever off one of our own limbs, strand users and suppress interest in us by being thought of as contract breakers?
The premise is false that the 1.x bindings are the barrier, while the architect(s) have chosen to create a two-headed situation for users and could easily choose to apply their talents to fixing that instead of jettisoning a massive body of work contributed by others, all the while ignoring the loss that represents of core capabilities not present elsewhere in the product.
It’s also mistaken to believe there is a chain from every developer to the code he/she contributed; it is perfectly normal for others to submit PRs on code they didn’t originally contribute. Writing code is not magic!
A tone not seen in many and probably most FOSS projects, is the threat of breaking a major “contract” with the user, but you have reinforced the idea that “users need to be flexible” to the point that they lose core capabilities and just suck it up and rethink years-old work, with possibly no viable path forward. For every other project out there that doesn’t hang this over its users’ heads, all else being equal it would have much more interest and enthusiasm.
But you’re definitely right – it is what it is, and it’s becoming what it’s becoming.
I completely agree. But no one is doing it. There is no one continuing to the compatibility layer. Unless and until someone steps up to do so, it’s dead code for all intents and purposes.
I’m not saying that people can’t contribute. I’m saying people are not doing so. If just one developer is willing to step up and take on maintaining the compatibility layer there wouldn’t even be a problem. No one has volunteered. No one has stepped up. It’s been nearly a year since this topic first came up and still no one has volunteered.
Some are vocal about wanting to preserve it yet no one is willing to step up and do something about it.
follow the instructions here to check out the PR (#259).
Uninstall the Expire1 binding.
You will find an “Expire” folder under community. Copy the contents of that folder to your /etc/openhab2 folder (it’s already organized the same as your automation folder.
There is no additional configuration required. It will pick up your existing Expire binding configs as written, though there are a few new features/bug fixes that are possible now including the ability to set an Item to UNDEF explicitly, you can set a String Item to an empty String, and you can set a String to the String “UNDEF”.
git init
Initialized empty Git repository in /etc/openhab2/bwo/.git/
git remote add rich https://github.com/rkoshak/openhab-helper-libraries.git
git checkout -t rich/expire
fatal: 'rich/expire' is not a commit and a branch 'expire' cannot be created from it
I may give it a try later. I fetched OK but it looks the same as what I tried.
This line is the issue. from org.openhab.core.library.items import StringItem
Remove that line. I’m messing with this script today and that import isn’t used. It’s giving you an error because org.openhab.core is only present if you have compat1.x installed.
Please add a comment to the github and I’ll come back later today or tomorrow to take a look. I assumed that these have moved from org.eclipse as part of the great merge earlier this year. But if I’m indeed not using it there is no reason for the import to be there.
The current version of openhab still uses the eclipse namespace despite the merge.
I spent some time implementing and modify this script on the weekend. I will be making a PR on your branch when I have time. I added the live reload handling I think I suggested on the past as a hold over until we have item registry triggers. This required restructuring the expire rule and trigger generator to be dynamic.
OK, I got back to testing on a clean 2.5 Milestone 4 install. I removed the unneeded line and now get a different error.
2019-11-03 14:01:07.602 [ERROR] [ipt.internal.ScriptEngineManagerImpl] - Error during evaluation of script 'file:/etc/openhab2/automation/jsr223/python/community/expire/expire.py': AttributeError: 'function' object has no attribute 'triggers' in <script> at line number 179
Yes that log is saying that the trigger generator function did not make any triggers (because no valid configurations exist). If you now have a valid configuration on an item you should remove the expire binding and restart openhab. When I first switched over to it the fact that expire binding was installed cause openhab to treat the expire metadata as not metadata so the script can’t see it until you restart.
