Closed GoogleCodeExporter closed 9 years ago
Original comment by kai.openhab
on 27 Oct 2012 at 7:56
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
[deleted comment]
reverted yesterdays fix since it does not solve the problem very accurately.
Original comment by teichsta
on 5 Apr 2013 at 8:03
Original comment by kai.openhab
on 22 May 2013 at 8:11
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
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
[deleted comment]
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
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
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
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
Which "execute" method are you exactly referring to?
Original comment by kai.openhab
on 25 Jun 2013 at 8:41
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
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
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
Original comment by kai.openhab
on 7 Jul 2013 at 9:38
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
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
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
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
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
Original issue reported on code.google.com by
sandro.s...@gmail.com
on 26 Oct 2012 at 11:55