Install this though the karaf console. You will 1000% have to restart openhab for this to work properly once you install it. It also has a tendency to stall/fail if the system has been up for a while so it may take a few attempts.
Go into services/runtime.cfg and paste the following:
You’re going to want to paste that config in after you load the new jar, while the OH service is shutdown.
This in theory should help if not completely resolve the issue. This works on both OH2.5 and OH3.
Please let me know if it helps, or completely does not so we can track as part of the PR above.
EDIT: To be clear, this only resolves some of the issues specific to JuPnP. The issue of the device being on a seprate VLAN may or may not be resolved by this. That is due to the fact that you aren’t repeating UPnP messages across the VLANs as well as some funny business Sonos did.
well basically that is exactly what i’m doing with that multicast-relay. again, all of this already worked already. i’m also fully aware that the binding-desc states that this might be an issue, because it was coded for the setup that both OH and the sonos devices are within the same subnet. but (!) we are already at that point where OH reaches the speakers in another subnet, but can’t discover them, even though the speaker “talks back”. what @ariela did is just to add another interface and voila, it seems to work for OH. so actually (if you ask me) the issue should be somewhere between receiving the package and interpreting it.
Sorry, should have read the thread more before replying. There are a few things here that could be causing the issues. I’ve done mDNS/UPnP across subnets before, but it’s never been clean. @Lolodomo please keep me honest about the way the Sonos binding works with my thoughts here. The Sonos binding is getting it’s basic data from jupnp obviously. JuPnP establishes a registry internally of all devices that it sees. So the fact that you’re seeing them is a byproduct of that. You mention that you grabbed some pcap and that the OH host is ignoring the reply packet. Can you check the TTL on the return packet? I vaguely remember somewhere that the Sonos packets all had a TTL of 1 which is causing them to get dropped when it gets decremented.
hi! took me some time, because i’ve set up opnsense in parallel to see if it’s a routing issue on the firewall itself. answer is plain simple; yes.
i just installed an opnsense plugin called “os-udpbroadcastrelay” (same as @pstoermer was mentioning here) with the most basic config (it literally tells you the sonos params in the help), that’s all… re-run oh’s discovery, all speakers instantly in my inbox.
Pay attention with a multicast-relay, my friend. I’ve tried this in my environment (all Ubiquiti), and there were some crazy behaviours …I preferred to add a new interface on OH much easier, and still acceptable from security point of view.
Nothing complex … depending on your implementation. I’ve added a new interface in my openhabian vm hosted by Synology … a leg in the vlan where I have all my Sonos devices … and voilà, everything’s working
Not 100% sure you convinced me … I have this implementation:
vlan 3: sonos devices (and other media devices that use UPnP, like Denon …)
vlan 10: sonos controllers
vlan 17: OH3
Sonos controllers are working correctly, and they see all Sonos devices.
OH3 can discover automatically Denon, but not Sonos
OH3 is able to discover Sonos only adding a new interface on vlan 3 in my vm
vlan1 <-> vlan3 worked until sonos s2
vlan2 <-> vlan3 always worked, even after sonos s2 (as you said: “sonos controllers are working correctly, and they see all sonos devices.”)
the settings in opnsenses’ “udp-broadcast relay” are quite simple (if anyone wants to give it a try);
relay port: 1900
relay interfaces: the ones you need to broadcast between (in my example from above vlan1, vlan2, vlan3)
broadcast address: 239.255.255.250
additionally, i added a very simple firewall rule on vlan3 that allows traffic between “sonos speakers” (= alias) to "sonos controllers (= alias).
after a few day of testing, i can’t find any anomalies in my unifi controller that are bound to upnp or multicasting.
if i was asked to sum that whole thread up for anyone joining in late;
it is not possible /wo additional “implementations” to get the sonos binding to work if oh3 and the sonos speakers are in different subnets
though, there are 3 different approaches that lead to working results;
A) @pstoermer approach by running a python-based multicast-relay in kubernetes is described here
B) @ariela approach by adding a new interface in openhabian is described here and here
C) my approach (non-kubernetes and non-openhabian), by using the “os-udpbroadcastrelay” plugin for opnsense is described right above
I’m quite interested on how you implemented opnsense in a unifi environment I’m using USG, that is not a firewall indeed … and I would add an additional layer of security. Perhaps we can discuss this topic offline
Hi Christian,
I use pfsense instead of opnsense. Can you detail how you implemented the udp-broadcast relay as I do not see this plugin. is it a command line install in pfsense?
i started with an USG4pro, but was not happy at all and sold it after only a few weeks. my next step was installing pfsense on a ci323 (because of the needed 2 nics [wan/lan]) - with the goal to have dns/firewall/dhcp/… all at one place. what i kept were the unifi ap’s, because - hands-down- they’re awesome.
i then changed the ci323 to a protectli appliance (also with pfsense). at that time i was already thinking about switching to opnsense, but due to time issues, i decided to still go with pfsense (just imported the old config after applying the necessary changes [ci323 has two nics, protectli fw4b has 4]).
for failover, i decided to buy another fw4b few months ago, but this time i wanted to (finally) give opnsense a try, so i set it up in a seperate subnet so that two firewall appliances won’t interact with each other.
i’m really happy now with opnsense (went live last week) and i will stay with it (no plans to change back - also because of the late “news” of pfsense and their way back to closed source).
all in all i have my opnsense in place that is connected to my modem and my managed switch (to apply vlan tags). opnsense is solely responsible for firewalling/rules, providing dhcp and also serves as dns. of course there are some additional features like ntp and that broadcast-relay…
from time to time i fire up the unifi controller (hosted in a vm) if i need to change things - but this is very rare.
hi buddy. pfsense doesn’t have a pre-built package for that broadcast-relay. the only thing you can do is to follow peter’s approach.
the latest pfsense distros come with pre-installed python, but please keep in mind that there’s no symlink from python to the installed pkg. so if you want to call a python-script (and we’re talking here about a python-based relay), you would need to call it with e.g. python3.X <your_script>.py.
please also note that the relays’ description says “multicast-relay.py requires the python ‘netifaces’ package.” so you will also need to install pip on your pfsense to get that needed ‘netifaces’ package installed on your machine.
again, i never installed that relay on pfsense, so unfortunately i can only try to point you into the right direction.
Hi @epicurean,
I would definitely give it a try with the approach @csi_oh mentioned. In my description I talk about Kubernetes a lot and that may sound a bit over the top. But the part that you may need is way simpler: Very roughly speaking you need to have a (virtual) machine that has two network interfaces, one for each network. In my case the network interfaces have the names enp1s0 and cni0. You find ‘your’ names by calling ip addr and then looking for familiar IP addresses. This command might help you on this, e.g. if one of the networks is starting with 192.168:
Thank you Christian and Peter for responding. All this info appears to be way over the top for me so i will endeavour to read up to understand. Really makes me wonder if all this effort is worthwhile just to be able to control Sonos devices with OH
This might not be relevant because I don’t use the OpenHAB plugin for Sonos. Instead I use SONOS2MQTT.
I’ve just implemented VLANS and after fiddeling a bit with my firewall rules I got it working without the need for shuffling broadcasts between my VLANS.
My Sonos speakers reside in the IOT VLAN and OpenHAB together with the SONOS2MQTT service resides in my SERVERS VLAN.
I set the env variable SONOS2MQTT_DEVICE pointing at my SonosZP in my IOT VLAN so no need for any broadcasts. Also, the sonos-tts-polly service works great. I feel it’s a “clean” solution, and I’m happy to have expelled yet another gadget to my IOT VLAN.
Below is my Vyatta zone based firewall rule that I use on my EdgeRouter in case someone is interested.
name IOT_TO_LAN {
default-action drop
description "IOT IPv4 traffic to LAN"
rule 1 {
action accept
description "Established and related"
log disable
protocol all
state {
established enable
related enable
}
}
rule 2 {
action drop
description "Drop invalid state"
log disable
protocol all
state {
invalid enable
}
}
rule 210 {
action accept
description "Allow traffic to TTS Server from Sonos ZP"
destination {
group {
address-group TTS_SERVER
}
port 5601
}
log disable
protocol tcp_udp
source {
group {
address-group SONOS_ZP
}
}
}
rule 220 {
action accept
description "Allow traffic to SONOS2MQTT from Sonos speakers"
destination {
group {
address-group SONOS2MQTT
}
port 6329
}
log disable
protocol tcp
source {
group {
address-group SONOS_SPEAKERS
}
}
}
rule 250 {
action accept
description "Allow traffic to MQTT Servers"
destination {
group {
address-group MQTT_SERVERS
}
port 1883
}
log disable
protocol tcp
}
rule 600 {
action accept
description DNS
destination {
group {
address-group DNS_SERVERS
}
port 53
}
log disable
protocol udp
}
}