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.
@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.
@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.
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.
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.
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.
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.
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.
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.