by ·7 Kommentare

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:

Das Endergebnis sieht dann so aus:

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://smarthome-loewemann.de/p/dmx-bridge-to-loxone

Super Arbeit, Danke!

Update II

Wir haben wieder Ethernet DMX Bridges auf Lager und konnten den Preis sogar um 10,- Euro senken: https://shop.codm.de/module/8/ethernet-dmx-bridge-v0.4

Upate III

Endlich ist es soweit, der Nachfolger der DMX Bridge V0.4 ist im Shop bestellbar: DMX Bridge V0.5 im cod.m GmbH Shop.

Volle 512 Kanäle durch die Nutzung eines ATMega 644p anstatt eines 328p und damit mehr zur Verfügung stehender Speicher.
Natürlich ist es immer noch ein 16MHz Microcontroller und beim gleichzeitigen Dimmen von vielen Kanälen wird es zur Performanceproblemen kommen.

Des weiteren sind wir endlich von den günstigen Schraubklemmen weg 😉

by ·38 Kommentare

Bluetooth BLE Sensor Node

Zusammen mit Techdata haben wir bei cod.m auf Basis des Giess-o-Mats einen Bluetooth Low Energy-Bodenfeuchtesensor (soil moisture sensor) gebaut und an die IBM BlueMix Cloud angebunden: https://ibm.techdata.de/weitere-informationen/smart-garden

Technisch misst ein kaskadierter Schmitt-Trigger die Frequenz an den beiden Kontaktflächen, die im Erdreich sitzen. Anhand dieser Frequenz kann eine Aussage über die Bodenfeuchte getroffen werden.
Die Sensoren laufen mit CR2032 Knopfzellen und bilden ein Bluetooth-Mesh. Auf einem RaspberryPi befindet sich ein weiterer Node, der das Mesh zugänglich macht und die Daten an die BlueMix Cloud sendet.

Das zur Präsentation und Proof-of-Concept geplante Projekt hat doch ein wenig Aufmerksamkeit erzeugt 😀

Um nicht auf Batterien angewiesen zu sein, haben wir uns Gedanken gemacht, wie man einen solchen Sensor kabelgebunden realisieren könnte. Die Entscheidung fiel hier recht schnell auf 1-Wire, da man damit ohne großen Implementations- und Verkabelungsaufwand einen Bus mit bis zu 100 Metern aufbauen kann. Außerdem haben wir damit durch andere Projekte genug Erfahrung und können bei dieser Idee darauf bauen. Zusätzlich hatte ich zwischenzeitlich die vorzügliche OneWireHub-Bibliothek gefunden, mit der man ohne große Probleme 1-Wire-Devices emulieren kann.

Da wir ja auch mit der Loxone-Welt recht verbunden sind, haben wir uns für die Emulation eines DS2438 entschieden. Der DS2438 ist eigentlich ein Batteriewächter, der neben Temperatur auch Spannungen von 0.00-10.00V messen und übertragen kann – damit hätten wir 0-100% als Wert. Dieser Baustein wird bereits bei vielen Fühlerprojekten im Loxone-/1-Wire-Universum genutzt und kann ohne Probleme über die 1-Wire-Extension an den Miniserver angebunden werden. Natürlich auch an jeden anderen Master, der mit dem DS2438 klar kommt (owfs, etc.).

Smart Garden 1-Wire Sensor Node V0.2

Die Platine wurde so klein wie möglich gehalten und im Prototyp mit passiven Bauteilen der Größe 1206 gefertigt. Auf der 1-Wire Seite des Sensors haben wir außerdem einen MAX9940 zum Schutz des Microcontrollers verbaut. Der Sensor benötigt eine eigene 5V-Stromversorgung da eine parasitäre Speisung aufgrund des Stromverbrauchs des Microcontrollers nicht in Frage kam.

Ein weiteres Problem war, dass jedes 1-Wire-Gerät eine (weltweit) eindeutige Seriennummer hat und diese Seriennummer auch nicht doppelt auf dem Bus vorkommen darf, weil die einzelnen Geräte darüber adressiert werden. Da der DS2438 auch einen Temperaturfühler integriert hat, haben wir kurzerhand einen DS18B20 mit auf die Platine gepackt, um erstens die Temperatur zu messen und um uns zweitens die MAC (Seriennummer) zu „borgen“. Nach Anpassung des Family-Codes haben wir damit wieder eine eindeutige Seriennummer, die uns erlaubt mehrere Sensoren pro Bus zu nutzen. Natürlich könnte man auch einfach eine beliebige Seriennummer vergeben, hätte aber eben dann das Problem, dass man jeden Sensor einzeln mit einer eigenen MAC programmieren müsste.

Nun möchte man ja, wenn möglich dass die Sensoren lange halten, sowie Wind und Wetter trotzen. Wir arbeiten gerade daran, die Platine komplett nach IP67 zu vergießen, sodass man sie sogar vergraben könnte. Das Problem, welches damit einhergeht ist, dass man dann keine Software mehr auf den Microcontroller spielen kann oder anderweitig eine Konfiguration vornehmen kann – außer eben über die nach Außen geführte 1-Wire-Schnittstelle…
Auch dazu haben wir eine Lösung erarbeit: Der DS2438 hat neben seiner Funktion als Batteriewächter und Temperaturfühler auch einen über 1-Wire beschreibbaren Speicherbereich – „40-byte nonvolatile user memory“. Das 1-Wire Protokoll erlaubt es, diesen Speicher zu bedienen und so können wir darin Konfigurationsparameter ablegen und der Microcontroller kann diese verwerten. Dadurch haben wir die Möglichkeit, gemessene Frequenzen als „trocken“ oder „feucht“ zu definieren. Je nach vorhandenem „Erdreich“ kann die Messung des Sensors nämlich variieren. In Pflanzenerde beispielsweise ist ein anderer Zustand „feucht“ als in einem Glas Wasser.

Wir dachten uns, dass diese Konfiguration am besten über ein Mobilgerät erfolgen sollte. Es gibt also nun ein ESP8266 basiertes Gerät, mit dem man sich per WLAN verbindet. Dieses Interface wird statt dem 1-Wire-Master am Bus angeschlossen und man kann damit jeden Sensor kontrollieren und konfigurieren. Zum Beispiel kann man den Sensor, der ja nur durch seine Seriennummer identifiziert wird, blinken lassen, um ihn zu lokalisieren. Zusätzlich kann man festlegen, ob er bei der Messung generell blinken soll und natürlich die oberen und unteren Frequenz-Grenzwerte für feucht/trocken speichern.

Smart Garden Konfigurationsinterface

Für die Zukunft ist durchaus geplant, dass das Konfigurationsgerät ein eigenständiges Gateway mit MQTT- oder HTTP-Anbindung sowie eigenem Status-Webinterface wird. Der Anbindung an Systeme ohne eigene 1-Wire-Schnittstelle steht damit nichts mehr im Wege.

Schlussendlich ist der Sensor also nichts anderes als ein ATMega328p, ein kapazitiver Bodenfeuchtesensor und ein DS18B20 zur Temepraturmessung. Die Software wie auch die Hardware werden als Open-Source veröffentlicht werden und so könnte sich jeder auch den Sensor selbst bauen 👍

Der Sensor wird, sowie er fertig ist, bei uns im Shop verkauft. Bis dahin halte ich euch natürlich weiter auf dem Laufenden und freue mich über eure Anregungen und euer Feedback.

Update

Die Produktionsprototypen der Sensoren sind fertig. Das erste Mal im VQFN-Package gelötet und es sieht gut aus!

Im Bild ist auch der oben erwähnte Hub zu sehen. Damit können – wenn benötigt – die Grenzwerte, Intervalle, etc. der Sensoren konfiguriert werden.

by ·8 Kommentare

Im Loxone-Forum haben findige Leute, unter anderem Robert L., an einer günstigen Möglichkeit gearbeitet aus einem Arduino mit Ethernet-Shield und RS485-Wandler einen DMX-Controller mit Netzwerkanschluss zu bauen.

Die erste Idee bestand in der Anbindung an den Loxone Miniserver als Ersatz für die offizielle DMX-Extension mit der Nutzung eines „Virtuellen Ausgangs“ per UDP. Natürlich funktioniert das auch mit jedem anderem System – zum Beispiel node-red oder alles was UDP spricht.
Durch UDP gibt es ja bekanntermaßen keinen TCP-ACK, wodurch Overhead vermieden wird aber auch nicht sicher gestellt werden kann, dass ein Datenpaket auch wirklich ankommt. Bei einer Dimmersteuerung ist es allerdings unerheblich, ob von 100 Paketen die eine Dimmkurve beschreiben, nur 97 ankommen.

Der Original-Code ist übrigens genauso auf einem ESP8266 lauffähig und Robert L. hat sogar extra eine angepasste Version für den günstigen H801 (ESP8266) WLAN-Dimmer geschrieben, der direkt LED’s anteuern kann und keinen separaten DMX-Dimmer mehr benötigt.

Die Nutzer im Forum haben viele Unzulänglichkeiten der original DMX-Extension zu Tage gefördert und sich vielfach für die Lösung von Robert L. ausgesprochen.
In der Elektroverteilung ist WLAN eher weniger zuträglich und ich suchte schon lange nach einer Möglichkeit endlich mal selbst Ethernet auf einer Platine zu implementieren und hatte damit das passende Projekt gefunden.

Der Prototyp

Offensichtlich hatte ich mir viel vorgenommen als im Forum kund tat, dass ich eine Open-Source Platine (CC-BY-SA) Version der Platine designen, produzieren sowie bestücken und zum Verkauf anbieten könnte.

Allein der Aufbau des Prototyps war recht anspruchsvoll, was man im oberen Bild recht anschaulich sieht. Zum Testen habe ich mir auf ebay einen günstigen 3-Kanal-DMX-Dimmer bestellt, da ich keine eigene DMX-Installation besitze.

Den originalen Code habe ich nur ein wenig aufgeräumt und um die später erwähnte EEPROM-Funktion erweitert. Die Ethernet-Verbindung habe ich um DHCP erweitert, was dann auch die default Einstellung sein wird.

Schaltung

Über die letzten Wochen und vor allem am letzten Wochenende durfte ich dann am eigenen Leib (Zeit) feststellen wie viel Arbeit in sowas steckt. Dies ist (bis jetzt) meine bei Weitem komplexeste Schaltung!

Explizit möchte ich aber hier noch mal die Hilfe aus dem Loxone-Forum erwähnen, ohne deren Input die Umsetzung so nicht möglich gewesen wäre. Beim Ethernet Teil mit WizNet’s W5500 konnte ich mich zum Glück beim Layout des W5500 Ethernet Shields bedienen, das als Open-Source frei verfügbar ist.

Ethernet DMX Bridge Schaltung

Der W5500 ist die zweite Weiterentwicklung des im üblichen Arduino Ethernet Shield verbauten W5100. Zusammen mit Paul Stoffregen’s exzellenter Arduino Ethernet Bilbiothek, die ursprünglich für den Teensy entwickelt wurde, merkt man die erhöhte Verarbeitungsgeschwindigkeit deutlich. Direkte vergleiche mit der „alten“ Hardware müssen den subjektiven Eindruck natürlich noch bestätigen.

Paul’s Ethernet Bibliothek hat mehrere Vorteile. Darunter unter anderem die komplette Auto-Erkennung des verwendeten W5x00, vor allem aber die bessere Verarbeitung in der Bibliothek selbst:

Wiznet socket registers are cached, which greatly reduces SPI communication overhead, at the cost of a small increase in RAM usage. TCP connections and UDP packets accessed in small chunks typically see a substantial performance boost.

Zusätzlich habe ich noch ein 24AA025E48 EEPROM von Microchip in die Schaltung integriert. Der Speicher des EEPROMs wird zwar nicht genutzt, aber es bringt eine EUI-48 ID mit die als weltweit eindeutige MAC-Adresse für das Ethernet-Interface genutzt werden kann. Anregung dafür fand ich bei Freetronics, einem australischen Arduino-Produzenten.
Die WizNet Chips haben von Hause aus keine MAC-Adresse. Sie bringen mittlerweile zwar eine mit, diese ist aber ein Aufkleber auf der Platine und damit nicht wirklich nützlich für den Code auf dem Microcontroller.
Im Normalfall initialisiert man die Ethernet-Bibliothek einfach mit einer beliebigen MAC-Adresse, was für das lokale LAN absolut ausreichend ist. Wenn man aber im selben LAN mehrere gleiche Geräte verwenden möchte, muss man für jedes die Addresse anpassen und somit eine eigenen Software kompilieren. Dieser Aufwand entfällt durch die Nutzung der EUI-48 ID des EEPROMs, was auch die „out of the box“-Nutzung genau genommen erst möglich macht.

Die Spannungsversorgung wird zwischen 24V und 5V wählbar sein. In der 5V Version wird der OKI-78 Spannungswandler entfallen, wodurch man bei dieser Version noch ein paar euro sparen kann.

Platine, Gehäuse und BOM

Nach der Schaltung ging es dann an das Layout der Platine. Ich würde behaupten, dass dies der dickste Batzen arbeit war.

Da die Platine im Labor eines befreundeten Prototypenherstellers entstehen und „gebacken“ wird, habe ich mich für handbestückungsfreundliche SMD-1206 Bauteile entschieden.

Phönix Contact BC 35,6

Der Anspruch war, keine Gehäusebearbeitung nötig zu machen um auch Nicht-Bastlern die Möglichkeit zu geben die Ethernet-DMX-Bridge zu nutzen und zusammen bauen zu können. Der Gewinner ist das hervorragende Phönix Contact BC 35,6 2TE Hutschienengehäuse. Hier auch ein Dank für die unkomplizierte Zusendung von Mustern um die verschiedenen Gehäusetypen auszuprobieren und die vorzügliche Beratung des Vertrieblers.

Ich habe den UART sowie den ISP des ATMega328p nach außen geführt. Der UART wird benötigt um eine Programmierung per Arduino-IDE zu ermöglichen. Als Pin-Belegung habe ich mich für die Anordnung des FOCA FTDI Adapters entschieden, die mir über DTR auch den Auto-Reset des ATMega zur Programmierung erlaubt.

Ein integrierter FTDI-Chip entfällt aus Kostengründen. Außerdem ist die Programmierung ja nur einmalig – wenn überhaupt – nötig. Mit Jumperkabeln kann man natürlich auch jeden anderen USB-FTDI-Adapter nutzen. Wenn der eigene Adapter kein DTR-Signal zur Verfügung stellt, reicht ein manueller Reset der Schaltung während des Programmierens um im Arduino-Bootloader zu landen und damit den Sktech zu übertragen.
Mit dem ISP spiele ich den Arduino-Bootloader auf und er bietet natürlich auch die Möglichkeit der direkten Programmierung der MCU.

Ethernet DMX Board Layout

Die Platinen sind mittlerweile bei OSHPark bestellt und bereits auf dem Weg in die Produktion.

Als nächstes war also das „sourcen“ der knapp 60 Bauteile dran – das alleine war eine abendfüllende Angelegenheit.
Ich habe DigiKey, RS-Components und Reichelt nebeneinander gestellt. Die meisten Bauteile werde ich bei DigiKey bestellen, weil es dort die besseren Rabatte bei SMD-1206 gibt und auch Markenhersteller wie Murata und Panasonic vorrätig sind. Reichelt liegt bei manchen Bauteilen vorne und bekommt auch einen Teil der Bestellung ab. RS-Components war entweder nur vergleichbar oder teuerer – einzig bei der Netzwerkbuchse hätte ich etwas sparen können. Allerdings wäre der Vorteil durch die Versandkosten wieder aufgefressen worden.

Ausblick

Die ersten Boards werde ich im Loxone-Forum anbieten und bin gespannt, wie die Erfahrungen und Rückmeldungen aussehen. Das Board wird mit Gehäuse (optional) zukünftig im geplanten cod.m-Webshop bestellbar sein.

Achso, hier natürlich noch das Ganze in Aktion 😀

Ich bin wirklich begeistert wie „responsive“ alles ist. Zu sehen übrigens das Loxone-Webinterface, Anbindung dann über virtuellen Ausgang per UDP.

Wie immer gilt, bei Fragen, Feedback und Kritik, immer gerne melden.

Update

Mittlerweile sind die gefertigten Platinen eingetroffen und es sieht wirklich gut aus. Werde die Tage dann mal die Teile bestellen um das Ganze zu bestücken.

Update II

Die Platinen sind mittlerweile bestückt. Leider hat sich, wie bei einem ersten Prototyp ja fast üblich, ein Fehler eingeschlichen. Mit einem Quick-Fix funktioniert aber alles und ich bin wirklich ein wenig stolz 😉

Mittlerweile habe ich V0.3 des Layouts fertig. Ich werd noch ne Nacht drüber schlafen und diese dann in Produktion geben. Wenn diese dann funktionieren, steht einer kleinen Serie nichts mehr im Wege.

Update III

Mittlerweile ist ja etwas Zeit vergangen und wir haben sie genutzt: Unsere WEEE-Registrierung, damit man in Deutschland offiziell Elektronik verkaufen darf, ist auf dem Weg und sollte in den nächsten Wochen bewilligt sein. Die CE Konformitätserklärung für die Ethernet DMX Bridge ist so gut wie fertig.

Das Wichtigste allerdings ist, dass wir nächste Woche einen Termin beim Bestücker haben um die Bauteile maschinell bestücken zu lassen. Dazu mussten wir einen Nutzen produzieren lassen und können nun eine Kleinserie herstellen:

Update IV

Es ist soweit! Die Hardware ist fertig und steht zum Verkauf. Alles Weitere findet ihr im Shop: https://shop.codm.de/module/8/ethernet-dmx-bridge-v0.4

by ·Ein Kommentar

Im Oktober habe ich eine Crowdfunding Kampagne gestartet, um meinen eigenen Miniserver für die Weiterentwickling von node-red-contrib-loxone zu ermöglichen. Das war nötig, da der bis dahin geliehene Miniserver von seinem Besitzer, einem befreundeten Elektriker und Loxone-Partner, zurück benötigt wurde, um eine Testumgebung für ein Kundensystem aufzubauen.

Durch das viele Feedback auf die Entwicklung von node-red-contrib-loxone im LoxForum habe ich mich bestärkt gefühlt, es ein mal mit einem Crowdfunding über GoFundMe zu versuchen. Ich war überwältigt! Innerhalb von 2 Tagen wurden 343,- € gespendet und unzählige Hilfs- und Unterstützungsangebote wurden gemacht. Ich habe viele Leute, deren Namen ich nur kannte, kennengelernt und viele Telefonate geführt. Die nötige Differenz zum eigentlichen Preis habe ich dann noch selbst beglichen und den Fundraiser entsprechend beendet.

Vielen VIELEN Dank an alle Unterstützer – egal auf welchem Weg!

Natürlich gab es auch Kritik, die sich aber, so zumindest meine Wahrnehmung, schnell aus der Welt schaffen ließ. Der Node-Red-Node ist Open-Source und jeder kann ihn durch die MIT-Lizenz kostenlos, auch in kommerziellen Projekten, einsetzen. Die Entwicklung findet für jedermann einsehbar auf GitHub statt und wer möchte, kann (und sollte?) sich an der Verbesserung des Codes und der Dokumentation beteiligen. Ich freue mich über jedwede Kritik 🙂

Auch nach dem „einfrieren“ der GoFundMe-Seite haben sich viele Leute beschwert, dass sie nichts mehr spenden konnten. Ich habe mich also entschlossen, die Kampagne wieder zu eröffnen und jedem die Möglichkeit zu geben mich, auch nach erfolgreicher Finanzierung des Miniservers,  weiterhin ein wenig bei der Arbeit an node-red-contrib-loxone zu unterstützen: https://www.gofundme.com/miniserver-fur-nodered-entwicklung

Nochmal, vielen Dank an ALLE – ihr seid der Knaller!

 

by ·10 Kommentare

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.

Update

Sebastian Hehn hat in seinem Blog sehr anschaulich und für Anfänger verständliche Verwendung von Alexa mit Loxone über node-red gezeigt – Super!

Amazon Echo steuert Loxone Smart Home via Node-RED