OH2: bindingChanged called before item creation

Setup, Configuration and Use 1.x Compatibility
1

Hello

This discussion is the follow of this one: https://groups.google.com/forum/#!topic/openhab2/MT-kP1CV0x4

As a short summary, I have a problem with one 1.x binding I have developped when I run it in OH2. My binding tries to update items while items are not yet created by OH2.

Starting from the error log, “Received update for non-existing item: Item ‘xxxxxxx’ could not be found in the item registry”. I found that the problem is in method processBindingConfigsFromModel from class GenericItemProvider (Eclipse SmartHome).
It looks like that code at lines 160-162 (reader.startConfigurationUpdate) finally calls removeConfigurations that triggers the calls to “bindingChanged” for each item in my binding. That is in this method that I update the value of the item. The problem is that the item is only created later at lines 165-170.

So the main problem is probably that “bindingChanged” is called while adding and removing a binding configuration and that is not clear for me how to distinguish when it is a adding or a removing. Normally I should do nothing when it is a removing.

Any advice ?

The behavior is certainly different in OH1 as I encounter no problem.

2

Maybe this code would be better ?

                // create items
                for (ModelItem modelItem : model.getItems()) {
                    createItemFromModelItem(modelItem);
                }

                // start binding configuration processing
                for (BindingConfigReader reader : bindingConfigReaders.values()) {
                    reader.startConfigurationUpdate(modelName);
                }
    
                // read new binding configuration
                for (ModelItem modelItem : model.getItems()) {
                    Item item = .... // Getting the item from modelItem
                    if (item != null) {
                        internalDispatchBindings(modelName, item, modelItem.getBindings());
                    }
                }
    
                // end binding configuration processing
                for (BindingConfigReader reader : bindingConfigReaders.values()) {
                    reader.stopConfigurationUpdate(modelName);
                }
3

Well a bindingChanged() call indeed does not tell you whether something has been added or removed. To be precise, you should not even worry about the existence of items, you should only be interested in the ones for which there is a binding configuration for your binding. And this is what bindingChanged() tries to inform you about - that something about the configuration has changed. WIth this call, you get the BindingProvider instance, which you can query for the binding configuration. If it has some, you should be allowed to send and receive events to this item, if it doesn’t, you should not use the item anymore.

So far the theory. Looking at GenericItemProvider.modelChanged(), it indeed seems as if first the binding config update notifications are sent and the item is added to the registry only afterwards.
The strange thing is that this code is exactly the same in OH1 - so I am a bit reluctant to change anything here without better understanding the problem.
Another observations is that a call to bindingChanged should usually return as quickly as possible - so you should only add the infos you get to some place and process them asynchronously afterwards. If this would be done, I would expect the item to be added to the ItemRegistry already (as it would be the next thing the thread does).
I would need much more time to analyze it in detail to give a concrete advice. Unfortunately, I won’t find that time in the coming weeks. But maybe my comments above give you some better idea where to debug and analyze further. If you have an explanation why the same code works in OH1, but not in ESH/OH2, this would be indeed a breakthrough.

Regards,
Kai

4

Thank you Kai for your answer.

If I encounter this problem, that might be because I am running a very minimal OH2 setup with only this binding (and on a very slow hardware - RPI). As a result, the binding is started very shortly during the starting process (before items loading). In a more complex setup, maybe the binding would have been started after items loading.

My OH1 setup is different with a lot more bindings. I will try to create a similar OH1 binding to try to understand what is different during the starting process.

In the past when I tested this binding in a minimal OH1 setup on my Windows 7 PC, I already discovered that my binding could start running before the items are loaded. That is why I started to delay pushing items update until bindingChanged is first called. Unfortunately, in OH2, that seems to be not enough.

As a workaround, I will use my 20 seconds cyclic call to delay even more pushing first items updates and so avoid pushing event updates inside bindingChanged.