Ich betreibe derzeit eine Vielzahl von Logiken auf einem (alten) Wiregate, zusätzlich ein paar Daemons, hier mal eine kleine Auflistung.
Standalone daemons:
Das ist über die letzten 6 Jahre einfach so gewachsen und vieles wurde einfach gemacht, weil es verfügbar war oder sich aus bestehenden Information herleiten ließ. Von der Wartbarkeit ist es natürlich eine Katastrophe. Das meiste (aber nicht alles, z.B. homebridge-knx) läuft derzeit noch auf dem WG. Da Lenny aber schon in die Jahre gekommen ist, habe ich zunehmend Probleme noch neuere Projekte zu integrieren oder (Bug)Fixes für die alten Versionen zu kommen. Deshalb bin ich seit einer Weile auf der Suche nach "etwas Neuem". Es mag sein, dass vieles davon mit dem Wiregate-Nachfolger möglich sein wird, aber da ich ein großer Freund von OpenSource bin, habe ich beschlossen, mich nach Alternativen umzuschauen. Generell wollte ich weg von der Vielfalt der unterschiedlichen Programmiersprachen und Anbindungen. Nach langer Suche bin ich nun bei "node-red" hängengeblieben. Das ist ein nodejs basiertes Framework mit genialem UI und vielen vorhandenen nodes als Gateways zu den unterschiedlichsten Projekten. Als kleinsten gemeinsamen Nenner könnte man immer mqtt nehmen, einen universellen Messagebus. Den habe ich aber für meine Anwendungen bisher noch nicht gebraucht und konnte mit node-red "Hausmitteln" alles realiseren. Wer den visuellen Logikeditor des GIRA Homeserver kennt, der wird sich sofort mit node-red anfreunden können. Doch anstatt nur vorgefertigte Blöcke mitzubringen, lässt sich an jeder Stelle ein "Funktionsblock" mit Javascript einfügen. Dadurch behält man die Flexibilität einer Scriptsprache gekoppelt mit fertigen Gateways für die unterschiedlichsten Anwendungen. Aufgesetzt habe ich das ganze auf einem Raspberry Pi 3 mit Ubuntu Xenial (wohlgemerkt nicht basierend auf einem fertigen Image, einfach plain vanilla Ubuntu).
Was ich innerhalb von 2 Abenden komplett Nachbauen konnte waren:
homebridge-knx werde ich vermutlich erstmal separat laufen lassen (auf dem gleichen RPi). Es gibt zwar auch eine node-red Integration, aber hier sehe ich im Moment keinen Mehrwert.
Und hier mal ein paar Screenshots von ein paar Flows: node-red-screenshot-knx.png
Empfang von KNX Telegrammen. Der Switch gibt mir an Output 2 nur "writes" aus, mit dem GA Filter schaue ich auf GA's die mich in meinen Flows interessieren und gebe die per "link" in den entsprechenden Flow weiter. Genauso kommen per "link" diverse messages aus anderen Flows an, die per Funktion in das richtige Format gebracht werden und dann auf den Bus gesendet werden.
node-red-screenshot-artnet.png
Die 4 "link"-Inputs links kommen vom KNX Flow und repräsentieren die 4 GA's für RGBW-Steuerung. Mit einer Queue verhindere ich zuviele Daten auf einmal, mache daraus eine einzelnes Message mit RGBW Werten und schicke die ins Netz zum ArtNet node.
node-red-screenshot-enocean.png
Hier werde ich noch einem nativen enOcean Input arbeiten, derzeite nehme ich die "Hello World" Applikation aus dem eoLink SDK und parse deren Output. Die Werte werden dann an den Bus gesendet.
node-red-screenshot-funksteckdosen.png
Obwohl ein fertiges nodejs Project für CUL gibt, steuere ich hier direkt den seriellen Port an. Die Befehle sind wirklich simpel und meine kruden Baumarkt Steckdosen folgen sowieso keinem Standard.
Bei den Screenshots habe ich mir Mühe gegeben, dass man in der Spalte links immer unterschiedliche Nodes für Input, Output und Funktionen sieht, damit man einen Eindruck bekommt, wie mächtig und gleichzeitig simpel das Ganze ist.
Ich werde hier immer mal von meinen Erfahrungen und dem Stand der "Migration" von node-red berichten. Falls dabei Flows zustande kommen, die über ein bisschen Klicken hinausgehen, werde ich diese veröffentlichen. Hier mal ein Beispiel mein "Intertechno" Funktion:
Das ist wirklich kein schöner Code, man kann noch viel optimieren, aber es gibt einen Eindruck wie einfach man hier Zusammenhänge herstellen kann.
Ganze vergessen, node-red findet man hier: https://www.nodered.org/ einen Überblick über vorhandene Nodes und Flows gibt es hier: https://flows.nodered.org/
Standalone daemons:
- knxdmxd (zur Steuerung eines ArtNet nodes mit RGBW Bändern)
- dafür notwendigerweise olad für DMX <-> ArtNet
- fhem zur Kopplung von
- enOcean (Hoppe Fenstergriffe): enOcean -> KNX
- CUL (InterTechno schaltbare Steckdosen), KNX -> CUL
- eHZ Reader (befüllt derzeit nur RRDs)
- Wiregate Plugins für:
- Zentralfunktionen für Anwesenheitserkennung
- simple Logikfunktionen und Verknüpfung von Elementen die als Szene nicht realisierbar waren
- Abruf Wetterdaten von Unwetterzentrale und Senden von Warnungen an KNX
- Abruf Wetterdaten von Weather Underground und Aufbereitung für die Visu (CometVisu)
- diverse Schaltuhren (uhrzeitabhängige Aktionen)
- diversen Kleinkram
- homebridge-knx für Apple HomeKit / Siri Integration
- Miele@Home Gateway
- NIBE RS422 Gateway
Das ist über die letzten 6 Jahre einfach so gewachsen und vieles wurde einfach gemacht, weil es verfügbar war oder sich aus bestehenden Information herleiten ließ. Von der Wartbarkeit ist es natürlich eine Katastrophe. Das meiste (aber nicht alles, z.B. homebridge-knx) läuft derzeit noch auf dem WG. Da Lenny aber schon in die Jahre gekommen ist, habe ich zunehmend Probleme noch neuere Projekte zu integrieren oder (Bug)Fixes für die alten Versionen zu kommen. Deshalb bin ich seit einer Weile auf der Suche nach "etwas Neuem". Es mag sein, dass vieles davon mit dem Wiregate-Nachfolger möglich sein wird, aber da ich ein großer Freund von OpenSource bin, habe ich beschlossen, mich nach Alternativen umzuschauen. Generell wollte ich weg von der Vielfalt der unterschiedlichen Programmiersprachen und Anbindungen. Nach langer Suche bin ich nun bei "node-red" hängengeblieben. Das ist ein nodejs basiertes Framework mit genialem UI und vielen vorhandenen nodes als Gateways zu den unterschiedlichsten Projekten. Als kleinsten gemeinsamen Nenner könnte man immer mqtt nehmen, einen universellen Messagebus. Den habe ich aber für meine Anwendungen bisher noch nicht gebraucht und konnte mit node-red "Hausmitteln" alles realiseren. Wer den visuellen Logikeditor des GIRA Homeserver kennt, der wird sich sofort mit node-red anfreunden können. Doch anstatt nur vorgefertigte Blöcke mitzubringen, lässt sich an jeder Stelle ein "Funktionsblock" mit Javascript einfügen. Dadurch behält man die Flexibilität einer Scriptsprache gekoppelt mit fertigen Gateways für die unterschiedlichsten Anwendungen. Aufgesetzt habe ich das ganze auf einem Raspberry Pi 3 mit Ubuntu Xenial (wohlgemerkt nicht basierend auf einem fertigen Image, einfach plain vanilla Ubuntu).
Was ich innerhalb von 2 Abenden komplett Nachbauen konnte waren:
- ArtNet-Ansteuerung, ersetzt olad und knxdmxd
- enOcean "read" Gateway (Empfang von enOcean Telegrammen und Umsetzungen in KNX), ersetzt fhem
- CUL "write" Gateway (Empfang von KNX Telegrammen und Umsetzung in Intertechno Schaltbefehle), ersetzt fhem
- ein paar einfache Logiken, die sukzessive die Wiregate-Plugins ersetzen werden
- eHZ (vermutlich über serialinput Plugin lösbar)
- Miele@Home Gateway (noch nicht weiter geprüft)
- NIBE RS422 Gateway (vermutlich über serialinput Plugin lösbar)
homebridge-knx werde ich vermutlich erstmal separat laufen lassen (auf dem gleichen RPi). Es gibt zwar auch eine node-red Integration, aber hier sehe ich im Moment keinen Mehrwert.
Und hier mal ein paar Screenshots von ein paar Flows: node-red-screenshot-knx.png
Empfang von KNX Telegrammen. Der Switch gibt mir an Output 2 nur "writes" aus, mit dem GA Filter schaue ich auf GA's die mich in meinen Flows interessieren und gebe die per "link" in den entsprechenden Flow weiter. Genauso kommen per "link" diverse messages aus anderen Flows an, die per Funktion in das richtige Format gebracht werden und dann auf den Bus gesendet werden.
node-red-screenshot-artnet.png
Die 4 "link"-Inputs links kommen vom KNX Flow und repräsentieren die 4 GA's für RGBW-Steuerung. Mit einer Queue verhindere ich zuviele Daten auf einmal, mache daraus eine einzelnes Message mit RGBW Werten und schicke die ins Netz zum ArtNet node.
node-red-screenshot-enocean.png
Hier werde ich noch einem nativen enOcean Input arbeiten, derzeite nehme ich die "Hello World" Applikation aus dem eoLink SDK und parse deren Output. Die Werte werden dann an den Bus gesendet.
node-red-screenshot-funksteckdosen.png
Obwohl ein fertiges nodejs Project für CUL gibt, steuere ich hier direkt den seriellen Port an. Die Befehle sind wirklich simpel und meine kruden Baumarkt Steckdosen folgen sowieso keinem Standard.
Bei den Screenshots habe ich mir Mühe gegeben, dass man in der Spalte links immer unterschiedliche Nodes für Input, Output und Funktionen sieht, damit man einen Eindruck bekommt, wie mächtig und gleichzeitig simpel das Ganze ist.
Ich werde hier immer mal von meinen Erfahrungen und dem Stand der "Migration" von node-red berichten. Falls dabei Flows zustande kommen, die über ein bisschen Klicken hinausgehen, werde ich diese veröffentlichen. Hier mal ein Beispiel mein "Intertechno" Funktion:
Code:
if (msg.payload.dstgad === "0/0/65") {
if (msg.payload.value === 0) {
newMsg = { topic: "Lichterkette", payload: "is0FFF0F0FFFF0\n" };
} else {
newMsg = { topic: "Lichterkette", payload: "is0FFF0F0FFFFF\n" };
}
node.send(newMsg);
} else if (msg.payload.dstgad === "0/0/69") {
if (msg.payload.value === 0) {
newMsg = { topic: "Weihnachtsbaum", payload: "is0FFF0F0FF0F0\n" };
} else {
newMsg = { topic: "Weihnachtsbaum", payload: "is0FFF0F0FF0FF\n" };
}
node.send(newMsg);
}
return [null, msg];
Ganze vergessen, node-red findet man hier: https://www.nodered.org/ einen Überblick über vorhandene Nodes und Flows gibt es hier: https://flows.nodered.org/
Kommentar