In ZWave, I just call the following -:
updateStatus(ThingStatus.OFFLINE);
and this works fine. If the status is staying as INITIALIZING, then I’m pretty sure this will be why your bridge status callback isn’t being called.
It should work though if you add a detailed status (well, I assume so!) - but I would try and simply set to OFFLINE and see if that works.
This sounds to me as if you have this bundle installed twice. Can you rule that out (e.g. having one left in addons or so)?
@kai: you’re right, I just discovered that few minutes ago. After uninstalling the unwished bundle, the error disappeared but not my main problem.
Then, I understood why my bridge polling job was crashing, it was accessing the things while they were not yet initialized. I commented one part of my code and the job is now working well.
Unfortunately my bridge thing remains now in INITIALIZING state. As a consequence, the things remain in INITIALIZING state too but that is normal.
In the code, I am setting the state of the bridge to ONLINE in initialize but there is a delay in initialize (code taking some time) before the state is set. Could it be the problem ?
@MikeD Your “Astronomical Data” section looks pretty neat. How about creating a PR to add this to the demo setup (maybe as a new entry unterneath the weather section in the sitemap)?
I set the state to ONLINE after 3 seconds in the bridge initialization and it seems to be not taken into account now. Does init process requires that the initialize is very short in time ?
During this time, I see that my child things are initialized => disposed => initialized. Is it normal ?
Solution found, I will first set bridge state to OFFLINE and schedule a job in charge to establish the connection with the Freebox Revolution. If it succeed, it will set the status to ONLINE.
Definitely YES (this probably should be added to the JavaDoc…).
For the freebox binding, I submitted a PR fixing the initialization problem.
Remain initialization problems with astro and hue bindings.
For the RFXCOM binding, I will fix the NPE.
Hi @Kai, I am relatively new to Github and have not created a PR before, but will do some reading and then give it a try.
Worst case, I can send you some revised sitemap, item & thing files. I will give the PR option a try first as it would be worth knowing how to do this. Hope to have something through tomorrow.
If you see this in many binding (only ones that also have bridges?), maybe there is some change with the call of the bridgeHandlerInitialized method. From the logs posted here so far, I cannot see any error though. Could you come up with a debug log that clearly shows that initialize() of a ThingHandler is not called (which leads to it sticking in INITIALIZING state)?
@kai: I am only using 5 openHAB 2.0 bindings (astro, ntp, rfxcom, hue and freebox) and 3 of them use a bridge/thing structure.
I have now submitted a PR for the RFXCOM binding fixing the initialization.
So now priority would be the hue binding and hue lights systematically remaining in INITIALIZING state.
For the astro binding, that is not systematic. I take a look to the code and the only thing I found is that few attributes are not initialized to null in the constructor. Not sure if this could explain this behavior.
One interesting thing I discovered is that bridgeStatusChanged can be called for a thing even before initialize is called for the thing. It explained the NPE for the RFXCOM binding.
HueLightHandler:initialize looks really weird to me.
If run when the bridge is in state INITIALIZING, it will set the thing state to INITIALIZING ! I thing that is clearly the problem.
And there is cases (probably rare cases) when state is not set at all in this method.
And finally just a remark, this binding does not implement bridgeStatusChanged.
I will create an issue.
We have 18 bindings with bridge/thing structure.
I tested 3 of them and I discovered bugs in the initialization in the 3 !
Z-wave was reported to be ok.
So I will encourage to check carefully the 14 remaining bindings.
I very much hope that those issues will be gone once https://github.com/eclipse/smarthome/issues/1479 is implemented. I’ll try to put more priority on it…
Fine as well, but have a try to do it yourself!
Do you have a suggestion for coordinates to use?
I’d suggest these for a start.
I suppressed my previous message regarding the Sonos initialization. After resetting my mapDB database, the exception did not occur again.
And I just submitted a PR fixing the hue binding initialization.
I can confirm that the Systeminfo binding is now working ok again after updating to build #417.
)