Policy - text files and/or GUIs

Of the core group of maintainers, some are pro files and others are very much pro UIs.

Is there an official policy on the topic? I am specifically referring to text files remaining as first class citizens going forward? I personally have no interest in the admin UIs as the text files can be generated which cuts out immensely on the setup time and makes the OH installation truly ephemeral.

No there is no such thing as an official policy. What’s closest to being a current guideline is this.
It’s pretty safe to assume that neither of these methods will be dropped in the foreseeable future.

3 Likes

Is that up to date?
Is there any reason that HabMin is preferred over the Paper UI for zwave?

Yes.

Yes. PaperUI will update all parameters while habmin will only update changes.

There is no official policy.

There has been talk about potentially changing the format of the text configs and changing how they are loaded (i.e. requiring an explicit load action instead of having them automatically reloaded). But I don’t know if there is any actual work being done on this front. No matter what, if it does change in these ways then there will also be some sort of automated or semiautomated way to transition from the current format to that new format.

Will this happen in OH 3? I can’t say.

It’s worth mentioning that the JSONDB stuff can also be backed up, stored in git or what ever, and restored to make your OH installation truly ephemeral as well. I run OH in Docker, yet I still allow OH to automatically discover my Things and I have no problem spinning up an exact duplicate of the config as the need arises.

The format doesn’t really matter - generating one text format or another is the least of my worries.

The problem is that I don’t want to have to back it up which is entirely doable if everything is generated. And messing around with changes to a JSON file is really ugly compared to simply generating a full .items file.

When packaging for NixOS (I’ll do a write-up of this at some point in the future) where we have a full programming language available to describe the configuration of machines, it’s super convenient when you have a external canonical source of truth that describes your network which can be used to then generate all the various components.

Specifically how I am doing this right now when running both OH and HA in tandem while moving things over, I can generate the configuration for both from one source. So if “switch-3” is moved from the lounge to the nursery, it will automatically appear in the right group and at the right location for both OH and HA.
I already have

Is there any particular reason for that or is it simply because nobody has sat down and formalised it?

@peterhoeg What is your reasoning to run both OH and HA?

Look at 2019 survey : 94 % of users are using text configuraction.

Short answer: no and no. Long version: go read the threads in the development section if you really want to know.

Because I already have HA working while I’m getting things figured out for OH - but I definitely want to get rid of HA and use OH exclusively. That same source of truth is also used to generate a bunch of other things. The fact that I can use that for both OH and HA is just gravy.

1 Like

Your main complaint seems to be that the json is not fun to edit by hand, but you are doing the edits programatically and json is a great format for that. And from what you describe, you only do this when deploying OH.

I’m not saying you should use the jsondb for this, but I do disk up when ever I see someone say stuff like this is impossible with jsondb. It’s not.

There is no one to formalize it. A change to the config file might come before the AC but the AC does not dictate the direction of OH. The AC only mediates controversies between maintainers. The maintainers if the various parts of OH control the direction the software goes in.

Fair enough. I recently moved my small zwave network from HA to OH.

Oh it’s definitely not impossible, but having to mutate state in a blob of JSON is far uglier than simply generating a set of .items files. Let’s say I remove an item (dead, re-purposed, given away, whatever) - I will know need to know a lot about the internals of the jsondb in order to be able to cleanly remove it whereas in the case of the generated item file, I simply don’t generate it.

Not really. You just need to know the name of the Item. You could pull/find the relevant record with a super simple JSONPATH. It’s actually pretty easy to find and remove an element of an array (which is the operation you are talking about) with most JSON libraries.

Is using a JSON Path with $.MyItem (where MyItem is the Item name) really that much more complex than a REGEX akin to .* MyItem .* to find the Item entry? All the Items are stored in an array. The root element for each Item is the Item’s name. Everything about the Item is stored in that one record. Things are only a little more involved but essentially the same. It’s not a complicated JSON format.

Or if manipulating JSON directly isn’t desired, you can remove an Item really easily using the REST API. You don’t even need to mess with JSON then, you just need the Item’s name.

1 Like

Sure, it’s definitely doable. But in either case (direct manipulation of the jsondb or using the rest api), we still need to keep track of state outside (creates, deletes and so on) whereas when we generate .item files, no state ever needs to be manipulated - either the files are there or they are not. That makes things far nicer.

The difference you are referring to is caused by the actual situation of openHAB using jsonDB and .items and .things files. While jsonDB is used internally , the user can use the files as well. The glitch is both methods do not exchange.
If openHAB would be using one version solely, even if it would be jsonDB, keeping track would not be needed!

I noticed another “glitch” the other day. The Paper UI correctly does not let you delete text-based items, but it unsuccessfully attempts to allow editing of them.

Editing the JSONDB can only be done when openHAB is not running.
Using the REST API can only be done when openHAB is running.

Text files can be edited whether or not openHAB is running (when it is running, openHAB will automatically pick up the changes).

1 Like