Disabling State Auto-Update in OpenHAB 2

openHAB logo

Intro

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.

The Binding

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

Disabling Auto-Update

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.

Conclusion

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.