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.
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
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. 
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
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.
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
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 
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.
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
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.
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
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
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
4 Likes
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.
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 … 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 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
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
As always: I appreciate your input and work you provide to the community. 
Not sure why you, amongst all posts, quoted mine, and unfortunately only partially, thus creating the impression you are responding to what I’d posted.
Just to clarify what that post fragment should have been:
… and the reason provided: which I use to inform my decision.
Since I am neither clinging to text-based config, nor do I need convincing either way, I will assume your response is directed at people other than me.
That said: I will be using the GUI, as everything I’ve read so far clearly promotes this approach for various positive reasons.
[And I will most likely start from scratch to make full use the functionality in OHv3.]
I was mainly responding to the three questions as they were interesting and stayed in such a way as to not take a stand, just asking why individuals made the choices they did. So I posted mine.
That’s what I did and I’m very happy with the result.
3 Likes
I agree with you on (almost) all accounts.
But what what should people on this forum take away from this? Never voice your opinion unless you have it confirmed by a developer via a GitHub issue? Features in openHAB either work intentionally or are workarounds - pick any of the two explanations but don’t complain? I posted a link to a table - supposedly put together by the devs - where they explicitly state that some things cannot be done via the UI. So I made a conscious decision to not open yet another GitHub issue to annoy developers who already have their hands full. We are both IT professionals so we both know how it is. I also tent do give explanations for why I come to conclusions. I may still be wrong 50% of the time. But I do try.
There is an important paradigm in software development: Keep one and the same functionality in one place and use one technology to implement it. Not doing so immediately doubles all efforts: Double the testing, double the documentation, double the implementation time. And it confuses the hell out of the users - as can be observed in this forum many many times over. Reality of course is not that simple and there can be a conscious decision to make an exception from this general rule (or recommendation / best practice - if “rule” is too strong a word for it). Most of the time such a decision is driven by: The need or wish to maintain compatibility and/or the need or wish to satisfy a diverse user base. There may be other reasons as well. The openHAB team has made the decision to stick with both UI based and file based configuration. And I applaud that decision. I am on the text based bandwagon. Others will love the UI based approach.
Having said this there is the issue of feature parity. And again - I love what the devs are doing. Most of them in their spare time and without pay. Software development is hard and requires discipline. And everyone is nagging and there is no pleasing some people. But that doesn’t change the fact that there may be problematic situations and that it is worth pointing them out. While the decision to keep both UI based and text based configuration is sound I do not think the same thing applies to the disparity of features. The map transformations are a good example. This only creates a feeling of insecurity among the user base. Is this deprecated? Should I or should I not use it? Also, creating dozens of rules and doubling dozens of items just to produce display texts is exactly what devs wanted to avoid by having map transformations in the first place. Yes, there is an alternative. Does it make sense? Absolutely not.
This is only emphasised by the fact that both UI and text files feed into the same “single point of truth” - the JsonDB. I completely see why the current situation is like it is. The devs can only do so much and UI design is hard and time consuming. But no, it does not make sense. It is a shortcoming. And no one needs to be happy with it as long as there are civilised discussions about it.
Here’s a personal point of view: Your comments tend to sound bossy. This forum is not your company and we are not your employees.
2 Likes
I must say that I 100% agree with using the UI for everything I need.
OH2 MQTT was a pain for thing however with OH3 creating all my things again didn’t take to long with the code tab. I didn’t even try and login with VSCode until yesterday.
Ask a good question get a well formed answer.
My approach is the same as Rich’s for the simple reason is that is the way I would expect new people to be able to setup the easiest.
With the widgets I am creating it relies on you adding the thing by discovery and creating the items using the create equipment from thing with the default item names. This means you can add the widget as the default one for that equipment and it will auto populate the data without the user having to set everything up. Then on the page you just add widget from model and no setting are required it just works.
Anyone can voice their opinion. But simply voicing your opinion dues not mean others have to agree and without someone to do the work of implementing it nothing will result in the voicing of the opinion. Repeatedly voicing the opinion without attempts to actually do something about it is pretty much just complaining for the sake of complaining. It doesn’t solve anything.
Ultimately, the developers are competent and have made the best decisions they can based on the information at the time and the willingness of someone to work on it. Endless arguments on the forum do nothing, especially without issues and feature requests. And even with that, someone has to volunteer to implement it.
I think what gets me the most about such threads is the people complaining somehow think that anything they are saying is something we haven’t considered before. That somehow we are not competent enough to see things the same way. Or worse, we don’t lack competency, we just don’t care or are actively malicious.
That’s the part that hurts.
It’s always: why is it this way? That’s stupid, you should do it my way. After expaining why things are the way they are we end up with OpenHAB doesn’t care about it’s users. It’s exhausting and explains some of the reactions on this forum.
I also give the benefit of the doubt to those who raise the issues. I’m sure that’s not the intent. But if you are digging a hole and someone wonders by, munching on a sandwich and starts to explain to you how you are digging that hole all wrong without even offering to pick up a shovel and help, you might understand how theses types of threads come across.
3 Likes