Node-RED Nodes für externe ioBroker Integration

[rewenode]

@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

[rewenode]

@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.

[Marc Berg]

@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 = 50KB

Summe: ~650KB
─────────────────────────────────────────

1 Multiple States Node:

1 × Node-Instanz ≈ 5KB
1 × Callback-Handler ≈ 1KB
100 × State-Tracking ≈ 50KB

Summe: ~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.

[rewenode]

@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]

@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.

[Marc Berg]

@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 ein Function Node, in diesem 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, ..)

[Marc Berg]

@marc-berg sagte in Node-RED Nodes für externe ioBroker Integration:

(muss ich anpassen)

--> v0.15.0-1

[rewenode]

@marc-berg sagte in Node-RED Nodes für externe ioBroker Integration:

--> v0.15.0-1

Klasse, werde ich gleich mal testen.
Dein Argument mit dem ioB-in kann ich nachvollziehen. Dein Lösungsvorschlag klingt sehr flexibel. Bin mal gespannt.

[rewenode]

@marc-berg Das klappt prinzipiell wunderbar
Wenn ich alle WS-ioB-in trigger, klappe es super!

const registeredNodes = context.flow.get('iobroker_in_nodes');

Object.values(registeredNodes)
    //.filter(nodeInfo => nodeInfo.name && nodeInfo.name.includes('[Dashboard]'))
    .forEach(nodeInfo => nodeInfo.triggerCached());
    
return msg;

Mit dem Filter stehe ich noch auf dem Schlauch.
Im Subflow kann ich das 'iobroker_in_nodes'-Object nicht inspizieren.
Interpretiere ich deinen Beispielfilter richtig?

nodeInfo.name steht hier für den Namen des WS-ioB-nodes. Der darf nicht leer sein und muss den String [Dashboard] enthalten.
Oder bin ich hier auf der falschen Fährte?

[rewenode]

@Marc-Berg Ok, habs geschnallt
Alle Dashboard relevanten ioB-In mit [Dashboard] im Namen zu versehen, macht absolut Sinn. Schließlich brauchen nur die den Page/Tab Change Event.
Das werde ich auch so machen und dann den Filter einschalten. Welche key`s da ggf. noch zur Filterung zur Verfügung stehen, kann ich mir im Hauptflow ansehen, wenn ich da ein ioB-In platziere.

Meinen Subflows habe ich nun einen Eingang spendiert, da brauche ich den UI-control nur einmal im Hauptflow.

Da bleiben eigentlich keine Wünsche offen.
Danke

[Marc Berg]

@rewenode sagte in Node-RED Nodes für externe ioBroker Integration:

//.filter(nodeInfo => nodeInfo.name && nodeInfo.name.includes('[Dashboard]'))  

nodeInfo.name steht hier für den Namen des WS-ioB-nodes. Der darf nicht leer sein und muss den String [Dashboard] enthalten.
Oder bin ich hier auf der falschen Fährte?

ja, so ähnlich. Mit dem Konstrukt

nodeInfo.name && nodeInfo.name.includes('[Dashboard]'))

stellt man sicher, dass die Funktion keinen häßlichen Fehler auswirft, falls ein Node keine "Name" Eigenschaft besitzt. (ein eher theoretischer Fehler).

Ich werde die Funktion noch ausbauen, sodass man den Namen der Trigger-Gruppe pro iob-in Node festlegen kann. Auf diese Weise muss man die Nodes im function Node nicht nochmal filtern.

[rewenode]

@marc-berg sagte in Node-RED Nodes für externe ioBroker Integration:

Ich werde die Funktion noch ausbauen, sodass man den Namen der Trigger-Gruppe pro iob-in Node festlegen kann. Auf diese Weise muss man die Nodes im function Node nicht nochmal filtern.

Klasse

v0.15.0-1 läuft jedenfalls schon mal seit gestern und tut genau was sie soll.