One major complication of using openHAB in an enterprise environment is that the event handling does not always play nice with custom bindings. There are times when you would like to control the state updates through your binding, instead of the state being immediately updated after a command is posted.
In openHAB 1 you can statically define your items with definition files, that can include an
autoupdate="false" configuration, which will prevent this behavior. However, what if your items are not defined statically this way? Well, as it turns out you’ll have to go through a bit more work.
autoupdate feature is actually a binding that is added by default to the openHAB 2 installation. This blog should save you probably near a couple weeks trying to figure this out, as stack traces are basically useless through OSGi applications.
The actual binding responsible for this behavior it turns out, is the Eclipse SmartHome autoupdate binding. If you follow the link, you can see that it’s not clear how to disable this behavior. As it turns out, there are two ways of doing this.
Method 1: Remove the binding
The easiest way to disable auto-update is to remove the binding entirely from openHAB. You can do this by opening your openHAB 2 installation (
ssh openhab@localhost on Linux,
openHAB/start.bat on Windows), then typing
bundle:uninstall "Eclipse SmartHome AutoUpdate Binding".
This comes with a side-effect though, any binding which depends on this auto-update feature will stop working or have erratic behavior. This solution works best when you’re creating a custom installation that only uses your binding.
Method 2: Create a Config Provider
Another option is to implement your own
AutoUpdateBindingConfigProvider and register it with OSGi. Looking at the default provider, you can see that it gets the auto-update property from the config files (which are no longer used in openHAB 2). You could create your own provider which simply returns
false for all of your things/channels/items, and thus only prevents auto-update on those items. You just have to make sure to register it as a provider with OSGi, which you can do by copying this file into the OSGI-INF directory in your binding, and replacing
AutoUpdateGenericBindingConfigProvider with your own
BindingConfigProvider implementation; you’ll also have to remove the
BindingConfigReader entry. Since the default implementation simply returns
null, the setting returned by your new provider will be used to determine when auto-update is applied.
Documentation on auto-update for openHAB 2 is sparse, and the transition of openHAB to Eclipse SmartHome is still largely in progress, so some implementation details have escaped most developers. Auto-update is normally good practice, but can interfere with direct updates being pushed from the binding, such as when a sent command is rejected by the underlying device. Replacing the config provider with your own can significantly increase the control you have over your enterprise openHAB 2 application.