wait until-ähnliche Node / Arbeit mit "Context"
-
Hallo zusammen,
meine Frau und ich sind neu in ein zu Hause gezogen, wo wirklich alles am KNX Bus hängt. Nun, nach dem Auspacken der Kartons, geht es für mich an das Umsetzen verschiedener "smarter Abläufe". Dazu habe ich mich in die Thematik Node-Red eingelesen, scheine intellektuell jedoch bisher nicht über die absoluten Basisdinge hinauszukommen
Ehe ich also mich an komplexe Wetter+Temperatur-Abhängige Jalousiensteuerung wage, habe ich mit einfachen Themen begonnen, welche ich aber bisher nicht bewältigt bekomme. Ich hoffe daher auf die nötigen Gedankenanstöße (gerne mit Quellen zum Nachlesen), um das gelöst zu bekommen. Ich möchte mit den ersten beiden Problemen beginnen:
- Problem: Das Ende von Großgeräten ausgeben.
Ich habe mir zwei Flows angelegt, um das Ende von Waschmaschine und Spülmaschine über Telegram ausgeben zu lassen. Dazu hängt jedes Großgerät an einem Aktor mit Stromzähler, welche den Verbrauch pro Sekunde in mA ausgibt.
Dieser Verbrauch wird über die GA abgerufen und geprüft. Niedrige mA Verbräuche sagen "Idle oder Fertig".
Jetzt ist es bei den Geräten aber so, dass sie auch während des Programms, oder gleich zu Beginn in der Aufheitzphase niedrige Verbräuche sekunden-/minutenweise haben und mir aktuell Telegram pro Waschgang gefühlt 20 mal sagt "Die Spülmaschine ist fertig".
Bei meiner Recherche bin ich auf eine Node aus dem Homematic-Bereich gestoßen, die sich wait-until nennt. Diese nimmt den msg.payload, hält ihn eine Zeit x fest und wenn nach der Zeit x immer noch keine neuer msg.payload eingegangen ist, schickt er die msg weiter. Dies würde das Problem sehr gut lösen, nützt mir aber nichts, weil kein Homematic.
Nun hab ich die Situation etwas entschärft, in dem ich eine Delay-Node eingefügt habe, die nur alle 10 Minuten eine Nachricht durchlässt, macht am Ende aber immer noch 3-5mal "Die Waschmaschine ist fertig" und man rennt teilweise umsonst -> nicht sehr smartWie kann ich eine "wait-until"-Node sinnvoll nachbauen, auch ohne Homematic?
- Problem: Verarbeitung von Fensterkontakten zu einem Status.
Ich habe pro Fenster 2 Fensterkontakte, welche über einen Binäreingang auf dem Bus je nach Fensterstellung (zu, kipp, offen) true und false schicken. Diese beiden Kontakte kann ich wieder über zwei GA abrufen und so in Node-Red bekommen. Da ein Payload ja nie auf den anderen wartet, wie ich bei vielen Experimenten und Nachlesen rausfinden musste, habe ich die beiden ausgelesenen Kontakte mittels Change-Node in den Context geschrieben. Nun führe ich beide Change-Nodes in einer Funktion zusammen, welche eine Wenn-Dann-Prüfung ausführt. Hinten soll dann als Payload der jeweilige Status rauskommen.
In der Change-Node steht:
Setze msg.payload auf/nach flow.kontakt1 (bzw. kontakt2)
In der Funktion-Node steht:var kontakt1 = flow.get("kontakt1") var kontakt2 = flow.get("kontakt2") if (kontakt1 == false && kontakt2 == false) msg.payload = "Fenster gekippt"; else if (kontakt1 == true && kontakt2 == true) msg.payload = "Fenster zu"; else if (kontakt1 == true && kontakt2 == false) msg.payload = "Fenster offen"; else msg.payload = "Hier stimmt was nicht"; return msg;Es ist am Ende aber egal, wie oft ich das Fenster öffne, schließe oder kippe, es kommt immer "Hier stimmt was nicht".
Weiß jemand, was ich falsch mache?
Herzlichen Dank
Almeda - Problem: Das Ende von Großgeräten ausgeben.
-
@almeda Manchmal frage man sich schon manchmal, ob die Suchfunktion eine neue Erfindung ist. Langsam kann ich manche Poster verstehen, weil man selbst gerne helfen will, aber auch nicht jedes Mal das gleiche Schreiben will.
Hier mal ein ähnlich gelagerter Fall bzgl. Deiner Großgeräte.
Muss man nicht so lösen, aber hier kann man mit der Aggregator Node und der RBE Node einiges machen.https://forum.iobroker.net/topic/44925/node-red-wama-status
@almeda sagte in wait until-ähnliche Node / Arbeit mit "Context":
Bei meiner Recherche bin ich auf eine Node aus dem Homematic-Bereich gestoßen, die sich wait-until nennt. Diese nimmt den msg.payload, hält ihn eine Zeit x fest und wenn nach der Zeit x immer noch keine neuer msg.payload eingegangen ist, schickt er die msg weiter. Dies würde das Problem sehr gut lösen, nützt mir aber nichts, weil kein Homematic.
So eine Node - mit sogar noch viel breiterem Funktionsspektrum - ist im Standardumfang von NodeRed vorhanden und nennt sich trigger Node.
Hier muss man nichts nachbauen - das gibts alles schon.
Zu Deinem 2. Problem sollte fast funktionieren.
Nur wenn Du schon in NodeRed in Javascript programmieren willst dann solltest wissen, dass man Vergleiche auch mit Typen also mit "===" machen sollte. (https://www.w3schools.com/js/js_operators.asp) Zudem bin ich mir nicht sicher, ob Du in Deiner Adapterkonfiguration diese dumme Stringkonvertierung ausgeschaltet hast. Dann vergleichst Du wahrscheinlich Bools mit Strings und brauchst Dich nicht wundern, dass Deine Vergleiche ins Leere laufen. Prüfe einfach mal im Kontektmenü, wie denn der Inhalt Deiner Variablen ausschaut und dann wirst Du schnell die Ursache finden, warum Deine Vergleiche nicht aufgehen. Jedenfalls ist das etwas, was ich jedem gleich am Anfang empfehle, sofort die Stringkonvertierung aufzuheben, sonst macht das später nur umso mehr Arbeit.
In Deinem Fall würde ich auch beide Kontakte zu einem Objekt in einer Flowvariable zusammenfassen, wobei Du einfach viel verloren gibst, wenn Du wieder das tolle an Node Red nämlich Deine Visualisierung Deiner Logik in Programmkontext einer Function Node versteckst. Was willst Du denn mit dem Ergebnis anfangen? Du musst dann die payload wieder analysieren, um Deine Flows je nach Zustand unterschiedlich zu behandeln. (Ist payload = Fenster offen, Fenster geschlossen, Fenster gekippt) Dann kannst Du doch gleich die Flows entsprechend im Vorfeld analysieren.
In meinen Augen ist auch ein Fehler in Deiner Logik (selbst wenn Du die richtigen Typen miteinander vergleichen willst).
Ich gehe mal davon aus, dass Du 2 Kontaktsenstoren am Fenster hast, um den Gekippt-Zustand ebenfalls erfasst. Wenn also beide Kontakte offen (false) sind, ist in meinen Augen das Fenster nicht gekippt sondern offen. Aber gut, das würdest Du alles selbst noch rausfinden.Dann ist das Fenster aber offen, wenn beide Kontakte offen sind und geschlossen, wenn beiden Kontakte zu sind (also true in Deinem Fall) - gekippt ist dann aber der einzige wo nur der obere Kontakt offen ist.
Das heißt von der Logik her: Der untere Kontakt sagt Dir immer, ob das Fenster offen ist, während der obere Kontakt nur in dem Fall überprüft werden muss, wenn der untere Kontakt geschlossen ist.
Meinst Du nicht, dass so was viel anschaulicher und NodeRed eher gerecht wird, als Deine Abfragen über eine Function Node?
-
@mickym vielen Dank für deine geduldige und ausführliche Antwort.
Zunächst zu deiner Kritik: Ich habe die Suchfunktion tatsächlich mehrmals bemüht, bevor ich mein Thema erstellte, nur eben nicht das passende gefunden. Daher auch meine anfänglich Frage gerne nach einem Verweis zu entsprechender Literatur, wo ich mir die benötigten Dinge anlesen kann.
Ich habe jetzt schon einige Themen gelesen und bewundere tatsächlich sehr, mit welcher Leichtigkeit du Node-Red zu beherrschen scheinst. Und wenn ich deine Lösungsansätze dann so lese, denke ich jedes Mal "Mhm gute Idee und eigentlich total simple". Aber selbst komme ich noch nicht auf diese Lösungswege und versuche anscheinend immer zu viel auf einmal zu wollen.
Zum 2. Problem:
Du hast total recht, ich habe 2 Kontakte und das Problem mit der Statusänderung bei jeweils nur einem Kontakt war mir zwar schon aufgefallen (ich hatte nämlich schon mal eine halb funktionierende Lösung mit einer Join-Node), aber ich wollte das Problem angehen, wenn ich zumindest bei "geschlossen" und "offen" wenigstens schon mal ein korrektes Ergebnis erzielt hatte.
Ziel ist am Ende, den Status grafisch in einer Visualisierung anzuzeigen und für weitere Dinge wie "Es regnet gleich, ein Fenster ist noch offen/gekippt" zu verwenden.Danke erstmal für die gegebenen Gedankenanstöße, ich versuch das nun mal entsprechend umzusetzen. Sollte ich noch irgendwo hängen bleiben, frage ich noch einmal nach.
-
@almeda sagte in wait until-ähnliche Node / Arbeit mit "Context":
@mickym vielen Dank für deine geduldige und ausführliche Antwort.
Zunächst zu deiner Kritik: Ich habe die Suchfunktion tatsächlich mehrmals bemüht, bevor ich mein Thema erstellte, nur eben nicht das passende gefunden. Daher auch meine anfänglich Frage gerne nach einem Verweis zu entsprechender Literatur, wo ich mir die benötigten Dinge anlesen kann.
Also ich hoffe es ist in jedem Fall angekommen, dass ich gerne helfe und meistens gibt es auch nicht nur EINE Lösung, sondern mehrere Lösungen und jeder muss für sich die beste Lösung herausfinden. Warum ich vielleicht auf die Suchfunktion hingewiesen hatte, weil ich das Thema erst kürzlich hatte. In letzter Konsequenz muss man auch logisch überlegen, ob über die Trigger Node oder die Blockly Lösung diese wirklich zielführend ist. Wichtig ist ja, dass man sich über die Konsequenzen einer Lösung im Klaren ist. Wenn ich also herausfinde, dass im Normalverlauf eines Programms des Stromverbrauchs einer Wasch- oder Spülmaschine herausfinde, dass einen niedrigen Stromverbrauch für eine Zeitraum x anhält, dann wird sich ein Ende auch erst herausfinden lassen, wenn der Zeitraum x + abgelaufen ist. Meine Spülmaschine braucht nur wenn ich sie einschalte und nur die Lämpchen leuchten bereits 3 Watt, schaltet sich aber nach Ende komplett ab - das hier kann ich sehr exakt auf 0 Watt abprüfen. Bei anderen Maschinen gibt es wegen Knitterschutz etc. andere Probleme. Aber es ist ja auch gut, mal diese Probleme von der Logik her anzugehen.
Ich habe jetzt schon einige Themen gelesen und bewundere tatsächlich sehr, mit welcher Leichtigkeit du Node-Red zu beherrschen scheinst. Und wenn ich deine Lösungsansätze dann so lese, denke ich jedes Mal "Mhm gute Idee und eigentlich total simple".
Danke schön.
Ich muss aber auch sagen bzw. Dir Mut machen, dass Du das auch hinbekommst, je mehr Du Dich mit diesem tollen Produkt beschäftigst und vor allem bereit bist über die eigene Logik nachzudenken. Ich mache dass nun seit knapp 2 Jahren und meine ersten Flows sind aus heutiger Sicht auch eine Katastrophe. Oft bin ich nur zu faul, das in Angriff zu nehmen, da es funktioniert. Du wirst auch erleben, dass Du bei bestehenden Themen einen bestimmten Leidensdruck benötigt, um die Dinge in Angriff zu nehmen. Meine Lichtsteuerung ist ein gutes Beispiel. Die ist soweit perfektioniert, dass sowohl bewegungs- als auch Lichtabhängig geschaltet wird und auch von Tageszeit. Aber es gab Situationen, wo ich an einem düsteren Regentag mich geärgert habe, dass das Licht sich immer automatisch ausgeschaltet hatte. Ich wusste genau warum - aber es hat einen gewissen Leidensdruck benötigt bis ich mich darum gekümmert habe.Aber selbst komme ich noch nicht auf diese Lösungswege und versuche anscheinend immer zu viel auf einmal zu wollen.
Am Anfang zu viel auf einmal zu wollen ist auch ganz natürlich. Du wirst aber sehen, wie sehr es Dein logisches Denken im allgemeinen verbessert, wenn man die Dinge in seine Einzelteile zerlegt, aber das Große und Ganze nicht aus den Augen verliert. Deswegen kann man als Außenstehender immer dann am Besten helfen, wenn man weiß wo die Reise hingehen soll und nicht nur Teilprobleme gemeldet wird, wie ersetze ich Teilstrings usw. . Du wirst in manchen Threads auch feststellen, dass ich mich selbst verbessere in dem mir dann immer leichtere Lösungen einfallen. Das heißt auch das ist ganz normal, wenn sich die eigenen Lösungen im Verlauf vereinfachen und verbessern.
Zum 2. Problem:
Du hast total recht, ich habe 2 Kontakte und das Problem mit der Statusänderung bei jeweils nur einem Kontakt war mir zwar schon aufgefallen (ich hatte nämlich schon mal eine halb funktionierende Lösung mit einer Join-Node), aber ich wollte das Problem angehen, wenn ich zumindest bei "geschlossen" und "offen" wenigstens schon mal ein korrektes Ergebnis erzielt hatte.Danke erstmal für die gegebenen Gedankenanstöße, ich versuch das nun mal entsprechend umzusetzen. Sollte ich noch irgendwo hängen bleiben, frage ich noch einmal nach.
Wenn Du die Fähigkeiten von NodeRed kennenlernen willst, versuche wirklich am Anfang bewusst function Nodes zu meiden, wo Du es nur kannst. Es gibt Situationen , wo man sie braucht oder wo der Flow zu ausufernd wird, und damit der Übersichtlichkeit leidet - aber wie gesagt am Anfang versuche die function Nodes zu vermeiden wo Du kannst. Du kannst einen Flow in eine function Node packen, aber Dir geht der Sinn dieser Flows verloren.
Hier habe ich mal die gleiche Logik mit und ohne function Node implementiert:
Ich habe festgestellt, dass es immer weniger wurden, je länger ich das Produkt genutzt habe.
Hier habe ich mal ein paar in meinen Augen gute Quellen und die tollen Videos von Steve zusammengefasst.
Ansonsten stehe ich Dir gerne mit Antworten zu Deinen Fragen zur Verfügung, wenn ich helfen kann bzw. auch weiß - manches gerade im Systemumfeld ist dann auch eher was für andere Spezialisten hier an Board. Alles kann ich auch nicht lösen - insbesondere aus der Ferne ist das oft schwierig.
-
@mickym
Danke für deine erneute ausführliche Antwort. Leider komme ich nicht weiter, was sicherlich an meinem Anfängerstatus liegt.
Zunächst: "IoBroker-Werte in String konvertieren" war tatsächlich ein, habe ich nun ausgestellt.Bezüglich Fensterkontakte:
Ich habe die Logikidee von dir nun einmal ohne Funktion umgesetzt. Funktioniert leider weiterhin nicht.
Die Injections-Nodes für True/False sind nur die Platzhalter für die KNX-In-Node, um nicht ständig das Fenster auf- und zumachen zu müssen. (Meine Frau wird wahnsinnig, so oft hab ich die schon gekippt )Flow hab ich hier mal angehängt:
Bin gespannt, was du sagst...
-
@almeda Also zuerst einmal bitte ich Dich neben den Spoiler die Code Tags </> zu nutzen, das macht das Kopieren wesentlich einfacher.
Zweites ist das eine gute Idee - das mit Inject Nodes zu simulieren - bei Exportieren brauche ich auch die KNX Nodes nicht, da ich ja auch nur mit Inject Nodes simulieren kan.
Drittens kann Dein Flow nicht funktionieren, da
Du in deiner ChangeNode oben immer true reinschreibst - egal was Du versuchst mit Deiner Inject Node zu schreiben. Schau Dir den Inhalt der Flow Variablen also immer im Kontextmenü an.
Ich nehme mal an, dass die Bezichnung 459 von KNX herkommt.Um also den Inhalt Deiner Flow Variablen auf true oder false zu setzen - musst Du oben naturlich die Flow Variable auf die payload setzen, die Du über die Inject Nodes initiierst - also :
Das Topic ist hier völlig irrelevant - das benutzt Du gar nicht und kannst es ggf. aus den InjectNodes löschen.
In den Kontextdaten siehst Du dann ja (refresh - nach jedem Drücken der Inject Node) ob sich die Variable auch ändert:
Die Trigger für den Status sind irrelevant da kann drin stehen was will. Für Dein Beispiel langt also eine Inject Node. Dass ggf. dann mehrere Trigger zum Anstoßen des Flows nimmst ist was anderes.
Mir fehlt ausserdem in der Flow-Variable der 2. Kontakt. Gehe ich mal davon aus, dass der Kontakt 458 unten ist und 459 oben, dann kannst Du 2 Flow Variablen setzen oder 1 Objekt. Können wir gerne später machen - dann benennt man die Flowvariable wie das Fenster und nutzt 458 für unten und 459 für oben.
Aber wenn Du nur mit dem unten als Trigger arbeiten willst wie in Deinem Flow dann passt zwar der 1. Switch - aber was Du mit den 2. machst ist mir schleierhaft.
Um den Status Deiner Flow Variablen zu überprüfen interessiert Dich weder die payload und die payload wird nie 459 oder ungleich 459 sein, so wie Du es definiert hast.
In dem Fall ist ja durch den 1. Switch bekannt, dass die payload immer true ist!!! Und nun willst Du den Status der flow variablen abfragen:
Also muss der 2. Switch wie folgt aussehen:
Im 2. Fall prüfst Du nur ab, dass nur true durchgelassen wird. Wenn beide Kontakte false wären, würde Dir das Fenster auf den Kopf fallen.
Kannst ja als Katastrophenszenario noch einbauen. Geh jetzt mal eine Runde in den Biergarten - also kommt momentan höchstens Text als Antwort. 
Hier zum Import bitte das nächste Mal auch in CodeTags:
Wie gesagt - ich würde beide Kontakte in Flows schreiben und beide Kontakte triggern lassen.
Im Moment triggert nur Dein unterer Kontakt. Wenn Du also von geschlossen auf gekippt stellst, wird der Flow nicht angetriggert.
Deshalb hier die endgültige Lösung - bevor ich mich auf den Weg mache:
Und wenn Du das Ganze in Schön machen willst, speicherst Du es als ein Fensterobjekt mit Kontakt oben und unten.
Also Flow.WohnzimmerRechts.unten und Flow.WohnzimmerRechts.oben. Außer Deine knx Adressen sind Dir schon so im Fleisch und Blut 🩸
Im Prinzip ist es sogar umgekehrt. Eigentlich brauchst für die Statusermittlung nur den oberen Kontakt als Trigger. Dann kann man sich das mit den 2 Variablen auch sparen. Allerdings musst Du den unteren Status immer zuerst abfragen. Ich bin leider auch nicht sofort optimal logisch -
@mickym said in wait until-ähnliche Node / Arbeit mit "Context":
@almeda Also zuerst einmal bitte ich Dich neben den Spoiler die Code Tags </> zu nutzen, das macht das Kopieren wesentlich einfacher.
Alles klar, wird in Zukunft gemacht..
Du in deiner ChangeNode oben immer true reinschreibst - egal was Du versuchst mit Deiner Inject Node zu schreiben. Schau Dir den Inhalt der Flow Variablen also immer im Kontextmenü an.
Ok ich hatte wohl nicht begriffen, wie flow-Variablen funktionieren, aber deine Erläuterung hat nun sehr dazu beigetragen, dass mein Verständnis gewachsen ist. Hab dein Flow erstmal nicht kopiert und importiert, sondern erstmal versucht, anhand deiner Erklärungen, die Probleme auszumerzen und das hat gut geklappt. thumps up
Ich nehme mal an, dass die Bezichnung 459 von KNX herkommt.
Korrekt, dass ist das sog. Kommunikationsobjekt des betreffenden Fensterkontakts.
Mir fehlt ausserdem in der Flow-Variable der 2. Kontakt. Gehe ich mal davon aus, dass der Kontakt 458 unten ist und 459 oben, dann kannst Du 2 Flow Variablen setzen oder 1 Objekt. Können wir gerne später machen - dann benennt man die Flowvariable wie das Fenster und nutzt 458 für unten und 459 für oben.
Also ob die Kontakte oben und unten verbaut sind, weiß ich nicht, da ich nur die aus dem Sturz kommenden Kabel angeschlossen habe, alles andere hat der Fensterbauer fix fertig eingebaut. Ich weiss nur folgende Konstellationen:
458 True 459 True = Fenster zu
458 False 459 False = Fenster kipp
458 True 459 False = Fenster offenTatsächlich fände ich eine Lösung als Objekt gut, da dies die Sache vllt. kompakter machen könnte. Ich meine ich habe einige Fenster und müsste jetzt für jedes einen solchen kompletten Flow, wie du ihn final mit beiden Kontakten als Träger reingestellt hast, anlegen. Überlege gerade ob es auch eine Möglichkeit gibt, das Kommunikationsobjekt aus der KNX-in-Node nicht in eine Variable zu übergeben, sodass sich dann das Objekt in einer Flow-Variablen automatisch anlegt. Dann müsste man den ersten Teil nur einmal schreiben?!?
aber was Du mit den 2. machst ist mir schleierhaft.
Hier habe ich versucht, das jeweilige True/False-Ergebnis (aus 458) aus der ersten Switch-Node mit dem Inhalt der Flow-Variable (aus 459) zu vergleichen. War vllt. ein Denkfehler. Ich sag ja, ich denke irgendwie noch viel zu kompliziert.
Wie gesagt - ich würde beide Kontakte in Flows schreiben und beide Kontakte triggern lassen.
Im Moment triggert nur Dein unterer Kontakt. Wenn Du also von geschlossen auf gekippt stellst, wird der Flow nicht angetriggert.Absolut berechtigter Einwand, war auch so gedacht und muss ja eigentlich auch so sein, wenn man bedenkt, dass z. B. von zu auf offen, oder von offen auf kipp immer nur ein Fensterkontakt und dessen Status aktualisiert wird.
Und wenn Du das Ganze in Schön machen willst, speicherst Du es als ein Fensterobjekt mit Kontakt oben und unten.
Also Flow.WohnzimmerRechts.unten und Flow.WohnzimmerRechts.oben. Außer Deine knx Adressen sind Dir schon so im Fleisch und Blut 🩸
Im Prinzip ist es sogar umgekehrt. Eigentlich brauchst für die Statusermittlung nur den oberen Kontakt. Dann kann man sich das mit den 2 Variablen auch sparen. Allerdings musst Du den unteren Status immer zuerst abfragen. Ich bin leider auch nicht sofort optimal logischAlso meine Kommunikationsadressen sind mir tatsächlich in Fleisch und Blut übergegangen, nachdem ich vor der externen Logik mit Node-Red schon einiges in den Logik-Engines der KNX Aktoren umgesetzt habe
Wie oben schon gesagt, wie das mit den Objekten funktioniert, würde ich mir gerne noch mal in einem Beispiel hierzu ansehen.
Kühles Bierchen und vllt. später wenn du noch Zeit hast, würde ich mich hier über Erhellung noch freuen -
@almeda ist das wirklich sicher, dass zweimal false gekippt ist. Das ist für mich total unlogisch
-
@mickym
Absolut sicher.
Hab es jetzt auch so eingestellt und eben mal am lebenden Objekt getestet, funktioniert so einwandfrei. -
@almeda OK.
Dann noch mal eine grundsätzliche andere Methode, als über Flow Variablen. Diese sind eigentlich, wenn man nur einen 2. Parameter braucht etwas "overengineered".
Wenn Du das mit den Objekten verstehen willst - ist das ziemlich easy. Ein Objekt besteht aus mehreren Eigenschaften, die wiederum verschiedene Datentypen enthalten können oder weitere Objekte enthalten:
https://www.w3schools.com/js/js_objects.asp
var car = {type:"Fiat", model:"500", color:"white"};In diesem Beispiel gibt es also ein Objekt car mit den Eigenschaften type, model und color.
Zwischen den einzelnen Nodes in NodeRed werden Nachrichtenobjekte verschickt bzw. das Objekt msg. Das enthält unter anderem meist eine Eigenschaft payload, das die Nutzdaten enthält und die Eigenschaft topic - die beschreibt um was es sich handelt. Wenn Du die Debug Nodes umstellst, dass sie Dir das ganze Nachrichtenobjekt zeigen dann siehst Du das auch.
Deswegen bietet die Inject Node diese beiden Eigenschaften als Standard an - das ist aber kein MUSS.
Bei einer Standard Debug Node - wird in der Grundeinstellung nur die payload ausgegeben und das Topic in Rot.
Man sieht das msg.topic Fensterstatus und dass die Eigenschaft msg.payload ausgegben wird.
Lässt Du Dir aber das ganze msg- Objekt ausgeben.
Damit wird dann das gesamte msg Objekt, wie in der Inject Node definiert - ausgegeben:
Um das Object car in die Inject Node aufzunehmen, definiere ich einfach eine weiter Eigenschaft car - das ein Objekt darstellt.
Das Objekt in der Inject-Node wird automatisch konvertiert, wenn man es als JSON String eingibt:
Inzwischen hat das Nachrichtenobjekt also neben der Eigenschaft, topic und payload noch eine Eigenschaft car, das wiederum 3 weitere Eigenschaften enthält.
Eine neue Eigenschaft kann ich auch direkt definieren. Nehmen wir an wir wollen der Eigenschaft car noch die Eigenschaft fuel mit dem Wert Diesel hinzufügen, so geht das einfach durch:
Braucht man nur 2 oder 3 Eigenschaften in einem Nachrichtenobjekt muss man diese nicht in einer Flow-Variablen sammeln sondern kann das auch direkt im Nachrichtenobjekt machen, zumindest wenn man iobroker Datenpunkte hat. Dann sammelt man diese einfach ein und hat sie dann auch ohne Flow-Variablen immer im Huckepack.
Zur Demo habe ich mal 2 Datenpunkte mit 458 und 459 angelegt:
Als Trigger werde ich die beiden Punkte triggern lassen und die payload in die Eigenschaft 458 und 459 verschieben.
Der Wert false ist in der payload des msg.Objektes wenn diese Datenpunkte getriggert werden. Im topic sieht man den Pfad (das ist leider nicht konsistent mal mit / mal mit .)
Wir verschieben nun im jeweiligen Datenobjekt den Wert der payload in die Eigenschaft des msg.objektes in 458 bzw, 459
Mit der iobroker GET Node holen wir uns nun in jedes Nachrichtenobjekt den jeweils fehlenden Teil herein.
In den Get-Nodes kann man direkt spezifizieren in welche Eigenschaft des Nachrichtenobjektes geschrieben werden soll - ist also nicht zwangsläufig die payload:
Man sieht nun, dass in jedem Nachrichtenobjekt beide Eigenschaften enthalten sind:
Nachdem Du das ja mit den Objekten denke ich verstanden hast, kannst Du die Status in einer Flow Variablen für viele Fenster sammeln.
Ich fasse jetzt mal gekippt und offen als offen zusammen und geschlossen ist geschlossen.
Lassen wir mal einfach, ob das nun gleich zu lassen: geschlossen = true und offen = false;
Über 2 weiter Change Nodes setze ich in einer Flow Variablen mit dem Objekt die Eigenschaft Wohnzimmer auf den Status true oder false (je nachdem ob ein Fenster geöffnet ist oder nicht).
Du siehst im Kontext also die Variable Fenster ist nun ein Objekt:
Du wirst nun mehrere Flows haben - für jedes Fenster ich kopiere jetzt nicht die Flows sondern setze einfach mal ein Flowvariablen für verschiedene Fenster.
Bei Bedarf hole ich die Flow Variable wieder in eine payload, um sie zu analysieren oder abzuspeichern:
Nun kannst Du das ganze noch in einem JSON String wandeln, um es in einem ioBroker Datenpunkt zu speichern:
Diesen String kannst Du dann in einem Datenpunkt speichern oder Du nutzt meinen Subflow um eine hiearchische Datenstruktur im iobroker anzulegen
Hier nochmal den gesamten Flow zum Spielen und Ausprobieren:
-
Als Ergänzung solltest Du aber immer überlegen worauf Du hinauswillst.
Anstelle den Status des Fenster mit offen oder geschlossen = true oder false zu beschreiben, könntest Du Dir auch einen Zahlencode überlegen.
0 = geschlossen
1 = gekippt
2 = offenWenn Du später einen Alarm programmieren möchtest kannst Du dann das Level einstellen - zum Beispiel 0 (für Urlaub) oder 1 (für kurzfristige Abwesenheit).
Dann speicherst Du den Status der Fenster mit diesem Code. Im Urlaub löst Du dann Alarm aus, wenn Status >0 also geöffnet oder gekippt, bei kurzfristiger Abwesenheit ist Alarm wenn Status > 1, dann wird nur Alarm bei geöffnetem Fenster gegeben.
Da musst halt im Vorfeld überlegen, was Du machen willst. Die Split Nodes können Dir die Objekte zerlegen und die JOIN Nodes alles wieder zusammenfassen. Dazwischen machst Du die Analysen, die Du willst.
-
@mickym Sorry offtopic aber eine gute Gelegenheit es mal anzusprechen. Ich habe schon viele deiner Erklärungen zum Thema node-red gelesen und einiges gelernt. Dafür erst einmal vielen Dank. Es scheint ja leider nicht sehr viele Nutzer zu geben die dieses Instrument einsetzen. Ich muss gestehen das mir zB Blockly leichter fällt und mich sehr viel schneller ans Ziel bringt. Dennoch fasziniert mich node-red und ich versuche zumindest ein Teil meiner Automatisierung damit umzusetzen. Du hast nicht zufällig "versteckt" auf irgendeiner Webpage ein Tutorial verfasst was einem das Thema, in deiner sehr guten erklärweise, rüber bringt
-
@noah3112
Hatte ich schon mal gepostet - deshalb hier einfach noch mal rauskopiert:
Hier gibts ein paar deutschsprachige Videos:
https://haus-automatisierung.com/nodered-tutorial-reihe/Nur die Function Nodes würde ich nie nutzen, dass geht mit Change Nodes viel einfacher!!!
Die besten Tutorials sind in Englisch - aber ich finde den Typ eigentlich super - sodass man es auch als nicht nativ-Speaker versteht.
aber empfehlen würde ich Dir diese Seite:
http://www.steves-internet-guide.com/node-red-overview/dann die ersten Videos von Steve unter
Using Node-Red Nodesstartet hier:
Beginners Guide to Node Red Inject and Debug Nodes
Ich finde, selbst wenn man nicht gut Englisch kann, kann mir hier durch Zuschauen viel von Steve lernen.
Ausserdem hast Du wenn Du eine Node in Deinen Flow ziehst - über die Node Hilfe eine Beschreibung, wie der Node funktioniert.Schau mal ob Dir das hilft.
Ich selbst habe kein Tutorial verfasst.
Ansonsten hier noch der Link zum Forum: https://nodered.org/Und falls ich Dir anhand einer konkreten Aufgabenstellung helfen soll, dann melde Dich einfach über einen Thread - da konnte ich ja schon manches erklären.
Ich muss gestehen das mir zB Blockly leichter fällt und mich sehr viel schneller ans Ziel bringt.
Das kann ich ja gar nicht verstehen. Ist bei mir umgekehrt - aber vielleicht kann ich ja was dafür tun, dass sich an der Geschwindigkeit was ändert.
Ach und am Besten Du nimmst ein bestehendes Blockly und versuchst das mal in NodeRed umzusetzen - dann siehst ja wie beides funktioniert und was ggf. einfacher ist. Das Prinzip ist nämlich immer das Gleiche - egal was Du nutzt:
Trigger => Verarbeitung => Steuerung bzw. Ausgabe
