OH3 - Textual configuration still supported?

Development Misc
24

@rlkoshak is there any intentions or plans to introduce more mass-editing friendly interface for the things? Text feels most natural to me as copy-pasting is extremely fast, however I could imagine proper tabular interfaces with mass-editing functionality.

I can see the Code tab but it does not lend itself in case you need to create several dozen things since you see only one thing at a time. This is the situation I have with the modbus binding…

Based on the above discussion I am not sure if the .things file is still the preferred way to go in the cases?

2 Likes
25

I do not know what is planned in that respect but I know that something like that will not be coming out in 3.0. I also don’t know if there is an issue opened for something like that so it might be worth opening an issue.

Based on what I know of the REST API I don’t know how easy it will be to implement but it should be possible.

In the mean time, I see no reason why using .things files for modbus would be a problem. It’s not that .things files are no longer supported. And nothing said above concerning the technical aspects of how .things files work is different from how 2.5 works. The same files are supported and the same problems with using them are still present. The only thing that is substantially different is we have more ability to deal with Things in the UI in a more flexible way now in OH 3.

I’m aware that modbus and KNX (I think) .things files will probably remain best managed in .things files.

1 Like
26

yeah… probably I should fire up an issue on this to discuss further with the UX experts. It feels a bit backwards to have files for some purposes while some other things are conveniently located in the UI.

As binding developer, I could even offer alternative/more convenient ways to batch-configure things, like an excel file/csv whatever, but that too sounds a bit one-off solution just for one binding, something we could perhaps solve on a more general level by improving MainUI configuration experience for large number of (similar) items and things.

27

So, for Items you can import them using .items file syntax.
image

Choose “Add Items from Textual Definition” and write or paste in your Items definitions.

image
image945×784 72 KB

Notice the built in syntax checking.

I imported about a hundred Items in one go that way (I’ve since started just creating the Items anew through the UI because it’s so darned easy to do so through the Model). Yannick has mentioned he might look into doing the same for Things at some point. If that happens, you could write a .things file type syntax for a bunch of things and import them all in one go. Editing already imported Things and Items is where the trouble will be.

2 Likes
28

Do you mean that, after your mass import, you removed them again and instead replaced them with ones defined exclusively via the MainUI? If so, what was the reason?

1 Like
29

No, I only imported about 15% of all my Items through the text config that first go. After that and I got a feel for the model and such I abandoned importing the rest, retrofit the Items I already imported to my new OH 3 model (I had a model in OH 2.5 already for HABot), and now only create new Items from the UI directly, mostly though the Model add equipment from Thing.

As a consequence my Item names are actually kind of a mess. But I’ve found that it doesn’t really matter so I’m just going with it. Maybe some day I’ll clean them up but for now there’s no compelling reason to. It’s the labels that I need to get right.

30

Yeah the import might be handy way to ensure that all parameters are consistent. With my oh3 experiments I started with the equipment model actually and found somewhat satisfying seeing the structure in a hierarchical way. But I find this view not the best one to adjust parameters in a batch way.

For me it’s simply easier to inspect and compare things and items when they are represented with one view, prererably in a tabular format which allows spotting differences (one entry per line in text format or a table).

Text file format allows correcting the necessary things with the same view. Same goal could accomplished with tabular web UI or similar. Import-functionality however has some limitations, as sometimes items should be removed / renamed, I guess not a big deal.

Import hopefully reconfigures existing items, otherwise it’s not usable for this mass editing imo. The import is great for the migration I understand, but is it the right tool after the initial import? I don’t think so.

I hope I do not sound too negative, I am simply trying to open up some of the use cases I have. I know this has been discussed in endless threads here but I have been missing constructive discussion what I think might benefit the UX as a whole when managing larger set of things/items

1 Like
31

4 months later, 29 replies and no one has answered the question. I’m afraid this is what I’ve seen for many releases now. I’ll comment on specifics below as I go through this.

32

@hilbrand, I’m glad that it’s still supported. It would be helpful if you could point to examples.

OH2 many of us had .items, .things., .rules files, well now in OH3 these are now used like this…

33

@droid, I’m afraid it isn’t in my opinion. The still isn’t documentation and this thread itself is a testament to ‘yes they are, but gui is best. Here’s a link to the pros/cons with examples of gui only config’.

34

I’m not sure I understand what you mean here. Each binding documentation has text examples and an overview of all channels. Also there is still the documentation on the openHAB website.

35

So thank you very much for all the answers.

From my point of view it would help the project to decide for one route or the other.

So it would help to say “we are going for UI based JSON DB config”. Please do migrate your text based stuff via the following migration path.

But from the discussion here it feels like “hmm yeah UI based is nicer but we don’t kill the other approach but well it could be maybe killed in the future but well hmm we don’t know”.

My personal opinion is that text based config is a lot nicer (perhaps I love it because I can cleanly put it under version control) but JSONDB is OK as well.

But PLEASE decide for an approach and do stick to the approach in the future and build out the tools to use it comfortably. (migration paths, mass editing etc)

To be honest. I don’t like the UI as it is right now yet. It feels UX and UI wise like jQuery UI ten years ago trying to fake iOS and Android UIs. This happens when using these kinds of frameworks. This is for sure a reason why I step back from migration right now.

But simple enough I would love to get the feeling of following a future proof way in the project. And that’s what I don’t get at the moment. It feels like in the Linux distro world. A bunch of ways to do exactly the same and no one wants to finally decide a way.

So step one would be to decide what is the future way of doing it and lay out a clear migration path.

1 Like
36

The path is quite clear. While improving the UI, we will keep the possibility of textual configuration for power users.

2 Likes
37

But please make that clear in the documentation. My takeaway is that I have to migrate to the UI based approach. But the simplest way of doing it is not clear to me. (for hundreds of lines of things, items, rules etc files)
For the rules we got the exact same topic. A bunch of approaches but no clear path.

I don’t like IOBroker but the way of doing it in this project is quite clear.

1 Like
38

If you read the following carefully, it should be clear.

3 Likes
39

Yannick made a statement on (nearly) this some days ago: he wants to implement an import/export feature UIbased - txtbased. I feel this to be a very good idea.

There are a lot of people/oh-users who prefer text based configuration.

Me for one: it depends. To integrate a new binding / bridge or a single thing or item, UI is fine. For mass edits (more than two items let’s say), i’d prefer “search and replace” in a text file. Or when i decide for a new naming sheme for {whatever}.
So for me future direction of openHAB seems to look like: UI first but have real import/export feature for mass edits f.e.

Hans-Jörg has a better insight, i think. So the above should read like a cautious addition based on Yannick’s words. :wink:

1 Like
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.