node-sonos-http-api: TypeError: Cannot read property 'coordinator' of null

On CentOS 7, this error was caused by the firewall. Running these commands fixed my issue.

$ sudo firewall-cmd --zone=public --permanent --add-port=5005/tcp
$ sudo firewall-cmd --zone=public --permanent --add-port=3500/tcp
$ sudo firewall-cmd --zone=public --permanent --add-port=1905/udp
$ sudo firewall-cmd --reload

Not sure for whom this will be useful. I was struggling with Issue 77 on a Windows 10 PC. I had allowed firewall traffic, but only to my private network. In my upgrade to Windows 10, it must have made my networks public. This firewall conflict caused the server to not find Sonos players. I went through the steps to make my network “discoverable” which makes it private; now the server is functional. Excited to have this working!

Applying the firewall configuration by @mrdvt92 on my Debian system fixed the issue for me 👍

One solution I found when running this on my Pi is to just sudo reboot the Pi and that seems to force this to rediscover the Sonos network.

I’ve hit this error when I reboot my routers, and rebooting my Pi has been the easiest solution. I’m sure you could stop and restart this Node.JS service instead if you didn’t want to do a full reboot. For me logging into hombridge and doing a sudo reboot is my fastest path to getting up and running.

@throweggs port-forwarding won’t be enough, and if you use NAT, it won’t work because the discovery protocol relies on the source IP to know where to connect back to.

Sonos (or rather, UPnP) uses bi-directional sockets, which means they need to be addressable and connectable both ways. It also requires either broadcast or multicast traffic to be forwarded, which is rarely the case.

But I would be surprised if Hyper-V doesn’t support a bridge network, where the virtual interface will get an IP from your local DHCP like it’s own dedicated machine? See this article (first section, regarding standard bridged networking) https://smudj.wordpress.com/2015/05/14/windows-10-hyper-v-setting-up-networking-shared-and-bridged-options/

Please open up a new issue or enter the chat as well, because posting comments here notifies anyone subscribing to this topic which is a bit annoying for them 😃

Using the latest version of node-sonos-http-api, recently it cannot find my sonos. Perhaps a recent sonos update? I wondered if anyone else is having a similar issue? I"ve restarted all sonoses, wireless router, server, but still no good. Haven’t changed anything else recently that I can think of.

Factory reset sonos and re-setup. No help.

@hernandito You ca not run this with docker without using bridge networking (thus, no NAT port binding allowed, --net=host). It requires multicast traffic as well as inbound and outbound connections, which makes it super hard to get going between different subnets.

See https://github.com/chrisns/docker-node-sonos-http-api

I too get the error: No system has yet been discovered. Please see #77 if it doesn’t resolve itself in a few seconds.

I’m running the docker image on a Synology NAS. Synology has the option of using a Gui/Wizard to launch the images/create the containers, or to specify the Docker Run parameters. Unfortunately, the --net --restart options do not seem available (according to the IMAGE section here --net=host --restart ). However, I also tried to start the Docker from SSH using the docker run --net=host --restart=always -d <your container/image name> command and I didn’t see a different behavior.

Running the current code (from git) on my Windows laptop, I am able to control my Sonos (although there are issues with TTS).

When I open a terminal on my Docker image (using Synology’s Docker platform) and try something like curl http://localhost:5005/zones I get the same error described in the previous comment: “No system has yet been discovered. Please see #77 if it doesn’t resolve itself in a few seconds.”

This is my first experience with Docker, so my learning curve it steep, but if I can share logs or anything here, I’ll be happy to do it.

How can I debug this further? Is there a way to confirm is it is a problem of multicast packets not reaching my docker?

Thanks.

I tried to