There are lots of people still using file based configs. Based on the sorts of questions that get asked on the forum, I’d say there are a bunch of people who use file based who really have no business doing so, but that’s neither here nor there.
In my day-to-day job, when I’m not doing PPT engineering (ugh) I’m working with text files. I’ve very comfortable with text files. However, with OH I am almost exclusively using a managed config. The only think that isn’t managed through MainUI is my tiny personal rules libary and my published openHAB Rules Tools Announcements.
Reasons for my choice? In no particular order:
-
I very rarely need to look at the docs to figure out how to do something. It’s all there in the UI. All the options are presented with explanation.
-
It’s very difficult to make a syntax error in the UI. And in those rare cases where that happens, it’s very easy to figure out. Any time lost to occasionally using the mouse is more than made up for in time saved hunting down missplaced commas or a lowercase letter that should be upper case. This is a mjor reason I won’t support file based configs very much anymore. I’d rather spend my time solving real problems, not typos.
-
Intellisense is pretty good in MainUI when coding rules. It’s not as good as VSCode with the OH add-on but I find I don’t need that much because of the Developer Sidebar.
-
Automated and semiautomated creation of various entities (Things autodiscovery, Item through “create equipment from thing”.
-
The Developer Sidebar is the key to productivity with managed configs. I’m as productive if not more productive through the sidebar than I was through VSCode. It provides:
- context sensitive help and tutorials
- you can search for any entity in OH and pin it for later use letting you set up an adhoc workspace letting you easily navigate and manipulate (enable, disable, command, run) Items, Things, Rules, Widgets, Transformations, etc in one browser page
- quick access to the -Scratchpad- rule where you can experiment and quickly try stuff out, or send commands and updates or other operations you can’t do through the pinned entities in the sidebar.
- expression tester which is helpful when developing widgets
- event stream viewer which is basically events.log available right there in the sidebar with built in filtering, stop and start.
-
All configs are saved in text files too and order is maintained making it suitable for checking in to source control (e.g. git) for history tracking. You can also manually inspect and if all else fails edit these files.
-
The massive proliferation of Item metadata, some of which can be quite large, have made .items files very challenging to use.
-
While I use JS Scripting for rules, Blockly is available for those who are not as adept at programming. And since it’s graphical, it’s hard to make syntax errors (see above) and you rarely need to use the reference docs because everything is presented right there.
-
The concept of rule conditions have made many of my rules much simpler.
-
Access to view and modify any OH configuration when I’m away from home.
-
The semantic model is a lot more work to retrofit to existing Items (again, needing to look stuff up in the docs instead of selecting from a list). It’s much faster and easier to create Items anew using “create equipment from thing” if you want to use the semantic model (which I highly recommend if using MainUI).
-
Because everything is in the UI already, it doesn’t feel weird to use rule templates which are only available through the UI. There are a number of excellent rule templates on the marketplace. Why write rules you don’t have to?
-
Custom MainUI widgets are pretty much only possible to create through the UI.
-
This is more a statement against using Rules DSL than for using the UI, but even simple UI rules can do things that are impossible to do in Rules DSL like have a rule call another rule or enable/disable another rule. Even Blockly can access more of the OH API than Rules DSL can now. I recommend against any new development of Rules DSL and your time would better be spent working in any of the other rules options.
-
In those relatively rare cases where you need to make a bunch of something similar (e.g. a bunch of Generic MQTT Things) you can use either the REST API or the Code tab to copy/paste/edit and rapidly create a bunch of similar “things”. Sure, it’s not as quick and easy (thought the REST API comes close) as editing a text file, but it’s also not something that usually needs to be done that often making this minor inconvenience a relatively non-issue.
-
Updates to configs are much less disruptive. In file based configs, saving a single .items file might cause all your Items to reload and a bunch of your rules to retrigger. With a managed config, if you edit an Item, only that one Item is updated. OH doesn’t have to go out and reload and initialize a bunch of stuff (I believe this is getting better for file configs).
-
This is relatively minor, but loading and startup is a little faster with managed configs.
-
Managed configs get automatically backed up. The number of backups is configurable and if a file becomes corrupted the most recent backup is used.
I’m sure there are more I could come up with but I think I’ve a pretty good list now.
If text files is your thing, they are not going away any time soon. For me, they feel like they just make everything harder for no good reason. You may have a good reason but I don’t. I’ve also found there are lots of bad reasons people stick to files too which is somewhat irksome.