OH3 - Textual configuration still supported?

Development Misc
40

In example - OH2: clear directory structure and file examples for .items and .things (to keep it simple, but clearly there are other file types) It’s an OH definition, not a binding definition, though there were variations. The main structure was defined.

When the files are updated, the engine picks these up, good or bad and tells you in the logs.

OH3 - After upgrade from OH2, the things and items are transitioned, yay! But if I make any changes to the original files, they aren’t picked up or reflected. As I search through the docs and posts, I see mentions of the following:

  • Copy/paste items config into a text input box and they will be updated. But there is no comment about the file format. Is it the OH2 format? Is there a different format which leads to the next…
  • The question is asked about if Things are to be through GUI only. This isn’t answered other than ‘yep files are still ok’. Where/how do these get updated and what is their format? The only text upload that I find says items.
  • The mentioned Pros/Cons link lists those, yes, but then the examples following are all GUI. Perhaps examples of using text files in addition to GUI as an A/B comparison would help us.
  • Then there is mention of ‘JSONDB’ config and how that’s recommended. Is this a 3rd type of config mechanism or is this the ‘text’ based config that is referenced, but using JSON now? An example, again, would be helpful. Perhaps an A/B/C comparison of how to add/change/delete items and things through the three methods?

@hmerk - that’s the point. It should be clear, I agree, but clearly it isn’t, hence the continued questions and requests. In example - on that page it states that you can define and manage Things through text files. Great! Are they the same format as previous? Is it supposed to be in the JSONDB file format, how do I actually do this with the MainUI?

From that page:

“Things and Items can still be defined either in configuration files or via the GUI. We highly recommend adding them to the system database via Main UI, though. Note there is an option in Main UI to bulk create Things and Items by copy and pasting the contents of existing .things/.items files.” Screen shots of the referenced Main UI area would be very helpful.

Great, things and items can be defined in text or GUI. But then it is immediately followed by the recommendation and another reference to the MainUI bulk import. Umm, if I were to follow the recommendations, how would I do that? I follow the link and it tells me where the files are stored (OPENHAB_USERDATA/jsondb/) and that they are separated. I’m apparently able to update these and they will take effect. Is that the same format that is to be copy/pasted in the UI?

Regarding the Main UI to bulk create things and items. When I go to Items and click the + I am indeed shown a box to copy/paste. My first question is why not use the same files that were used to initially populate and secondly, it doesn’t mention Things at all. When I go to Things and hit the +, I’m brought to the Bindings UI… Fortunately @rlkoshak showed an example of an item import of groups at least, thank you!

@yab Thanks for the reference to someone considering an import/export, that would be helpful!

My main concern/gripe/issue that is those at the core don’t seem to think any of this is a problem with many very smart people asking and being dismissed. Unless/until you consider that perhaps the configuration page/examples ‘Should be clear, but most certainly aren’t given the feedback’, things won’t improve. This feels like a carry on of the overly difficult learning curve.

Someone even mentioned along the lines of “New users come to OH with the expectations of point and click ease of use”. Well, umm, yeah that’s what people expect in most any product. I’d say that OH itself recognizes it with the new UI changes.

41

@hmerk, we’re not just bringing gripes, but also offering suggestions.

You have two replies here that are short and dismissive. I offer these as a way to demonstrate what I’m trying to say:

“The path is quite clear” No, no it’s not. That’s what we’re actually politely telling you in no uncertain terms. YOU may think it’s clear, but it’s not.

“If you read the following carefully, it should be clear” No, no it’s not and I’ve given a bunch of feedback in another reply.

If you consider our feedback as out of the ordinary or perhaps you consider us ‘novice or unwilling to read instructions’ speaking for myself, this is wrong. I did read and I gave you feedback on them.

If you can consider that perhaps the docs and examples are NOT clear, though you thought they were, then we might make progress.

1 Like
42

For me it looks like you are searching for a way how to use your textual-configurations in the UI, and you are looking for features, that reflect changes on that config via the UI, back in the textual-configs.

Neither of this is supported as far as I understand it. You are able to stick with you textual config, but then the UI will not give you any help. It is the same as it was with OH2 and PaperUI.

And because of that, there is no need to have an updated documentation for textual-config. All the existing textual-config documentation is still valid.

So there is no new nifty feature for textual-config, and I understand that people like you, doing everything via textual-config are looking for such new features in a new major-release.

For me it looks like this release is focused on the new UI and cleaning up many things in the background without breaking much of backwards-compatibility. You can easily import your textual-config, but this is a one-way process.

1 Like
43

Nope. Just like you want text, others want GUI. There will NOT be any such “decision” in favor of one or the other. openHAB has thousands of users and you’re only one of them.

44

How about careful reading ? (highlighting by me)
And you expect a tutorial-like guidance from the reference documentation.
You must not - you are looking in the wrong place.

I’d think your main concern is that you dislike the direction taken in OH3 which has a preference for GUI because that is what by far most people need and are waiting for.
Many do - I myself prefer text, too - but it’s outright wrong to blame any of “those at the core” for “dismissing very smart people”.
That’s a hefty attack you should justify or apologize for (I’m stating that as a moderator)

None of the capabilities in the area of textual configuration were abandoned, they all still work like they did in OH2.
The main “problem” in your words is that config changes you make via UI are not written back to text input format files. They aren’t because noone ever has built a code module to do that. And noone will (unless you yourself start coding rather than complaining).
But there’s absolutely nothing new about that - maybe except for that the documentation on that is now clearer as it now literally states that text config is a one way street.
In fact the whole thing works exactly the way it has been working in OH2.

You wrongly quoted @hmerk. That’s obviously what you understood but he didn’t say anything about “the” path because there isn’t any. There even does not have to be any.
Yes, freedom (of choice) can be a challenge that most people don’t want to take on - they want to be pushed down a specific road by either software or docs. But that isn’t what OH does. It offers alternatives and describes what they will do.
OH devs do not choose “the path” for you. That remains to be your responsibility.

Documentation is never as complete as users want it to be. But it can be just as good as your contributions are, i.e. the quality of user feedback.
I could go on to point at the fact that OH code just became ready in time and it now takes contributors others than the devs to provide more and better documentation.
That’s a sad mostly empty space in fact - any user (like for example yourself) could jump this bandwagon if only he was willing to contribute a share of his time to it. But almost noone does.
Instead you spend your energy on complaining. And specifically your feedback is disrespectful and not helpful at all. You’re just blaming someone who is neither a dev nor docs writer, and you do not offer anything constructive yourself.

45

Just to underline it again: have a look here.

Whom to blame? Me or you? I for myself did not contribute anything to the docs (or something else) up to know. If i would do so, i bet I’d have a look at my own needs first. Won’t you?
So all this we are talking about is quite natural: developers and maintainers have their motivation. Contributers have. And even users have.
For openHAB i feel user orientation is not so bad - said in bavarian manner: “not scolded is good enough”.

46

You are quoting me completely out of context. @droid was asking for a decision torwards just one way of configuration. And this decision was already made and written many times before, therefore the path is clear: openHAB wil keep two config options.

Again quoted out of context.
@droid wrote that with his understanding, users have to migrate to GUI config.
Thats is a misunderstanding and should be clear with the config docs.
If it is not, please let us know where we can optimise the documentation, or better, contribute to make the docs better.

2 Likes
47

As opposed to Mike i feel OH is definitely giving users more than a hint, that UI config is preferred. This became already visible for me with 2.5 at the end. And it is, what I see now.
Maybe that is what Mike addresses: on the face, you may go with txt. But you can’t really “use” it (with new features) at the end. It feels kind of “Oh these textlovers will know how to work around!”

I see. I’ll believe when the functionality is available. ATM it depends on Yannick, if and when the “decision taken” will be implemented.

1 Like
48

Ok now I am completely confused. With “please make a decision” I meant please decide if it is UI only or code only or both.

49

No, it is not Yannick‘s decision if openHAB will have oth config options.
Right now, one can configure items, things, sitemaps and rules via text files, or can use the UI. This is not going to change.
Import and export fearures in the UI are a complete different topic.

50

I want to make a change in my text based configs and have the system pick them up. I guess I would expect the UI to reflect the changes afterward, sure.

I mention UI because others keep mentioning it in conjunction with text. I’m not looking for it.

Update config, system respond, see reflected changes as was in OH2.

“You can easily import your textual-config, but it’s a one-way process”. Sure! I’d love to. Other than the initial config that is imported, I keep saying (and believe it’s reflected with others): what is this easy process you mention?

Copy my files into the UI import utility? If so, it appears to be just for items. How does it work for things? If ‘easily import’ means a single one time only, that’s a different discussion. If ‘easily’ means import once and then work with JSONDB files, sure, just clarify it.

I’m not looking for anything other than to help do what we’re asking for:

Keep and update my config in text files.
Yes, it’s supposedly easy and supported.
I imported via my initial setup, but now changes in the files don’t make any changes in the system.

I keep hearing that I can and as you say, it’s easy, I’m told that it’s clear. I’m simply trying to say that no, it’s not clear. I give examples of what’s in the docs that are ambiguous and missing examples. I made suggestions (A/B/C examples).

I’m not looking for any new feature, nope(*). I want to update my configs and have the system actually honor it just like has been before.

  • Yes someone mentioned a new feature to import configs, but that is simply because updating the files in place don’t actually make any change.
51

This decision is up to our users. As said before, openHAB supports both, UI, texual, even a mixture, which is absolutely not recommended.

52

Both of these statements are outright wrong. Any item,things,sitemap,rules work like they did in OH2.
If you update things or item in .things or .items, that updates these things/items in OH
(it might take some time however for that to become effective, which is related to the way this is implemented and which actually is a major reason why moving to GUI is better hence recommended).

Even the “new feature” to have Main UI as the user UI i.e. the “pages” part can be configured via text even though it does not really make much sense to do that, a WYSIWYG editor as built into Main UI is clearly more practical here.

Both options are supported in the CURRENT 3.0 release, AFAIK for all functions, and there are no plans whatsoever to remove any of this.
But noone will give you or anyone else any guarantee how the future will look like.
openHAB is a collaborative effort. There is no fixed roadmap or product management to determine what is being worked on.
Devs work on and contribute whatever they want to contribute, so if someone chooses to contribute a new feature that can be used via GUI only then that’s what it is.
So like it or not but you won’t get the statement you probably want to hear that each and every functionality, including future extensions, will also be available via text input.

Yes you are encouraged to use the GUI because of the advantages a GUI has in the config area of OH (input validation for example), but you are not forced to.
That is no contradiction to the statement above that both methods are supported.

2 Likes
53

AFAIK, this should work like before. You don‘t need to import your items to see them in the UI. items files should still work and those items should be shown as read only in the UI. If this is not the case, post examples that this does not work or even file a bug report on github.

54

As I read through the thread, those were stand alone answers to questions. Not terribly out of context.

Yes, the decision was made, but one is much more ‘supported and documented’ than others. It was also mentioned to use the JSONDB files and I’ve asked if that is actually a 3rd option or is that your definition of text files?

I have offered places in the documentation that is not clear, as the sentence above. I’ve suggested an A/B/C example of adding/editing things and items with the GUI/text config/JSONDB if, indeed, the last two are different.

I also asked if the text file changes, assuming they are OH2 format, are supposed to be automatically picked up like previously (which they aren’t in my installation) or if they need to be entered through the UI ‘mass update’ feature of copy/pasting into the UI.

These are recommendations and pretty clear questions.

Again, if you feel these are clear and examples aren’t necessary, then we’ll continue to have the same and users will attempt to document reality in the forums with many different attempts. Just as it has always been.

I need to get on with Christmas so will be off the rest of the day.

55

Ok so this gives me the answer I wanted. :blush: The UI based approach is encouraged so I should migrate my stuff to be future proof.

But if you want to hear it or not having no roadmap is a pretty bad approach of doing software. It doesn’t matter if it is an open source project or not.

56

Exactly, it doesn’t for me, which is my point. With all the other documentation issues as mentioned, perhaps a simple clarification:

Pros/Cons… followed by:
If you choose to continue to use text based files, they should continue to work exactly as they had in the past, though subject to the cons listed above. No change in previous methods are necessary.

57

Your point is to blame devs and other volunteers although when it doesn’t do for a user it’s that person’s own fault. You probably have a syntax error in your files.
That as I already said is exactly one of the good reasons to move from text to GUI as that provides input validation.

That is a NULL statement therefore not in the reference docs and also absent from the ‘breaking changes’.

58

But in the end the key takeaway for me is:

  1. Textual config is possible as it was in 2.5
  2. UI approach is highly recommended
  3. UI approach gets picked up faster due to the internal way of how the whole thing works

So in the end users should use the UI based approach and text based configs do work but it would be wise to port them over to the UI based approach which means saving them to the database.

59

Never ever would have had stated that. What does someone write quite often? Read carefully! If my en language was somewhat missunderstandable:
The decision was taken, fine. If it will be implemented (before a player with an other UI comes around f.e.), is up to ? right now (i understood).