Ich habe zusammen mit dem Loxone-Forum eine Alternative zur DMX-Steuerung auf Netzwerkbasis entwickelt. Hier im Blog habe ich ja schon recht viel über die Hardwareentwicklung geschrieben, wollte aber jetzt auch mal zusammentragen, was sonst noch dazu gehört.


Einstellbare Dimmkurven

Robert Lechner hat im Loxone-Forum vor längerem seine Entwicklung einer Alternative zur Loxone DMX Extension gezeigt und vor allem die Software dafür programmiert. Die Software lässt sich einfach auf einen Arduino (Atmega 328p) mit Ethernet-Shield (W5100) und RS485-Adapter flashen und hat ein paar Vorteile gegenüber der bei Loxone etablierten DMX-Steuerung. Die größten sind wohl, dass beliebige UDP-Kommunikation zur Steuerung genutzt werden kann und, dass sich Dimmkurven sowie Geschwindigkeiten beim schalten übergeben lassen. Man kann also DMX nicht nur am Loxone-Miniserver nutzen, sondern auch an z.B. node-red oder eben einfach an allem, was UDP spricht.
Die Anbindung an Loxone erfolgt über einen einfachen Virtuellen-UDP-Ausgang. Im Loxone-Forum wurde die Anbindung auch schon recht ausführlich erklärt.

Das Protokoll zur Ansteuerung ist von Robert natürlich auch dokumentiert.


Ich bin begeistert, wieviele Leute diese Lösung nachgebaut haben und auch in ein 2TE-Hutschienengehäuse montiert haben, um eine günstigere Alternative zur Steuerung von DMX-Geräten zu haben. Das Feedback im Originalthread liest sich durchweg positiv.

Hier als Beispiel ein paar Bilder von hismastersvoice aus dem Forum:

Im Oktober 2017 habe ich dann eine „große Klappe“ gehabt und angeboten, eine Platine für die Schaltung zu entwickeln.

Ziel war es, eine bestückte Open-Source-Platine zu bauen, die den „besseren“ WizNet-Ethernet-Chip (zuerst W5200 dann W5500) enthält, eine „echte“ MAC-Adresse hat (EUID48), einen Verpolungsschutz sowie einen großen Spannungsversorgungsbereich hat und eine Schutzbeschaltung auf RS485/DMX-Seite enthält. Das Ganze dann bitte noch in einem ansprechenden Gehäuse 😉

Für mich war das eine gute Gelegenheit zu lernen, wie man Ethernet selbst auf eine Platine bringt und was man alles für eine Kleinserie bewerkstelligen muss. In meiner Firma wurde die Nachfrage nach Eigentwicklungen für Kunden auch immer größer und so war es sinnvoll die ersten Versuche zu starten.

Die eigentliche Hardwareentwicklung kann hier im Blog und im Ursprungsthread verfolgt werden.
Natürlich war es damit nicht getan, denn wenn man in DE offiziell Elektronik verkaufen möchten, muss die Entsorgung des Geräts wie auch die Versorgung der Verpackung schon geregelt sein, wenn etwas das Haus verlässt. Meine Firma ist also mittlerweile WEEE-registriert, ist Mitglied im VERE e.V. und lizensiert Versandverpackung. Dazu gehört auch eine monatliche Mengenmeldung an die verschiedenen Stellen und die Zahlung entsprechender Gebühren.
Natürlich wollten wir auch die CE-Konformität für die Bridge erklären, weswegen ich einen mehrtägigen Kurs besuchte, um mich dann – mit externer Hilfe – durch einen Dschungel von CE-Richtlinien und Europanormen zu kämpfen.

Dann war noch die Frage, wo man denn bitte eine Kleinserie der Platinen bestücken lassen kann. Bei ~60 Bauteilen pro Platine wäre der Preis bei Handbestückung einfach nicht mehr marktfähig gewesen. Zum Glück fand ich ein paar Orte weiter einen kleinen Elektronikbestücker, der einen Europlacer und entsprechende Lötautomaten betreibt… es konnte also in die Fertigung gehen.

Vom letzten Prototyp bis zur ersten fertigen Platine vergingen aber noch ein paar Tage. Die Bauteile mussten mit dem Bestücker abgesprochen werden, leichte Änderungen an der Platine gemacht werden und vor allem ein Nutzen gefertigt werden – also die Platte, auf der 2×5 Platinen in einer großen Platine gefertigt sind, damit der Placer diese bestücken kann.

Hier ein Video wie sowas dann aussieht:


Nachdem das alles erledigt war, fehlte nur noch die Anleitung. Diese wird eng an de CE-Konformitätserklärung geknüpft, da dort ja auch Risiken eingeschätzt werden und die bestimmungsgemäße Verwendung definiert ist.
Die Platine ist komplett als Open-Source entwickelt, wer möchte kann sich also anhand des Schaltplans selbst eine Bridge zusammenbauen.

Für alle, die ein fertiges CE-konformes Produkt mit Garantie und Bedienungsanleitung im ansprechenden Gehäuse inklusive Schutzbeschaltung möchten, haben wir die Ethernet DMX Bridge seit letzter Woche offiziell im Verkauf.
Es wurden ursprünglich 30 produziert und es können zeitnah 20 nachproduziert werden.

Ethernet DMX Bridge

Ethernet DMX Bridge im geschlossene 2TE-Gehäuse

Ich freue mich wie immer auf euer Feedback und hoffe, dass ein paar Leute mit den ganzen Infos was anfangen können 🙂


Update

Stephan Löwemann hat ein Tool entwickelt womit man auf einfache Art und Weise die virtuellen Ausgänge für die Steuerung der DMX Bridge in der Loxone-Config erzeugen kann:

https://www.loxforum.com/forum/faqs-tutorials-howto-s/34948-g%C3%BCnstige-und-bessere-alternative-zur-dmx-extension/page13

Super Arbeit, Danke!


Update II

Seit eben ist die Ethernet DMX Bridge in begrenzter Stückzahl wieder im Shop verfügbar. Falls ihr von der aktuellen Charge keine mehr ergattern könnt, meldet euch bei mir. Damit fällt es mir leichter die Menge für die nächste Produktion abzuschätzen.

In unserem Bürogebäude in Haiger befindet sich seit ein paar Jahren im untersten Stockwerk eine Event-Gastronomie: http://arnos-event.de/
Arno, Wirt und Namensgeber der Bar, wollte für seinen Loungebereich eine besonderere Beleuchtung als in den restlichen Räumen.

Die Wahl fiel auf die bekannten Neopixel (WS2812) in RGBW, von denen wir ~1600 Stück in der Lichtkante der Decke montierten. Die Steuerung für den Stripe lag einige Zeit brach, aber nun hatte ich endlich Zeit, etwas passenden zusammenzubauen. Eines der Hauptprobleme ist bis heute, dass es sehr wenige Neopixel-Projekte gibt, die den Warmweiß-Kanal (RGBW) mitbenutzen oder überhaupt mit so vielen Pixel klarkommen. Die Adafruit-Neopixel-Library unterstützt die Anordnung (GRBW) zum Glück… benutzt wird sie aber offenbar von keinem Projekt, was auch die Steuerung von Außen zulassen würde.

Leßt bitte in jedem Fall den wirklich sehr nützlichen und wichtigen Adafruit-Neopixel-Überguide. Hier ist alles erklärt, was ihr über das Arbeiten mit Neopixeln wissen müsst.

Hard- & Software

Meine ersten Versuche begannen auf einem Arduino Mega (ATMega 2560, 8kb SRAM) und ein wenig selbst programmierten Code. Der Mega deswegen, weil er einerseits die richtige Spannung (5V) hat und andererseits genügend Speicher für die ~1600 Pixel bietet.

Für jedes Pixel mit RGBW werden 4 Byte im RAM des Mikrocontrollers benötigt. Das heißt also: 4 x 1600 = 6,4kb. Ein Arduino Uno (ATMega 328p) mit seinem 2kb SRAM wäre damit schlicht überfordert. Ich hatte nur nicht bedacht, dass ich für Transistionen zum Beispiel von einer Farbe zur anderen ja minimum das doppelte an Speicher haben muss.
Die Pixel leuchteten also erst mal einfarbig. Durch ein Ethernet-Shield hatte ich zumindest schon ein krudes HTTP-Interface implementiert, um den Mega von „Außen“ zu steuern, das hat mich aber natürlich wieder Speicher gekostet.

Im Laufe des letzten Jahres habe ich dann immer wieder mal nach Software oder Controllern gesucht, die den Anforderungen genügen würden. Selbst im allseits bekannten chinesischen Warenhaus waren – wenn schon für ~2000 Pixel – nur RGB-Controller zu haben.
Irgendwann bin ich dann auf Tobias Blum’s MCLightning V2 für den ESP8266 gestoßen und war begeistert. Tobias setzt die Adafruit-Neopixel-Library ein, die ja mit RGBW Pixeln klarkommt. Er implementiert zwar auch keine Nutzung des Warmweißkanals, was ich aber für eine vernünftige Steuerung über Websockets oder MQTT fürs erste völlig in Kauf nehmen kann. Zusätzlich dazu hat Tobias die WS2812FX Library eingebunden, die einen netten Haufen an vorgefertigten Effekten mitbringt.

Da ich nicht wusste, wie viele Neopixel ein ESP8266 wirklich verkraften kann, plante ich die ~1600 Pixel auf 5-6 Controller aufzuteilen.

Die Spannungsversorung wird von sechs 10A/5V-Meanwell Netzteilen bereitgestellt. Alle 2,5-3m gibt es eine erneute Einspeisung der Versorgungsspannug um den Spannungsabfall im Stripe zu kompensieren, inklusive dem im Überguide empfohlenem 1000µF Kondensators,.

Controller

Die Idee, einen eigene Controller-Platine zu bauen war schon vor Längerem geboren, jetzt war dann auch die passende Software da. Bei der Hardware gab es folgende Punkte zu beachten:

  • Anpassung Logikpegel 3,3V zu 5V
  • 1000µF Kondensator zum Schutz der NeoPixel
  • Durchleitung von mehreren Ampere (5V) auf der Platine
  • leichte Programmierbarkeit (FOCA-Header, Flashtaster, etc.)

Neopixel werden mit 800kHz gepulst angesteuert, was einen einfachen Levelshifter für die Anbindung an 3,3V ausschließt. Der Adafruit Guide bot dafür zum Glück eine Lösung: 74HCT125 Logic-Level Line Driver. Damit ist es möglich, ohne jeglichen „Hack“, wie zum Beispiel die Nutzung einer Diode, die 5V-Neopixel direkt anzusteuern.

Basierend auf meinem esp2866-proto-board habe ich dann eine einfache Schaltung als Neopixel-Controller entworfen.

Schaltung ESP8266 Neopixel Controller V0.3

ESP8266 Neopixel PCB V0.2

Leider gibt es den 74HCT125 nur in einer Vierkanalvariante. Für die Produktion dieser Platine probierte ich zum ersten Mal Multi-Cicruit-Boards aus, die eine DRC-Datei für Eagle zur Verfügung stellen und somit das Layouten vereinfachen. Die Qualität der Boards ist überragend (HAL Bleifrei), der Silkscreen könnte allerdings etwas besser sein.
Als Controller kommt der bekannte ESP-12F zum Einsatz, der auf die „Mutterplatine“ aufgelötet wird. Die Bauteilegröße ist 1206, um Bestückung von Hand so einfach wie möglich zu machen. Die Kondensatoren und Widerstände sind entweder von Panasonic oder Murata. Den kleinen Preisunterschied zu China-Bauteilen macht die Qualität wieder wett.

Die Platine habe ich zum ersten Mal komplett alleine per Reflow mit Heißluft gelötet. Vielen Dank auch noch mal an Andreas Draxler von Draxler-Elektronik für die geduldige Beantwortung all meiner Fragen und die Hilfe.

Ich habe wie immer viel gelernt, vor allem was man beachten muss und wie schnell sich zum Beispiel zu viel Lötpaste unter dem ESP-12F rächen kann. Für solche Arbeiten ist in jedem Fall ein Solder-Stencil zu empfehlen, den ich aus Kostengründen hierfür gespart habe.

Auftragen von Lötpaste und Bauteilen für das händische Reflow-Löten

ESP8266 Neopixel Controller Platine fertig gelötet

Installation

Da im Gebäude der Installation eine Loxone zur Hausautomatisierung zum Einsatz kommt, stellt sich die Frage der Anbindung. McLightning erlaubt die Steuerung per Websocket, HTTP und MQTT. Da ich ja mehrere Controller gleichzeitig steuern wollte, war der Plan einen RaspberryPi 3 mit eigenem WLAN für die Controller und node-red einzusetzen. Die Verbindung zu den Controllern wird über Websockets hergestellt, weil ich durch das deaktivieren von MQTT und OTA noch mal Speicher spare.

Das bringt uns dann zu der Frage, wie viele Pixel denn nun mit dem Board angesteuert werden können?

EIN Controller (ESP-12F) kann ALLE ~1600 RGBW Pixel mit McLightning ansteuern! Allerdings funktioniert dann das Webinterface auf dem Mikrocontroller nicht mehr komplett, da anscheinend nicht mehr genug Speicher für die Bereitstellung des JSON zur Steuerung der Animationsmodi bereitsteht.
Außerdem ist mir aufgefallen, dass die Effekte dann – trotz maximaler Geschwindigkeitseinstellung – sehr langsam ablaufen.

Ich habe also die Pixel auf drei Controller aufgeteilt und diese dann per node-red vorerst provisorisch verbunden und ein node-red-dashboard zur Steuerung eingerichtet. Die gewünschten Befehle werden einfach nur an alle verbundenen Controller übertragen. Später ist dann die Anbindung an den Loxone-Miniserver per node-red-contrib-loxone geplant.

Conclusion

Auch wenn die Controller unterschiedlich schnell und nicht synchron laufen, kann sich das Ergebnis denke ich sehen lassen. Die unterschiedlichen Geschwindigkeiten kommen durch die unterschiedliche Anzahl an Neopixeln pro Controller zu Stande, ergeben aber bei „Breath“ und „Chasing Rainbow“ auch ganz nette Effekte 😉

Der Regenbogen ist im Beitragsbild oben zu sehen. Hier mal der „Fireworks“-Effekt in Aktion:

Wenn die Nachfrage hoch genug ist, produziere ich gerne ein Paar Platinen und packe sie in den kommenden cod.m-Webshop. Wer eine haben möchte, meldet sich einfach.

Fragen, Feedback? Meldet euch 🙂

 

 

Ich habe Anfang diesen Jahres einen node-red node für die Anbindung des Loxone Miniservers geschrieben: node-red-contrib-loxone. Die Entwicklung können Interessierte im Loxone-Forum nachlesen. An dieser Stelle auch noch mal Danke für das ganze Feedback!

Loxone baut eine recht komplette und dafür immer noch halbwegs offene Hausautomationslösung mit vielen fertigen Hard- wie auch Software-Komponenten und eigenem Funksystem. Es gibt eine eigene Konfigurationsoberfläche mit SPS-artigen Programmiermöglichkeiten und eine recht schicke Visualisierung. Ein großer Vorteil liegt zum Beispiel in der fertigen Logik der einzelnen Bausteine und in Extensions, die die Verbindung in andere Welten wie EnOcean, Modbus und DMX schaffen.

Mit der Zeit arbeitet Loxone aber immer mehr daran, in seinem System eher die eigenen Komponenten zu bevorteilen. Das äußerte sich zum Beispiel darin, dass die Modbus-Kommunikation nur noch im Fünfsekundentakt möglich ist.
In Anbetracht der Tatsache, dass der Miniserver schon ein paar Jahre alt ist, will ich das sogar verstehen. Das System muss seiner Hauptaufgabe (Schalten, Steuern, Regeln) nachkommen – und das hat eben die höchste Priorität gegenüber „nachgelagerten“ Aufgaben.
Der Miniserver ist zum Beispiel auch zu schwach auf der Brust, um SSL/TLS zu implementieren. Meiner Meinung nach einer der größten Nachteile des Systems…

Außerdem habe ich viele Kommunikationsmöglichkeiten – wie zum Beispiel MQTT – vermisst. Mit node-red-contrib-loxone wurde es dann endlich möglich, gewisse Dinge doch wieder in die eigene Hand zu nehmen!
Hier möchte ich auch das vorzügliche LoxBerry Projekt erwähnen, das bereits viele Unzulänglichkeiten des Miniservers ausgleicht.

Mein wichtigtes Anliegen war, wie bereits erwähnt, die Öffnung der Plattform Richtung MQTT. Damit hatte ich dann alle Möglichkeiten eine Anbindung zu beliebigen Systemen zu realisieren.

Bei einem Freund, der als Elektriker Loxone vielen Kunden konzeptioniert und einbaut, habe ich dann mal testweise Homematic-Komponenten (Keymatic und Fensterkontakte) über node-red mit Loxone verknüpft.

Als Bindeglied diente mir MQTT, wie ich ja bereits unter Homematic mit node-red über homegear beschrieben habe. Über die günstige Nachrüstmöglichkeit von optischen Funk-Fensterkontakten freut er sich immer noch 😉

Die Verbindung des nodes läuft über den vom Miniserver bereit gestellten Websocket. Dieser wird zum Beispiel auch von der Smartphone-App genutzt. Der Verbindung zu node-red liegt die vorzügliche node-lox-ws-api von Ladislav Dokulil, dem ich hiermit explizit dafür danken möchte, zu Grunde. Dadurch musste ich die komplette Websocket-Kommunikation nicht selbst implementieren und konnte mich um die eigentlichen nodes kümmern.

Mit Version 9 der Loxone Software wurde jetzt die Verschlüsselung der Websocket-Aufrufe und der Login-Credentials umgestellt. Dank Ladislav konnte ich die gewünschte Verschlüsselung einfach in einen Konfigurationsparameter übergeben und brauchte nicht meinen kompletten Code anzupassen.

Wichtig ist, dass die „alten“ Verschlüsselungs- und Hashing-Methoden noch bis März 2018 von Loxone in Version 9 unterstützt werden. Für die älteren Versionen (<9) werden sie natürlich noch benötigt und sind daher weiterhin im Node als Parameter vorhanden.

Ich bin weiterhin gespannt, was die Leute alles in Verbindung mit Loxone und node-red anstellen. Kommentiert gerne, wenn ihr mich auf ein Projekt hinweisen wollt.

Inspiriert von Oliver Lorenz schreibe ich hier mal eine Alternative zum Anbinden von Homematic-Komponenten an node-red auf. Ich nutze für die Hardwareanbindung der Homematic-Komponenten homegear, da es mir die bidirektionale Kommunikation per mqtt erlaubt.

In Oliver’s Post musste ein Programm auf der CCU geschrieben werden, um die Zustände bei Auftreten (event) „zurück“ an node-red zu melden, oder sie müssten zyklisch abgefragt werden. Durch die Nutzung von homegear entfällt dieser Schritt, weil jedes event direkt per mqtt kommuniziert wird.

Hardware

Aus einem Vortrag beim @make_ldk von letztem Jahr habe ich noch folgende Folie, die die Struktur recht anschaulich zeigt:

Es bietet sich an, homegear auf einem Raspberry Pi zu betreiben, da man dort den direkten Zugang zu den eventuell benötigten Hardwareschnittstellen hat. Homegear kann mit einer Vielzahl von Geräten mit homematic (BidCOS) kommunizieren. Ich nutze hier ein CC1101-Funkmodul, das per SPI angebunden wird. Natürlich kann man auch das HM-MOD-RPI-PCB, das HM-LGW oder eine CUL benutzen. Weiteres dazu in der homegear-Dokumentation zu Homematic-BidCOS.

Auch wenn das CC1101-Modul der basteltechnisch größere Aufwand ist, so ist es doch die günstigste und auch technisch beste Lösung (Timing). Die Module lassen sich für unter 5,- € bei den üblichen chinesischen Versandhäusern bestellen. Pollin bietet zum Beispiel auch ein CC1101 Modul an, was sich ohne Probleme einsetzen lässt.

Der CC1101 kann mit 868MHz oder 433MHz funken, allerdings muss er für die entsprechende Frequenz die passenden Antennenkonfiguration vorweisen – 433er-Module funktionieren nicht mit Homematic, das in 868MHz funkt. Auf den Marktplätzen werden viele Module mit 433MHz als 868MHz verkauft. Am besten haltet ihr euch an die Vorschläge im Wiki von FHEM für den Selsbstbau-CUL, den ihr natürlich auch mit homegear nutzen könntet.

Homegear kann mehrere Protokolle/Hardware anbinden. Es kann also nicht nur mit Homematic, sondern auch mit MAX!, Sonos, Philips Hue, Intertechno uvm. auf dem hier gezeigten Weg kommuniziert werden.

Software

Ich nutze für dieses Beispiel hier nicht das fertige homegear-Raspbian, da es sich um ein für den Dauerbetrieb optimiertes read-only Image handelt. Stattdessen habe ich ein Raspbian mit node-red installiert und dort zusätzlich mosquitto (ein mqtt-broker) und homegear mit dem homematic-bidcos Paket installiert. Mosquitto lässt sich sehr einfach über das zur Verfügung gestellte Debian-Repository installieren. Danach nur noch den Dienst mit systemctl enable mosquitto.service aktivieren.
Für die Installation könnt ihr gerne openHABian nutzen oder euch an mein Anfängertutorial zur Installation eines RaspberryPi mit node-red halten. OpenHABian kann node-red wie auch homegear mit installieren.

Für die Grundlagen mag ich euch ein paar Links empfehlen:

Als Client, um die mqtt-Kommunikation zu überwachen, eignet sich mqtt-spy.

Aufbau/Konfiguration

Das CC1101 Modul wird direkt am SPI des Raspberry Pi betrieben, der Anschluss und die Konfiguration sind in der Dokumentation von homegear erklärt: Configure Texas Instruments CC1101 (SPI aktivieren mit raspi-config).

Nach Einrichtung des Betriebssystems sowie Verkabelung muss homegear und das Modul nur noch konfiguriert werden. Schaut dazu bitte in das Grundlagen-Tutorial unter dem Punkt „Konfiguration“ – wichtig auch der Absatz über AES (!) – oder in die Dokumentation von homegear.

Raspberry Pi 3 mit CC1101 SPI Modul

Update: Mittlerweile habe ich einen Adapter für das CC1101 Modul gebaut, damit man nicht immer so einen Kabelsalat veranstalten muss und eine externe Antenne anschließen kann. CC1101 SPI Adapter mit u.FL Antennenbuchse

Zum Test verwende ich einen HM-LC-Sw1-Pl-2. Nach dem Anlernen, wie unter First Steps beschrieben, meldet sich der Aktor mit seinen Datenpunkten per mqtt unter dem Topic homegear/<homegear-id>/plain/<device-id>/<channel>/<var-name>.
Die homegear-id und der Typ der Meldung wird in der mqtt.conf konfiguriert. Neben plain können auch noch json und jsonobj zurück gegeben werden. Achso, natürlich noch enabled = true setzen, um mqtt zu aktivieren.

Die in den Geräten vorhandenen Datenpunkte können in der offizielen Homematic Dokumentation nachgeschlagen werden.

In unserem Beispiel ist der Status des Aktors also unter homegear/1234-5678-9abc/plain/1/1/STATE zu finden (true/false). Um nun den Status zu „beschreiben“, tauschen wir plain im Topic einfach durch set aus: homegear/1234-5678-9abc/set/1/1/STATE. Dort können wir nun entweder true oder false hinterlegen (publish) – 1/0 würde genauso funktionieren, homegear verarbeitet die gelieferten Daten logisch.

In mqtt-spy kann man nun sehr gut die Zustandsänderungen unseres Status beobachten:

An „Last Received“ der Nachricht sieht man, dass Schaltbefehl senden (set) und Änderungen des Status (STATE) nur ca. 150ms auseinander liegen.

Die Zeit zwischen Betätigung des Tasters am Aktor bis zur Meldung per mqtt ist leider etwas länger (ca. 2s). Das liegt allerdings am Aktor selbst und im weiteren Zusammenhang an der 1%-Regel bei 868MHz.

node-red

Beispielhaft verwende ich node-red-dashboard zum Schalten des Aktors.

Man abonniert (subscribe) also das Topic des Status des Aktors und gibt diese msg.payload in einen Dashboard-Switch-Node. Der Switch muss so konfiguriert werden, dass er true und false als String in der on- bzw. off-payload versteht.

Beim Schalten sendet der Switch die konfigurierte Payload an seinen Ausgang und wir senden diese an unser set-Topic (publish).

Wichtig ist, dass ankommende Nachrichten nicht direkt an den Ausgang durchgereicht werden,  da es durch die 150ms Verzögerung beim Schalten zu einer Race-Condition kommen würde. Zum Glück bietet uns der Switch-Node dafür schon eine passende Option:

Der Switch-Node ändert seinen Status durch das eingehende Topic und sendet bei Betätigung die Änderung an das ausgehende Topic.

Conclusion


(die USB-Kamera hat ein wenig Verzögerung)

Damit haben wir erfolgreich Homematic bzw. jedes von homegear zur Verfügung gestellte Gerät an node-red per mqtt angebunden. Wichtig hierbei ist, dass wir dadurch einen eventbasierten Rückweg haben, also auch Schaltaktionen am Aktor selbst oder durch andere gepairte Homematic-Geräte direkt wieder in node-red gemeldet bekommen.

Ein weiterer Weg wäre über das neu in homegear eingeführte node-blue nur bestimmte Variablen der Geräte in mqtt zu publishen. Dazu dann vielleicht mal mehr in einem anderen Artikel.

Im Herbst letzten Jahres habe ich mir zu Hause eine Multiroom Audio Lösung mit dem Logitech Media Server in Verbindung mit node-red zur Automation gebaut. Der Artikel ist aus einem älteren Forenbeitrag entstanden.

Ich habe verschiedene Hardwarelösungen (nanoPi, nanoPiAir und RaspberryPi Zero) qualitäts- und kostentechnisch gegenüber gestellt. Den RasperryPi ZeroW gab es damals noch nicht.

Folgendes Funktionen sind bis jetzt umgesetzt:

  • Abspielen verschiedener Inhalte in verschiedenen Räumen
  • Synchrones Abspielen von einem Inhalt in mehrere Räumen
  • Jeden Player als Airplay-Empfänger nutzen
  • beliebiges ARM-Board/Linux als Squeeze-Player nutzen (RPi, RPi Zero, NanoPiNeo, NanoPiNeoAir jeweils mit USB Soundkarte)
  • Airplay-Geräte als Squeeze-Player nutzen (ginge auch mit Chromecast)
  • DLNA-Geräte als Squeeze-Player nutzen, leider dann nicht synchron möglich wegen Umwandlung
  • Abspielen MP3’s, Webradio, Youtube (Spotify geht, braucht aber einen kostenpflichtigen Account)
  • Anbindung an node-red um Lautsprecher ein/aus zu schalten wenn Musik läuft
  • Anzeige aktueller Titel, Steuerung Player per node-red
  • …more to come

Server

Der Logitech Media Server (Suqeezebox) läuft bei mir auf meinem x86/64 Server, den ich sowieso zu Hause habe. Auf diesem Server liegen auch meine über die Jahre gesammelten MP3’s. Es läuft Ubuntu 16.04.2 und installiert habe ich dann einfach die Debian-Pakete des LMS: http://wiki.slimdevices.com/index.php/Debian_Package
Das Ganze sollte aber genauso auf einem RPi mit einer USB-Festplatte funktionieren.

Der LMS hat ein Webinterface, das sich per http://<ip/host>:9000/ aufrufen lässt. Zugegeben, das ist ziemlich altbacken aber reicht für rudimentäre Bedienung und Konfiguration. Dort wird dann auch das Musikverzeichnis konfiguriert und das Durchsuchen angestoßen. Der LMS ließt die ID3-Tags und kategorisiert die Musik und macht sie durchsuchbar.

LMS selbst lässt sich per Plugins erweitern, auch aus Drittquellen. Dafür gibt es auch eine recht aktive Community. Wichtig waren für mich diese hier: https://github.com/philippe44
Ich betreibe den LMS ohne jeglichen Account (myqueezebox, etc.) – einzig einen Youtube-API Key musst ich bei Google erzeugen um die Youtube-Funktionalität zu nutzen.

Player

Als Player setze ich aktuell einen NanoPiNeo, einen RaspberryPi Zero, ein AppleTV und ein altes Noxon iRadio per DLNA ein. Als tragbaren Player nutze ich den NanoPiNeo Air:

Den NanoPiNeoAir kann ich nur eingeschränkt empfehlen, da mit ihm nur noch sehr schwer SSH-Kommunikation per WLAN möglich ist, wenn per USB Sound ausgegeben wird. Hatte dazu auch ne längere Diskussion im Armbian Forum https://forum.armbian.com/index.php/topic/3269-nano-pi-neo-air-unstable-wi-fi/
Aktuell läuft Ubuntu 16.04.1 bzw Debian Jessie auf den kleinen Dingern. Als Software nutze ich Squeezelite, das ich anhand dieser Anleitung installiert habe: http://www.gerrelt.nl/RaspberryPi/wordpress/tutorial-installing-squeezelite-player-on-raspbian/

Update 2017: Mit dem aktuellen Armbian kommt es kaum noch zu Problemen beim nanoPiAir.

Theoretisch lässt sich als Squeeze-Player auch ein altes Android Telefon nutzen oder ein RPi-1. Jeder Windows PC sollte genauso funktionieren. Ob ein Linux-Sat-Receiver auch geht, hab ich noch nicht geschaut.

Steuerung

Gesteuert werden kann der LMS natürlich durch das bereits erwähnte Webinterface. Richtig Spaß macht es aber erst mit einer passenden App auf dem Handy/Tablet. Unter Android habe ich Squeezer ausprobiert, was seinen Dienst tadellos erfüllt. Allerdings hab ich nur ein sehr sehr sehr sehr günstiges Android-Tablet zum probieren gehabt und ich glaube dadurch alleine blieb der Spaß auf der Strecke.

Schlussendlich habe ich iPeng 9 für iPad/iPhone gekauft. Mit 8,99€ wirklich happig, aber es lohnt sich in jedem Fall. Die App ist ordentlich geschrieben und bedient alle Möglichkeiten des LMS:

iPad

iPhone

node-red

Hier hab ich noch nicht so viel gemacht und nur den Player in der Küche angebunden. Ich prüfe jede Sekunde den mode des players und schalte bei play die Steckdose der Aktivboxen ein. Wenn auf pause gewechselt wird, wird 2 Minuten gewartet und dann die Steckdose wieder aus geschaltet.

Zusätzlich lasse ich noch im Dashboard anzeigen was gerade läuft. Da bin ich aber noch nicht ganz fertig.

(für „only when changed“ kann man natürlich auch den rbe-node nehmen)

Kosten

Kommen wir zum spannenden Teil, wo liegen die Kosten pro Player?

Die nanoPi’s habe ich direkt bei FriendlyElec bestellt, Lieferzeit ca. 3,5 Wochen. Mittlerweilse sind diese aber auch schon in DE bestellbar.

NanoPiNeo (Ethernet)
Board: 10€ (512MB)
SD-Karte 7€ (Sandisk 16GB)
GooBay 5V/2A Netzteil 7€
Generic C-Media USB Sound 3€
—–
28,-€

NanoPiNeoAir (WLan)
Board: 20€
IPEX Antenne ca. 5€
GooBay 5V/2A Netzteil 7€
Generic C-Media USB Sound 3€
(keine SD-Karte notwendig, da internes 8GB eMMC)
—–
35,-€

Präferierte Hardware

Empfehlen mag ich einen Raspberry Pi Zero mit PhatDAC. Der PhatDac ist eine „echte“ Soundkarte für den Rapsberry Pi Zero. Klanglich ist man dabei einfach in einer anderen Welt gegenüber den China-C-Media-USB-Soundkarten, das hört  sogar das ungeübte Ohr.

Raspberry Pi mit PhatDAC und WLan-Stick

Raspberry Pi Zero von thepihut (WLan)
Board: 4,50€ (4£)
PhatDAC 13,70€ (12£)
WiFi USB mini + OTG Adapter 8,50€
SD-Karte 7€ (Sandisk 16GB)
GooBay 5V/2A Netzteil 7€
—–
40,70€

Natürlich kommt da dann immer noch die gewünschte Aktivbox dazu. Für etwas qualitativ hochwertiges, sollte man schon um die 70-80€ ausgeben. Ein Sonos Play 1 ist also Preislich nicht ganz soweit davon entfernt.
Man muss für sich entscheiden ob der Bastellaufwand die Vorteile gegenüber dem Sonos aufwiegt.

Hier eine weitere Idee, wie man den Player schick in einer Regalbox verbauen kann: http://indibit.de/multiroom-audio-wlan-lautsprecher-selber-bauen/ – die Lösung mit den zwei Netzteilen hat mir nicht ganz so gut gefallen.

Update 2017: Durch den RaspberyPi ZeroW kann man die Kosten für den bevorzugten Player noch mal um 2,- € senken. Der ZeroW liegt bei 10,-£ und man benötigt dann eben keinen separaten WLan-Stick mehr.