VSCode is only useful for cases editing text configs. If you go 100% UI driven (which is more like 99% because there are a couple things that still can only be done through text files) you won’t have much used for VSCode. Rules can be created through the UI too. However, if you create or use libraries, those will have to be in text files.
Rules are rule. There are a few small breaking changes you’ll have to deal with mostly having to do with Joda DateTime being replaced with ZonedDateTime and executeCommandLine’s arguments changed. Nothing else changed so talking about 2.x and 3.x rules doesn’t really mean anything.
There is the ability to define rules through the MainUI but not even that is new, you could do that in OH 2.x too with the Experimental Rules Engine installed (which is now just The Rules Engine).
If you are asking about whether there is a way to convert rules in a .rules file to UI rules the answer is no. They have some fundamental differences in structure and definition that makes developing a tool to automatically convert them all but impossible. But why convert them? If you are happy with rules in .rules files then stick with rules in .rules files.
Yes, that’s what I was asking. Ok, so I can stick my old rules file, but, does it make sense? It appears the way forward is less and less file based. What are the cons of not adopting the UI rule definition?
(I have not fully grasped the Semantics stuff yet and what areas of the system use them, so the following is based on my current level of understanding…)
It appears the semantics is also the way forward. So, is using the old rules file have an impact on the use of the semantics?
That is one of the focus of a number of the developers. However they have all stated that file based configs will remain supported for the foreseeable future. I can’t imagine that files will not remain supported, at least for stuff that is already supported by config files. New stuff, like MainUI Page Widgets and stuff like that may not support file based configs.
I’m personally of the opinion that for most things (not rules) sticking with files, particular using files for Things, is masochistic and and for most users ends up becoming a huge and tedious time sink. But that’s just my opinion.
There have been some long standing bugs concerning the order that config files are loaded and rules starting to run before they are ready. I’ve seen anecdotal evidence that startup is slower with text based configs. You need to have access to the file system in order to change the configs. Stuff like that.
The semantic model is an optional way to organize and give a little extra meaning to your Items. It really has nothing to do with rules, yet, except for a couple of new Actions that can get the parent Equipment or Location for a given Item. For now all the model is used for is:
a structured way to organize your Items
automatically builds the Locations, Equipment, and Properties tabs of the Overview page in MainUI
Used by HABot to support natural language interactions with openHAB
That’s it. See the Getting Started Tutorial in the docs for more details. These things are definitely of benefit. But they are optional. Only use them if you have a need to.