Node-RED Nodes für externe ioBroker Integration

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

[MartyBr]

@Marc-Berg
Hallo, ich migrieren gerade meine Flows vom ioBroker-Node-Red zu dem eigenständigen Node-Red server. Deine Nodes sind in der Version 15.0 installiert.

Mein Problem ist folgendes:
Im Original-Node gibt es das Feld Attribut:

In deinem Node finde ich hier keine Möglichkeit, das Attribut festzulegen:

Hier gibt es Output Property.
Kann ich es so anwenden?

[Marc Berg]

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

Mein Problem ist folgendes:
Im Original-Node gibt es das Feld Attribut:

Hier gibt es Output Property.
Kann ich es so anwenden?

Das ist das Gleiche. Ich habe mich für den Begriff "property" entschieden, weil es besser in die Node-RED Konventionen passt.

[MartyBr]

@marc-berg
Danke
Passt

[rewenode]

@marc-berg Also zu meckern gibt es immer noch nichts;-) Inzwischen habe ich weite Teile meiner Flows migriert.
Bei einer Sache habe ich echt an meinem Verstand gezweifelt.
Ich habe mir vor langer Zeit so einen Flow gebastelt, der rein im function node per WS meine PV abfragt.
Da abboniere ich viele Datenpunkte gemäß deren API, die sehen dann z.B. so aus:

"_sum/EssActiveDischargeEnergy"

Die reinkommenden Daten schreibe ich dann in states mit dem Topic:

      msg.topic = "node-red.0/fems/" + fems_request_channels[i][requestKey];

Das läuft mit den alten nodes ok. Nicht aber mit den neuen.
Hab dann irgendwann endlich gemerkt, dass die neuen nodes zwingend den "." als Property-Trenner verlangen.
Das ist natürlich ok und sicher auch besser.
Will nur darauf hinweisen, falls noch jemand in diese Falle tappst;-)

Macht echt Spass, seine Flows mit den neuen Möglichkeiten gleich mal zu überarbeiten.

[Marc Berg]

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

Das läuft mit den alten nodes ok. Nicht aber mit den neuen.
Hab dann irgendwann endlich gemerkt, dass die neuen nodes zwingend den "." als Property-Trenner verlangen.

Um ehrlich zu sein, habe ich mir nicht viel Mühe dabei gegeben, die Umstellung so einfach wie möglich zu gestalten. An dieser Stelle hatte ich eine Weile überlegt, wie ich es mache. Insbesondere beim "in" Node konnte man ja auch das "MQTT" Format mit "/" wählen. Ich hab's dann weggelassen weil ich es nicht verwendete (dachte ich). Bei der Umstellung hab ich dann gemerkt, dass ich doch eine Stelle drin hatte.

Will nur darauf hinweisen, falls noch jemand in diese Falle tappst;-)

So wie ich selbst.

[MartyBr]

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

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

Das läuft mit den alten nodes ok. Nicht aber mit den neuen.
Hab dann irgendwann endlich gemerkt, dass die neuen nodes zwingend den "." als Property-Trenner verlangen.

Um ehrlich zu sein, habe ich mir nicht viel Mühe dabei gegeben, die Umstellung so einfach wie möglich zu gestalten. An dieser Stelle hatte ich eine Weile überlegt, wie ich es mache. Insbesondere beim "in" Node konnte man ja auch das "MQTT" Format mit "/" wählen. Ich hab's dann weggelassen weil ich es nicht verwendete (dachte ich). Bei der Umstellung hab ich dann gemerkt, dass ich doch eine Stelle drin hatte.

Will nur darauf hinweisen, falls noch jemand in diese Falle tappst;-)

So wie ich selbst.

Planst du das Verhalten noch zu ändern? Wo finde ich die Doku dazu? Ich verwende eine Menge mqtt-Nodes. Wenn ich das richtig??? gelesen habe, betrifft es den in und den out-Node?

[Marc Berg]

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

Planst du das Verhalten noch zu ändern?

Ich sehe im Moment keinen Grund dafür. Hier geht es ja lediglich darum, in welchem Format die Topics durch den Flow geschleust werden. Da es sich hier um ioBroker Nodes handelt, verwende ich natürlich die ioBroker Notation, und die ist mit Punkten.

Wo finde ich die Doku dazu?

Ich verstehe nicht. Die Nodes sind schon umfangreicher dokumentiert als 99,9% vergleichbarer Projekte. Soll ich jetzt auch noch dokumentieren, was ich NICHT mache?

Ich verwende eine Menge mqtt-Nodes. Wenn ich das richtig??? gelesen habe, betrifft es den in und den out-Node?

Ja. Beim "in" Node konnte man wählen, dass man statt der Punkte im Topic "/" hat. Und beim out-Node konnte man AUCH "/" als Trenner angeben. Das hat aber aus meiner Sicht Fehlerpotential, weil auch solche Bezeichner wie

möglich sind.

[rewenode]

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

Da es sich hier um ioBroker Nodes handelt, verwende ich natürlich die ioBroker Notation, und die ist mit Punkten.

Ich würde es ehrlich gesagt auch so lassen. Ist weniger fehleranfällig und in stateID Pattern sind die Beispiele ja auch mit Punkt. Da könnte man zur Not ja noch
"only dot notation is permitted" drunterschreiben.

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

Die Nodes sind schon umfangreicher dokumentiert als 99,9% vergleichbarer Projekte.

Würde ich mal zu 100% unterschreiben. Kann mich nicht erinnern schon mal so gut dokumentierte nodes gesehen zu haben. Danke dafür.

[MartyBr]

@marc-berg
Ich habe die Doku auf Github gefunden. Sie ist wirklich ausgesprochen umfangreich.