ItemProvider and binding bundle startup synchronization

[GoogleCodeExporter]

How syncronize the ItemProvider.addItemProvider with binding bundle startup? If 
startup of binding bundle is after startup of ItemProvider.addItemProvider the 
item will never binding.

The GenericItemProvider should actually re-read the configuration strings in 
the item model when addBindingConfigReader() is called

Original issue reported on code.google.com by sandro.s...@gmail.com on 26 Oct 2012 at 11:55

[GoogleCodeExporter]

Original comment by kai.openhab on 27 Oct 2012 at 7:56

• Changed state: Accepted

[GoogleCodeExporter]

This is my temporary workaround

diff -r ebf752ce45f6 
bundles/model/org.openhab.model.item/src/org/openhab/model/item/internal/Generic
ItemProvider.java
--- 
a/bundles/model/org.openhab.model.item/src/org/openhab/model/item/internal/Gener
icItemProvider.java Sun Oct 07 22:01:12 2012 +0200
+++ 
b/bundles/model/org.openhab.model.item/src/org/openhab/model/item/internal/Gener
icItemProvider.java Wed Oct 31 10:51:44 2012 +0100
@@ -243,6 +243,8 @@
            logger.warn("There are two binding configuration readers registered. "
                    + "Only the one of them will be active!");
        }
+       //Re-read items
+       modelChanged(".items",null);
    }

    public void removeBindingConfigReader(BindingConfigReader reader) {

Original comment by sandro.s...@gmail.com on 31 Oct 2012 at 9:52

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

reverted yesterdays fix since it does not solve the problem very accurately.

Original comment by teichsta on 5 Apr 2013 at 8:03

• Changed state: Accepted
• Added labels: Version-later
• Removed labels: Version-1.2.0

[GoogleCodeExporter]

Original comment by kai.openhab on 22 May 2013 at 8:11

[GoogleCodeExporter]

After i've upgraded felix.fileinstall bundle to the recent version above noted 
behaviour becomes even more obvious. The priority has been risen to 'critical' 
though.

See https://groups.google.com/d/msg/openhab/Pezt4CKGC84/BbtxXW1NMVcJ for some 
more details.

Original comment by teichsta on 12 Jun 2013 at 5:07

• Changed state: Started
• Added labels: Priority-Critical
• Removed labels: Priority-Medium

[GoogleCodeExporter]

FYI, for all non-indepth-programmers: A workaround is to simply re-save one of 
your item files. Openhab will reimport these and use the bindings you provided.

Original comment by honkton...@gmail.com on 12 Jun 2013 at 6:23

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

see 
http://code.google.com/p/openhab/source/detail?r=3a73da8af1cba9b28bacb7d6b713233
90258d764! and 
http://code.google.com/p/openhab/source/detail?r=3c53b60e256baabbb20acadfa559e6f
046e32441

Will start CI-Build now. Binaries will be available with build #432 in about 
one hour.

All, could you please verify this issue. Will close after getting your feedback.

Original comment by teichsta on 18 Jun 2013 at 4:42

[GoogleCodeExporter]

Have created my own binaries with the current repo. Even though in the startup 
logs items are still loaded before knx, the item status is beeing updated 
correctly after startup. No need to manually re-save an item file.

Original comment by airmax....@gmail.com on 18 Jun 2013 at 5:16

[GoogleCodeExporter]

From my view, this build (432) works just fine :)
Thanks for fixing this!!!

Original comment by honkton...@gmail.com on 18 Jun 2013 at 7:48

[GoogleCodeExporter]

Is this issue fully resolved?

I still have problem, that some of the bindings execute method is never called 
after start up. Binding itself is started, activate ad update callback 
functions are called, but no execute. If I touch item file, execute method 
start be called. Same happen if I stop and start binding from the console 
manually.

Original comment by pauli.an...@gmail.com on 25 Jun 2013 at 5:42

[GoogleCodeExporter]

Which "execute" method are you exactly referring to?

Original comment by kai.openhab on 25 Jun 2013 at 8:41

[GoogleCodeExporter]

I mean AbstractActiveBinding's "protected abstract void execute()" method which 
over written by the binding.

Original comment by pauli.an...@gmail.com on 26 Jun 2013 at 5:34

[GoogleCodeExporter]

Ah, right, thanks.
Could you please set the logging level of the class 
org.openhab.core.service.AbstractActiveService to TRACE?
You should then possibly see something like 
"{} won't be started because it isn't properly configured."
If you do, I think I have an idea what is going wrong...

Original comment by kai.openhab on 30 Jun 2013 at 8:10

• Changed state: Started

[GoogleCodeExporter]

Yes, you were right!

16:54:05.172 TRACE o.o.c.s.AbstractActiveService[:79] - Google Calender 
Event-Downloader won't be started because it isn't properly configured.
16:54:21.146 TRACE o.o.c.s.AbstractActiveService[:79] - Epson projector Refresh 
Service won't be started because it isn't properly configured.
16:54:21.146 TRACE o.o.c.s.AbstractActiveService[:79] - Epson projector Refresh 
Service won't be started because it isn't properly configured.
16:54:21.865 TRACE o.o.c.s.AbstractActiveService[:79] - IHC / ELKO LS refresh 
and notification listener service won't be started because it isn't properly 
configured.
16:54:21.865 TRACE o.o.c.s.AbstractActiveService[:79] - IHC / ELKO LS refresh 
and notification listener service won't be started because it isn't properly 
configured.
16:54:21.887 TRACE o.o.c.s.AbstractActiveService[:79] - NTP Refresh Service 
won't be started because it isn't properly configured.
16:54:21.888 TRACE o.o.c.s.AbstractActiveService[:79] - NTP Refresh Service 
won't be started because it isn't properly configured.

Original comment by pauli.an...@gmail.com on 1 Jul 2013 at 2:11

[GoogleCodeExporter]

Original comment by kai.openhab on 7 Jul 2013 at 9:38

[GoogleCodeExporter]

Pali, could you please retest it? Todays build has a fix included that I 
committed last night.
Note that you will have to slightly refactor your own (Epson) binding - instead 
of a isProperlyConfigure() method, you should call setProperlyConfigured(true) 
from your updated() method once everything is ready to start.
The GCal service still has the problem as this has a little design flaw, so 
that I couldn't easily fix it.

Original comment by kai.openhab on 8 Jul 2013 at 7:23

[GoogleCodeExporter]

I set this to fixed as my tests were successful. (for the open GCal issue I 
have created issue 371).
If you still experience problems, feel free to report them here and we can 
reopen the issue.

Original comment by kai.openhab on 8 Jul 2013 at 8:52

• Changed state: Fixed

[GoogleCodeExporter]

I can confirm that after fix, AbstractActiveServices are working correctly :)

Is there some kind of difference in AbstractBinding behaviour as well? Before 
fix, AbstractBinding's bindingChanged method was called after startup, but not 
anymore? On Onkyo binding I have used bindingChanged method to synchronise item 
state from AV receiver.

Original comment by pauli.an...@gmail.com on 9 Jul 2013 at 9:10

[GoogleCodeExporter]

Sonos binding polling thread is not started anymore. Currently sonos polling 
thread is started on bindingChanged method, so sonos binding has similar 
problem as I recognised on onkyo binding as well (see comment #20). 

Kai, are we using bindingChanged method incorrectly or is this side effect of 
the fix?

For me at least, it's not anymore clear which order updated, activated, etc 
method are called  and which is the correct way "start" the binding.  

Original comment by pauli.an...@gmail.com on 11 Jul 2013 at 10:22

[GoogleCodeExporter]

Kai

I stumbled on this tonight, and it seems that *all* my bindings are suffering 
the same problem. One user of the TCP binding has this problem, and so, the 
least we/I have to do is to audit all bindings that could suffer the same 
"touch" problem.

K

Original comment by karel.go...@gmail.com on 7 Oct 2013 at 8:39