Use Cases: node-red-contrib-ccu-jack

[ptweety]

Hallo zusammen,

ich bin ein ziemlicher Fan des CCU-Jack und mag auch sehr gerne mit NodeRed arbeiten. Letzteres als Automatisierung- und Integrations-Schicht für diverse Gerätschaften.

Bisher bringe ich das zusammen, indem ich ein paar der Standard Nodes zusammen mit ein wenig JavaScript in Functions verbinde. So langsam kommt bei mir aber der Wunsch auf, das ganze in einen echten node-red-contrib-ccu-jack Node zu gießen, um das auch jederzeit über die Palette installieren zu können.

Also habe ich mal meine Use Cases angeschaut und auf dieser Basis Gedanken gemacht, was mein Node denn so alles können sollte. Kurz gesagt habe ich eigentlich nur Interesse an einem Zwischenspeicher und an Geräte-Updates, aber nicht an Programmen und Systemvariablen. Aber vielleicht ist es ja nicht nur für mich interessant. Daher möchte ich hier mal nachfragen, wer daran Interesse hätte und welche Ideen in eine Umsetzung noch einfließen könnten.

Meine Use Cases:

• Ich sende alle Datenpunkte an InfluxDB und reichere diese mit ein paar Infos aus einem Cache an. (1), (2)
• Ich abonniere einige Datenpunkte via node-red-contrib-ccu und nutze diese Trigger für die Lichtsteuerung. (1), (2), (4)
• Ich lasse meine eigene HomeKit Integration über NRCHKB laufen, dafür brauche ich manchmal mehr als einen Datenpunkt bei eingehender MQTT-Nachricht. (1), (2), (4), (8)

Anforderungen an eine Implementierung:

1. Cache, welcher die Daten des CCU-Jack per VEAP Protokoll abfragt und lokal vorhält.
2. Eingehende MQTT-Nachrichten anreichern (devices, virtual devices)
3. Eingehende MQTT-Nachrichten anreichern (sysvars, programs)
4. Ausgehende Nachrichten filtern (devices, virtual devices)
5. Ausgehende Nachrichten filtern (sysvars, programs)
6. Ausgabe aus Cache bei Start unterdrücken
7. Ausgabe nur bei geänderten Werten im Datenpunkt
8. Ausgabeformat anpassbar gestalten / einzelner Datenpunkt vs. alle Datenpunkte eines Kanals
9. Ausgabe verzögern und gruppieren
10. MQTT-In integrieren (der Nutzer muss keinen extra Node anbinden) (ist es das Wert?)
11. MQTT-Out integrieren (ist mir eigentlich zu viel Arbeit, wegen Input-Validierung)

Was mir also für mich selber vorschwebt ist quasi eine Art rpc-event und ggfs. ein set-value Node (um in der Sprache von node-red-contrib-ccu zu bleiben). Selber habe ich keinen Bedarf an sysvar und program Nodes. Vorstellen kann ich mir auch noch den switch Node.

Also, wie sehen andere das Thema?
Welche Use Cases gibt es so bei euch?

Ach ja, ich will möglichst nah an Nodejs LTS bleiben. Das schließt leider fast automatisch RedMatic aus, solange es dort noch kein Update gibt

[Henke]

Vielleicht kann ich da mit der einen oder anderen Node helfen. Ich nutze keine Node mehr von RedMatic.

Mein Use Case:
1. Start: Mit einem Script hole ich mir über http Grundwerte der Installation wie Räume, Gewerke, Enums, Min/Max, Typ etc. der Datenpunkte.
2. Abfrage über einen MQTT Datenpunkt wobei das noch Aufgeteilt ist auf "virtdev/status/", "device/status" und Shellys
3. Aufbereiten und Cachen der Nachrichten, so dass fast das gleiche Datenformat wie bei RedMatic raus kommt. Aber es gibt z.B. nur noch iface und kein interface mehr.
4. Kontrolle der Nachrichten auf Min/Max, Alarmmeldungen, etc.
5. Weiterleiten der Nachrichten an entsprechende Subflows, die ziemlich gleich zu handhaben sind wie die von RedMatic. node-red-contrib-sub-link ist genial.
6. Ausgabe der Daten über MQTT

Das ganze sieht also nachher ziemlich ähnlich aus, wie RedMatic, nur das mir viele Standard durch die Nodes abgenommen werden. Beispiel: Nur senden, wenn sich der Wert geändert hat.

Alle 11 deine Punkte sind realisiert, aber es ist nicht für eine Veröffentlichung und einfache Installation optimiert. Wenn du es dir ansehen/testen möchtest, lasse ich dir gerne die Nodes zukommen.

Zusätzlich dazu noch die komplette Unabhängigkeit von RedMatic, eine komprimierte Speicherung des Caches jede Stunde/einmal am Tag und der interessanten Langzeitdiagramme. Filter, die Tagesdurchschnitt (zeitliche Bewertung) berechnen, Swinging Door Filter usw.

[ptweety]

Vielleicht kann ich da mit der einen oder anderen Node helfen. Ich nutze keine Node mehr von RedMatic.
...
Alle 11 deine Punkte sind realisiert, aber es ist nicht für eine Veröffentlichung und einfache Installation optimiert. Wenn du es dir ansehen/testen möchtest, lasse ich dir gerne die Nodes zukommen.

Ha, also bin ich damit nicht so ganz allein hier. Gerne kannst du mir das per PN senden ... bin gespannt.

[Zwenjo]

Was hat man denn für Vorteile, wenn man den CCU–Jack benutzt? Bisher bin ich eigentlich mit Redmatic gut zurecht gekommen.

[Henke]

Redmatic wird leider nicht mehr gepflegt, so das man eine Anbindung des CCU-Jacks (virtuelle Geräte), eine aktuelle Version von NodeRed und Fehler/Erweiterungen selber installieren/warten muss.
Redmatic ist eine Anbindung an die CCU und sobald andere, nicht Homematic, Geräte wie z.B. Shellys hinzukommen, müssen diese erst über Umwege in die CCU eingebunden werden (Cuxd,Jack,etc.). Da macht es der CCU-Jack einem schon ziemlich einfach und er kann viel mehr und das extrem flott.

Von da aus war bei mir der nächste Schritt, alles über MQTT zu machen recht schnell und so habe ich nur noch eine IO Schnittstelle. Sollte irgendwann ein Gerät kommen, das nicht über MQTT verfügt, ist es recht einfach die Daten in MQTT umzuwandeln und schon laufen alle Nodes/Subnodes wieder. Bei vielen Interfaces (Fritzbox, Apple Homekit, Whatsup, Email) mach es jedoch noch nicht mal Sinn, da es weniger Geräte als Input/Output Komponenten sind. Diese laufen auch bei mir als normale Nodes.

[ptweety]

Hallo nochmal,

ich habe aus meinem bisherigen Setup mal was zusammen gebastelt und würde gerne ein erstes Feedback einholen.

Die folgenden Screenshots zeigen aus meinen obigen Anforderungen die mögliche Umsetzung der Punkte (1), (2), (4), (6) und (7). Der Code ist allerdings noch nichtmal Alpha-Qualität und daher leider nicht zum Test verteilbar.

Der erste Flow zeigt die Jack Bridge, welche die Konfiguration verwaltet und die Anbindung via MQTT unterstützt.

Der erforderliche MQTT IN node sollte dynamisch konfiguriert werden. Damit kann die Verbindung zum MQTT Broker des CCU-Jack nach Abruf aller relevanten Daten über das VEAP-Protokoll aus der Jack Bridge angestoßen werden.

Die Bridge selber ist recht einfach aufgebaut und fungiert als Brücke zum eigentlichen Herzstück.

Und das ist nun dieser hier. Im Config node steckt die Verbindung mit dem CCU-Jack drin und letztlich auch die meiste Logik inkl. des Caches.

Weiter geht es mit dem zweiten Flow. Hier ist ein einfacher Jack Value node zu sehen.

Dort können nun einige Filter gesetzt werden.

Und so sieht dann die Ausgabe davon aus.

[ptweety]

Hallo zusammen,

ich habe den ersten Wurf nun mal auf Github veröffentlicht. Wäre schön, wenn Interessierte ihre Erfahrungen mitteilen.