OH3 - Textual configuration still supported?

Development Misc
81

The backup method you describe is a manual one and if that works for you go for it. Its not for me, mine are all automated as I am super lazy.

In the future there may be automated git configuration syncing. As a user would you want this feature

This with Mirroring would be ultimate backup solution. Mirroring for when you have a hardware failure of SD card so the recovery time is the time it takes to change SD card an boot. You don’t even need to redownload the jar files or setup the mqtt broker again.

Git is for when the house burns down and you want to rebuild it exactly the same as you did before.

I believe in freedom of choice and if you want to do it that way it is not wrong.

1 Like
82

No and yes.

“No” because it isn’t “feasible” to do any sort of DIY backup and restore of these files when you do not have enough knowledge of how the system works (as you said yourself).
It’s the straight road into disaster for many users.
That’s why it isn’t in the docs and also why I’ll never ever give a recommendation like that unless I’m convinced the addressee knows the prerequisites and consequences.

“Yes” because that’s what openhab-cli does. There already is a jsondb “backup” subfolder.

Leave implementation to the people that know how to do it. Use their tools and get them feedback to enhance them for everybody’s benefit.

As an overworked dev, you would want someone to build this feature.

83

someone to build and support this feature

There fixed it for you.
I am very aware that you asking for help dose not mean that it will be done. In fact I don’t think it worth the effort to build as the effort the team has put into Amanda and Mirroring is all that is needed. If someone wants it and takes it on then excellent go for it.

People don’t seam to understand that openhabian is not openHAB and both teams have put in a huge effort recently and you guys deserve some downtime.

2 Likes
84

Tuning in to this heated discussion but just wanted to add to the question the OP asked.

Short answer: As of now for some users a pure UI based configuration approach will simply be impossible without loosing features! This includes cases where map transformations are used. Which will be the case for many power users. Please see this table which sums up the capabilities of MainUI and items files very neatly.

Long answer: Inspired by this discussion I decided to switch to MainUI based items configuration today. I removed my .items file and imported it via MainUI. While this went very smoothly, I quickly noticed the following problems:

  • The map transformation issue (as mentioned above) which messed up my HABPanel display among other things. Yes, there is the rule based “proxy display item” workaround. I didn’t want to go down that rabbit hole for now.
  • Item metadata configuration capabilities are incomplete. I am using metadata tags to link items to the Homekit binding. They have special configuration options which are still present and working after MainUI import but which can only be changed textually via the code tab. You’d have to know the exact syntax, which (to my knowledge) is not documented. It is for items file based config.

Verdict: Text based configuration cannot go away anytime soon without breaking compatibility or at least inconveniencing many users. And if it should one day, there will still be the option to import. So there is no need to worry at all.

To new users I would say that it is probably best to go with MainUI item management. At least if the above issues are of no concern or if workarounds are used from the start. Special cases could still be handled via additional .items files. It is even possible (though probably not recommended) to edit JsonDB storage manually, e.g. to quickly change channel ids via search & replace. For those worrying about losing control.

3 Likes
85

And these examples show why the “many options to configure” approach does fail.
Now some things seem to be missing in the UI and some in the textual config.

Why not decide one main way to go? (like all the other smart home projects do as well) I don’t get why this seems so difficult in openhab.

2 Likes
86

Because of the users, simple as that.
This statement shall be no blame, don’t get me wrong.
We had many complaints about text config being to difficult, create a proper AdminUI.
When announcing a new UI, we got many complaints not to remove text config.
To not loose users on the way, both config methods are available.
Missing features in MainUI will come for shure…
And I still got no answer what features in textual config seem to be missing.

87

Because, to make a perhaps very flawed analogy to US politics, you’ll find that a convinced Republican will have a very hard time switching to voting Democratic just because you tell it’s the better ideology, or vice versa. It’s largely a matter of personal preferences and convictions. So IMHO it’s better to have both on offer, so everyone can make their own choice. But it depends on who is willing to work on what.

7 Likes
88

My wife gave me a worried look recently and asked me the following: “What should I ever do once you’re gone? I’ll never be able to maintain that!”

While I plan on staying very much alive for the foreseeable future and she was half joking there is a very real truth in what she said: From the average user’s point of view text based configuration is dead. There is no conceivable future where autoexec.bat and config.sys will ever come back into fashion again. And thank evolution for that!

I agree with you: Clearly the situation is not ideal. But openHAB is now closer to this goal than it has ever been.

As @hmerk pointed out there is nothing missing from text based configuration. (I do not have any Z-Wave devices which do seem to be the only exception according to the overview table.) On the other hand the devs do build more and more functionality into the UI. And only since OH3 there is one single central UI. Just go from there and extrapolate and it is clear where this is going. :slight_smile:

To be honest, my last “market research” round was long ago, but what open source smart home system does better at managing complexity than openHAB? I think the level of stability, flexibility and user friendliness is astonishing. With openHAB - in terms of configuration - you can have your cake and eat it too.

2 Likes
89

Well I understand that point but with limited development resources it would be wise to concentrate on a main way. (that is 100% supported and documented) If there are other ways that get developed fine but the main way should get all the resources first.

And by the way I don’t care if it is UI based or textual. So the UI based way is pretty fine for me too.

90

Choosing the method of authentication (basic/token/disable) in the configuration files and creating users with roles through textual configuration is missing.
Currently a first time setup of openhab is not possible without the gui because of this.

If you are honest with your self and if your wife is not into home automation already she will not maintain anything with a gui, either. It’ll just stop working some time and she’ll throw it out.

2 Likes
91

Good catch. However, judging from random posts in this forum many users who rely on text based config don’t even keep their things in config files. (Including me, btw.) So recreating things manually is part of the “disaster recovery” workflow. And in that respect adding users and roles is just one simple additional step. I suppose it boils down to “cost”. Which is relatively low compared to recreating items and rules.

But you are right of course! See also this posting in a similar thread. Over there @robr57 asks how to deal with a dev-prod system situation and how to carry over just part of a configuration (like a subset of items).

Yeah, you’ve got a point.

However I’m still trying to live the Star Trek dream of software usability :wink: so that’s where my mind was when I wrote that. Who knows what will be possible in 10-20 years time. She will have to maintain our NAS and backup system because we went paperless in 2016. This setup could not just be axed because it is a critical system and her work depends on it and all family documents are in there. But this will be doable due to the fact that all the configuration is in fact gui based and she definitely has an above average knowledge (and willingness to learn IT related stuff) for someone not in IT. So that was basically the point I was trying to make.

92

Are you really asking for creating users with password through plain text files ? I think, apart from GUI, creating them on karaf console, which already exists, is the better approach.
Can‘t comment on authentication method, but i guess there is a config param too.

1 Like
93

Not everything that works or used to work is a feature. It’s only a feature when it’s intentional and documented for the sort of use case you want to use it for.
For example I could create things or change settings by directly writing into runtime files.
But this will be overwritten on next regular change to the configuration.
Some “features” can be replaced by others. This for example applies to most transformation stuff.
You can call that from rules instead. So the functionality isn’t gone.

Expecting full feature parity is another common misconception.
If there is a GUI way to do something such as say to define a widget, is that a deficit that you cannot do so via text ? No it isn’t. It’s an advantage of GUI over text, a feature that is only available in GUI.

And not everything that does not work is intentional i.e. an intended lack of or “lost” feature. It can be a bug, too. Those two things you mentioned, have you opened Github issues ?
Was that ever supposed to be used in this context ?
You must not claim so unless a developer confirms this e.g. on the Github issue you opened.
If you didn’t it’s nothing but your very own personal point of view only

That’s another outright wrong claim that we have already discussed on the other thread and it does not turn into a right one by repeating it.
It just won’t work* the way you want it to work by using flat files as the input.
But it can be done through console which is text and automatable, too.
And fortunately so. Just as @hmerk commented that would be a security risk at work.

* I’m not even sure it can’t be done.
Maybe if someone with more endurance and willing to contribute (rather than just consume) sat down on his 4 letters trying to find a solution he might find one.

94

In my case I made an update from 2.5 to 3.0 and the whole config was taken over including textual configuration. Of course the items etc referenced in a text file was visible but not editable within the GUI.
Seems that you can stay with the text config but the future seems to go towards another direction.
In my case I decided to migrate everything to GUI configuration.

Greetz

1 Like
95

The good news is that YOU get to make this decision! Yippee, that’s right you get the choice and there are many angry discussions in other smart home projects that have recently killed textual config from people that don’t like the direction taken by that other project.

Unlike other projects openHAB can say that:
100% of bindings support the UI method.
99% of bindings support textual method.

Since the support is done at the core level, all bindings get both automatically. This thread is proof that we have people that strongly want both methods and the good news is that both are possible and users get the choice.

I find it amusing that people get annoyed over having choice compared to being a part of a project that dictates to you.

3 Likes
96

I tried to find it but maybe I missed it. It would be nice if you could give me a hint.

Enter user:role:password in a users.cfg and on the first start the plaintext password gets replaced by the password hash. It’s not more secure/unsecure than the json.db. Or can you please elaborate where you see the security risk?

Because using the console is not the same as file based configuration. It requires a running openhab instance and physical/ssh access to the machine openhab is running.
If it is not in a file it is not file based configuration!
Otherwise why not just curl the rest commands and say it’s textual configuration.

Now that’s just low.

I too think this is one of the great strengths of openhab.
You can have an easy start through the GUI but if you want to you can build complex tools on top of the openhab configuration files.

Fun fact:
There are people on this forum that left other smart home projects because openhab provided textual configuration. If you look through the old configuration threads you sometimes can read it in an answer.

1 Like
97

Do you mean this :

image
image972×200 5.25 KB

add the following to runtime.cfg :

org.openhab.restauth:allowBasicAuth=true
4 Likes
98

Oh come on, it wasn’t directed at you. We both know you contribute.

But it illustrates the situation: you can use what’s there because some volunteer built it for you.
If it’s not there, wait for someone to build it or build it yourself.

Define or call it whatever you like. Textual configuration (the thread title) it is.

The point is: it does the job.
BTW even the documentation uses this term and does not promise you anything other than that.
So please once and for all stop annoying us with ever repeating that demand of yours.
Thank you.

99

I am sure we all bring different experiences, expectations, maturity, culture, thinking and knowledge to the our ways of using openHAB.

I am in the business of change, and it is funny to notice how I resist change in various areas. I was once a system engineer and left the trade as I saw no future in it; the realisation that not necessarily the best product survives, but rather the better marketing… but also the ever increasing speed of change.

I started out with OHv1. It was all great, except that rule DSL was doing my head in; and it still does today :slight_smile: … then migrated to OHv2, also being happy that v1 bindings kept working. I am a late adopter, and read the forum a lot, to see what problems others encounter, which then steers my decision on what to use and what not. When the GUIs came out, which I perceived as half-baked, one could do this, the other could not, and the other could do both, but not all… I happily refrained from using them and continued text-based config (being stable, understood, and transparent), with all the advantages pointed out here and elsewhere.
Yes, they are all in one directory, easy to shift and backup, modify and ‘disable’.

To convince people like me (as one example of users) to use a GUI will prove difficult (adding that nobody needs or is expected or obliged to convince me).

But… and I think some guidance (with sensible reasoning) on the best way of using OHv3 would help many, including myself. I appreciate even subtle comments like:
a) this is what I do and I no longer help others doing it differently
b) this way has many benefits outweighing the other way
c) I used to do it this way, but now do this, because…
As I said, I am carefully observing and reading the forum… and it takes time for these comments to surface… and I appreciate these nevertheless.

As for road maps and open source… I had to learn that open source is anarchy. Individuals will do what they see fit, enter and leave any project they like with a care factor ranging from 0 to 100 on what their work means to others as long as it suits them.
The statement above is my opinion (and distilled from years of observation), without any intent to insult or denigrate any person or work.

From what I have seen so far WRT OHv3, it seems to be the best thing OH has ever been. It is exciting, some of the functionality I do not get (though I have a sense how good it is, I just do not grasp it to the extend to make use of it)… GUI and JSON DB seem to be the way forward, which I will embrace over time.

So for those who think something should be different, sure, provide constructive feedback and ask questions. In case you don’t like it (and I have been there, and had more frustrations than I ever admit), chose something else that suits you better.
Open source relies on the goodwill of others; I appreciate their work, even it at times it does not suit my vision. Yes, at times I wish I would be a good enough programmer to change the world :slight_smile: and as I am not I have to live with what is on offer (If I so chose).

… and the word ‘choice’ appeared quite frequently in this thread… for a reason: it is yours to make.

To all in involved: all the very best for 2021… and if you are developer, ignore the imbeciles and keep up the good work!

[edit] corrected typos

6 Likes
100

I wasn’t going to respond on this thread because it’s the same old argument we’ve had multiple times before. As for the main thrust of the discussion I have just a few comments.

  • backup and restore of the JSONDB is just as easy as backup and restore of the conf folder. If you want to see what openhab-cli does, why not open up the zip file and take a look? Any backup strategy that doesn’t include parts of userdata, even if you are 100% text configs, is incomplete. Bindings store data there, persistence is there, and anything done through the UI is there.

  • the docs are the way they are because that’s the best efforts of the volunteers who helped write them. Same goes for the features in the code. If you don’t like it, if the best efforts are not good enough, pitch in to help. “Making suggestions” frankly only serves to demoralize those who are putting forth their best efforts. at least open an issue and provide actionable suggestions.

  • If you want to preserve text based configs and feel they are second class citizens, pitch in or find someone to make them first class. Everything in OH is the way it is because someone decided to volunteer to do it. If your feature isn’t implemented, it’s because no one volunteered to do it and in all likelihood no one is going to volunteer to do it.

Now for this intreaging list of questions.

I discover all of my Things through the UI or Karaf Console. I will not help with .things file problems. Debugging syntax errors and finding the right parameters took up a huge percentage of my time. I realized that if people who had thesesproblems just used the UI and auto discovery we both would have saved hours. So I no longer so pens my time doing that. If a user wants to use. things files they are welcome to but I’m not a computer and refuse to be a syntax checker for .things, especially given for most technologies creating a Thing just involves accepting it from the inbox.

Over time I suspect my Rules DSL skills will atrophy and I’ll lose my ability to support them. But that’s more a matter of “you use or you lose” than a deliberate choice. Already I’m faced with needing to update a bunch of DP posts and I just don’t want to, especially for many of them I have ready made libraries people can just use instead of copy/paste/edit.

I pregnant won’t do to much with sitemaps as I’ve moved wholely over to Pages and am happy there.

I’ll probably still help with. items files as the syntax is relatively simple. But I don’t use them any more. I’m 100% UI based in OH 3 and quite happy.

b. I probably already answered but for Things, figuring out .things file syntax is a huge time sink. So far, except for a couple of very specific edge cases, the only justification for using them is “because I want to” or are based out of ignorence on how OH works.

For rules, although they are relatively more complicated to use, the other languages besides Rules DSL’s ability to create and use libraries more than makes up for that. And will the Helper Libraries, even those can be nearly as straight forward as Rules DSL. If much rather say "download this file and put it in this folder and add xyz my etadata to your items"b than post some code and expect users to be able to copy/paste/edit. Hence my unwillingness to update the DPs. I don’t want to tell you how to update the Time Of Day DP to use ZonedDateTime when you can just install my javaScript version and go without needing to care about that stuff.

c. I used to define everything but things then text based configs. I’m now 100% UI. This is because the Ui actually works for everything I’ve wanted to do. The model and “create equipment from Thing” has made creation and management of Items really easy for me and the Ui builds itself. The code tabs provide a way to share stuff on the forum. And features like the developer sidebar, scratch script, event stream, etc makes me every bit as productive as I am in VSCode.

Finally, it’s clear that the new users who will need the most help will be UI users and I be want to be knowledgeable enough to help them.

And that’s kind of an important point I almost make there. For better or worse, if text based configs feel like second class, well that may be because the developers of oh themselves are not using them. And no amount of complaining is going to force them to.

5 Likes