Spotify connect to sonos over different subnets and a firewall

We have some nice Sonos speaker in our network. Of course we devided our network in private and guest. Guest just have acces to the internet.

Sometimes we want our guests to be able to choose the music. In the past they used a tablet for this but they had no access to their own playlists.

Since some weeks Spotify connect is able to control Sonos speaker to play music on them. So why not allow devices from guest-LAN to acces Sonos speaker to control them via Spotify connect?

Our setup: We have a linux box with iptables as a gateway between these two subnets (seperated by VLANs).

Spotify connect uses mDNS for discovery so I sat up the avahi deamon and enabled two options in the configuration.

Also you need a tiny hole in your firewall. The first rule is to allow the access to the mDNS daemon. The other rules are one per Sonos device you want to allow acces to. We have „private“ Sonos devices we don’t want to share so we have not allowed all of them.

Spotify uses the local network just for gaining control – all the control itself is made via internet.

Amazon Dash Button mit ISC DHCPD und FHEM

Einen WLAN-Knopf für nur 5€? Den muss man doch ausprobieren 😉

nerf

Das die Amazon Dash Buttons umfunktioniert werden können ist mittlerweile weitläufig bekannt. Die aktuellen Lösungen reagieren fast alle entweder auf den DHCP-Request vom Dash Button oder dem nachfolgendem ARP Request. Meistens wird ein Script verwendet, welches auf die Netzwerkpakete horcht und bei Eintreffen eine Aktion ausführt.

Im FHEM-Forum taucht auch schon das erste Modul auf. Dieses öffnet einen Listener auf Port 67 (DHCP) und lauscht direkt auf die ankommenden DHCP-Requests.
Das FHEM-Modul können wir leider nicht verwenden, da wir auf dem FHEM-Server auch gleichzeitig unseren DHCP Server laufen lasse und der Port somit schon belegt ist.Also würde mir nur die Script-Lösung bleiben. Aber wozu ein extra Script laufen lassen, wenn das auch mein DHCP-Server übernehmen könnte?!

Der von uns eingesetzte ISC DHCPD ist in der Lage nach einem DHCP-Request ein Script auszuführen.

Das Script wird natürlich nur bei dem Button mit genau der MAC-Adresse ausgeführt. Zusätzlich überschreibe ich nur für den Button den Default-Gateway, damit der Button gar nicht erst zu Amazon durch kommt.

Achtung: Wenn AppArmor im Einsatz ist, muss man etwas entschärfen – der mag es nicht wenn der DHCP-Server plötzlich Scripte ausführt 😉

Die passende FHEM-Config besteht aus einem dummy und einem notify:

Der Notify reagiert nur auf ein „on“ vom Dummy und setzt den Status mit dem neu definierten at-Device nach 40 Sekunden wieder zurück auf „off“. Das nutze ich zum entprellen des Buttons. Mir ist beim Testen aufgefallen, das es sein kann, das der Button sich mehrmals meldet und der DHCP somit das Script mehrfach ausführt. Das Attribute „event-on-change-reading“ hilft beim entprellen, indem es das notify nur bei State-Changes ausführt und nicht jedes mal wenn der State gesetzt wird.
Es sind übrigens 40 Sekunden, weil der Dash-Button ganze 35 Sekunden wach ist, wenn man ihn nicht zu Amazon durchkommen lässt. Kommt er durch und bekommt eine Antwort von Amazon ist er nur 8 Sekunden wach. Wenn noch jemand einen Tipp hat wie man ihm den Call-Home abgewöhnt und trotzdem bei 8 Sekunden bleibt, gerne melden 😉 Man-in-the-middle wird wohl nichts, da die Kommunikation mit HTTPS gesichert ist und self-signed Zertifikate nicht angenommen werden.

Ich werde den Button jetzt unter den Wohnzimmertisch kleben und mich bei jedem Tastendruck freuen wenn die Beleuchtung in den Kino-Modus geht, die Leinwand runter fährt, der Beamer sich einschaltet, … 😀 Und beim nächsten Tastendruck wird der Kino-Modus wieder beendet.