What is a “config”, if you drag&drop stuff in the UI and silently in the background create an item that has a link to a newly created thing that you use within a rule? I think when allowing UIs to do stuff, you need a database and cannot think of everything as an isolated “config file” any more.
By that “if paper UI can edit things that are defined by a text file” would mean
A) paper UI edits are stored in map DB. And the whole thing is a mixture of mapdb and textfile?
B) paper UI does edit Text files only for these things?
Sorry I wasn’t really clear about what I meant: I wasn’t talking about one “config”. It would simply be helpful to export the configuration for a single service, just like I can define the parameters when I click “configure” in the PaperUI.
But maybe I simply don’t fully understand the way openHAB 2 works - my current problem is the following: I have an installation with RWE-Smarthome items (which is a v1 binding) and some hue lightbulbs. The rwesmarthome binding dumps a sample configuration to the log on initialization, so I can copy and paste this to my items file - however I have to adjust the names of course.
I’d like to do the same with the hue bulbs which are configured as things in the mapDB so I can group them together etc. in one place.
interesting… so mapdb to be replaced is already in the works?
any rough time plan for this to be in the beta?
By that “if paper UI can edit things that are defined by a text file” would mean
C) paper UI edits are stored in map DB and they overrule the text file (which can be removed/deleted/regarded as an “old import”
so I can group them together etc. in one place.
You can already now define a single item file, which mixes items and groups items that are linked to rwe and to hue at the same time. Whether the thing definition is in a file or in the db does not really matter there.
interesting… so mapdb to be replaced is already in the works?
any rough time plan for this to be in the beta?
No, these were just ideas being discussed.
As mentioned above: I think mapdb is quite efficient and I would rather suggest thinking about an export/import mechanism to text files. There is no time plan, since I do not know anyone working on this.
I think the problem is when you define the thing in a file after the discovery and save in mapdb.
I could try to reproduce the issue if necessary.
What was making openHAB strong and the way to go for me, was that everything was visible in text files. There was nothing hidden somewhere in a binary configuration I was not able to see completely (but potentially overruling my textual definitions).
The only thing that was not so perfect (and still is with openHAB2) was the Designer. It was only partially able to codecomplete the XTEND syntax which was making some easy things unnecessary complicated for less technical users (type casting for instance).
In my first tests with openHAB2 I was faced with the disadvantage that those constellations could lead to. Was was using the Astro binding. First the new one, with limited functionality (right now). Later the 1.9 version with my old Item definitions. I was failing to make the Items work even if the binding was loaded and seems to work (cron for the next day was in the log etc.)
No matter what I did (removing the addon and re-add it etc). No chance. Sooner or later I just deleted the mapdb (and maybe some other stuff) re-added the 1.9 binding and I worked perfectly.
But there was no chance for me to understand why.
So from my point of view. Items, Things and Rules should remain Text only. And if there is an option to edit them via Paper UI it should change them there. Or if needed create a overrule file to show in text that there are modification done in the ui which are active or something…
Having two places in parallel where one might overrule the other but I do not see if and why is scaring me …
2 Likes
@Lars:
Exactly the same happened to me and I could not agree more to your conclusion.
I do not really understand the benefit of the whole Paper UI.
Creating items was never a big deal and the autodiscovery is only nice to have.
The problems I am always struggling with is the convoluted and poorly documented DSL of the rule files. Designer is mitigating this disadvantage quite a bit. Without designer I would have stopped using openhab.
For me the first priority to improve the user experience would be to fix this tool and make it useable also for reasonable file sizes and remove other bugs.
For ‘advanced users’ - yes - that’s true. But many people spend a lot of time getting all the binding strings sorted. This is especially true of bindings like z-wave which are quite complicated to configure. The number of questions we get on configuring devices is huge - with the OH2 features, once this is sorted for a device, everyone benefits by reduced configuration.
Clearly there are different ways this could be done, and different people have different views - a lot of people do want something more ‘point and shoot’ while some clearly don’t (as is clear from this thread). Personally, I like the point and shoot of a nice GUI, but I also do like the option of being able to ‘get back to basics’ and edit the configuration easily if something goes wrong, or we want to paste a load of similar configurations quickly…
ESH, is a flexible framework so it’s possible to do ‘anything’ of course - if enough people want a feature, then it should be possible to make it happen…
(just my thoughts 
)
@chris
Please do understand me wrong I do not hate the paper ui. But it would not be my first priority to improve the ease of use. My priority would be everything that makes the creation of rules less complicated due to the complexity of the DSL and the class definitions.
1 Like
I fully agree and that’s why I tend to having the two modes co-exist: All textual as people are used to do it with OH1 for power users and a “I am not a programmer and I just want the stuff to work” simply mode for beginners (with possibly reduced possibilities). The question is really where to draw the line best and how to enable beginners becoming power users. I think an export of discovered things to a thing file is definitely something that makes sense and should not be too hard to implement. But reflecting any possible configuration in the shell or a UI in a nicely structured and formatted config file is not really feasible.
Note that there are no priorities of the project itself. It evolves by people contributing code to it. And the majority of contributions to ESH in the past two years is about setup and configuration of the system through UIs.
@Kai.
I know that what is developed is what the developers like.
This is clear. User are not paying so they do not have a right to talk about priorities.
It is all about developers having fun.
I have got the message.
I know that what is developed is what the developers like.
No, you got it completely wrong here. Note that a majority of contributions to ESH come from DT and they invest money in having developers implement what their users want. And guess what: DT customers/users do not want to configure their smart home through text files!
2 Likes
Yes. Maybe it is that what I don’t like so far.
If it would be like: If there is something defined in a text file, it wins and I am not able/allowed to do changes via paper UI it would be much more segregated.
But if it is the other way around, there could always be something “winning” that I am not so easy to see or find like the experience I explained above.
Rules/Items whatever could simply have a Symbol next to them showing if its a
-paper ui xxx
or
-advanced mode / manually added xxx
And that maybe exportable to have a backup way for mapdb stuff?
Why do some of us like the text files? For me:
- You have an easy overview what is defined (items, rules…). No magic settings frustrates when debugging - the error must be in some of those config files.
- You can copy+past: No 20 Buttons click and text input fields for add a view items
- simple backup and use old versions by saving/replace the text content
This could also be possible inside Paper UI with „source view“ editing or something like this. Therefore I din’t need the text files.
Maybe isn’t there a way for „source view“ in the UI? E.g. in a XML structure with DB field name and value (if needed between CDATA sections).
And… keep it simple. I thought about frustration when you didn’t know an error is from a wrong setting somewhere in the UI or in some text file, or just a problem e.g. with keep text files an DB in sync.
1 Like
Why not use some standardized db instead of a binary one? There are a lot of good options out there (i.e. NoSQL, etc). That way “text” users can easily modify the db, and non-users don’t need to.
It’s interesting…I’m a web developer, and more than capable of figuring out how to do text configs, but far prefer using the UI (except for rules). That said, I would really like it if I could tweak by directly in the database. I think of it as being very similar to what many web apps do: have a UI front-end with something like mysql (not suggesting that as the solution…would be a poor choice in this case)backing it. I can always hop into mysql and work directly there if I need to access the data.
And then for those who are migrating from OH1, have a way of importing the text files.
I hope its OK to add a little of my own thoughts. I think the current use of the Text Files is still a very important feature, at least until OH2 develops further along and perhaps there is some type of standardization in the bindings and item formatting.
I’m still relatively knew to OpenHab, but I do use the Kodi (formerly XBMC) and the Chamberlain MyQ bindings. And currently those bindings don’t necessarily generate items when you install them. I’m sure there are probably a bunch of other binding similar that are really customized specifically to one’s use and don’t necessarily create an item file.
So how do you back your up that information and items for these non typical bindings?
I think shorty707’s comment gets close to what I think could be a viable solution to making text files and other confuration mechanisms coexistst, as Kai Kreuzer puts it.
A key issue in this discussion so far has been the fact that config files are read-only (and I think they should be), which makes overriding anything they specify difficult to do, if you don’t want to either confuse your users and at the same time make the system accessible.
Hence, the two (read-only config files + dynamic configurations) must be unified with some finesse.
I’d like to see a tiered system, where OH2’s 1st place to look for config files is the conf/ directory.
The 2nd place to look, would be any form of dynamic configuration that was done through the (web) UI/karaf shell. This 2nd tier could also be a way for OH2 to override whatever is defined in conf/.
In order to not confuse power users, there should be a facility to prevent such overrides. E.g. by adding a final: true flag to a configuration file’s section, users can stop OH2 from ever creating any other representation of this section.
At the same time, the (web) UI should contain a section that clearly lists all configuration bits and pieces - regardless of whether the plugins involved support this kind of introspection - and for each of those display where it was loaded from, and whether it was marked final. On top of that, a button should also be added to each, that erases any overriding definition and reverts the respective config back to what is defined in the text file.
Lastly, a reliable & universal config export facility can help power users and beginners alike to understand in what ways changing the settings in the (web) UI would affect their textual configs. This feature could look like a button next to each config item in the aforementioned list, which opens an exported view of said config item, including all overriding properties that were created from the (web) UI.
I would like to extend this logic not just to the configuration of plugins, things and sitemaps, but also to the plugins themselves, meaning the binaries that power each plugin.
As you can tell form my comment, I think most of the issues brought forward in this discussion can be managed by providing visibility into what OH2 is doing, as well as means to explicitly & interactively control that.
Interesting topic. I ended up here trying to figure out how to manage an OH2 installation with a configuration management tools, in my case Ansible.
My goal was to be able to keep all the OH configuration, including Things, Items, Rules, Sitemaps, and also stuff like log level etc in a central location, and in case I want to deploy a new instance of Openhab (for instance for redundancy or if the hardware breaks down).
So I really want every part of the configuration to be in some sort of text format, like json, xml or something else.
How am I supposed to be able to keep my configuration in a central place and version controlled if some config is in a dynamic DB or the OSGI framework “somewhere”?
That also make it much more easy to troubleshoot in my opinion.
Why not make Paper UI optional (or maybe that is the plan)? So that we who love text files could continue just using that. And to attract a broader user base offer full functionality through the Paper UI.
But I believe mixing the two is going to lead to confusion.
And for the rules engine/language, to make that easier why not build on that Blockly concept in Habmin? I havent used it myself, but I guess that would really be easy to understand for most people.
A better documentation of the Xtend language used (specific to OH, with examples) could also help.
Thats just my 5 cents.
TL;DR: How do I manage the OH2 configuration with Ansible or some other configuration management tool? And to version control it?
If Paper UI means mapdb, then make it optional.
Blockly for rules + documentation, why not?
1 Like