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.
I use this configuration (separate Bridge Things file), and have done for some time, and have not had any issues when restarting openHAB - I can confirm your findings!
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 think Iâm missing something here - I see no reasons why things files shouldnât be used at Configuration | openHAB
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.
