I was able to find some old discussion, but before setting up my OH3 I like to know whether I can run into some potential problems.
Suppose I define my MQTT bridge in a dedicated things file. Is there a change for an error because another things file which refers to the bridge is loaded before the things file with the bridge ?
Or are all references resolved afterwards ?
A simular situation might happen with items, where groups are defined in another files.
Anything to consider here ? If so are things and items files processed in any specific order ?
Although the UI for OH3 is quite nice now, I will stick with file based. It’s more cumbersome to setup, especially with ZWAVE and MQTT, but once you have done that, it’s easier to maintain with the files under revision control. It’s also easier to add similar things and items. copy->paste->search->replace
Since I now have quite some more MQTT things, I wanted to split into multiple files, hence my question: what happens if the file containing the broker is processed later.
I just did some testing on this behaviour and can confirm that no error is raised if a things file (which refers to an MQTT broker) is loaded, while the broker is not there yet. It just displays ‘bridge error’ in paper UI.
I checked loading order in the logs as well, this things file containing the broker processed after a things file which refers to it, does not cause any problems.
Thanks for the advice, I understand your concerns. Probably because I am a software developer myself (unfortunately no Java experience), I prefer the file based approach.
Besides that, I am a happy Openhab user for over 4 years now. Currently with the migration to OH3 also targeting to move my ZWave things from UI based (with auto discovery) to ‘manual discovery’ file based. I still prefer the UI for viewing item/thing status, do a quick check of a button works, but just feel more comfortable with the files. It can be organized as you like, it’s possible to add comments, revision
control. Of course it’s required to deal sometimes with design/binding changes after an update, but I consider that no problem.
I’d expect a reason to look something like “you should do this because of this”. I think the closest is the paragraph specifically about Z-wave (in the Recommendations for New Users section):
Use Paper UI or habmin to manage ZWave things, but use configuration files to manage ZWave items.
There is a rationale to this: to use a GUI is comfortable for one-time actions, but you get any repetitive task easier and faster done using a text editor (e.g. search-and-replace names and parameters). Things can be autodiscovered so you don’t have to enter all of them manually. Once initially configured, their configuration is not changing much over time. On the other hand, you will keep changing items rather often. If you are new to openHAB, you will e.g. keep changing all of your item names as you keep learning what is a naming scheme you like best to work with in your rules. And once you are a pro, you will want to keep using files anyway. You can configure items via Paper UI, too, and you can use HABmin as well for both but remember once you use files, this will override any UI-made changes on next openHAB startup.
From this I get:
You can use the UI for Things because it can auto-discover.
You can use files for Items because you’re more likely to change them.
As that about the gist of it? Note I’m not arguing which way is better, just that I have trouble parsing any reasons from that link.
While it’s technically possible to use both methods in parallel, we recommend to choose only one of them to avoid confusion and a loss of overview of your openHAB environment. It would work to mix but you may easily forget about what is your “source of truth” when you reconfigure Things or Items at a later stage.
That doesn’t give a reason for why things files shouldn’t be used, does it? It just warns not to mix the two.
To me, the whole paragraph does - if you want to listen. Granted, it’s not very explicit but that’s because it’s a documentation of the current state and not a forum discussion thread. YMMV.
More cautious people who are not as convinced they’re doing ‘the right thing’ tm will hopefully understand that OH is going GUI and that means sooner or later there won’t be (full) backward compatibility any more.
So by all means take the route you want, but don’t get back here when you run into trouble when some day you cannot edit new properties via .things any more.
As I told the OP already: you have been warned.
Configuration done in files will be used (and Things/Items become visible and even changeable in Paper UI) if no Thing/Item of the same name was already created in PaperUI, but you can NOT create a Thing or Item using files and then use Paper UI to permanently change it. Configuration done in PaperUI will be used and permanently stored in the internal database if no Thing/Item of the same name already exists in files, but those additions or changes will not be copied back into any .things file. openHAB settings as defined in services/addons.cfg and services/runtime.cfg will override any settings made in PaperUI’s Configuration/System pane.
I agree it’s not explicit, and it doesn’t give any reasons. Perhaps we could read between the lines, but I don’t think we should be asking anyone to try and interpret what is written as anything other than what is written, especially for something as complex as openHAB, and many users do not have English as their first language.
I’m trying to learn. @waldorf had been told to read the information in the link provided to understand the reason why things files should not be used, and I was struggling to find those reasons.
I’m sure that ‘some day’ will be preceded by plenty of explicit warnings, which would provide an explicit reason not to use things files. Given those warnings then sure, no one can complain.
I’m still not quite sure about what, unless you’re talking about that ‘some day’ scenario. If that is the official case, perhaps a second warning in the docs which states something like “we recommend you do not use things files because things files will/maybe/certainly/possibly become deprecated in the future” might be pertinent?
I guess we’re veering off-topic here really. Looking to the future I think being able to mix and match in OH3 will be very useful (as I understand will be possible with the YAML configuration). I also understand that, as this configuration will be stored in the JSONDB, openHAB should be a bit faster too - might be reason enough to jump to UI configuration!
EDIT: I guess I shouldn’t say “mix-and-match”, more “configure in UI but get a textual representation that can be saved/shared/copied/pasted”.
As I said I disagree.
BTW: it’s me who wrote that text. And it hasn’t been updated in quite some time, and OH’s future direction was even less clear at that time than it is now.
I’m not. There’s already some dark corners today where .things don’t work because noone implemented it, and that’s how it’ll continue. It just will be forgotten about in more and more places - not intentionally so but it’ll happen.
Maybe. But statements like that IMHO do not belong into the docs, as do not reasons, and that I believe is also the doc maintainer’s pov.
But you’re free to suggest changes. There’s a link at the bottom of each page to submit your suggestions.
Hmm I started with a simple question and it ended up with an interesting discussion about config files vs GUI. You always will have the “prefer file” users as “prefer gui” users.
Bust just to add some (personal opinion) about auto discovery, which is considered one of the advantages of GUI usage.
There are situations where auto discovery is nice, but the added value is limited. Take for instance ZWave. When having a number of ZWave devices installed, upon auto discovery you will get a list of things. Most likely multiple similar things, they will have a meaningless node ID (it starts at 1, is stored inside the ZWave bridge and has no hard relationship to the node itself). That means you still have to do a lot of manual work to find out which thing controls which device.
When the ZWave bridge fails, and you need a new one, then all nodes will get a new ID (I consider this a shortcoming of ZWave), as a result the node ID for each thing needs to be updated. The node ID is also used in the channel definitions, which means channels need to be updated as well.
This is (imho) easier to update in a structured way using text files compared to a GUI. Also easier to spot errors: in combination with revision control, just look at the diff.
Sometimes during some testing/development it’s it easy to be able to (temporary) remove a config file or replace it by something else. Using the GUI this is not possible.
Just to say, both have it’s pros and cons, and it would be nice if they still could coexist in the future of OH.