Bindings not kept unless well defined in addons.cfg

[kgoderis]

It should be made clear in the documentation that in order for Legacy 1.x binding to be installed and run correctly it is not sufficient to toggle the switches in PaperUI, but that also remote=true and legacy=true should be set in {config}\services\addons.cfg

if not, and adding the bindings through the console command line (feature:install ...) will install the binding, but they will not be fed any configuration info coming from the relevant .cfg, and will thus not start up correctly

Secondly, when specifying the Legacy 1.x bindings as part of "binding = " in adding.cfg they should be explicitly declared with a "1" postfix, e.g. http1

[ThomDietrich]

it is not sufficient to toggle the switches in PaperUI

Why is that? That should be the case and the documentation was reduced for exactly that reason.

will install the binding, but they will not be fed any configuration info

Maybe instead this apparent bug needs to be addressed?

Please also compare https://github.com/openhab/openhab-docs/issues/309

[kaikreuzer]

adding the bindings through the console command line (feature:install ...)

Actually, there is another problem with installation through the karaf console: This won't add (any) add-on to the org.openhab.addons.cfg configuration file, which means that latest after a system update (osgi cache clean), these add-ons are lost again. We might therefore maybe better remove this installation option from the docs (or mark it as something that is only useful for temporary testing).

[maggu2810]

Why not using a FeaturesListener and act on the installed and uninstalled event? We could check if the feature starts with "openhab" (perhaps some others regex, too) and add / remove it from org.openhab.addons.cfg. Then it does not matter if the feature is installed by an extension manager, webconsole, karaf console, etc.

[kaikreuzer]

Good idea, that should work. Any volunteers? 😎

[asvilabs]

This issue is not just about 1.x binding but also third party bindings which will not necessarily be shown in paperUI, because the naming is different. I might do some tryouts along this line, FeatureListener and then sync it to addons.cfg. I had solved this problem partially but externally with my karaf automation shell scripts. But I would like a native Java solution. It anyone knows, please point me to addons.cfg full syntax and semantics and its Java handler class, I might work on this one soon.

[kaikreuzer]

This issue is not just about 1.x binding but also third party bindings which will not necessarily be shown in paperUI, because the naming is different.

Could you elaborate a bit more on what isn't working for 3rd-party bindings? I am not convinced that we are talking about the same feature here, because legacy addons are specified in Karaf features and the issue here is mainly about their resolution.

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/openhab-transformation-scale-disappears-after-system-reboot/122254/3