Hardware: NUC7CJYH with 8 GB RAM and 32 GB SSD + zwave: Aeotec Z-Stick Gen5 (ZW090)
Ubuntu Server 20.04
OH 3.2 stable
I run the system above “still” using item.files and rule.files (DSL) on OH3 and I am wondering about few things about the future proof of my system.
- items in files using semantic tagging and alexa definitions
→ will this be supported in the future?
→ Is there a crucial reason to change to mainUI item definition?
- DSL rules:
→ will file based definition be supported in the future?
→ Can DSL rules be transferred into newer formats (e.g. Blockly)?
On your 2nd question, have a look here. It’s an interesting topic to follow re what languages are supported and how this might develop in the future.
Thank you @chrismast and @rlkoshak
That comprehansive information and helps a lot for orientation.
So, I think it would make sense to move away from file based items first.
I have semantically tagged a significant part of my items, but I totally agree to @rlkoshak that this a lot of manual work.
Migrating my rules though is frightening me a little (having a family and a full-time job because I have more than 7000 LOC nowadays.
It’s probably a good idea anyway to review the stuff, but tranferring it from scratch will keep my busy for the next few corona wave lockdowns
Pay attention to the Marketplace. A number of those rules might just be replaceable with rule templates from there. Also pay attention to “foreseeable future”. It will probably be years before Rules DSL is lost. And it likely won’t be a choice made by the openHAB project but loss of support for the upstream Xtend project that forces our hand. But I would expect there to be years between now and then so there is no hurry.
And if you’ve ideas for some generic capabilities that could be converted to rule templates I’ll be happy to take a shot at implementing one.
For most users I want to get them out of the business of writing most of their rules. They should just be downloading rule templates, configuring them and only suppling very simple customizations.
For example, I’ve an Alarm Clock Rule posted as a rule template. Install that and then when you create a new Rule you have to option to choose it as a template. Then all you need to do is provide the Item that triggers the rule and another rule to call. The Alarm Clock Rule will then execute your provided rule at the date and time represented by the DateTime Item’s state. So all you have to code is the “what to do” and the rule template does the rest. There are already a bunch of templates posted and I’m hoping there will be more in a few months.
I would not be surprised if you could replace more than half of those LOC with rule templates, if not now then soon.
There are currently rule templates for:
- scene management: set your Items, click save and then you can restore those Items to that scene later (includes UI widgets as well as rule tempaltes)
- to today: advance a DateTime Item’s state to today’s date, preserving the time
- time of day state machine: the good old time of day DP
- debounce: let an Item remain in a give state for a configured time before forwarding that state to a proxy Item
- threshold alert: check the members of a group to see if any meet a criteria (e.g. humidity Items below 30%, battery Items below 25%) and call a script with the list of those Items. Supports rate limiting (no more calls than once every 8 hours for example) as well as a do not disturb period (e.g. no calls between 23:00 and 08:00.
- thing status: runs priodically and calls a rule with the list of Things that meet a given criteria (e.g. all the Things that are not online)
- persistence presence simulation: play back the states of your Items from the past to simulate presence when you are away.
The key thing is you do not ever have to look at code for any of these. All you do is provide the configuration parameters and it’s ready to go.
By the way, I wonder what does OH team think about OSGi perspectives.
That’s not something I’m knowledgeable about. But Karaf, the OSGi container OH uses, does no sign of losing support. I wouldn’t expect a move off of OSGi unless it’s forced somehow, but that’s not a user facing issue so I don’t really follow that.