search

jishi / node-sonos-http-api

An HTTP API bridge for Sonos easing automation. Hostable on any node.js capable device, like a raspberry pi or similar.
http://jishi.github.io/node-sonos-http-api/
MIT License
1.84k stars 462 forks source link

Configuring different Discovery Subnet #806

Open paFFr opened 3 years ago

paFFr commented 3 years ago

Hello,

I was wondering if there has been any feature implemented to support discovery of Sonos speakers located within a different subnet since the last request for this feature I could find from 2016. Since we have a VM running on an ESXi Server to host the Sonos node components but need to control speakers located on another side it is currently not possible to setup the Sonos Node api in the same subnet as the speakers, but both subnets are connected via a permanent IPsec Tunnel.

Is there any way to tell the sonos http api to search for the Sonos speakers in a different subnet?

Thank you for your great work!

With regards, paFFr

jishi commented 3 years ago

There is nothing implemented to bypass the normal ssdp discovery process right now, but there is also nothing that "prevents" SSDP from traversing subnet boundaries. However, you would have to add some sort of broadcast/multicast forwarder/relay and add the appropriate rules to allow traffic through.

Not sure why you have an IPSec tunnel between your VM and your network though, are the ESXi locate off-premises?

Here is another question about the same issue https://github.com/jishi/node-sonos-http-api/issues/266

It would be technically feasable to "pin" the discovery to a single Sonos player if you reserve an IP for it, but it hasn't been implemented. It also add extra points of failures, hence why I have avoided it.

paFFr commented 3 years ago

Hello jishi,

thank you for your reply, you are correct, the ESXi is located on a different site than the Sonos devices, so we have to cope with different subnets here. I was curious if there have been made any changes since the issue you linked was posted, but I guess this something that complicates the code by a lot while my situation is a rather rare use-case. I'll try and see if I can get this to work with multicast forwarding going forward.

Thanks for your support and the great work you do with this project!

With regards, paFFr