openhab-distro icon indicating copy to clipboard operation
openhab-distro copied to clipboard

Bindings not kept unless well defined in addons.cfg

Open kgoderis opened this issue 7 years ago • 7 comments

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

kgoderis avatar Mar 27 '17 15:03 kgoderis

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

ThomDietrich avatar Mar 27 '17 15:03 ThomDietrich

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).

kaikreuzer avatar Mar 27 '17 20:03 kaikreuzer

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.

maggu2810 avatar Mar 28 '17 11:03 maggu2810

Good idea, that should work. Any volunteers? 😎

kaikreuzer avatar Mar 28 '17 22:03 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. 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.

asvilabs avatar Dec 26 '17 21:12 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.

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.

kaikreuzer avatar Jan 02 '18 13:01 kaikreuzer

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

openhab-bot avatar May 12 '21 20:05 openhab-bot