yes, I have it on 1078. However, it does come online now, but I get quite a lot of error messages:
âsonos:CONNECT:RINCON_949F3E20â changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): The Sonos player RINCON_949F3E20 is not available in local network.
and:
[ERROR] [rg.jupnp.protocol.sync.ReceivingEvent] - Invalid subscription ID, no active subscription: (IncomingEventRequestMessage) NOTIFY /upnpcallback/dev/RINCON_000E58D12EBC01400/svc/upnp-org/AudioIn/event/cb SEQUENCE: 0
I think any UPnP call can randomly fail with the new library. So the problem could happen when you request a command from OH like a pause command for example.
But it doesnât log anything The file âsonos.logâ is there but keeps empty. Tried the same with homematic instead of sonos and this is working as expectedâŠsoâŠcfg-file should be OK. Iâm lost. Any ideas whatâs wrong here?
The problem is clearly in library jUPnP and the result of the move from v2.2 to v2.3.
We have to be patient and wait for a fix in that library. If noone is able or interested to fix it, I hope there will be a brillant decision by the staff to revert to v2.2.
More you will be to complain, more it could help Kai to take the right decision.
Thanks - yes, otherwise Iâll just have to stick to the old openHAB snapshot. I use Sonos for notifications around the house, so without a functional binding my system is essentially broken.
No need to blindly update and hope that anything has changed. If you are interested in the progress, simply follow the issue. As long as it is not solved, you should not expect that any newer openHAB build will have it miraculously fixed.
Hi,
I just upgraded to build #1084, since that would fix the Sonos issue. First of all, thanks Kai for all your time on this!
But now I noticed that Iâm unable to send any commands to my Sonos anymore (before it worked in 50% of the cases). It least I can now say the behaviour is more consistent.
Sending any command (play, pause, increase/decrease volume) does not work. Also reading current track is not working anymore.
I tried restarting OH, without success. I also removed my two Sonos things and added them again. No result. My Things and Items are associated correctly.
Is there anything else I can try?
Openhab.log doesnât show anything strange. New elements I noticed in my log compared to previous snapshot version are:
2017-11-19 09:45:33.377 [INFO ] [thome.model.lsp.internal.ModelServer] - Language Server started on port 5007
2017-11-19 09:45:46.879 [WARN ] [org.apache.karaf.services.eventadmin] - EventAdmin: Blacklisting ServiceReference [{org.osgi.service.event.EventHandler, org.eclipse.smarthome.core.events.EventPublisher}={event.topics=smarthome, component.name=org.eclipse.smarthome.core.internal.events.OSGiEventManager, component.id=52, service.id=149, service.bundleid=111, service.scope=bundle} | Bundle(org.eclipse.smarthome.core_0.9.0.201711182209 [111])] due to timeout!
Not sure if that is related.
Sonos binding is up-to-date. Karaf:
207 | Active | 80 | 0.9.0.201711182209 | Sonos Binding
The Sonos-issue I was having by upgrading to #1084 was not a Sonos specific issue. Actually, none of my bindings worked anymore. I was able to find the solution (read here). So currently, I have a reliable Sonos binding. However, I would recommend to read that entire topic (not just my post), since various people had some trouble with this upgrade.
Ok. It always happens after 30 mins now. Always after the device has been discovered a second time. Is there any possibility to disable UPnP auto-discovery?
Edit: The device has an MaxAge set to 1800s. After that the RemoteDevice expires and is removed from Registry.RemoteItems, which seems ok. But it is not added after the device was rediscovered, unless the disovery was triggered manually. I donât have much knowledge of UPnP, should the expiry timer reset after each communication with the device? That is not the case.
The first one is probably very special in my setup. My Sonos is in another subnet than my OH instance (192.168.1.253 and 192.168.0.58). The OH machine has two network interfaces (eth0 and eth0.105).
Using tcpdump -i eth0 -A dst 239.255.255.250 and port 1900 I can see the alive messages from the sonos device. I see alive messages from other devices as well. I set org.jupnp.transport.spi.MulticastReceiver to DEBUG logging and now the strange thing happens: I only see alive messages from devices in the 192.168.0.0 network, not from the 192.168.1.1 network.
I see the same behaviour in a test program, if I use s.joinGroup(multicastAddress, networkInterface); ,which is done in MulticastReceiverImpl of jupnp. If I use s.joinGroup(InetAddress.getByName(group)); I can see all messages. I have no idea where to go from here. @Kai, @sjka any suggestions?
The second problem is that if the device gets removed, from RemoteItems it never gets added back again, even if the device is discovered automatically later on. And the service subscriptions donât get removed.
Finally I solved it. After I found out that even with s.joinGroup(InetAddress.getByName(group)); some packets are lost and that waiting a long time in rare cases s.joinGroup(multicastAddress, networkInterface); catches packets (not from my Sonos but from UPnP devices in the other network), I did have a closer look with Wireshark on the packets. The problem seems to be that Sonos sends the packets with a low TTL. After increasing the TTL on the router with a mangle rule I now see all Sonos traffic. Shall we add a not to the binding documentation that the low TTL might cause problems with multicast traffic across subnet borders?
jwiseman
(Mr. Wiseman (OH 4.2 Snapshot on Pi4))
42