Dependencies between things and items files vs load order

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 ?

Any information would be appreciated.

I have not heard of any load order in OH3. I know OH2 can be quite random.

AFAIK this has not changed in OH3 so stick to the recommendations in
No things files.

1 Like

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. :slight_smile:

Having Things set up through the UI and using files for everything else is not too cumbersome. Many, including me, do that.

Which is why it’s the recommendation in the official docs.
@waldorf You have been warned.

1 Like

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!

@Bruce_Osborne and @mstormi

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.

If I were going to do that I would use the REST API to get the data from the UI based Things to use as a basis for the file entries.

We all prefer text input and you are free to use whatever you want. But there’s reasons for this recommendation you should not ignore, see link.

1 Like

I think I’m missing something here - I see no reasons why things files shouldn’t be used at

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.

Read on, there’s a WARNING isn’t there.

Do you mean this one?


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.

Read the text below the warning.

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.

The text below the warning:

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.

About starting to use .things today.

1 Like

(Emphasis mine)

OK, understood.

In that case, though, we shouldn’t be telling users to go read the docs for reasons, if they’re not there/don’t belong there.

As I said to me that’s reason enough but YMMV.

Now let’s move on to something productive.

1 Like

That’s indeed what I did, it’s the easiest way to get the IDs correct.

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.

1 Like