Child things missing handler when removing bridge #2757
Comments
Looks like a bug in your implementation. Note that you must not call updateStatus from the dispose method. |
|
@kaikreuzer Thank you for your quick reply. I have no updateStatus in my dispose methods. I only have a dispose method for the bridge, not for the connected things. I do expect this to be an implementation error on my side, but can't figure out what it could be. I was assuming that if there is no dispose method and my classes extend BaseBridgeHandler and BaseThingHandler respectively, removal should work. |
|
|
@kaikreuzer Correct for the pushed version, not anymore in my offline private copy. I removed that when solving another issue I discovered. It was just not ready for another push yet. Sorry for the misunderstanding. |
|
But you exception from above is clearly from that code. |
|
@kaikreuzer Below is a new log file. Removal of the updateStatus call got rid of the exception. However, the child thing is still not removed when removing the bridge. So in the paperUI, the net result is the same. I have the bridge thing removed and a child thing is remaining in state uninitialized. I appreciate all your effort on this. |
mherwege
changed the title
|
I have now updated the PR with my most recent code changes. The issue is still there. |
|
Why should a thing be removed if the bridge is removed at all? |
|
There is indeed no mechanism that would remove a thing in such a case. |
|
I cannot judge all consequences. In my case, the child items are left without any meaning and in an unitialized state (see log, handler missing). That does not make sense in my specific case. The things stop having a meaning when the bridge gets removed. They cannot do anything on their own. |
|
No, please don't remove things automatically (unless they where dynamically created by the bridge). The UNINITIALIZED state is fine. You can always assign a new bridge to the existing things and they start working again. Deleting them would require a lot of work to re-create them (especially for things that can't be auto-discovered). Maybe (I didn't look in the code if something like this is already there) we could add a comment to the UNINITIALIZED state (like the OFFLINE state has), which states "bridge not available" to make it more clear why the thing is in uninitalized state. |
|
Anyone has a real code example on how to remove the things? (Assuming this is totally fine as the bridge would recreate the things immediately when it comes back) |
Initialization of ThingHandlers happens in the following order: * Thing -> INITIALIZING * BaseThingHandler gets the callback injected * ThingHandler.initialize() * Thing -> ONLINE/OFFLINE/UNKNOWN The shudown however so far first removed the callback, and then called ThingHandler.destroy(). As a result, the ThingHandler did not get the chance to clean up first and could run into situations where it tried to e.g. send events but the callback was already missing. Hence the shudown process with this change becomes the exact reverse: * Thing -> UNITIALIZED (so that it's not used anymore) * ThingHandler.destroy() * BaseThingHandler gets the callback "un"injected * Thing -> UNINITIALIZED (HANDLER_MISSING) fixes eclipse-archived#2757 fixes eclipse-archived#1338 Signed-off-by: Simon Kaufmann <[email protected]>
Initialization of ThingHandlers happens in the following order: * Thing -> INITIALIZING * BaseThingHandler gets the callback injected * ThingHandler.initialize() * Thing -> ONLINE/OFFLINE/UNKNOWN The shudown however so far first removed the callback, and then called ThingHandler.destroy(). As a result, the ThingHandler did not get the chance to clean up first and could run into situations where it tried to e.g. send events but the callback was already missing. Hence the shudown process with this change becomes the exact reverse: * Thing -> UNITIALIZED (so that it's not used anymore) * ThingHandler.destroy() * BaseThingHandler gets the callback "un"injected * Thing -> UNINITIALIZED (HANDLER_MISSING) fixes eclipse-archived#2757 fixes eclipse-archived#1338 Signed-off-by: Simon Kaufmann <[email protected]>
Initialization of ThingHandlers happens in the following order: * Thing -> INITIALIZING * BaseThingHandler gets the callback injected * ThingHandler.initialize() * Thing -> ONLINE/OFFLINE/UNKNOWN The shudown however so far first removed the callback, and then called ThingHandler.destroy(). As a result, the ThingHandler did not get the chance to clean up first and could run into situations where it tried to e.g. send events but the callback was already missing. Hence the shudown process with this change becomes the exact reverse: * Thing -> UNITIALIZED (so that it's not used anymore) * ThingHandler.destroy() * BaseThingHandler gets the callback "un"injected * Thing -> UNINITIALIZED (HANDLER_MISSING) fixes eclipse-archived#2757 fixes eclipse-archived#1338 Signed-off-by: Simon Kaufmann <[email protected]>
Initialization of ThingHandlers happens in the following order: * Thing -> INITIALIZING * BaseThingHandler gets the callback injected * ThingHandler.initialize() * Thing -> ONLINE/OFFLINE/UNKNOWN The shudown however so far first removed the callback, and then called ThingHandler.destroy(). As a result, the ThingHandler did not get the chance to clean up first and could run into situations where it tried to e.g. send events but the callback was already missing. Hence the shudown process with this change becomes the exact reverse: * Thing -> UNITIALIZED (so that it's not used anymore) * ThingHandler.destroy() * BaseThingHandler gets the callback "un"injected * Thing -> UNINITIALIZED (HANDLER_MISSING) fixes #2757 fixes #1338 Signed-off-by: Simon Kaufmann <[email protected]>
) Initialization of ThingHandlers happens in the following order: * Thing -> INITIALIZING * BaseThingHandler gets the callback injected * ThingHandler.initialize() * Thing -> ONLINE/OFFLINE/UNKNOWN The shudown however so far first removed the callback, and then called ThingHandler.destroy(). As a result, the ThingHandler did not get the chance to clean up first and could run into situations where it tried to e.g. send events but the callback was already missing. Hence the shudown process with this change becomes the exact reverse: * Thing -> UNITIALIZED (so that it's not used anymore) * ThingHandler.destroy() * BaseThingHandler gets the callback "un"injected * Thing -> UNINITIALIZED (HANDLER_MISSING) fixes eclipse-archived#2757 fixes eclipse-archived#1338 Signed-off-by: Simon Kaufmann <[email protected]>
In developing my own binding (pull request #1589) I am hitting an issue when removing a bridge. When I remove the bridge, it gets removed correctly, but the child things are not removed. They go to an uninitialized state. Discovery results attached to the bridge are also removed. I am probably missing something in my coding, but was expecting child things to get removed before the bridge was removed. Note that the exception also appears for the bridge, but the bridge does get removed.
Any suggestions on what I need to do?
Here is the log:
The text was updated successfully, but these errors were encountered: