but… from what I understand, this story with the pid: is a temporary measure
I believe that they are working towards a more robust solution where there will be checks in the code to “clean up” stale configs without any user intervention.
Anyway, we are in the “managing OH2 configurations” HowTo thread, so people can find this stuff here in theory.
(and I didn’t do a very good job of explaining them… I can do better )
in case this is about a binidng that has an OH1 and OH2 version, for the pid process should I take pid:org.openhab.mqtt1 of pid:org.openhab.mqtt for the version 1 binding config? Same for MODBUS for example
You can also use config:property-list or config:property-get autoLinks to retrieve current setting. It is worth to note that above way be scripted through SSH interface without a need to have physical access to disk. (my way goes one level lower than solution proposed by @opus)
Though that way is not guaranteed to survive an upgrade process. In general, the files in that folder are not guaranteed to not become replaced on an upgrade, which is why runtime.cfg exists in the first place.
In practice those files often do not get replaced after you’ve edited them which raises a wholly different problem. Your edited file will not receive the updated contents as part of the upgrade.
In general, using runtime.cfg is the preferred approach.
Thank you, I found it at runtime.cfg.
However I’m curious where the configuration of autoLinks when I configure it via PaperUI.
I see that in runtime.cfg #org.eclipse.smarthome.links:autoLinks=false although I already enabled simplemode in PaperUI.
I think it might be arguable. The runtime.cfg is translated to OSGi Configuration Admin layer which is persisted in userdata folder. See that the syntax of runtime.cfg is <config-id>:<property>=<value> for a reason.
On my local setup I see that this setting is retained over restart when I changed it over paperui. You can try with config:list|grep autoLinks.