Quick question. I just set up 5 Ikea speakers of the type you apparently fixed in discovery. I created them as a "virtual device" then zapped the DNI to the Hex IP address.
Is there any advantage to running discovery? Will it retain my existing devices or clobber them?
Thanks!
the parent app calls a periodic refresh on each speakers dlna subscriptions, without this any speaker changes made via the sonos app won't reflect without a device refresh.
If you change the existing DNIs to something unique (not the current ip), then run discovery you can replace the existing with the ones discovered via the integration, then delete the old ones...
I have two locations with a Sonos Ikea speaker at each location. I used the above method to successfully swap at the location I am at. However at the remote site, the speaker is never discovered. I am connected to the remote site using Wireguard. Does the discovery need to be run locally? I'm not sure if the logs are saying it can't find the old device?
Thank you for this explanation.
I am a first time symfonisk owner and followed your post to add it by creating a virtual device.
I was wondering if there was any reason to still add the Sonos integration app. Now I have my answer.
Yup, that’s exactly what it’s saying. “No route to host (Host unreachable)”. Routing SSDP over a VPN connection is a tricky thing. My quick research of the problem seems to point to the TTL (time to live) setting of the SSDP messages. The complications get more interesting since there is also a TTL for the packet encapsulating the SSDP message.
There is also the possibility that the SSDP message isn’t properly reflected back across the VPN from the remote site.
BTW, Wireguard is an exceptionally light weight VPN. It can cause other problems because it is only focused on UDP traffic. It doesn’t like to pass TCP. (Someone has probably kluged a way to encapsulate TCP in a UDP packet, but that would be a very ugly baby. )
I suspect there are others in the community who have much more expertise in this area that can help. (@aaiyar do you know anyone?). I also believe this is such a specialized non-Hubitat issue that a VPN focused networking forum would get you an answer quicker.
I wish I could help more.
This is exactly it. You can setup a multicast relay between the physical interface and the WireGuard interface, and I’ve had this work with modest success - meaning it worked across two VLANs, but timed out across LANs.
Tagging @lewis.heidrick.
It would be helpful to have the ports being used to understand all the underlying communications. There may also be some other stuff going on with mDNS for example.
WIth that being said split tunneling with routing tables correctly configured by the vpn client and the vpn being established in the correct location on the router and not just a client connection I don't see any reason it shouldn't work.
Thanks, everyone. My solution is to just wait until I am back on site.
Download the Hubitat app
