NEWS
Hilfe bei debuggen einer übernommenen Funktion
-
Ja, die beiden Dosierpumpen brauche nur überprüft werden, wenn die Filterpumpe und der Durchflussschalter aktiv.
@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:
Ja, die beiden Dosierpumpen brauche nur überprüft werden, wenn die Filterpumpe und der Durchflussschalter aktiv.
Also wenn das so ist, dann kannst Du doch das obere Scheduler Signal direkt verwenden.
Du deaktivierst die Blockfunktion und erhälts alle 30 Sekunden einen Trigger und musst nicht extra überprüfen, ob die Filternode läuft.
Vielleicht langen aber auch die 60 sekunden, wie gesagt ich würde für den Filter trotzdem vielleicht einen Filter einbauen, damit der Filter nicht alle 30 oder 60s ein Ein- oder Ausschaltsignal bekommt.
Wenn Du also permanent Dir ein Signal ausgeben lässt, dann filterst du hinten und greifst vorne das true Signal für die Filternode ab.
Sprich gleichzeitig mit dem Einschaltsignal für die Filternode (das ja nun zyklisch alle 30s oder alle 60s) von der scheduler Node ausgegeben wird überprüfst Du nun ob die anderen beiden Pumpen eingeschaltet werden, wenn die Filternode ausgeschaltet wird passiert nicht.
Vielleicht sollten die dann aber auch ausgeschaltet werden. Dann musst Du nicht die Bedingungen abfragen, sondern machst das Gleiche als ob du die Automatik ausschaltest. Ich bin mir nicht sicher, warum man das unterschiedlich behandelt und es nicht sinnvoller ist grundsätzlich beim Ausschaltsignal für die Filternode, die beiden anderen Pumpen zuerst auszuschalten und dann mit 1 Minute Verzögerung die Filternode.
-
@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:
Ja, die beiden Dosierpumpen brauche nur überprüft werden, wenn die Filterpumpe und der Durchflussschalter aktiv.
Also wenn das so ist, dann kannst Du doch das obere Scheduler Signal direkt verwenden.
Du deaktivierst die Blockfunktion und erhälts alle 30 Sekunden einen Trigger und musst nicht extra überprüfen, ob die Filternode läuft.
Vielleicht langen aber auch die 60 sekunden, wie gesagt ich würde für den Filter trotzdem vielleicht einen Filter einbauen, damit der Filter nicht alle 30 oder 60s ein Ein- oder Ausschaltsignal bekommt.
Wenn Du also permanent Dir ein Signal ausgeben lässt, dann filterst du hinten und greifst vorne das true Signal für die Filternode ab.
Sprich gleichzeitig mit dem Einschaltsignal für die Filternode (das ja nun zyklisch alle 30s oder alle 60s) von der scheduler Node ausgegeben wird überprüfst Du nun ob die anderen beiden Pumpen eingeschaltet werden, wenn die Filternode ausgeschaltet wird passiert nicht.
Vielleicht sollten die dann aber auch ausgeschaltet werden. Dann musst Du nicht die Bedingungen abfragen, sondern machst das Gleiche als ob du die Automatik ausschaltest. Ich bin mir nicht sicher, warum man das unterschiedlich behandelt und es nicht sinnvoller ist grundsätzlich beim Ausschaltsignal für die Filternode, die beiden anderen Pumpen zuerst auszuschalten und dann mit 1 Minute Verzögerung die Filternode.
-
Hole ich mir das dann mit der Link-In-Node in den Zweig?
Dann ist dass das TRigger-Signal, wie bekomme ich dann die beiden MQTT-Arrays dazu? Einfach mit hier drauf?
@bf0911 Na über die mqtt-In Nodes spreicherst Du die entweder im Kontext oder wenn es eh im iobroker ist - holst Du Dir die Werte zur Laufzeit rein.
Wie gesagt ich bin mit Deiner Filterpumpenlogik s. unten noch nicht so klar.
Warum gibt es also unterschiedliche Vorgehensweisen, ob die Filterpumpe bei Deaktivieren der Automatik oder durch den Zeitplan ausgeschaltet werden soll??? - Das erschließt sich mir als Laie erst mal nicht.
-
@bf0911 Na über die mqtt-In Nodes spreicherst Du die entweder im Kontext oder wenn es eh im iobroker ist - holst Du Dir die Werte zur Laufzeit rein.
Wie gesagt ich bin mit Deiner Filterpumpenlogik s. unten noch nicht so klar.
Warum gibt es also unterschiedliche Vorgehensweisen, ob die Filterpumpe bei Deaktivieren der Automatik oder durch den Zeitplan ausgeschaltet werden soll??? - Das erschließt sich mir als Laie erst mal nicht.
Das ist ein sehr gute Anmerkung.
Ich hatte jetzt so gedacht, dass die Deaktivierung der Pool-Automatik direkt bzw. nach 1 Minute ausschalten soll, z. B. man stellt eine Undichtigkeit etc fest.
Und der Zeitplan ist der Regel-Betrieb, wobei halt da nur darauf geachten werden soll, dass die Dosierpumpen zu dem Zeitpunkt nicht laufen, damit die Chemie nicht in den Rohren bleibt.
Vielleicht denke ich auch zu kompliziert.
Wir können daher (erstmal) eine Vorgehensweise nutzen.
-
Das ist ein sehr gute Anmerkung.
Ich hatte jetzt so gedacht, dass die Deaktivierung der Pool-Automatik direkt bzw. nach 1 Minute ausschalten soll, z. B. man stellt eine Undichtigkeit etc fest.
Und der Zeitplan ist der Regel-Betrieb, wobei halt da nur darauf geachten werden soll, dass die Dosierpumpen zu dem Zeitpunkt nicht laufen, damit die Chemie nicht in den Rohren bleibt.
Vielleicht denke ich auch zu kompliziert.
Wir können daher (erstmal) eine Vorgehensweise nutzen.
@bf0911 Na ja dann schadet es aber auch nicht, wenn Du grundsätzlich die Filterpumpe immer erst 1 Minute nach dem Abschalten der Dosierpumpen abschaltest.
Und nochmal - Du wirst später sehen, dass es viel einfacher ist, wenn man die Logik zu Beginn so einfach wie möglich hält. Mit den Konfigurationsänderungen der ui schedulers können wir das nun wie folgt vereinfachen:
So nun wird grundsätzlich die Filterpumpe 1 Minuten nachdem die Dosierpumpen ausgeschaltet wurden, egal ob die Automatik deaktiviert wurde oder der Zeitplan das vorgibt.
Wenn die Filterpumpe eingeschaltet wird, werden die beiden Dosierpumpen mitein geschaltet. Und nun kannst Du noch die Bedingungen einfügen, ob die wirklich eingeschaltet werden oder ggf. wieder ausgeschaltet werden. Ist das für Dich nachvollziehbar?
Und hier der Import des Flows:
EDIT: So hier nochmal der überarbeitete Flow. Oben filtern wir die periodischen Signale mit der filter Node für die Filter-Pumpe zum ein- und ausschalten weg, so dass nur noch die Ein- und Ausschaltsignale durchkommen.
Unten hingegen werden die periodischen "true"" Signale für die Dosierpumpen verwendet.
-
@bf0911 Na ja dann schadet es aber auch nicht, wenn Du grundsätzlich die Filterpumpe immer erst 1 Minute nach dem Abschalten der Dosierpumpen abschaltest.
Und nochmal - Du wirst später sehen, dass es viel einfacher ist, wenn man die Logik zu Beginn so einfach wie möglich hält. Mit den Konfigurationsänderungen der ui schedulers können wir das nun wie folgt vereinfachen:
So nun wird grundsätzlich die Filterpumpe 1 Minuten nachdem die Dosierpumpen ausgeschaltet wurden, egal ob die Automatik deaktiviert wurde oder der Zeitplan das vorgibt.
Wenn die Filterpumpe eingeschaltet wird, werden die beiden Dosierpumpen mitein geschaltet. Und nun kannst Du noch die Bedingungen einfügen, ob die wirklich eingeschaltet werden oder ggf. wieder ausgeschaltet werden. Ist das für Dich nachvollziehbar?
Und hier der Import des Flows:
EDIT: So hier nochmal der überarbeitete Flow. Oben filtern wir die periodischen Signale mit der filter Node für die Filter-Pumpe zum ein- und ausschalten weg, so dass nur noch die Ein- und Ausschaltsignale durchkommen.
Unten hingegen werden die periodischen "true"" Signale für die Dosierpumpen verwendet.
Ich sag mal so halb. Das Trigger-Signal für die Logik der Dosierpumpen ist jetzt das "True"-Signal der Zeitsteuerung.
So wie es in dem Beispiel-Flow ist, würden die Dosierpumpen aber direkt laufen, richtig?
Das würde bedeuten, dass die Logik für die Dosier-Pumpen ganz unten im Flow vor der jeweilige Iobroker-out-Node ist, richtig?
Was noch fehlt, ist ob die Filter-Pumpe wirklich läuft. Das muss ich mir ebenfalls noch in den unteren Zweig holen.
-
Ich sag mal so halb. Das Trigger-Signal für die Logik der Dosierpumpen ist jetzt das "True"-Signal der Zeitsteuerung.
So wie es in dem Beispiel-Flow ist, würden die Dosierpumpen aber direkt laufen, richtig?
Das würde bedeuten, dass die Logik für die Dosier-Pumpen ganz unten im Flow vor der jeweilige Iobroker-out-Node ist, richtig?
Was noch fehlt, ist ob die Filter-Pumpe wirklich läuft. Das muss ich mir ebenfalls noch in den unteren Zweig holen.
@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:
So wie es in dem Beispiel-Flow ist, würden die Dosierpumpen aber direkt laufen, richtig?
Ja - aber das hab ich ja gesagt, du sollst jetzt die Bedingungen in diesen Ast einfügen, ja und vor die iobroker-Out Nodes eingefügt werden. :+1: :+1: :+1:
Jeder Flow bzw. jedes Script, das ich hier poste implementiert jeder auf eigene Gefahr. Flows und Scripts können Fehler aufweisen und weder der Seitenbetreiber noch ich persönlich können hierfür haftbar gemacht werden. Das gleiche gilt für Empfehlungen aller Art.
-
@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:
So wie es in dem Beispiel-Flow ist, würden die Dosierpumpen aber direkt laufen, richtig?
Ja - aber das hab ich ja gesagt, du sollst jetzt die Bedingungen in diesen Ast einfügen, ja und vor die iobroker-Out Nodes eingefügt werden. :+1: :+1: :+1:
-
Ich sag mal so halb. Das Trigger-Signal für die Logik der Dosierpumpen ist jetzt das "True"-Signal der Zeitsteuerung.
So wie es in dem Beispiel-Flow ist, würden die Dosierpumpen aber direkt laufen, richtig?
Das würde bedeuten, dass die Logik für die Dosier-Pumpen ganz unten im Flow vor der jeweilige Iobroker-out-Node ist, richtig?
Was noch fehlt, ist ob die Filter-Pumpe wirklich läuft. Das muss ich mir ebenfalls noch in den unteren Zweig holen.
@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:
Was noch fehlt, ist ob die Filter-Pumpe wirklich läuft. Das muss ich mir ebenfalls noch in den unteren Zweig holen.
Wie gesagt, Du kannst jetzt unten soviel abprüfen, wie Du willst. Da der Scheduler das Signal ja periodisch ausgibt, werden die Zustände des Gesamtsystem nun alle 30 oder 60 Sekunden ausgegeben.
-
Macht es sind, der Übersichtlichkeit, das Signal des Schedulers per Link-in und Link-out in die jeweilige Logik-Gruppe zu holen oder sollte man das komplett in eine Gruppe packen?
@bf0911 Im Moment würde ich nicht mit Links arbeiten - und ja die Logik für die einzelnen Dosierpumpen kannst Du dann Gruppieren, um das besser zu sehen. Mit Link Nodes würde ich erst dann arbeiten, wenn Dir der Platz nicht ausreicht. Die Gruppierung machst Du dann aber einfach später drum rum.
Ich würde dann wenn das zu komplex werden sollte - dann kann man mit Link Call Nodes arbeiten, um quasi Unterprogramme in einem Flow zu erzeugen. Aber im Moment würde ich alles zusammenhalten, das ist jetzt noch viel übersichtlicher.
-
Ich sag mal so halb. Das Trigger-Signal für die Logik der Dosierpumpen ist jetzt das "True"-Signal der Zeitsteuerung.
So wie es in dem Beispiel-Flow ist, würden die Dosierpumpen aber direkt laufen, richtig?
Das würde bedeuten, dass die Logik für die Dosier-Pumpen ganz unten im Flow vor der jeweilige Iobroker-out-Node ist, richtig?
Was noch fehlt, ist ob die Filter-Pumpe wirklich läuft. Das muss ich mir ebenfalls noch in den unteren Zweig holen.
@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:
Was noch fehlt, ist ob die Filter-Pumpe wirklich läuft. Das muss ich mir ebenfalls noch in den unteren Zweig holen.
In dem Fall würde ich sogar gar nicht auf die payload des Schedulers abprüfen, sondern mir für beide Pumpen den Status der Filter-Pumpe reinholen!!
Also so:
Damit überschreibst Du die payload aus der ui-scheduler Node und verwendest gleich den Status der Filterpumpe als Filter.
Du brauchst dann also kein extra Attribut für die get Node.
-
@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:
Was noch fehlt, ist ob die Filter-Pumpe wirklich läuft. Das muss ich mir ebenfalls noch in den unteren Zweig holen.
In dem Fall würde ich sogar gar nicht auf die payload des Schedulers abprüfen, sondern mir für beide Pumpen den Status der Filter-Pumpe reinholen!!
Also so:
Damit überschreibst Du die payload aus der ui-scheduler Node und verwendest gleich den Status der Filterpumpe als Filter.
Du brauchst dann also kein extra Attribut für die get Node.
ok, soweit verstanden und (hoffentlich) richtig umgesetzt.
Ich hab noch zusätzlich zur Filter-Pumpe den Durchflussschalter abgefragt. Der hat das Attribute msg.paddelschalter bekommen.
Jetzt muss ich von "Durchfluss vorhanden" auf die jeweilige Logik. Das wäre dann auf "PH-Wert", wie bekomme ich nun die Payloads aus den beiden MQTT-Arrays in den Zweig. Gehen die auch einfach auf "PH-Wert"?
-
@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:
So wie es in dem Beispiel-Flow ist, würden die Dosierpumpen aber direkt laufen, richtig?
Ja - aber das hab ich ja gesagt, du sollst jetzt die Bedingungen in diesen Ast einfügen, ja und vor die iobroker-Out Nodes eingefügt werden. :+1: :+1: :+1:
@mickym sagte in Hilfe bei debuggen einer übernommenen Funktion:
@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:
So wie es in dem Beispiel-Flow ist, würden die Dosierpumpen aber direkt laufen, richtig?
Ja - aber das hab ich ja gesagt, du sollst jetzt die Bedingungen in diesen Ast einfügen, ja und vor die iobroker-Out Nodes eingefügt werden. :+1: :+1: :+1:
Du musst also jetzt diese ganzen Parameter ermitteln und dann einsetzen:
dass wenn die Chlor-Pumpe nicht aktiv ist, Durchfluss vorhanden ist, die PH-Pumpe-Tageslaufzeit kleiner als die maximale Ph-Pumpe-Zeit ist, der PH-Wert größer als der PH-Grenzwert, die PH-Automatik
-
ok, soweit verstanden und (hoffentlich) richtig umgesetzt.
Ich hab noch zusätzlich zur Filter-Pumpe den Durchflussschalter abgefragt. Der hat das Attribute msg.paddelschalter bekommen.
Jetzt muss ich von "Durchfluss vorhanden" auf die jeweilige Logik. Das wäre dann auf "PH-Wert", wie bekomme ich nun die Payloads aus den beiden MQTT-Arrays in den Zweig. Gehen die auch einfach auf "PH-Wert"?
@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:
Ich hab noch zusätzlich zur Filter-Pumpe den Durchflussschalter abgefragt. Der hat das Attribute msg.paddelschalter bekommen.
Musst Du nicht machen - das macht es doch nur kompliziert.
Schau am Anfang wird die payload auf den Status der Filter-Pumpe gesetzt und der Flow geht nur weiter, wenn diese true ist. Nun kannst Dir doch den Status des Paddleschalters in die payload holen (überschreibst damit den Status der Filter-Pumpe - den brauchst Du aber nicht, da Du ja ab diesem Zeitpunkt davon ausgehen kannst, dass die Filterpumpe läuft), den Status der Filter-Pumpe brauchst Du doch nicht mehr und prüfst in der anschließenden switch Node wieder nur die payload. Zusätzliche Attribute brauchst Du nur, wenn Du beide Zustände noch verknüpfen willst.
Jetzt muss ich von "Durchfluss vorhanden" auf die jeweilige Logik. Das wäre dann auf "PH-Wert", wie bekomme ich nun die Payloads aus den beiden MQTT-Arrays in den Zweig. Gehen die auch einfach auf "PH-Wert"?
Nun da müsstest Du mir zeigen, was aus den beiden mqtt nodes rauskommt und was Du damit machen willst.
-
@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:
Ich hab noch zusätzlich zur Filter-Pumpe den Durchflussschalter abgefragt. Der hat das Attribute msg.paddelschalter bekommen.
Musst Du nicht machen - das macht es doch nur kompliziert.
Schau am Anfang wird die payload auf den Status der Filter-Pumpe gesetzt und der Flow geht nur weiter, wenn diese true ist. Nun kannst Dir doch den Status des Paddleschalters in die payload holen (überschreibst damit den Status der Filter-Pumpe - den brauchst Du aber nicht, da Du ja ab diesem Zeitpunkt davon ausgehen kannst, dass die Filterpumpe läuft), den Status der Filter-Pumpe brauchst Du doch nicht mehr und prüfst in der anschließenden switch Node wieder nur die payload. Zusätzliche Attribute brauchst Du nur, wenn Du beide Zustände noch verknüpfen willst.
Jetzt muss ich von "Durchfluss vorhanden" auf die jeweilige Logik. Das wäre dann auf "PH-Wert", wie bekomme ich nun die Payloads aus den beiden MQTT-Arrays in den Zweig. Gehen die auch einfach auf "PH-Wert"?
Nun da müsstest Du mir zeigen, was aus den beiden mqtt nodes rauskommt und was Du damit machen willst.
Gerne.
aus Pool/Ph-Parameter kommt
{"Pausenzeit_min":15,"Laufzeit_sec":60,"MaxTagesLaufzeit_min":5,"PH_Grenzwert":7.2,"PH_Pumpe_Automatik":"OFF"}und aus PH-Pumpe-Tageslaufzeit kommt
{"minutes":3,"hours":"0.04"}Da sind Werte für einzelne Logik-Schritte drin, wie prüfe ob Max.Tageslauf kleiner als Tageslaufzeit ist oder ob PH-Wert größer als Grenzwert ist.
Ich hoffe du, verstehst was ich meine.
Quasi Variablen ;-)
-
Gerne.
aus Pool/Ph-Parameter kommt
{"Pausenzeit_min":15,"Laufzeit_sec":60,"MaxTagesLaufzeit_min":5,"PH_Grenzwert":7.2,"PH_Pumpe_Automatik":"OFF"}und aus PH-Pumpe-Tageslaufzeit kommt
{"minutes":3,"hours":"0.04"}Da sind Werte für einzelne Logik-Schritte drin, wie prüfe ob Max.Tageslauf kleiner als Tageslaufzeit ist oder ob PH-Wert größer als Grenzwert ist.
Ich hoffe du, verstehst was ich meine.
Quasi Variablen ;-)
@bf0911 Nun ja - dann machst du es so, wie es wahrscheinlich urspünglich war und speichere die Ausgaben dieser beiden mqtt nodes in Kontextvariablen. Ich denke das geht noch in Flow Variablen und brauchst Du nicht in globale Variablen. Ausser Du willst Deine Steuerung auf mehrere Flows verteilen, wofür ich im Moment aber noch keinen Anlaß sehe.
Am Besten Du nimmst es direkt wo du es berechnest.
Hier hast Du doch die Laufzeit berechnet:
https://forum.iobroker.net/post/1159698dann fügst Du halt in diese Change Node gleich die Speicherung in die flow Variable ein und gut ist. Dann bleibt das übersichtlich und Du brauchst die mqtt-IN Node für die Laufzeit gar nicht
-
@bf0911 Nun ja - dann machst du es so, wie es wahrscheinlich urspünglich war und speichere die Ausgaben dieser beiden mqtt nodes in Kontextvariablen. Ich denke das geht noch in Flow Variablen und brauchst Du nicht in globale Variablen. Ausser Du willst Deine Steuerung auf mehrere Flows verteilen, wofür ich im Moment aber noch keinen Anlaß sehe.
Am Besten Du nimmst es direkt wo du es berechnest.
Hier hast Du doch die Laufzeit berechnet:
https://forum.iobroker.net/post/1159698dann fügst Du halt in diese Change Node gleich die Speicherung in die flow Variable ein und gut ist. Dann bleibt das übersichtlich und Du brauchst die mqtt-IN Node für die Laufzeit gar nicht
-
Also, so wie im alten Skript!?!
Das mit dem berechnen habe ich auch verstanden.
Die Ph-Parameter kommen einfach vom Dashboard. Dann ich lass ich die bei der Logik oder lieber beim "Dashboard" schreiben?
-
@bf0911 Nein das ist viel zu umständlich.
Wie gesagt die Dauer hast Du doch unten berechnet.
Und die Ausgabe der anderen mqtt-In Node speicherst Du in EINER Flowvariable.
Ok, da werde ich mich morgen früh direkt ransetzen.
Dann kann ich die Logik natürlich entsprechend für die Chlor-Pumpe übernehmen und anpassen!!
Was dann noch fehlt, ist das periodische Ein- und Ausschalten der Dosier-Pumpen in Abhängigkeit der über das Dashboard eingestellte Lauf- und Pausenzeit, damit das Becken nicht sinnlos überdosiert wird.
Kannst du das ganz kurz umreißen? Im Urpsrungs-Skript wurde das (natürlich) wieder mit Funktions-Nodes gelöst.
DAmit verabschiede ich mich erstmal bis morgen.
Ich danke dir, wiederholt, für deine Geduld und Mühe!
-
Ok, da werde ich mich morgen früh direkt ransetzen.
Dann kann ich die Logik natürlich entsprechend für die Chlor-Pumpe übernehmen und anpassen!!
Was dann noch fehlt, ist das periodische Ein- und Ausschalten der Dosier-Pumpen in Abhängigkeit der über das Dashboard eingestellte Lauf- und Pausenzeit, damit das Becken nicht sinnlos überdosiert wird.
Kannst du das ganz kurz umreißen? Im Urpsrungs-Skript wurde das (natürlich) wieder mit Funktions-Nodes gelöst.
DAmit verabschiede ich mich erstmal bis morgen.
Ich danke dir, wiederholt, für deine Geduld und Mühe!
@bf0911 Nun das Setzen der Lauf und Pausenzeiten kann ich so nicht sehen. Das wird auch erstmal eigens gemacht.
Nun erstmal zurück zu Deinen beiden Parametern ph Laufzeit und ph Parameter.
Also die Laufzeit berechnest Du ja bereits - also gehe ich mal davon aus, das wird schon irgendwo getriggert.
Du kannst also in der gleichen Change Node, inder Du die Laufzeit berechnest, die Laufzeit auch in der Flowvariablen speichern.Sprich Du musst das nicht mehr einlesen oder extra triggern lassen, sondern speicherst es gleich in einer Flowvariablen
Die ph-Parameter aus mqtt - reißt man nicht auseinander sondern speichert es als ein Objekt ab.
Im Kontext sind dann die kompletten Objekte gespeichert.
Wenn Du dann über die SwitchNode Bedinungen abfragen möchtest, kannst du es dann direkt tun ohne diese Parameter in das Nachrichtenobjekt einzulesen.
Sprich du kopierst Dir aus dem Kontext direkt den Pfad zu der Eigenschaft, die du untersuchen willst.
in diesem Fall ist es der ph Grenzwert.
Wenn du den Pfad kopiert hast:
PH_Parameter.PH_Grenzwertkannst Du das entweder direkt in der Switch Node vergleichen - hier am Beispiel PH-Wert
oder Du holst Dir vorher das ganze Objekt in die Nachricht und kannst dann auch Parameter mit einander vergleichen.
Man könnte es auch machen ohne sich das Objekt in das Nachrichtenobjekt zu holen, dann musst Du halt 2 mal mit JSONATA den entsprechenden Wert holen.
Hier zum Ausprobieren:
Support us
814
Online32.4k
Benutzer81.6k
Themen1.3m
Beiträge