Yesterday I have temporarely installed latest snapshot and for me this is not solved yet. I still see no status changes for all my Sonos One and Play1. Is the fix already in latest snapshot? Now I’m back on 5.02.
Hi Michael,
This is little difficult to follow the thread as we talk of many different subject.
Let’s concentrate on Sonos stuff.
If i understand:
- It was working correctly in 5.0.2.
- It was not working in 5.1 - M2 : which is normal as this version introduce the bug.
- It also not working for you in latest snapshot, which is strange.
I will test it later this day, but the current snapshot have the fix, and so should work ok.
Michael,
Strangely, it works on my développement machine, but seems not working with latest snapshot.
I’m currently moving my dev machine to machine to main branch to check what’s wrong.
Laurent.
Michael,
I’m a little disappoint about this issue.
I’ve said you it was not working, but after making quite lot of test, as it was not working at first place, it restart working on my openhab 5.1 snapshot without modifying anything. I’ve just start / stop the Sonos thing several time.
I’m asking myself if it’s not related to something that I observe on my dev platform a few weeks ago, but have not commit the modifications.
@Nadahar : I would appreciate your advice on this.
I’ve notice something nasty occurred in the Sonos binding, but I can explain why.
In the current code of initialize in ZonePlayer:
@Override
public void initialize() {
logger.debug("initializing handler for thing {}", getThing().getUID());
if (migrateThingType()) {
// we change the type, so we might need a different handler -> let's finish
return;
}
configuration = getConfigAs(ZonePlayerConfiguration.class);
String udn = configuration.udn;
if (udn != null && !udn.isEmpty()) {
service.registerParticipant(this);
pollingJob = scheduler.scheduleWithFixedDelay(this::poll, 0, configuration.refresh, TimeUnit.SECONDS);
} else {
updateStatus(ThingStatus.OFFLINE, ThingStatusDetail.CONFIGURATION_ERROR,
"@text/offline.conf-error-missing-udn");
logger.debug("Cannot initalize the zoneplayer. UDN not set.");
}
}
We are pooling a job with 0 delay, that should start the this::poll immediately.
But I’ve noticed that this::poll is not start every time, and so that the binding stay time to time uninitialized until th refresh delay occured.
This does not seems to occurs if we put a bigger value to initialDelay (1 or 2 seconds).
This can be a problems as gena subscription are setup in the poll function, and so nothing is working until the first refresh.
I’m not sure also if we have not an issue at all about start of jupnp stuff.
When I’ve got the problem this afternoon, It seems that I’ve not received upnp event at alls.
I’ve put a breakpoint on ReceivingEvent:executeSync function, but didn’t eat the breakpoints at all, even for traditional Upnp devices. I was not able to trace it deeper as for some reason, after some openhab start/stop, it restart to work correctly.
Laurent.
All I can say is that this polling is unnecessary and frankly “an abuse” of the UPnP protocol. If you want to “poll”, you should do so by sending a SEARCH and wait for the NOTIFY response, but it’s normally not needed at all. Invoking a function to check that the device is “live” is just wrong.
As to why it sometimes “fail” I can’t say, the protocol isn’t being used as designed. I guess it depends on what function is invoked, that status of the device or other factors.
In my refactoring, the following will happen: After the call to service.registerParticipant(this), UpnpIOService will notify the binding (as soon is a thread is available from the pool) of the current status of the remote device - online or offling. Likewise, it will inform the binding if this changes in the future. All the binding need to do is to react to these events and set the Thing status as online or offline from that.
I’d say that the only thing that should be done here is to set the ThingStatus to INITIALIZING (or OFFLINE if no UDN is configured), and then handle the rest from the events.
There are multiple issues there, hence my refactoring. It’s hard to point to “one specific issue”, because the issue is really that the protocol isn’t used the way it’s meant to be used. For online/offline events to be received, the UDN registered for the participant must be the root UDN. Otherwise, you’ll never receive an event, which might be why this polling stuff has been invented in the first place (as a consequence of not understanding that you can’t register the UDN of embedded devices and get notified).
I have refactored some of the UPnP code, and modified the upnpcontrol binding accordingly. However, I don’t have any of the problematic UPnP devices with embedded devices myself, so I can’t test if what I have done will work.
If anybody out there is willing to test, please let me know. I haven’t modified the Sonos binding in my test code, but could potentially do so. Ideally though, I’d want to test what I have with e.g. a Denon or Marantz that have embedded devices. We’ll have to figure out how to do the testing, I’ll probably have to upload a build somewhere. The test can be run from a computer, so that you don’t have to “mess up” your “real” OH installation.
The Sonos binding is working for me in the snapshot 4952, a snapshot just before 5!1 milestone 3.
The bug introduced just before milestone 2 was fixed shortly after release of milestone 2.
It doesn’t work for me in 5.1M3, and it seems to work randomly, sometimes it does and sometimes it doesn’t. I can help with testing.
As I’ve said multiple times, the “fix” was a band-aid, and a proper fix is needed. Which I’ve tried to make, but so far nobody with such a device has been willing to test.
If I understand correctly, you don’t mean a Sonos device, right?
A Sonos device is a possibility, but it would mean more work for me, because I’d have to figure out how they are organized (UPnP-wise) and then modify the Sonos binding to do the test. Ideally, I would like something that can work with the upnpcontrol binding, which I already have modified for testing. I know that Marantz and Denon receivers “qualify”, but there may be others. There’s no “easy way” to tell which devices qualify for testing, because it depends on the details of their UPnP implementations - we need devices that implement “embedded devices”, which most UPnP devices don’t.
If finding anything else than Sonos devices for testing turns out to be difficult, I need somebody to provide some “UPnP diagnostics data” from one of these devices. Unfortunately, the tools for such “UPnP diagnostics data” are few and some don’t produce output that can easily be shared (as text).
For Windows it’s almost hopeless, I’ve more or less given up finding anything that works. There are some old, abandoned projects, but none that really give me what I need. I know that Cling Workbench used to provide this, but it probably requires some ancient Java version to work.
For Android I’ve found “UPnP Explorer” and “UPnP Tool” that give somewhat usable data, but neither offers to output this to a text file AFAIK.
There are also things like UPnP Inspector that might provide what I need, but I haven’t taken on the burden of trying to get all the Python stuff working well enough to test it.
There are also some tools for Linux that I haven’t tried, because I don’t have a Linux VM available on the necessary IP subnet, and UPnP doesn’t traverse subnets, but I think that e.g. “gssdp-dicover” can produce usable results.
For information, SSDP and UPnP are one and the same in this context, SSDP is the name of UPnP’s “discovery protocol”, which is what is used to acquire the necessary information.
Do you have Developer Tools for UPnP Technologies? I have an .msi for that which is about 8MB. Please PM me with an email address where I can send it to.
I’ve got a Sonos Move and a Sonos One, and would gladly help.
Sadly, it’s behind a paywall.
Hi @michaeljoos,
I’ve retried M3 tonight, and see no SONOS issue on my side.
Can you please send me:
- The result of bundle:list command in openhab console.
- Your latest logs, after activating those logs:
log:set DEBUG org.openhab.binding.sonos
log:set DEBUG org.openhab.binding.upnpcontrol
log:set DEBUG org.openhab.core.io.transport.upnp
log:set DEBUG org.jupnp
Thanks,
Laurent
There is a direct link too. You just need to dig a bit.
Also, you said in a previous post that sometime it’s working, sometime not.
Can you be a little more specific on this.
Is it that it works and stop working after some times.
Or is it that when you restart openhab, sometime it works, sometime not.
No, I meant that heise.de itself is paywalled. It’s the “usual extortion” these days, where you either accept tracking (which is out of the question), or have to pay an insane price to access the website.
Try this