Addons.cfg vs addons.config

Also, ( and usually) addons.config in Userdata.
Some v1 bindings were moved to Legacy, according to the Release Notes.
Many people find restarting OH definitely helps. Some have claimed up to 3 times is needed.
When I first upgraded to 2.5 my text configuration files were not read properly until after a restart of OH.
I believe 2.5 is more strict on syntax errors that were just warnings in previous versions.

That’s regenerated taking addons.cfg as input.

Don’t. That’s shooting at the dark and not recommended because it does not explain what’s wrong and doesn’t help most of the time. That’s why I intentionally do not mention it here.

What most likely is required is to clear the cache, but you should not need to restart OH multiple times.

I don’t know of any (recent) such changes but of course yes there can have been. Which some user may feel annoyed by, but ultimately it is a progress, isn’t it.

1 Like

addons.config also lists addons added through the UIs. Many people have addons.cfg all commented out.

AFAIK addons.config isn’t any “source of truth” as are addons.cfg and PaperUI hence my instruction to check back with both of those but not with *.config

If an addon is invalid and does not load, will it show in the Paper UI? What about v1 bindings that moved without Legacy enabled? I do not know the answers to these questions, only what we have done here to get people working with 2.5 upgrades.

As I understand it, addons.config is the source of truth. Consider the old bug when you removed something completely like a broker config in mqtt.cfg or a cached url in http.cfg but those removed settings persist. It’s because they were copied into the config files and removing them from the cfg files wasn’t enough. OH well regenerate addons.config based on changes to addons.cfg, but from that point, it’s the config file OH actually uses. If you install add-ons through the REST API, addons.config is the only authoritative source. That’s the file OH is actually going to act upon. So it’s important to check both versions of the file if you are using addons.cfg and it only makes sense to check the config file if you don’t use the cfg.

1 Like

I think we mean the same thing but misunderstand each other.
So we agree addons.config is what OH uses and that is changed whenever a change in any of its sources triggers that.
My point - remember my post is to adress users - however is you need not (users even shall not) manually change it but only ever modify the two input sources addons.cfg and PaperUI.
Neither of these is the single source of truth but for each parameter, only one of them ever takes precedence, meaning it is “the” (only) source of truth for that parameter.

There are some circumstances where manually editing theses files is the only solution to certain problems. If say not to edit it except as a last resort but never edit it isn’t feasible. Though the cases where that is two required should become more and more rare.

Agree, but remember the OP, my post is directed at the average user to have one of the most common issues on 2.5 so I left that out instead of starting a big decision tree picture.

Where will I find addons.config?

It’s OK. I found it.
/var/lib/openhab2/config/org/openhab

The correct answer is that it depends on how OH was installed. It is in the userdata tree but locations vary. For instance with a Docker install userdata is at /opt/openhab/userdata.