All I can say is that things change.
When OH 3 was released the developer maintaining the Jython add-on and the Helper Library disappeared. A fork was made and there was a scramble to make the helper library compatible with OH 3 as only the one person who disappeared had any rights on the original repo. Since then there has been no one volunteer to support the Jython add-on and the Helper Library hasn’t seen a merged PR for at least two years.
And all that lack of work and interest from the OH side of things probably has something to do with the fact that there has been no progress on the upstream Jython project itself. Python 2.7 has been end of life for several years now yet the Jython project still shows no sign of Python 3 support any time soon. And there is very little working being done on that project at all.
No one can predict the future with 100% accuracy. At one time Jython’s future looked bright. Not any more.
All the more reason to start looking at migrating now when you have the chance to take your time rather than later when there’s an update somewhere that completely breaks Jython for good.
My understanding it there is very little that HABApp cannot do that the built in OH rules can. But keep in mind that most of the rules syntax stuff you are used to working with was provided by the Jython Helper Library. So anything is going to look different from what you are used to.
What about it? No one is really maintaining it. But as things change in openHAB core that require changes to the add-on to keep it compiling and running maintainers do step in and make those changes. However, they are not making additions to the add-on to account for new features added to core. Also, the Helper Library isn’t part of openHAB. The core Jython capability itself is not part of openHAB. Those are both third party and neither really has sufficient support any longer. All the work in the world on the add-on doesn’t matter if the upstream Jython or downstream Helper Libraries are not kept up.
Some of the features in OH 4 that I’m pretty sure Jython doesn’t support even now include:
- new rule triggers like
Time is <item>and system startlevel triggers sharedCacheandprivateCachewhich lets you store stuff outside of the rule and, in the case ofsharedCacheshare between rules. The caches are nice in that they clean up after themselves if all the rules that reference an entry are reloaded to include cancelling timers.- features to make coding rules in the UI reasonable like auto injecting the helper library rather than requiring the same explicit imports for every single script action/condition.
I see no reason why it wouldn’t be. But it too is not a part of the official openHAB repos. I don’t know what, if any, succession plans they have should the lead developer disappear for whatever reason. But it runs on standard Python so at least you don’t have to worry about that going away or breaking.
Most of the above lessons learned have been applied to the remaining languages in OH 4, particularly GraalJS (i.e. JS Scripting) and jRuby. In both of those cases the upstream capabilities are currently actively supported, the helper libraries are a part of the openHAB project (and come with the add-on), have multiple maintainers, and since they are a part of the openHAB project itself, the project leads can assign new maintainers should the need arise.
Blockly, the graphical programming language in MainUI “compiles” to GraalJS for what ever that’s worth.
And I suspect you might find that you can do more with less lines of code in both jRuby and GraalJS than you can with Jython, if lines of code is a concern. Also don’t forget to look at rule templates on the marketplace. Why recode a rule that you can just install and configure? Finally, look for other third party libraries which can help as well. For example I have openhab_rules_tools which provides a bunch of libraries for making working with timers a lot easier. For example, if you have a rule that needs to keep a separate timer for each Item that triggers the rule:
var {timerMgr, helpers} = require('openhab_rules_tools');
var timers = cache.private.get('timerMgr', () => new timerMgr.TimerMgr());
var runme = () => {
// code to run when the timer goes off
}
var flapping = () => {
// code to run when the timer already exists
}
timers.check(event.itemName, 'PT5M', runme, true. flapping);
That call to check will create a new Timer keyed on the Item name if one doesn’t already exist to go off in five minutes and call runme. If one does exists, reschedule it and call flapping. The last two three arguments are optional.
