You need to tag or add metadata to Items. Not Things.
Items are much easier to create by hand and present far fewer syntax problems. So I, and the official docs say to use .items files for Items and not to use .things files for Things.
I do not use Alexa but I do use GA which does require tags, soon to require metadata. And because of that and other reasons I follow the official advice in the docs and define my Items in .items files. But all my Things are defined through PaperUI or the REST API and I’ve never had a syntax error or had to research what fields are available or what needs to go into them.
I think that using the user interface - is the wrong way to go and poor engineering. Any configuration should be done by importing the “configuration directory” without any additional actions. I think this is what the developers created the “addons.cfg” file for.
For example: 3 weeks ago my SD card died (luckily I’m synchronizing the configuration via Syncthing). To restore OpenHab, I simply put my current configuration in the new OpenHab directory. He set up all the addons himself and everything worked as if nothing had happened.
addons.cfg is legacy. The “configuration directory” that gets imported is located in /var/lib/openhab2. When running openhab-cli backup/restore it includes that folder. Whether or not it’s bad engineering is a matter of opinion (often driven by an ignorance of all the requirements driving the development) but you are free to volunteer your time and join the development team and show them all how they are doing it wrong.
addons.cfg is mentioned in the documentation as a valid way to configure.
I cannot find confirmation of this statement (that this file is “legacy”) in changelog and documentation. Can you give me a link?
1:
With this information we can now edit the addons.cfg file in the $OPENHAB_CONF/services folder on the machine you are running openHAB on.
2:
openHAB settings as defined in services/addons.cfg and services/runtime.cfg will override any settings made in PaperUI’s Configuration/System pane.
I am guided by official documentation. That’s what it says: Site configuration: /etc/openhab2
Userdata like rrd4j databases: /var/lib/openhab2
My opinion: the existence of two equivalent folder with configurations, one of which is not mentioned in the documentation (everywhere it is specified that it is “userdata” but not a configuration) and which contains a configuration in an undocumented format - is bad engineering and bad architecture pattern.
I also find it bad engineering to require manual input with a GUI without the ability to automate the process (via file or API).
For now - that they are doing the right thing - I can fully configure the program using only /etc/openhab2. I understand the engineering reasons for the second directory and I do not judge them. We (programmers) do it all the time))).
Unfortunately, I will not be able to join the development - my specialization is C++, Python and industrial programming on IEC-61131. The threshold to enter such a large project is quite high - you cannot just say “you can join”.
But as you can see, I have already noted some problematic points in the documentation. Maybe it makes sense to discuss them and make PR?
Frankly the docs have not managed to keep up with the development in a number of areas, this being one of them. But referring to it as legacy does not mean it’s not supported nor does it make it invalid to use it. But it is a method of configuring openHAB that is left over from openHAB 1.x and IMHO the way it is loaded and processes is not ideal.
There is only one configuration folder. The stuff in /etc/openhab2/services gets copied to /var/lib/openhab2. In the case of addons.cfg, the actual file used by openHAB is in /etc/openhab2/config/org/openhab/addons.config. The file format is the same as the format used by /etc/openhab2/services/addons.cfg, minus the comments.
There is nothing that you can do through any UI that cannot also be done through configuration files, the Karaf Console, or the REST API. Almost everything can be done through the REST API and Karaf Console. For now, there are three things that cannot be managed through those two:
configuration of persistence
configuration of sitemaps
configuration and use of OH 1.x bindings.
In fact, everything that the UIs do is through the REST API. So you can’t do those three things through the UIs either. In OH 3 that list drops to one (right now), configuration of persistence.
The main supported way to configure OH is through the REST API. A UI exists for users to use but you can automate the interactions with the REST API to your heart’s content. There are several such scripts and programs on the forum that do so (e.g. moving data from one persistence database to a different one). Using text based configs in the /etc/openhab2 folder remains supported and probably will continue to be supported, but it is legacy support.
And yet you persist in calling their efforts “bad engineering”.
About the only issue I see that you’ve identified thus far is that the documentation is behind in some areas. We are fully aware of this and are waiting for OH 3 to get closer to done before a full rewrite of the docs where this particular issue is high on the list to be corrected. That being said, the threshold to help with the documentation is actually very very low. You don’t even need to leave the browser to create and submit a PR. See How to file an Issue.
