Sonos - broadcasting between different subnets

Hi there,

I just wanted to know if there’s anyone out there who managed to run openHAB and Sonos speakers in different subnets. I’m fully aware of the disclaimer in the binding-page, saying that there are troubles if someone tries to run the setup in different subnets.

Nontheless I’m successfully(!) running the Sonos controller in a different subnet than the speakers by opening specific ports on my firewall. I’d like to pinpoint here that the controller is in the same subnet as openHAB - so theoretically it should be possible.

I was just curious if someone could elaborate how the binding-discovery is working for Sonos devices.

Many thanks & KR

Discovery through UPnP.

Hi @Lolodomo, many thanks for that input.

After proper routing on the firewall, openHAB finds all of our Sonos speakers now, even if they’re in a different virtual subnet.

I am having trouble finding my Sonos equipment (on a different subnet) from OH. Can you share what you changed in your router or other network equipment?

Hi there, do you have any firewall in place?

Yes, I am using pfsense. And I understand I need the PIMD package which I downloaded and installed. But I am confused about the settings. Right now ,the Sonos binding on my OH cannot detect my Sonos Connect Amp

Hi there,

I’m using the following packages;

  • Avahi

Enable: true
CARP: none
Action: allow
Interfaces: select the ones you’re broadcasting (at least VLAN of openHAB + VLAN of Sonos)
Disable IPv4/v6: false
Refection: true
Publishing: false

  • pimd

General: Enable, bind to none, threshold type = packets (count), threshold value = 1, SPT interval = 100
Interfaces: select the ones you’re broadcasting (at least VLAN of openHAB + VLAN of Sonos)
BSR: prio = 5
RP cand: prio = 20, time = 30
RP addr: create two entries per Sonos-IP, one with multicast group and one with

  • pfsense rules

For the Sonos VLAN I highly recommend to allow everything FIRST, and then (step by step) look through your states and check what’s happening.

I came up with creating an alias for multicast addresses (,,, and I allow the (“IoT” in my case) VLAN to interact with this multicast alias group.

Second, I created an alias group for our “Sonos devices” and one for the “Sonos controllers” (1 = openHAB, 2 = the smartphone running the Sonos app). “Sonos devices” is allowed to access “Sonos controllers” on different ports (1400TCP, 1900-1901UDP, 3400-3401TCP, 3500TCP, 4444TCP, 6969UDP, 8080TCP and *UDP). The last entry (*UDP) is necessary because it seems that discovery is done on a random port number.

  • openHAB rules

I found out that Sonos devices are visible for exactly 30mins after any action has been taken between a controller and a Sonos device. As I’m not willing to upgrade to the new Sonos S2 app - which is supposed to be broken as s*, I can’t control my Sonos devices from my smartphone anymore. So I came up with an openHAB rules that triggers Sonos discovery over openHABs’ REST API every time a Sonos device things becomes “offline”. That works like a charm and I’m in full control over our speakers.

1 Like

Thank you Christian.
Can you show me what your pfsense rule for your sonos vlan look like? I am hazy about how you did the alias for multicast addresses, and also the creation of an alias group. Do share your openhab rule as well if you can.

Unfortunately I accepted the suggestion to upgrade to Sonos S2 app. Hope this is not going to be a limiting factor


first off I’d like to mention that this is no “standard-procedure”. There’s a lot going on in the pfsense forums, because everyone has a different setup and systems running. It seems that pimd-package is necessary (tbh. I’m just glad it’s working so I haven’t tried out if I can deactivate Avahi-package for example).

Anyhow, this is my firewall alias for the multicast adresses (structure is the same for “Sonos_Speaker” and “Sonos_Controller” - just /w different IPs of course)

These are the my firewall rules (keep in mind that firewall rules trigger in order of first-match, so this is why I put the *UDP at the bottom because I want this to be the “last choice”). You can also see the states/traffic here - where 8080TCP is the most triggered rule). Again, I suggest you start with “ALLOW ALL” for your Sonos VLAN towards Multicasting, and “ALLOW ALL” for your Sonos speakers to your controller(s). In further steps you might come up with something like;

the rule consists of two parts;

  • an openhab-rule that triggers on Thing ‘sonos:One:RINCON_XYZ’ changed

then, read the thing status via:

var current_status = getThingStatusInfo("sonos:One:RINCON_XYZ").getStatus

if the thing’s not “ONLINE”, trigger a .sh script that calls the REST API of openHAB:

if (current_status != "ONLINE") {
    var String executeCommand = executeCommandLine("/PATH_TO_SCRIPT/", 1000)
  • and a sh-script outside openhab
curl --insecure -X POST --header "Content-Type: application/json" --header "Accept: text/plain" "http(s)://OPENHAB_IP/rest/discovery/bindings/sonos/scan"
1 Like

Is the “sonos controller” the same IP address as Openhab?

“Sonos Controller” is an alias for my Sonos controllers (so in case I add one in the near future, I just need to modify the alias and not every single rule).

Host 1 is my smartphone
Host 2 is openHAB (YES, the same IP address as openHAB)

@csi_oh I have followed your settings up to the part before creation of rules. With the sonos binding installed, OH still cannot see my sole sonos connect amp

Do you see any handshakes in pimd package?

what would handshakes look like under status of PIMD?

Basically you should see a multicasting routing table there.

Have you tried to manually scan with the Sonos binding?
Have you tried to do something with your smartphone Sonos app?
Is the Sonos app in the same subnet as openHAB?

Yes I see the table
A scan with the Sonos binding does not show my only Sonos product -Connect Amp (on IOT)
I can see the Connect Amp on my S2 sonos app
YES the Sonos app is on the same subnet as openhab (on LAN).