`2025-10-14 17:22:13.535 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘sonos:SYMFONISK:RINCON_38420B9457A601400’ changed from UNINITIALIZED (NOT_YET_READY) to INITIALIZING2025-10-14 17:22:13.572 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘icalendar:eventfilter:a5fe099ce2:805f02815d’ changed from UNINITIALIZED (NOT_YET_READY) to UNINITIALIZED (BRIDGE_UNINITIALIZED)2025-10-14 17:22:13.590 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘icalendar:calendar:a5fe099ce2’ changed from UNINITIALIZED (NOT_YET_READY) to INITIALIZING2025-10-14 17:22:13.608 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘sonos:SYMFONISK:RINCON_38420B9457A601400’ changed from INITIALIZING to ONLINE`
`2025-10-14 17:27:23.893 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'sonos:SYMFONISK:RINCON_38420B9457A601400' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): The Sonos player RINCON_38420B9457A601400 is not available in local network.`
`2025-10-14 17:53:31.795 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'sonos:SYMFONISK:RINCON_38420B9457A601400' changed from OFFLINE (COMMUNICATION_ERROR): The Sonos player RINCON_38420B9457A601400 is not available in local network. to OFFLINE (COMMUNICATION_ERROR)`
`2025-10-14 17:54:26.234 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘sonos:SYMFONISK:RINCON_38420B9457A601400’ changed from OFFLINE (COMMUNICATION_ERROR) to OFFLINE (COMMUNICATION_ERROR): The UPnP device RINCON_38420B9457A601400 is not yet registered.`
Those are some older logs but - over there I’ve lost control after ~25 minutes from restart. Other addon, that have some mention of UPNP, is AndroidTV but from what I understood, UPNP discovery is only happening with Philips TVs. Other than that, there is nothing interesting in the logs
Discovery is one thing, taking an existing Thing offline is another. You’d need to enable DEBUG logging at least for the affected bindings, and perhaps for OH in general, to have much chance of capturing something of interest in the logs. Your log here indicates that it’s the Sonos binding that experiences the problem..? Do you have problems with your Philips TV at the same time as the problems with the Symfonisk appears?
After a quick peek in the Sonos binding, it seems that the above would be exactly what you’d see if there’s a network problem. That doesn’t mean this is the cause, but there’s no way to tell whether this is a problem with OH’s UPnP or with the network. Do these devices never reappear after having been absent without restarting OH? Do they always reappear after restarting OH?
I enabled trace debug before but there is really no interesting information there (binding provides very little info)
I forgot to mention that I don’t have Philips TV - only Android TV - so that UPNP code shouldn’t affect it. I also don’t have that problem in 5.0 version of OH.
Do these devices never reappear after having been absent without restarting OH
I have 2 times longer time, when I could power off and on without problems. If I see that device is not responsive after 5 minutes after power on, then only things that helps is restart of openhab app (not whole raspberry pi)
I have Symfonisk speaker, which I power off when its not used. When I powered it on it was connecting to internet correctly within minute or two and I could control it via Sonos binding. Now, after upgrade to 5.1m1, after some time (can be few days, can be few minutes) it is stuck in “The UPnP device RINCON_38420B9457A601400 is not yet registered” state after powering on and only restart of Openhab helps.
I will try now DEBUG on org.jupnp and I will let you know if there is something valuable there.
Edit: Seems restarting (bundle:restart) jUPNP Core Library in karaf is enough to resume normal operation of Symofnisk
The clue is to figure out what has changed between 5.0 and 5.1M1 that could possibly impact this. I don’t have any idea, but many things are changed that I’m not aware of. It could be “anything”. I can’t see that there has been any relevant changes to the Sonos binding, and JUPnP is the same version as it was in 5.0. But, it could be something seemingly unrelated that makes JUPnP stop working. We either need some good idea of what could be causing it, or logs/thread dumps that reveal what’s going wrong.
Hi, after enabling logs, I had few days of it working correctly but I’m away since Friday so I’m not able to observe it. What I noticed too, that after restart of jupnp, control of Symfonisk was working but no info about tracks was displayed. There were some errors about it but I had power loss too, and lost logs from that period. Once I will be back I will try to look at it again but I believe it is still happening for me
I can confirm this. Upgraded from 5.02 to 5.1M2 and Sonos is not working anymore!
Then I thought maybe something did go wrong with update –> Back to 5.02 and Sonos working again.
Upgraded again to M2 but Sonos is still broken. The commands are working (Play, Stop, Volume) but no Status change . . . not for Control, not for Volume, not for Track.
That’s not the same as what the others have reported. They have reported that it works for a while, then stops working. If you’re saying that it’s not working at all, it might be a different issue - maybe with the binding itself.
I looked through your logs, and they don’t reveal anything of interest that I can see. They basically just unsubscribe and then subscribe to the UPnP services - all the “noise” in between is just OSGi doing its thing and not of relevance.
If you want to find anything of interest, you should try to capture logs while whatever doesn’t work occurs. It sounds to me like you’re saying that events aren’t getting through (OH subscribes, but the idea is then that evens should be generated when anything subscribed to changes). If so, traces of this might be logged by jupnp or by the binding itself, depending on “how far” the events make it, if they are generated at all. If they aren’t generated at all, the error must be in the jupnp library.
What @michaeljoos described also happened to me once (maybe even more often but I haven’t observed it before) - see quote from my post. I’m still away so far I wasn’t able to test it further
Things have happened elsewhere, and we are not aware that events are not working for the Sonos binding in M2. We also know why, and are working on addressing it.
When it comes to the “general instability” of UPnP, we’re also following some potential causes. Do any of you that experience these issues happen to have the UPnPControl binding installed?
Yes, the events aren’t coming through from the device to OH, which means that nothing that happens on the device will be reflected in OH without a “refresh” of some kind.
