Configuration without PaperUI, only config files?

  • OpenHAB version: 2.5

I have a working OpenHAB configuration, migrated from OpenHAB 1.x, that is a mix of PaperUI and config files, with some items defined in PaperUI and some others in comfig files.
Can be surprising, but I would like to use only config files. Currently I have MQTT devices, Ikea Tradfri, pushover notifications and video surveilance cameras.
AFAIK this is possible with OpenHAB 2.5, even if I add more devices (except Z Wave devices) and if it would still be possible in OpenHAB 3.0.

N.B. The reason for this need is that i want to automate the deployment of the configuration with puppet and for that I need to have all the configuration in text files.

You can also directly write into the jsondb file. That’s what the UIs do.

I thought the UIs only communicated with OH through the API.

@listas
I am also a big fan if the textual configuration but currently it is not possible to deploy from scratch with a textual configuration only.
You have to create the admin user through the paper ui on first start (I have already created an issue here).

@mstormi
As Bruce pointed out the UIs communicate through the rest api.
Also editing the .db files is not the same as textual configuration, because entries will not be validated and it is necessary to stop openhab every time to make the change.

1 Like

@Spaceman_Spiff besides creating the admin user in the first start, would it be possible to do all configuration with text files?
Also I could configure puppet to restart OpenHAB each time that it modifies a jsondb file (and take the rist of a malformed configuration), but that is less than a perfect solution.
Also I read your issue, and the answers you got from lolodomo, and this brought another issue to my mind. In other projects internal config files (like jsondb files here) are “internal” and can change without warning from release to release. That could impose certain level of risk if I use them directly.

Yes - it’s definitely possible and that is how I am running my installation. Notable exception is z-wave because you can not set device parameters once you created a thing in a file.

Editing internal (.db) files that are not meant to be edited is always bad and nothing more than a dirty hack. There are way to many possible errors, may it be schema changes, undesired side effects, runtime problems, lack of validation, etc…
Just because it’s file that contains text doesn’t mean it’s meant to be edited.

1 Like

I believe the Main UI in OH3 requires configuration through the UI.

right my comment was a bit too condensed

correct but think of the use case
This is for initial setup of a system only. I don’t know why one would want to setup an OH box more than once.

So you should manually setup your system through UI, take a copy of jsondb when it’s done and deploy that every time you install (not update!) through Puppet. That way it has been validated before.
For updating you should not do that I agree but for that you can push .things/.items/.rules files.

But that is just restoring a backup from an existing configuration which might be bound to a specific installation. It already might not work if you move the .db from one openhab instance to another.
There might be links, things and services in the .db that don’t exist on the instance or the .db schema might have changed with the new openhab version or don’t exist in the older openhab version.
And if you only want to setup certain parts of the installation you start merging end editing the .db files and most certainly will make errors and miss important parts which leads to flaky behavior.

As soon as you don’t want to deploy the exact configuration to the exact instance working with the .db is not feasible any more. And if you start administration multiple instances the only real way is to merge and share content based on configuration files and it’s really frustrating some times that textual configuration is neglected by the maintainers.

1 Like

No. The idea is to deploy a minimum jsondb (and static config files) once and ONLY to bootstrap a fresh system with the minimum of config that is required to get it running working.
This will work for any instance.

Note there are no things, items, links, rules at this stage.
Then move on and use file upload to do all the config.
Those get validated and you can replace them to update the config.

In the long run you better accept that OH went “GUI first”.
I also like file config better, in particular for remote deployments and operations, but you must not blame maintainers for “neglecting” file config, that just ain’t true.

Since, I assume, you wish to use a UI for monitoring, be aware that, I believe, parts of the OH3 UI need to be configured through the UI.

You are right, this will of course work but only as long as the content for the minimum config is the same.
This includes e.g. the admin user which has to be shared across instances.

This is rather an observation and not “blaming”. I know this is an OS project and everybody contributes what they feel like doing.
But none of the new OH3 features (GUI, API auth type and users) can be configured through textual configuration hence textual configuration is neglected.

1 Like

Yes you can add users through Karaf console (I have not tried but that’s probably including the initial admin) today.
I’m sure this will also be possible for the new GUI but as that is just getting out the door you must not expect that to be available and documented right today.
That’s a matter of prioritization.
Again: that’s not neglection. You are not making friends by insisting on that view (und das wird im Englischen als ‘blaming’ und nicht genauso wie im deutschen Wortsinne verstanden).

That is not textual configuration though. That is command line configuration. If the UI truly was just using the API to communicate with IOH that should include the user configuration parts.

You can also configure that via users.json.

I didn’t want to spark a battle with my question. As it has been said, This is an Open Source proyect, and in the documents it’s clearly stated: Let’s put this in the front: nobody here works for openHAB. The community members are helping with an Open Source Project, not a commercial software.
So, I understand that here (and in any other OS forum), when I receive help, it is welcome as it is, the same that when I try to provide help in any forum.

That said, the reasons that I have for looking for text configuration are clear but, probably, very specific of my case. (It’s not normal having sooo much servers - RPis, etc. at home that you need to manage with Puppet) and for the 99% of the users, the GUI is better.

There are other options that can support full text file configuration (please, don’t take this as a threat), but I prefer to stick with OpenHAB if possible. That’s why I was asking.

thanks to all for your comments.

1 Like

I am under the impression that it will not be supported and I have not read otherwise.
If that is not true, I’ll gladly revoke that part of my argument.

You have to enter the hashed password so that will not work for creating new users / modifying existing ones.

@listas
Textual configuration works (at least to some degree) and will save you lots of headaches in the long run.

Or maybe it isn’t. But even that would not be neglection.
I’d highly question that it makes sense to define a GUI via text config (as long as storage is in text form but that it is already) especially as unlike with sitemaps, you need to use some sort of interactive what-you-see-is-what-you-get editor when designing the Main UI anyway.

Und ‘argument’ würde hier vermutlich mehrheitlich übersetzt mit ‘Streit’. Du formulierst gerade echt nicht sonderlich geschickt.

Which can be done using console instead. Stop insisting on files. Karaf CLI also is textual input that you can trigger from Puppet, Ansible or the like.
And it probably can be accomplished somehow. Today you can enter users in users.properties with a plaintext password that gets replaced by its hash by Karaf on first use, maybe this already works.
Just sit down and find out yourself and don’t expect GUI developers to provide you with that information.

Or interact with the REST API to do it. I don’t know Puppet, but Ansible and Chef can both make REST API calls as part of their playbooks/cookbooks. I’d be surprised if Puppet can’t do the same.

As was mentioned in the conversation between Marcus and Spaceman_Spiff, if you have lots of openHAB servers at your home and each has a different configuration with some shared configuration as well, than it becomes a pretty important feature to be able to deploy piece parts of configuration through automation. But, if you’ve just the one config which is going to usually be the case for most home users of this home automation software, a simple restore from backup/check out from source control of the entire config should be more than adequate. And in that case all you need to do is have Puppet check out the conf and userdata folders and you are good to go.

I have a similar setup and a similar problem with lots of machines I need to manage. I prefer Ansible as it’s lighter weight, but the concept is the same. Ansible checks out my full OH config from my git server (including userdata which includes the JSONDB) and pulls the image and runs the container with that checked out config.

I do have three instances of OH, my production 2.5, and instance at my dad’s house, and my OH 3 system. Each has their own repo, though I could have just as easily created their own branches.

I’m not going to weight in on one approach over the other. I just want to point out that often times I see people saying “X cannot be done with JSONDB” when in fact it can be done and done just as easily, depending on your specific requirements.

If you phrase it like that everything is a textual input. Rest API commands are also just text that gets sent over http. File based has many advantages and is not without reason the unix philosophy.

That mechanism was exactly what I was hoping for but it doesn’t work because there is a role tied to the user (e.g. administrator, user).

I am not a native speaker and my intention is not to come off rude so I appreciate the comments about my phrasing.

1 Like