OH2 cached config files

I’ve started experimenting with OH2 and discovered that changes in config files don’t seem to work. I set up MQTT to subscribe to a topic to populate my items, and then after I commented out the topic and rebooted it still was subscribed to it and kept receiving updates
Is there an easy way of getting rid of this no longer needed subscription?


I had the same behaviour while playing around with item and sitemap files.
For me a simple OH2 restart on the console did the job.
Heres how to restart openhab from the console:

With my setup (Pi v3 with newest Openhabian) the command is:

# (Re-)Start openHAB (background service)
sudo systemctl restart openhab2.service

Maybe there is a better way to clean the cache, but since a restart doesnt take too much time i didn’t search for a better solution so far. :smiley:

After removing the “shadow” config files, you MIGHT find that it’s sufficient to restart only the MQTT binding instead of the entire openHAB system. I haven’t tried this, so I can’t say for certain, however.

1 Like

You even don’t need to delete shadow files, but use the karaf console to delete configurations. This is because openHAB reads config files and omits empty or commented parameters, so you can generate a config, but you can’t delete it through the config files.

ssh openhab@localhost -p 8101
(password is habopen by default)
config:edit org.openhab.mqtt
(list of properties)
config:property-delete <name-of-unwanted-property>

Thanks for the reply, I looked into the Karaf console and I can see that the property is no longer there, and the fault is gone. I did however blow away most of the config directory before posting the question, so that is probably why. Needless to say I’d only do that on a high spec fast non live test system. Its good to get a feel for how this works and how to do it properly before I eventually go live!
Now if only I could find why the onewire binding is moaning about not having a hostname when I don’t think it needs one…
I’ve since transitioned to testing on a Pi and Jessie. The problem reoccured after I copied over my testing configuration files and I only managed to clear it by uninstalling the binding, then deleting its full set of properties from karaf before reinstalling it again. Just deleting the individual property didn’t keep it away