This repository has been archived by the owner on May 7, 2020. It is now read-only.
Binding initialization stalls during startup (intermittently) #1847
Comments
mhilbush
changed the title
|
All cases that you mention refer to the Z-Wave binding. Does the same problem occur with e.g. any of the ESH bindings or anything "simpler" than Z-Wave? |
|
I experienced it with zwave and systeminfo. I'm unable to provide specific details on systeminfo because systeminfo was not in debugging mode at the time. In the forum topics cited above, others have commented that they've seen similar behavior with other bindings, including as knx, rfxcom, meteostick, max, and ntp. I referenced those in this issue, but I don't have any specific log detail, such as what I provided for zwave. |
|
Yes - This is the same issue that I periodically have with the meteostick binding. There are also reports on the MAX binding and RFXCOM binding and Astro. I wouldn’t like to say if it’s all ‘exactly’ the same as there aren’t logs for all these instances. I don’t believe this is anything to do with zwave - it started happening with no changes to the binding - of course, I could be wrong... |
|
Does this only happen on Karaf or did anyone see this happening when being started from within the IDE? |
|
I’ve personally never seen any of these issues in the IDE. |
|
@kaikreuzer installed today complete clean fresh version. Discovery services work fine, but seems like something goes haywire with the initialize method. I think it may be at the time the status update is done (as the thing goes never online) |
|
btw, I can also confirm that in the IDE this issue does not happen |
|
Guys, I have just installed snapshot number 402 and have now restarted 6 times in a row without problems https://community.openhab.org/t/binding-not-starting-consistently-since-6-19-build/11741/49 Please let me know if there is anything I can provide to help track down the problem. |
|
I am using Eclipse SmartHome based distributions myself that differ from openHAB. Is there any scenario that should be tested that triggers the failure very frequently? |
|
All, good news! I think I have found the issue - it had been introduced by #1419. Will work now on a fix and provide you an update soon. |
As I am very interested in, could you please fix the reference?
Thanks |
It is a recursive bug ;-) Fixed the link! |
|
All, please have a look at #1856 - I hope it solves the issue once and for all! |
|
Unfortunately, #1856 does not fully solve the issue yet :-( |
|
@kaikreuzer @maggu2810 @cdjackson I was away on holidays, just upgraded the runtime here, and ran in the same problems. My findings are:
after which the thing is either initialised, or either not. It is random behaviour, and seems to be linked to a timing issue (e.g. workload issue). I do have a lot of bindings, and some with '00's of Things. They tend to take a while to get processed, and have an effect on the overall environment
and then life goes on normally.
|
|
@kgoderis I assume I don't understand the problem. The "deferring handler initialization" is no error itself, it is only a log message that the XML files are not fully processed yet and the handler initialization will be done later. Do you want to say, that the handler initialization not done at all? |
|
I think we should split your problem. "Deferred Handler initialization" and "missing dynamic channels". (I replied to the first one above) |
is it initialised, but part of the channels as defined in the XML are not added to the Thing. I have created #2042 |
|
This all works ok in the zwave binding. |
|
@cdjackson Did a bundle:restart a few times. Will try your suggestion. err... guess that is a no no |
|
@cdjackson Not sure what you mean by "adding" in this context (@ runtime?), but cold starting the runtime generates the problem, with the correct definition in place. |
|
By ‘adding’ I meant to recreate the thing so that it re-read all the definitions. If the correct definition is already in place then it’s probably broken. |
|
@kaikreuzer @maggu2810 shall we continue in this thread, or open an new issue? the issue of some bindings not initiliazing is still there |
|
I'd suggest to first review and merge #2087 as this is anyhow changing a lot of the underlying infrastructure. |
|
ok |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
There have been numerous reports of bindings "stalling" (for lack of a better word) at startup. I have experienced the problem with the zwave and systeminfo bindings. Others have reported similar behavior with knx, rfxcom, meteostick, and max.
I first noticed this behavior with the 6/19 build, and it continues through the most current build (#399). At the time I was installing builds on almost a daily basis, and I do not recall seeing this behavior in the 6/17 and prior builds (I think I skipped installing the 6/18 build, so I don't know about that one). I started this forum thread, which has now become quite long.
https://community.openhab.org/t/binding-not-starting-consistently-since-6-19-build/11741
There are other forum threads describing similar behavior.
Here.
https://community.openhab.org/t/z-wave-binding-things-initializing-after-restart/12173
And here.
https://community.openhab.org/t/testing-z-wave-binding-on-openhab-2/7522/1372
This originally was thought to be related to the circular reference issue. However, the problem continues even after the circular reference fix.
There may be some relationship to the XML file loading issue, but perhaps not.
#1796
Here's the summary of what I'm seeing:
Start openhab. Things start out pretty normal.
But at this point there's nothing. Initialization of the zwave stick and nodes never starts.
When things start normally I would see messages like this.
The "Initializing ZWave thing handler" message is the first thing called in the ThingHandler's initialize() method, so I'm assuming that the initialize() method is never being called.
@cdjackson, please feel free to add to this if you have any additional information.
The text was updated successfully, but these errors were encountered: