Node-RED Nodes für externe ioBroker Integration
-
@peterfido sagte in Node-RED Nodes für externe ioBroker Integration:
Die Uhrzeit könnte aber auch an meinem Docker-System liegen.
Ich statte meine Container standmäßig mit der localtime vom Host aus:
-
@marc-berg Ja, da war ich nachlässig. Die Docker-VM ist normal nur für Stirling PDF. Da ist mir die Uhrzeit egal. Somit bitte meine Bemerkung mit der Uhrzeit ignorieren.
Für den Test hier habe ich dann noch Node-Red als Docker Container hinzugefügt.
Dass da ein autarkes Node-Red werkelt, wird bei den Mitgliedern aus dem Forum hier eher die Ausnahme sein.Im ioBroker habe ich zwei Node-Red-Instanzen laufen. Eine für alles außer Eaton Easy und eine für Eaton Easy, da es zu Timeouts kam, welche ich so nicht wegbekommen hatte. Möglich, dass ich da mehr Ressourcen zuweisen müsste. Geht aber jetzt mit den zwei Instanzen zuverlässig stabil.
-
@marc-berg Das abonnieren der 6 Temperaturwerte verlangt vom ioBroker keine großen Ressorcen. CPU und RAM geht im Grundrauschen mit unter. Netzwerkverkehr ist natürlich mehr geworden.
-
@peterfido sagte in Node-RED Nodes für externe ioBroker Integration:
CPU und RAM geht im Grundrauschen mit unter
Selbst wenn man ganz brutal "*" abonniert, ist am ioBroker nichts zu merken. Solange man sich keine Schleifen fabriziert, sollte der externe Zugriff unproblematisch sein.
-
In der Version 0.5.4 wurden noch ein paar Bugs behoben. So konnte man z.B. nicht die Anmeldedaten ändern, ohne Node RED neu starten zu müssen.
-
Es gibt ein paar neue Nodes und Funktionen:
https://github.com/Marc-Berg/node-red-contrib-iobroker/blob/main/CHANGELOG.md
Mit dem getHistory Node kann man auf historische Daten zugreifen, ohne direkt die Datenquellen (History/SQL/InfluxDB) einbinden zu müssen.
Der getObject Node wurde erweitert, damit man (ggf. gefiltert nach Type) eine Liste von verfügbaren Objekten ausgeben kann.
Es gibt einen neuen Node "inObject", damit kann man Objektänderungen (Neuerstellungen, Anpassungen/Löschungen) abonnieren.
-
@marc-berg Du bist echt produktiv
Danke dafür.
Damit werden die contrib Nodes immer mehr zur echten Alternative für den ioB-Adapter. -
- Es gibt einen neuen Node "iob-log", hiermit kann man das Livelog des ioBrokers abonnieren (Anbindung über Admin-Adapter notwendig)
- die README wurde umgestaltet
- Man kann im History-Node nun auch "Dashboard 2.0" (@flowfuse/node-red-dashboard) als Output-Option angeben und bekommt entsprechend fertig aufbereitete Daten
-
@marc-berg sagte in Node-RED Nodes für externe ioBroker Integration:
Es gibt einen neuen Node "iob-log", hiermit kann man das Livelog des ioBrokers abonnieren (Anbindung über Admin-Adapter notwendig)
Hab ich jetzt seit gestern ohne Auffälligkeiten laufen. Das ist echt eine Hilfe.
@marc-berg sagte in Node-RED Nodes für externe ioBroker Integration:
Man kann im History-Node nun auch "Dashboard 2.0" (@flowfuse/node-red-dashboard) als Output-Option angeben und bekommt entsprechend fertig aufbereitete Daten
Mal sehen, ob ich das die kommenden Tage mal testen kann. Beschäftige mich gerade mit dem Dashboard 2.0
-
@rewenode sagte in Node-RED Nodes für externe ioBroker Integration:
Hab ich jetzt seit gestern ohne Auffälligkeiten laufen. Das ist echt eine Hilfe.
Danke für's Testen!
Mal sehen, ob ich das die kommenden Tage mal testen kann. Beschäftige mich gerade mit dem Dashboard 2.0
Steht etwas versteckt in der Readme, der Chart Node muss so konfiguriert werden:
Wenn du noch Anregungen und Verbesserungswünsche hast, gern her damit.
-
@marc-berg sagte in Node-RED Nodes für externe ioBroker Integration:
Wenn du noch Anregungen und Verbesserungswünsche hast, gern her damit.
Sieht erstmal perfekt aus. Als Singlestate ist die Übergabe an die Chart-Node sehr einfach. Dafür ist das bei vielen states evt. eine Fleißarbeit.
Da wünschte ich mir die Möglichkeit, ein arrayOfStates angeben zu können. Ich kann aber auf die Schnelle auch nicht überblicken, wie aufwendig das wäre. -
@rewenode sagte in Node-RED Nodes für externe ioBroker Integration:
Da wünschte ich mir die Möglichkeit, ein arrayOfStates angeben zu können
Das gilt eigentlich generell für das Abonnieren von states. Machmal sind da standard-wildcards für mich zu unflexibel. Bisher filtere ich mir dann die Daten im Nachgang oder (im Fall meiner eigenen WS-function-node) verwende gleich ein arrayOfStates für die zu abonnierenden states.
Aber ist sicher nur nice to have und ich kann auch nicht beurteilen, ob das von allgemeinem Interesse ist.
-
@rewenode sagte in Node-RED Nodes für externe ioBroker Integration:
Da wünschte ich mir die Möglichkeit, ein arrayOfStates angeben zu können. Ich kann aber auf die Schnelle auch nicht überblicken, wie aufwendig das wäre.
Ja, kann ich verstehen. Die Umsetzung stelle ich mir gerade ziemlich fehleranfällig vor, und das werde ich (bevor ich ganz sicher bin, dass der Rest ~100% funktioniert) eher nicht angehen. Aber mit der "append" Option kann man den Chart Node auch gut mit mehreren Datenreihen beschicken:
-
@marc-berg sagte in Node-RED Nodes für externe ioBroker Integration:
Aber mit der "append" Option kann man den Chart Node auch gut mit mehreren Datenreihen beschicken:
Da hast du recht, das tut es auch.
-
@rewenode sagte in Node-RED Nodes für externe ioBroker Integration:
Das gilt eigentlich generell für das Abonnieren von states. Machmal sind da standard-wildcards für mich zu unflexibel. Bisher filtere ich mir dann die Daten im Nachgang oder (im Fall meiner eigenen WS-function-node) verwende gleich ein arrayOfStates für die zu abonnierenden states.
Das sähe dann so aus:
Man kann eine Reihe States abonnieren und entscheiden, ob man nur den jeweils geänderten State als Message wie bisher haben möchte oder gebündelt wie im Bild mit allen States sowie dem "Auslöser". Wenn sich aber in kurzer Zeit alle Werte ändern, bekommt man das Bündel x mal. Bin mir noch nicht sicher, ob das gut ist.
-
@marc-berg sagte in Node-RED Nodes für externe ioBroker Integration:
@rewenode sagte in Node-RED Nodes für externe ioBroker Integration:
Das gilt eigentlich generell für das Abonnieren von states. Machmal sind da standard-wildcards für mich zu unflexibel. Bisher filtere ich mir dann die Daten im Nachgang oder (im Fall meiner eigenen WS-function-node) verwende gleich ein arrayOfStates für die zu abonnierenden states.
Das sähe dann so aus:
Man kann eine Reihe States abonnieren und entscheiden, ob man nur den jeweils geänderten State als Message wie bisher haben möchte oder gebündelt... Bin mir noch nicht sicher, ob das gut ist.
Das ist genial. Gebündelt ist nicht nötig und sicher nicht sinnvoll aus den schon von dir genannten Gründen. Es sei denn, man will das explizit so haben.
Es mag Fälle geben wo das hilfreich wäre. z.B. Wenn man zu einem State immer einen 2ten(oder mehrere) braucht, weil mann beide in der Weiterverarbeitung vergleichen/auswerten muss. Da habe bisher meist nach dem Empfang einer Änderung einen get für den 2ten state ausgelöst oder mir die Änderungen gespeichert. Bei solchen Sonderfällen ist das sicher hilfreich, weil es eine ganze Menge Aufwand sparen kann.
Mach so wie du denkst und es für dich keinen extremen Aufwand bedeutet. -
@rewenode sagte in Node-RED Nodes für externe ioBroker Integration:
Da habe bisher meist nach dem Empfang einer Änderung einen get für den 2ten state ausgelöst oder mir die Änderungen gespeichert. Bei solchen Sonderfällen ist das sicher hilfreich, weil es eine ganze Menge Aufwand sparen kan
Genau das. Da es auch bei mir den einen oder anderen Flow vereinfachen wird, werde ich es drin lassen.
-
@marc-berg sagte in Node-RED Nodes für externe ioBroker Integration:
Das sähe dann so aus
EDIT: noch Ideen für weitere Nodes oder Erweiterungen/Verbesserungen? Mir fällt nichts mehr ein, was sich nicht mit Node-RED Standardmitteln lösen ließe.
-
@marc-berg Vielleicht eine Option, das Node-Red oder den Rechner darunter neu zu starten.
-
@marc-berg sagte in Node-RED Nodes für externe ioBroker Integration:
v0.9.5
Da bin ich echt platt
Läuft wie geschmiert bis jetzt.
Ich werde die Tage beginnen meine Flows nacheinander umzustellen. Da wird bestimmt noch das ein oder andere auftauchen.@Marc-Berg Hast du mal getestet, ob deine contrib-iobroker auch unter dem iob-node-red Adapter läuft? Das würde die Umstellung der Flows vereinfachen, weil ich dabei nicht mit 2 Systemen hantieren müßte. Habe im Moment kein Testsystem zur Hand, sonst würde ich das selbst testen.
Ich dachte daran, jeweils den original-Flow zu adaptieren und dann zu deaktivieren. Dann kann der neue Flow einige Zeit laufen und beobachtet werden, wobei ich (falls nötig) per Knopfdruck wieder auf den alten Flow wechseln könnte.Deine notes sind wirklich exzellent dokumentiert. Macht echt Spass, damit zu experimentieren.
@marc-berg sagte in Node-RED Nodes für externe ioBroker Integration:
Mir fällt nichts mehr ein, was sich nicht mit Node-RED Standardmitteln lösen ließe.
Ja, das stimmt schon, aber mit so komfortablen nodes ist es entschieden angenehmer
