I’ve been using OpenHAB since the early days, and I’m curious to know how many of you still prefer to use text-based configuration for items, rules, and things.
I’ve noticed that the UI has gotten significantly better over the years, and I’m wondering if more users have transitioned to fully using the UI for everything.
What are your thoughts? Do you still prefer text-based configs, or have you moved on to using the UI exclusively? Any particular reasons for your choice?
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.
In my opinion, every new user should start with the UI, then switch to text config if they find the UI too limiting. The vast majority would never feel the need to do so.
It’s more complicated for users who predate OH3, because many of us have systems that work just fine. Admittedly, this is why I’ve been so slow to move out of text files for items and rules. Rather than carrying over the rules I’ve made (which reflect RulesDSL thinking), I want to rebuild around UI/Blockly rules. I just need to find the time to do it, and openHAB has been a low priority for me in 2024.
I exclusively use file based rules and a few .items and .things file, but mostly have moved the bulk of my things, items and sitemaps into being created programmatically from a ruby script (file based)
This is no longer true. There were bugs in the past that made it reload everything but they have been fixed I believe. Now only the modified items are reloaded (as how it should be)
I have a very small installation which doesn’t change often and was initially only created to bridge my legacy home automation system to HomeKit. I have not yet bothered to migrate the remaining text items to UI.
I started with text files because, as far as I remember, the documentation was focused on text and, because of my job, I know the advantages of text based editing. Copy/paste from documentation and adapting seemed to be easier than trying to use the UI where I couldn’t make sense of most options.
I only found out later that the UI automates many steps and it has improved considerably, too. But, as an occasional user, I still struggle with the semantic model and don’t really make use of it, yet.
I also migrated everything (things, items, sitemaps, rules) to files when 3.0 came, because I can now see everything in the UI that I configured in files.
I started completely text-based but migrated 90% to UI. I can’t explain any better than Rich, it’s just much quicker: A new binding with things and items is just a few clicks away. More important the exceptions:
MQTT-things. I find them hard to configure in the UI especially because most of the examples are text based
Rollershutter-items: The rollershutter-profile from the marketplace that simulates positions requires text based items as there is no way to provide the profile-configurations from the UI.
I started with OH 1.8 and text files.
Especially for my KNX system I found it’s very comfortable, once it works for one device, I just copied the lines and adjusted GA and so on…
Also my rules are all text files. I work with VSC and so I have them all in one overview. And several rules are a bit more complicated, I couldn’t imagine how to solve this with UI.
But younger things and items are often created with UI, so it’s a mixture 95:5 …
I also use the text bassed version, for the same reasons.
I have an installation of OpenHab to test the configuration before move to “production”.
With text based file I can modify in test environment end then move the file directly.
For me its a mix. I prefer having my items and rules in text but things tend to be better with UI. I personally find I have a bit more control doing it via files but the UI is great too.
One more text based user here. I am running four OH systems at different locations, vpn connection to all at the same time, all can be opened in VSCode on my dev rig, reuse (copy&paste) my own code between the sites is soo easy. Probably i could do sg similar via web ui, but i have 100+ things, 500+ items, 50+ rules text based, lazy to rework all, until absolutely nevessary. Backup and versioning is peace of cake this way, probably also possible on more modern way, but i am too old and hate to change if sg is working perfectly…
The only place I find txt based things/items useful, is where I have to deal multiple things/items which need repetitive corrections.
I have several mobs devices with 30-80 things each, so editing them at once or consecutive is very convenient and is not available with UI.
One more super useful feature I find now is feeding mod is documentation of the device to ChatGPT and asking it to prepare things/items. It does hallucinate, but still super helpful
and text files.