Echtzeit Node-RED Anbindung

[Gnomi_Berlin]

Hallo,

ich verwende eigentlich in Node-RED node-red-contrib-ccu. Das läuft stabil aber mit Verzögerung bei Änderungen in der CCU.

Für eine spezielle Anwendung brauche ich eine schnelle Node-RED Reaktion, wenn sich in der CCU ein Aktor oder eine Variable ändern.
Würde mir der CCU-Jack helfen oder welche Lösung gibt es noch?
Ich hatte in der Vergangenheit mal etwas dazu gefunden, konnte jetzt aber nichts eindeutiges finden.

Wenn CCU-Jack: ich habe gelesen, das der einen eigenen MQTT Broker mitbringt. Muss ich diesen verwenden oder kann ich meinen Standard Mosquitto verwenden?

Gruß
Jörg

[Henke]

Meine Lösung "RedHM" hat eine schnellere Anbindung an die CCU, was aber eher in den rein technischen Bereich geht und an Optimierungen liegt. Eine reale Auswirkung bei HmIP Geräten wirst du nicht feststellen.
CCU-Variablen können nur aktiv von NodeRed abgefragt werden und sind damit für mich unter NodeRed vollkommen ungeeignet.
Früher habe ich dafür Geräte im CCU-Jack angelegt, was mir aber auf Dauer zu unflexibel war.
Jetzt verwende ich dafür eigene virtuelle Geräte (wenn Datenpunkte geloggt werden sollen) oder eigene "Parameter" die wie Geräte bei Änderung Werte senden. Fazit: Ich habe wohl so ziemlich alle Methoden durch.

Da du Mosquitto am laufen hast, habe ich den Verdacht das es um MQTT Daten geht. Da ist die Lösung mit den in NodeRed eingebauten Nodes ziemlich einfach.

Daher, bitte etwas präziser, wo kommen die Echtzeitdaten her?

[Baxxy]

ccu-connection-node hängt, genauso wie der Jack, als Client am RPC. Sobald das Event eines Gerätes auf der CCU eintrifft wird es an die Klienten weitergeleitet.

Kann mir nicht vorstellen daß es da großartige Delays gibt.
Systemvariablen dürften über den Jack schneller sein, der scannt (nur die markierten) alle 3s. Ccu-connection-node scannt per default (aber einstellbar) alle 30s alle SysVars.

[Henke]

Kann mir nicht vorstellen daß es da großartige Delays gibt.

Nun ja, da sind so die einen oder anderen Fallstricke.
Den RPC kann man nicht sonderlich beschleunigen, aber die Aufbereitung der Daten sowie die Verteilung auf die entsprechenden Nodes schon. Da konnte ich, verglichen mit node-red-contrib-ccu gut einen Faktor von 3+ raus holen.
Bei den ersten Versionen mit node-red-contrib-ccu brauchte ein Neustart fast 2 Minuten, da ein definierter Systemzustand über die Sicherung alles Datenpunkte/Parameter wieder hergestellt wird. So grob 1200 Nachrichten, die verarbeitet werden müssen. Das konnte ich später auf 1 Minute drücken durch Optimierung der verarbeiten Nodes.
Mit RedHM läuft das jetzt noch etwas anders. Die Datenverteilung läuft über eine Baumstruktur, nicht über Schleifen. Die Aufbereitung ist optimiert und jetzt brauche ich statt 60 Sekunden ganze 10.2 Sekunden auf einer CCU3. Das ist schon angenehm, aber der wesentliche Punkt ist, das die CCU3 gerade mal im Tagesdurchschnitt 3.3 Prozent der Rechenleistung braucht. Da bleibt die so kühl wie im Leerlauf und in so 10-15 Jahren kann ich mir ein Bier von den eingesparten Stromkosten kaufen...
Und da werden nicht gerade wenig Daten verarbeitet. Die Shellys sind echte Plappermäuler. In den letzten 50h HmIP 15.800 vs. MQTT 1.663.000
Aber zurück zur Echtzeit...

1: MQTT Gerät angebunden über Jack:
Gerät -> Jack -> CCU -> node-red-contrib-ccu -> nodes

2: MQTT Gerät angebunden über RedHM:
Gerät -> MQTT Broker -> RedHM -> nodes

3: MQTT Gerät angebunden über node "MQTT In":
Gerät -> MQTT Broker -> "MQTT In"

Es fällt dabei jeweils ein Schritt weg und das macht schon was aus. Der Unterschied zwischen 2 und 3 ist aber nicht relevant, da die Schritte schon ziemlich optimiert sind. Tests die Daten direkt vom Broker, der als Node läuft, zu verteilen brachten keinen relevanten Vorteil. Das war für mich eher interessant zu sehen wie viel Zeit ich verbrauche.
Der Unterschied zwischen 1 und 3 ist jedoch nicht unerheblich. Nicht umsonst hat ptweety sein node-red-contrib-ccu-jack und ich mein RedHM entwickelt.
Der Jack jedoch ist Referenzklasse, was den Speicherverbrauch und die Geschwindigkeit angeht. Rattenschnell dat Teil.

[Gnomi_Berlin]

Danke @Henke und @Baxxy,

und die Frage von

@Henke:
Daher, bitte etwas präziser, wo kommen die Echtzeitdaten her?

Ich habe einen Bewegungsmelder von Homematic und möchte unverzögert ein Photo erstellen und dann weiter verwenden.

Derzeit ist das Photo immer ein paar Sekunden verzögert nach Auslösen des Bewegungsmelders.

Ich verwende Node-RED in einem extra LXC Container zur piVCCU3 auf dem gleichen Raspberry 4B.

Mein Grundkonzept: Homematic Geräte und Variablen werden mit der Logik und Scripts der piVCCU3 behandelt, Kombinationen mit nicht Homematic Geräten nur in Node-RED über MQTT oder eben node-red-contrib-ccu zur CCU.
Wenn ich z.B. Telegram Nachrichten als Befehl sende, kommen entweder Antworten zu Abfragen oder z.B. Nachrichten auf den Fernseher in "Echtzeit" zurück oder an. Daher hatte ich node-red-contrib-ccu Bewegungsmelder Ereignis an Node-RED als Verzögerung in Verdacht.

RedHM und node-red-contrib-ccu-jack kenne ich noch nicht.

Danke schonmal

[Henke]

Dafür ist node-red-contrib-ccu definitiv schnell genug. Kontrolliere bitte mal, wann die Bewegungsmeldung bei der CCU ankommt (den Kanal des Bewegungsmelders auf protokolliert stellen) und welche Einstellungen der Bewegungsmelder hat.

[Gnomi_Berlin]

Danke @Henke,

wegen eines Bugs in der piVCCU3/CCU3 konnte ich die Parameter des Bewegungsmelders nicht auslesen.
nun zu:

Dafür ist node-red-contrib-ccu definitiv schnell genug. Kontrolliere bitte mal, wann die Bewegungsmeldung bei der CCU ankommt (den Kanal des Bewegungsmelders auf protokolliert stellen) und welche Einstellungen der Bewegungsmelder hat.

Protokollieren habe ich noch nicht umgesetzt. Aber die Einstellung des Bewegungsmelders habe ich nun:

in Node-RED:

Ich sehe nicht, wo ich da bezüglich Geschwindigkeit etwas verbessern könnte.

Danke schonmal.