Node-RED Nodes für externe ioBroker Integration
-
@marc-berg sagte in Node-RED Nodes für externe ioBroker Integration:
.tgz aus dem Release runter-
Und nochmal danke
-
In der v0.12.0 habe ich noch ein wenig an der Darstellung des History-Node geschraubt (Tab-Darstellung).
Außerdem kann man im Node jetzt einstellen, wie man mit fast zeitgleich eintreffenden Queries umgehen möchte, die ja auch mal länger laufen können:
-
@marc-berg Bin da auf ein Problem gestossen. Könnte evtl. ein Bug sein oder an meiner Vorgehensweise liegen.
Ich arbeite relativ intensiv mit alias-states. Hauptsächlich um Sensoren schnell wechseln zu können.
So ist der alias-state: alias.0.Klima.office.Temperatur halt die Temp im Office.
Diesem State ist der Ort (enum.rooms.ground_floor.office) zugewiesen.Der Sensor selbst(base) ist irgend ein Temperatursensor, der auch schnell mal gewechselt werden kann.
Zum Test grad der Temp-Sensor einer Tasmota-Steckdose: "mqtt.0.stTasmota-8.tele.SENSOR"
Diese wiederum hat eigene Eigenschaften, die ich i.d.R. ebenfalls in enums abgelegt habe. Da ist dann halt der Hardwaretyp/Batterie etc. hinterlegt.Ich habe mir da so Listen gebastelt z.B. „offene Fenster“, die dann neben dem Status auch gleich signalisieren, wenn die Batterie zur Neige geht. Kurz, machmal brauche ich neben dem State auch das eigentliche (base) Objekt.
Mit den alten iob-Nodes bin ich immer folgendermaßen vorgegangen:
Umständlich aber funktioniert.
Jetzt versuche ich das mit deinen nodes. Da nehme natürlich statt der iob-list-node die „WS ioB getObj+Enum.
Die Node ansich tut einen hervorragenden Job und ist extrem flexibel.

Obwohl der topic korrekt gesetzt ist, bekomme ich den Fehler, wenn ich als letztes das base object abfragen will.
Frage ich das base object separat ab, läuft alles bestens.

Sieht fast so aus, als hätte es mit dem msg-object zu tun, was ja komplett durchgeschleift wird.Getestet mit V0.10 externes NR und ioB NR Adapter.
-
Exportiere bitte noch die verarbeiteten Datenpunkte aus MQTT.* und alias.* aus dem Objektbaum als JSON und stelle sie hier rein.Ahh, Fehler gefunden. Der letzte Node bekommt durch die Verkettung als ObjectType "any" (als String) mitgegeben, den es so nicht gibt. Ich schleife ja die Suchparameter mit. Als Quickfix diese Eigenschaft im letzen Change-Node einfach löschen.
Ich schau mal, dass ich den Eingabe-Parameter "any" und "null" gleichsetze.
Das ist wie die Geschichte mit der "any"-Key ...
-
@marc-berg Hoffe, ich habs richtig exportiert.
mqtt.0.stTasmota-8.json alias.0.Klima.office.Temperatur.json -
@rewenode sagte in Node-RED Nodes für externe ioBroker Integration:
Hoffe, ich habs richtig exportiert.
ja, sorry. Habe meinen letzten Post editiert.
-
@marc-berg sagte in Node-RED Nodes für externe ioBroker Integration:
Als Quickfix diese Eigenschaft im letzen Change-Node einfach löschen.
Ja passt so
Und keine Eile, das läuft ja noch nicht produktiv. -
@rewenode sagte in Node-RED Nodes für externe ioBroker Integration:
Sieht fast so aus, als hätte es mit dem msg-object zu tun, was ja komplett durchgeschleift wird.
Die aufgeräumten Objekt-Eigenschaften sind in der v0.12. verfügbar. Bald in der Palette oder jetzt auf Github.
-
Da das Abfragen der Objekteigenschaften und der Aliase doch eng zusammenhängt, habe ich es gleich in den GetObject Node mit eingebaut.
Damit müsstest du nicht mehr den Umweg über fünf Nodes nehmen.
-
@marc-berg sagte in Node-RED Nodes für externe ioBroker Integration:
Da das Abfragen der Objekteigenschaften und der Aliase doch eng zusammenhängt, habe ich es gleich in den GetObject Node mit eingebaut.
Das ist wirklich klasse und eine echte Erleichterung
Danke -
@marc-berg Kurze Zwischenfrage, habe gerade mal flüchtig die 12.0-4 getestet. Vlt. war ich da zu voreilig.
Ich frage ein Alias Object ab und bekomme neben dem aliasObject die aliasEnums UND das targetObject. Soweit perfekt!
Allerdings wird das targetObject ohne die targetEnums geliefert? Oder mach ich da was falsch?
-
@rewenode sagte in Node-RED Nodes für externe ioBroker Integration:
Oder mach ich da was falsch?
Nein, du machst nichts falsch. Eine Frage der Philosophie ist wahrscheinlich, ob man alias und target (in das dann wohl immer identische?) Enum legt.
Ich könnte jetzt die Enums von alias und target zusammenfassen und deduplizieren, besser ist es aber, wenn ich die Enums sauber dem jeweiligen Objekt zuordne.
-
Jetzt haben alle target objects in aliasInfo.aliasTarget.target (bzw. targets.read/targets.write) die gleichen enum assignments wie das ursprüngliche Objekt, wenn sie in entsprechenden enums eingetragen sind.
Die enum assignments erscheinen jetzt sowohl beim base-Objekt als auch bei allen alias target objects korrekt. -
@marc-berg sagte in Node-RED Nodes für externe ioBroker Integration:
Ich könnte jetzt die Enums von alias und target zusammenfassen und deduplizieren, besser ist es aber, wenn ich die Enums sauber dem jeweiligen Objekt zuordne.
Die Enums von alias und target sind i.d.R unterschiedlich, jedenfalls bei mir.
Der Alias ändert sich nicht, ist einem festen Ort zugewiesen.
Das Target device kann irgendwas sein und hat je nachdem individuelle Enums (Batterie/Hardware etc). Hatte früher mal aus diesem Grunde den Ort am Target festgemacht. Das ist aber unpraktisch, weil dann auch der Ort am target geändert werden muss, wenn das Teil woanders eingesetzt wird.
Ob die Enums beim getObj bei einem Alias die Enums zusammenfasst sind ist eigentlich egal, Hauptsache, es werden sowohl die target und die alias Enums zurückgegeben. Zusammengefaßt wäre einfacher bei der Weiterverarbeitung, weil das alias-object ja in der Regel so betrachtet wird, als wäre es ein tatsächliches device.
Getrennt ist aber auch ok.
Hoffe, ich habe das nicht zu verworren ausgedrückt. -
@marc-berg sagte in Node-RED Nodes für externe ioBroker Integration:
Die enum assignments erscheinen jetzt sowohl beim base-Objekt als auch bei allen alias target objects korrekt.
Grad mal reingeschaut. Das sieht perfekt aus! Da fällt mir erstmal nichts mehr ein
-
@Marc-Berg Ich hab da mal eine prinzipielle Frage
Ich habe jetzt mal etwas intensiver mit den nodes von einem externen NR gespielt. In meine Beispiel versuche ich mich gerade mit dem Dashboard 2 vertraut zu machen. Besonders die Verwendung von Subflows vereinfachen die Arbeit ungemein.
Mein Test sieht etwa so aus:
Hier habe die WS-ioB-nodes alle in den Subflow gepackt, was den Hauptflow extrem vereinfacht.
Natürlich sind hier auch andere Szenarien denkbar.
Man könnte auch die zu abonnierenden states über einen einzelnen externen WS-ioB-IN realisieren, und die Daten den Subflow-Instanzen extern zuführen.Was ich mich frage:
Wie verhalten sie diesbezüglich eigentlich die WS-ioB in Bezug auf Speicher/Performance?
Will fragen, was ist besser, die states einzeln zu abonnieren oder alle in einem node zu abonnieren.
Dabei lass ich mal außer acht, dass der externe Aufwand im Falle von mehreren states pro WS-ioB-IN steigen wird, weil die Daten i.d.R. wieder auseinanderklamüsert werden müssen.In meinem Test mit den 3 Instanzen des Subflows gibt es keinerlei Probleme. Bin nach wie vor von den WS-ioB nodes begeistert.
-
@rewenode sagte in Node-RED Nodes für externe ioBroker Integration:
Was ich mich frage:
Wie verhalten sie diesbezüglich eigentlich die WS-ioB in Bezug auf Speicher/Performance?
Will fragen, was ist besser, die states einzeln zu abonnieren oder alle in einem node zu abonnieren.Speichertechnisch dürfte der "MultipleStates" Ansatz Vorteile bringen. Wenn ich das mal grob überschlage:
100 einzelne Nodes:
100 × Node-Instanz ≈ 100 × 5KB = 500KB
100 × Callback-Handler ≈ 100 × 1KB = 100KB
100 × State-Tracking ≈ 100 × 0.5KB = 50KBSumme: ~650KB
─────────────────────────────────────────1 Multiple States Node:
1 × Node-Instanz ≈ 5KB
1 × Callback-Handler ≈ 1KB
100 × State-Tracking ≈ 50KBSumme: ~56KB
─────────────────────────────Und auch die CPU-Belastung düfte etwas geringer ausfallen.
Ob in heutigen Hardware-Szenarien das wirklich relevant ist und den Mehraufwand rechtfertigt, muss man entscheiden.
In meinem Test mit den 3 Instanzen des Subflows gibt es keinerlei Probleme. Bin nach wie vor von den WS-ioB nodes begeistert.
Freut mich. Ich habe meine Prod umgestellt (noch ohne Optimierungen auf Basis der neuen Möglichkeiten), mit 600 Nodes (davon ca. 180 ioBroker WS Nodes) dümpelt der Container bei ca. 100MB und 0.1-0.2% CPU dahin.
In Summe (vor und nach der Umstellung) sehe ich keinen Unterschied bei Memory und CPU. Das geht im Grundrauschen unter.
-
@marc-berg sagte in Node-RED Nodes für externe ioBroker Integration:
Ich habe meine Prod umgestellt (noch ohne Optimierungen auf Basis der neuen Möglichkeiten), mit 600 Nodes (davon ca. 180 ioBroker WS Nodes) dümpelt der Container bei ca. 100MB und 0.1-0.2% CPU dahin.
In Summe (vor und nach der Umstellung) sehe ich keinen Unterschied bei Memory und CPU. Das geht im Grundrauschen unter.Das klingt gut. Werde ich auch erst mal so machen. Falls es Engpässe gibt , kann ich ja immer noch nach Multistate umstellen.
In vielen Fällen ist das bei mir eh vorteilhafter. Ich arbeite ja nicht überall mit Subflows. -
@rewenode So langsam stelle ich immer mehr meiner Flows um und bisher kann ich von keinen Problemen berichten
Dass das recht langsam voran geht liegt daran, dass ich gleichzeitig meine Dashboards umstelle.Und da habe ich mal eine Frage.
Wäre es möglich, dem WS-ioB-In einen Eingang zu verpassen, um sozusagen von extern einen "Send initial value on startup" auszulösen?Hintergrund.
Bei vielen Dashboards habe ich das Problem, dass ich aktuelle Werte nach einem Page/Tab Change Event benötige.
Jetzt mache ich das mit einem UI-control, der dann für jeden (eigentlich abonnierten Wert) einen WS-ioB-get triggert.
Das klappt zwar super, verdoppelt aber die WS-ioB nodes für alle Werte in der Anzeige.
Da wo ich mit multiplen states arbeiten kann ist das nicht so problematisch. -
@rewenode sagte in Node-RED Nodes für externe ioBroker Integration:
Wäre es möglich, dem WS-ioB-In einen Eingang zu verpassen, um sozusagen von extern einen "Send initial value on startup" auszulösen?
Möglich ja, aber: Nein.
Abgesehen davon, dass der iob-in Node schon ziemlich überladen ist, finde ich es konzeptionell falsch. Ein "-in" Node sollte nur einen Ausgang haben, ein "-out" Node nur einen Eingang. Sonst werden Flows unlesbar, wenn man keine Trigger mehr erkennt.
Aber ich verstehe das Problem und könnte mir eine Lösung vorstellen:
- Jeder iob-in Node registriert sich selbst im Flow-Context und stellt eine Trigger-Funktion bereit. (muss ich anpassen)
- Dein Dashboard Change Event triggert eine Function Node, in dieser steht sinngemäß:
const registeredNodes = context.flow.get('iobroker_in_nodes'); Object.values(registeredNodes) .filter(nodeInfo => nodeInfo.name && nodeInfo.name.includes('[Dashboard]')) .forEach(nodeInfo => nodeInfo.triggerCached());Oder beliebige andere Filter-Mechanismen, die Node-RED zur Verfügung stellt (alle Nodes eines Flows, einer Gruppe, ..)
