OH3 - Textual configuration still supported?

You can also split the topic things from the broker thing, which you will find even less examples of:

Bridge mqtt:broker:myUnsecureBroker [ host="192.168.0.42", secure=false ]
Thing mqtt:topic:mything "My Thing" (mqtt:broker:myUnsecureBroker) {
    Channels:
        Type switch : lamp "Kitchen Lamp" [ stateTopic="lamp/enabled", commandTopic="lamp/enabled/set" ]
        Type switch : fancylamp "Fancy Lamp" [ stateTopic="fancy/lamp/state", commandTopic="fancy/lamp/command", on="i-am-on", off="i-am-off" ]
        Type string : alarmpanel "Alarm system" [ stateTopic="alarm/panel/state", commandTopic="alarm/panel/set", allowedStates="ARMED_HOME,ARMED_AWAY,UNARMED" ]
        Type color : lampcolor "Kitchen Lamp color" [ stateTopic="lamp/color", commandTopic="lamp/color/set", rgb=true ]
        Type dimmer : blind "Blind" [ stateTopic="blind/state", commandTopic="blind/set", min=0, max=5, step=1 ]
}
2 Likes

to leave off-topic here:

please, if someone knows the answer, please go over there! :wink:

1 Like

Textual config is still supported. However, disc errors do not occur when creating Things and Items through the Ui. That alone degrees a ton of debugging and time specify on support on this forum. All of the options are self evident and reasonably documented in the UI as well.

Those who are motivated to do it all through text files can certainly do so. But ultimately it becomes a big time sink for both then and those of us who offer support on the forum.

There are some bugs as well that only occur with text based configs and there are some minor things mostly to do with rules, that are only possible with JSONDB configs. JSONDB configs tend to be faster as well

The improvements in the ui have largely addressed a lot of the things that drive people to using text configs. For anything that is missing, please file issues. Or continue to use text configs, but I suspect it will become more and more nitch and therefore more and more difficult to get support over time.

I’m not so sure that this is a valid feeling. The text based configs are at least one step, maybe even two steps removed from what is going on under the hood. The JSONDB fingers are actually much closer to what is going on under the hood and it much more closely represents how this information is actually represented in the data structure in memory. Given that, the forns present in the ui and the rest api itself is as close or close to what’s going on under the hood as the text configs.

the developer if there binding, with good reason I think, decided it wasn’t his job to document that. The .things done syntax is not defined but controlled by the binding developer. And when created through the UI the syntax is always right. It’s actually a significant imposition on the binding developers to document the. things done syntax and I completely understand why done may not want to do it. Especially for binding’s that support automatic discovery.

Personally, I’ve spent enough time trying to help people with. things files and won’t do it any more. It’s a huge time sink and both my time and the users time would be better spent solving home automation problems instead of syntax errors.

2 Likes

I know what you mean and I’m sure that digging a bit deeper into the system would reveal me a whole new world of complexity.

It may be related to my starting point with OH1 where only text based config was available and I was forced to understand how it all works (even if it was/is ‘only’ some markup language far away from the real core-system) - but tbh I love(d) to invest my spare time digging into each single item, understanding what it does and smiled like a baby if I got even the smallest thing visibly working.

And this is one of the main ‘downsides’ (and the reason why I still using only textual config) of a fancy automated UI for me (and I normaly love UI stuff as you may have noticed :stuck_out_tongue: )… You stop appreciating the little things. One click brings up hundreds of items, so you easily get overwhelmed by possibilites and the understanding for the effort, someone took to create these.

For me personally, it helped me a lot (especially in the beginning, with no clue how complex home automation could be) to understand the basic mechanics of OH but I also fully understand and appreciate the way that OH developed in that way.

There might come the time, where I have to say goodybe to textual configuration and have to begin understanding the UI config and JSONDB stuff (especially when you say that it might be faster) but until then, I’m happy to annoy myself with my *.items and *.things files - even if I might be alone with this mindset. :slight_smile:

yes, I got that feeling playing around with OH3 also. And after some learnings and stuff I found out that you also can use the “textual configuration” for loads of stuff mostly. For my part, if I have to configure things, which aren’t on “auto-discovery”, you can use “code” to duplicate items way faster than clicking around and the built-in checks do the job WAY better than any IDE would be! :wink:

This wasn’t meant as it may sounded, I didn’t want to impose work on top of somebody’s free time, I just wanted to point out, I did the RTFM thingy! :wink: And yes, PaperUI is not the best solution but the OH3-UI is much more like it.

tl;dr>
So I guess, I’ll switch to UI-based configuration and backup the JSONDB then! :wink:

a short q.e.d. just now:

just a misspelled seperator instead of separator and boom: ~2+ hours from my side and I guess a few from others in a stupid thing configuration! :wink:

2 Likes

I’m right now wondering what that means to logging.
/var/lib/openhab/etc/org.ops4j.pax.logging.cfg is empty by default and can only be edited by hand or via Karaf console commands.
While this has been sort of an issue ever for everyone to populate, those who did like me now wonder what we need to replace in there. I have not seen docs on that, are there any?
Will a simple find-replace org.eclipse.smarthome into org.openhab.core be right ?

You can use code in MainUI now to to copy, paste and edit most stuff including Things and Rules. Item are a little harder because what appears to be one “thing” in a .items file is actually three things, the Item, the Link and the Metadata.

In OH 2.5, you can also use copy/paste/edit through the REST API to duplicate Things. In the past I’ve moved about a dozen MQTT Things from MQTT 1.x to 2.4 (at the time) in about five minutes using that approach, about as fast as would have taken editing the file.

I believe the logging moved to log4j.xml and now uses the much more common and well documented XML configuration format. So you will probably need to redo your logging customizations. See https://logging.apache.org/log4j/log4j-2.8/manual/configuration.html#XML for the spec. Obviously I’ve not messed with the logging yet but theoretically with the move to the XML syntax we should not be able to keep all our customizations in a separate .xml file and import it to the main log4j.xml file.

If you refer to stuff like filter for and number and size of files, possibly.
But if you change log levels in Karaf, this gets reflected in org.ops4j.pax.logging.cfg just as it used to get.

@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

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

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.

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.

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

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

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.

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

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.

@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…

@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’.

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.