I am going to jump in here, I have been using openhab since the V1 days and went through the confusion about what I can and can’t do in paperui, then reverted to doing as much as I can in text files so I can build rules. I will admit i read about half the thread before I started skimming to the end so apologies if this has already been said.
Lets take a step back and have a look at how other large projects are doing this kind of thing. In the systems engineering/devops world things are evolving towards infrastructure as code. In the Chef world this means a ruby DSL that describes how a service is deployed and configured. Puppet, Ansible and Salt all do it a little differently, but ultimately the goal is to be able to get the code into a source code repository eg git a complete description of how something is deployed, have it is versioned, and have it regression tested. The bonus is you can share your chef examples with other users in the community. This is also how most software development is done. It all comes back to a text. So I think having a text based way to deploy OpenHab is important for the reasons i stated above for infrastructure as code.
Lets put that aside for one second and agree that we also need a way for non technical users or users who just don’t care about versioning, sharing, repeatable deployment, and just want a gui to click on. I think one of the challenges of openhab is that it is a relatively complex thing to install, requires knowledge of linux, how to install rpm/deb packages, even installing using openhabian on a raspberry pi has a reasonably high bar. So our user base will tend to be on the more technical level to start with. If openhab wants to become more mainstream then that is an area that needs to be worked on. Lets just assume openhab need to pass the spouse test, so being able to use openhab by a spouse who didn’t install it should be a goal that we have. In my opinion openhab fails the spouse test at the moment, my spouse is a software developer and I would never dream of inflicting paperui on her. Hab pannel is getting closers but she still will not use it. So the TDLR is that we need a UI that works for management and configuration.
So how have other companies solved this? The first example i am going to use is Tenable’s Security Center. They split the UI from the Core and the only way to interact with core of the product is via the API, but you can write your own interactions using what ever language you like as long as you use the REST based API. If you don’t want to do that then you use the provided UI that talks to the API. They have replaced the UI completely a couple times, the first was in Flash, then the more recent version is HTML 5. The second example is Amazon AWS, again everything is via an API, if you want to deploy using infrastructure as code eg git based text files you can use tools like Teraform to configure and deploy your complete service from the network, security, loadbalancers, all the way to webservers. If you want to do it manually most of the AWS APIs now have a web GUI that allows you to configure it.
So here is my suggestion, lets focus on creating an API for creating, updating, and deleting the types of objects we need, eg rules, items, things, persistences, bindings. Then build an abstraction layer that allows you to do everything via text files, or yaml, or json, or the existing openhab DSL. If you don’t like the yaml then there is nothing to stop you from writing your own app that uses json. Then the GUI people can build their version that does the same thing using the same APIs. It really shouldn’t matter how the data is persisted in the core app as long as it can manipulated consitently via the API. I haven’t looked at the openhab APIs in detail so this much of this may already exist, so all that has to be done is build an app that works with the existing text files.
Lets look at the rules file as an example. Is there a way to upload a rules files to openhab via the API? I am guessing no since I can’t edit a rules file via PaperUI but willing to be corrected on this. Having a simple way to upload an existing items,things,configs,rules would be a kind of V1 API type thing. Then V2 would would add more complex APIs that allow you build via something like a GUI. The V1 API would give everyone the same thing they have right now with some wrapper code that that you run to perform an update. If you use github you could even publish using a webhook on merging a pull request. The V2 API would require a more complex app that parses the rules and translates them into the V2 API calls to manipulate the data stored in the core app.
Using an API also gives you the advantage of being able to query the core for auto discovered things and create textual representations of them if you choose, in essence this could be the way to backup all the data stored in core. The Web GUI might use the APIs to export it to a single yaml file and give you a graphical way to import only the sections you want, again the actual format shouldn’t mater as long as the app you are using knows how to backup the data then import it again.
With an API based solution all you need to do is write or convince a developer to write an app that does what you want, be it GUI or Text.
What do people think, could this work for us?