Configuration options with openHAB2

I only use config text files. I would prefer the paper-ui as an editor of the config text files.

Thanks for the update, appreciated.

I have followed this thread and some other threads very thoroughly because it matters to my company and the way we use openHAB2. We support a number of clients and having many clients, we aim to automate our procedures. The only way we can automate is by having either config files or a very well defined REST API to manipulate the configuration - Doing work in Paper UI or habmin is not an option.

I would like to propose that openHAB2 kept the Paper UI and database solution and developed that as far as possible to please the normal users - I fully understand that argument.

But, instead of basing the runtime activities under openHAB2 on the database contents, then it would make more sense to have an export/publish button that translated database content into configuration files and those were then used at runtime.

This serves 3 main purposes:

  1. There would be no confusion about where things were stored, people using the database would still get config files that “counted” - it would be much cleaner
  2. People who use the PaperUI, but eventually would like to move to config files could learn the config code by example
  3. Users could do all the work they were capable of themselves in the Paper UI (with the constraints of a form driven tool) and then get help from experts for the last details not possible by Paper UI in the config files.

In other words, make the user friendly Paper UI a code generator instead of a standalone configuration tool, the product would then truly cater to both techy people and end users.

2 Likes

Good thinking. But this approach would mean a one-way sync, right? So once I’d started tampering with my things in the files, I could never get back to editing them in the UI again? Something tells me that’s gonna get confusing for users as well. I would say you’d also need a corresponding import button to get those changes back in the UI. Other than that I think it’s a great idea. This world we’re living in now with two different ways to configure that creates stuff in two completely different places is very confusing


I very much appreciate all the thought that has gone into this discussion so far. As a *NIX sysadmin for many years, and as a user of openHAB, I would like to relate my experience moving to openHAB2. In summary, just shoot me.

  • My biggest difficulty has been in sorting through documentation and community discussion to figure out how things work. Absolutely this is a moving target - that is clear from reading this thread. But I have to tell you that, as an educated user coming from openHAB, sifting through the chaff to get to some understanding of the current situation has been HARD. I cannot tell you the number of times I have tried things on my dev system, made some breakthroughs in understanding, had to document what worked so far, and then wipe the system and rebuild from zero. Rinse and repeat. Often.
  • While people say you can do everything with text files in openHAB2, the documentation on this, especially regarding Things is thin and hard to find.
  • FWIW, what I have found is that a hybrid approach between the paperUI and text files is probably where I am going to land. The UI is convenient and fast for configuring bindings, Things and items, but I really like text for rules and sitemaps.
  • Backup is a serious concern. As admins/users of the system, we need solid documentation on backing up installations in OH2, and the sooner the better. Oh - and please, it would be great if this single “source of the truth” could be easy to find, and kept up to date. In fact, I view this problem as so serious that I may stick with OH1 until I can be sure that my understanding of the backup scenario in OH2 is correct.
  • Troubleshooting a db-only implementation is a nightmare. Troubleshooting with text files is quick, easy, and predictable (that last point is super-critical in troubleshooting).

Again, I really appreciate all the work that has gone into this project. I am involved in several “volunteer-powered” efforts, so I understand the limitations, and I wish I could contribute more. As a sysadmin, I know I am not a programmer. I have learned that the hard way over the years. So I cannot help there. But with all the praise I have for the project, I also have had a lot of pain in transitioning to OH2. I hope the conclusion of this discussion will help those that come after me/us.

1 Like