-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[avmfritz] Call monitoring does not work #9712
Comments
Did you try to restart the binding or even openHAB itself? I figured that there is no initial refresh of the Call Monitor Channels. I added this feature in #9734. |
I tried restarting the binding, yes. I now also tried removing and re-adding the box Thing, after which the call monitor started working (as in: my Item started updating). FWIW, the 'Handler BoxHandler of thing ... tried updating channel call_state although the handler was already disposed.' messages are still there, despite it working. I wonder what's going on there, multiple handlers being activated or something? |
Sounds a little bit like an orphaned thread. I hope nothing critical. I am really wondering if it is still present after a full restart. Another possibility will be to create a thread dump. |
Is there a written explanation for doing the thread dump somewhere I can use? I'd do the dump then and try a full restart afterwards. |
Have a look here. |
If I delete the box Thing, indeed only one of the two threads is gone. |
Thanks for your research. I improved the thread handling - beside an initial refresh of the channels - in #9734. |
Expected Behavior
When connecting an Item to the
incoming_call
channel of the Fritz!Box thing, the Item should be updated whenever there is an incoming call.Current Behavior
Item stays at
NULL
permanently.Steps to Reproduce (for Bugs)
Call FonIncomingCall "Anruf [%s]" {channel="avmfritz:fritzbox:192_168_178_1:incoming_call" }
Your Environment
Relevant log excerpt on binding restart (with org.openhab.core.thing and org.openhab.binding.avmfritz set to DEBUG)
From a quick glance at the code, I'm not sure how this (handler being considered disposed) could happen though, since no evidence of
unregisterHandler
being called can be found in the log. Hoping for insight from your side ;-)The text was updated successfully, but these errors were encountered: