Hilfe bei debuggen einer übernommenen Funktion
-
@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.
-
@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"?
-
@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.
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
-
@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
-
@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!
-
@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:
-
@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:
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.
Ich hab den Flow nochmal am Anfang verändert und auch nur die Dosierpumpenansteuerung gefiltert, wenn der Zeitplan aktiv ist, sonst kann das mit dem Ausschalten Konfliktsituationen ergeben.
Was ich aber hier schon sehe mit count Down Nodes etc - finde ich schon wieder Mist. Sowas macht man mit trigger Nodes - die schon an Board sind.
Sprich Du überprüfst die Laufzeit am Anfang und dann lässt Du einfach die Pumpe eine von Dir definierte Zeit laufen.
Während dieser Zeit würde ich mit einem trigger Block auch noch dafür sorgen, dass während der Laufzeit der Pumpe keine weitere Nachricht ankommt.Sprich um das jetzt konkreter zu machen und dieses Wirr-Warr da oben zu entwirren.
Prüfst Du also erst für die ph Pumpen mit Pausen und Laufzeiten.
Ich hab hier mal einen Vorschlag - ohne Fachwissen natürlich.
Die Parameter im Kontext musst Du natürlich selbst setzen.
Jedenfalls finde ich diesen Flow wesentlich übersichtlicher, als dieses Wirr-warr da oben und mit den function Nodes als Black-Boxes.
Hier mal alles zum Import:
-
Guten Morgen,
das mit den Variablen habe ich soweit umgesetzt.
Deinen neuen Flow hab ich auch schon geladen, was mir da direkt auffällt, dass du die "Vergleiche" per JSONata machst.
Ich hatte gehofft, meine Bedingungen so abzufragen.
-
Wenn ich deinen neuen Flow richtig interpretiere, wird nach Ablauf der Laufzeit ein "False" an die Pumpe gesendet und dann über den anderen Trigger die Pausenzeit abgewartet, richtig?
Dann hast du ja noch das "Trigger & Block" gesetzt, welche nur ein "False" ausgeben würde, wenn ich den "manuellen Reset" nutze.
Nutzt dieser Block dann das "true" der Bedingungen und wenn da ein False wäre, würde die Pumpe noch für die eingestellte Zeit laufen und dann nicht mehr, weil am Trigger & Block kein True mehr durchkommt? -
Egal, ob ich deine Change- und Switch-Node für die max. Laufzeit nutze oder auch meine, bei beiden wird kein True ausgegeben.
Die Tageslaufzeit steht auf 0 Minuten und die max. Tages-Laufzeit auf 5 Min. Damit wäre ja eigentlich die Bedingung erfüllt.
-
Und dann (mutmaßlich zum Schluss) stehe ich noch vor der Herausforderung,
die einstellbaren Parameter ohne Function-Node zu erstellen.
So ist es im eigentlichen Skript:
Ich glaube auch verstanden zu haben, was dort gemacht wurde, erholt sich aus der Flow.Variable Ph-Parameter die einzelne Werte, schreib die in das jeweilige msg.payload, dieser payload wird über das Dashboard geändert und mit der zweiten Function-Node wieder ins Array geschrieben.
Ich gehe davon aus, dass man fürs zurückschreiben wieder JSONata nutzen muss, da wäre mir aber die Syntax nicht klar.
-
@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:
Guten Morgen,
das mit den Variablen habe ich soweit umgesetzt.
Deinen neuen Flow hab ich auch schon geladen, was mir da direkt auffällt, dass du die "Vergleiche" per JSONata machst.
Ich hatte gehofft, meine Bedingungen so abzufragen.
Ja das geht auch prinzipiell, allerdings muss der variable Teil in dem Vergleich oben abgefragt werden.
- das geht auf jeden Fall:
- das geht nicht - bzw. Du musst das umdrehen:
das habe ich gerade getestet (damit kannst Du die ChangeNode) weglassen in meinem Flow:
Hier habe ich es mal getrennt getestet:
Kannst ja selbst so ausprobieren:
3. geht schon - aber willst Du eine Nachrichteneigenschaft abfragen?
- Sollte auch gehen, aber ansonsten wie 2.
Also im Prinzip geht das alles, wie Du es Dir vorstellst. Bei Vergleichen innerhalb von Kontextvariablen würde ich aber ggf. testen.
-
@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:
Egal, ob ich deine Change- und Switch-Node für die max. Laufzeit nutze oder auch meine, bei beiden wird kein True ausgegeben.
Die Tageslaufzeit steht auf 0 Minuten und die max. Tages-Laufzeit auf 5 Min. Damit wäre ja eigentlich die Bedingung erfüllt.
Das geht aber musst ggf nochmal Deinen Kontext überprüfen:
Dann über switch Node direkt oder über Change Node.
-
@bf0911 Um Dein Dashboard zu intialisieren brauchst Du das topic nicht. Dieser Mensch scheint irgendwie nicht begriffen zu haben, dass man in das topic auch Objekte schreiben kann.
Du lädst Dir einmal den Kontext in eine payload und verteilst das dann über eine Change Node direkt an Dein Dashboard.
Vorher solltest Du aber den Kontext über mqtt bereits eingelesen haben. Also in dem Fall musst Du wohl mit dem retain Flag arbeiten oder Du speicherst grundsätzlich nicht in mqtt sondern im iobroker.Du musst jedenfalls kein JSONATA verwenden, sondern geht alles direkt - so wie auch bei den switch Nodes, wie unten beschrieben.
Wie gesagt Du musst Dir halt mal überlegen, ob Du für die Speicherung mal generell mqtt oder den iobroker verwendest.
Ich hab mal nur als Parameter für Dein Dashboard den Grenzwert und die max. Tageslaufzeit genommen.
Ist also sehr einfach, ohne JSONATA und alles.
Du holst Dir also den ganzen Kontext in Dein Nachrichtenobjekt und initialisierst dann einfach die Inputfelder mit den Eigenschaften deines Objektes ph-Parameter. Du musst halt nach dem Neustart warten bis Dein Kontext initialisiert ist (bei mqtt durch das Retain oder bei Iobroker In durch das sofortige Auslesen).
Ich habe deshalb mal den Init auf 10s gestellt. Eventuell brauchst noch länger:
Wie Du siehst kannst Du die Ausgabe des Dashboards direkt in die Parameter im Flowkontext schreiben,
Eigentlich doch sehr easy und verständlich. Hier der Flow:
-
Danke für deine Ausführungen.
Ich hatte es mit der Nachrichten-Eigenschaft so verstanden, dass ich dafür z. B. False oder True von den Pumpen abfragen kann.
Deswegen msg.chlorpumpe.
