Hilfe bei debuggen einer übernommenen Funktion

[BF0911]

@mickym

Wow, wie immer eine ausführliche und verständliche Antwort.

Ich werde mir das mal mit deinen Tipps anschauen.

Danke!

[BF0911]

@mickym said in Hilfe bei debuggen einer übernommenen Funktion:

Und zu guter Letzt - natürlich schauen, dass nirgendwo anders deine PH Pumpe steuerst - alte Flows deaktiviert und keine weiteren Stellen, an den die PH Pumpe gesteuert wird.

Wie genau meinst du das? oder bezieht sich das eher auf 2 Flows etc?

Die PH- und Chlor-Pumpe werden in den Flow an 2 Stellen geschaltet.

Einmal in dem "Zweig", Filter-Pumpe aus, dann Dosier-Pumpen aus und einmal in dem jeweiligen Logik-Zweig.

[mickym]

@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:

Einmal in dem "Zweig", Filter-Pumpe aus, dann Dosier-Pumpen aus und einmal in dem jeweiligen Logik-Zweig.

Na in dem Filter-Pumpe aus, können die ja nur ausgeschaltet werden, da ja nur false durchgelassen wird. In der Switch Node wird ja nur false durchgelassen (boolean).

Also kann ja nur an der Stelle mit der trigger node eingeschaltet werden. Also nur an einer Stelle. Wie gesagt Du kannst ja immer mit Inject Nodes testen oder die Bedingung dass die filter node aus sein muss, nach hinten an den ersten Ausgang der schaltenden trigger node machen.

Die Wahrscheinlichkeit dass noch ein true Signal unterwegs ist, während schon abgeschaltet wurde halte ich eher für gering. Ausserdem selbst wenn sich die PH-Pumpe für 1 Minute einschaltet, sollte sie sich ja selbst wieder abschalten.

Ich weiß ja nicht, ob Du noch irgendwo was manuell schaltest.

Wie gesagt mit debug Nodes und inject Nodes arbeiten. Mehr kann ich auch nicht sagen. Ansonsten mach Dir wie gesagt einen Überwachungsflow - der Dir alle x Minuten den Zustand Deiner Pumpen meldet.

Und wie gesagt die Debug Node beim Ausschalten, kannst Dir ja noch ins Log schreiben lassen

Allerdings würde dann ja eigentlich die Filternode nicht ausgeschaltet.

Wie gesagt - ich kanns mir im Moment auch nicht erklären, wenn der Flow so ist, wie ich ihn vor mir habe.

[BF0911]

@mickym

Ich hab mal wieder eine neue Idee, wo ich nicht so reicht weiß, wie man das sinnvoll umsetzt.

Ich möchte, dass die Dosierpumpen-Logik erst 15 oder 30 Minuten nach Start der Filterpumpe starten.

Das Delay-Node verzögert ja jede Nachricht um die entsprechende Zeit. Der UI-Scheduler schickt alle 30 Sekunden ein True oder False. Für mein Verständnis würde ja dann jedes true verzögert werden, was nicht gewünscht ist.

Jetzt hatte ich testweise mal ein Filter-Node vor dem Delay gesetzt. In meiner Testumgebung mit Inject-Node, kam nur ein True an, bis ich halt ein false schicke. Soweit so richtig.

Nun, ist die Frage, der Ui-Scheduler schickt ein "true" zum Start und triggern der einzelnen iobroker-get-Nodes. Diese werden dann aber durch den Filter dann erst wieder aktualisiert, wenn ein false kommt richtig? Und nicht wie bisher alle 30 SEkunden.

Lange Rede, kurzer Sinn, bin ich auf dem richtigen WEg oder total falsch?

[mickym]

@bf0911 Wenn Du das nicht mehr willst, dass der UI-Scheduler alle 30s sendet - dann brauchen wir auch keinen Filter Node für die Filterpumpe und den Rest der Pumpen - dann gewöhnen wir dem UI- Scheduler das Senden alle 30 s ab, in dem wir impliziert den Filter anwenden.

Sprich damit gewöhnen wir der UI-Scheduler Node generell ab, dass sie im Intervall sendet. Nun kommen nur noch Signale wenn der Zeitplan sich ändert. Diese Überpfügung alle 30 s kann man sich dann auch sparen und würde wieder auf default von 60s gehen, da Dich ja nur noch Änderungen interessieren.

Wenn du dass nun willst, das nur nach einem Aktivierungssignal nach 15 oder 30 Minuten der Flow für die Dosierpumpenlogik losläuft, dann nutze wieder eine Trigger Node.

Diese Trigger Node übernimmt vollständig das triggern der Dosierpumpen:

Immer versuchen den Flow so einfach wie möglich zu halten, um die Transparenz zu erhalten. Hier mal die veränderten Nodes zum Import:

Spoiler

[
   {
       "id": "678c75e771b741cf",
       "type": "ui_time_scheduler",
       "z": "d25606275138920f",
       "group": "3979c1d87146b072",
       "name": "",
       "startDay": 0,
       "refresh": "30",
       "devices": [
           "Filter-Pumpe"
       ],
       "singleOff": false,
       "onlySendChange": true,
       "customPayload": false,
       "eventMode": false,
       "eventOptions": [],
       "sendTopic": false,
       "lat": "",
       "lon": "",
       "customContextStore": "",
       "outputs": 2,
       "order": 1,
       "width": 0,
       "height": 0,
       "x": 130,
       "y": 1900,
       "wires": [
           [
               "734dada8a6cc2f4e"
           ],
           [
               "51faf2b5bfa34119"
           ]
       ]
   },
   {
       "id": "51faf2b5bfa34119",
       "type": "switch",
       "z": "d25606275138920f",
       "name": "Pumpenautomatik aktiv?",
       "property": "Pumpenautomatik",
       "propertyType": "flow",
       "rules": [
           {
               "t": "true"
           }
       ],
       "checkall": "true",
       "repair": false,
       "outputs": 1,
       "x": 370,
       "y": 2100,
       "wires": [
           [
               "bf1b3cdd0ebcbe1f",
               "10db98b5762e33d9"
           ]
       ]
   },
   {
       "id": "10db98b5762e33d9",
       "type": "trigger",
       "z": "d25606275138920f",
       "name": "",
       "op1": "",
       "op2": "true",
       "op1type": "nul",
       "op2type": "bool",
       "duration": "30",
       "extend": false,
       "overrideDelay": false,
       "units": "min",
       "reset": "false",
       "bytopic": "all",
       "topic": "topic",
       "outputs": 1,
       "x": 620,
       "y": 2460,
       "wires": [
           [
               "1371455361c75baf",
               "083d7a431bf1c459"
           ]
       ]
   },
   {
       "id": "083d7a431bf1c459",
       "type": "debug",
       "z": "d25606275138920f",
       "name": "Starte Dosierpumpen",
       "active": true,
       "tosidebar": true,
       "console": false,
       "tostatus": false,
       "complete": "payload",
       "targetType": "msg",
       "statusVal": "",
       "statusType": "auto",
       "x": 880,
       "y": 2400,
       "wires": []
   },
   {
       "id": "3979c1d87146b072",
       "type": "ui_group",
       "name": "Scheduler",
       "tab": "5fb772105c6cc8b7",
       "order": 2,
       "disp": true,
       "width": "6",
       "collapse": false,
       "className": ""
   },
   {
       "id": "5fb772105c6cc8b7",
       "type": "ui_tab",
       "name": "Home",
       "icon": "dashboard",
       "disabled": false,
       "hidden": false
   }
]

Da die trigger Node parallel für die Dosierpumpen genutzt wird, wird das triggern der Filter-Pumpe nicht verzögert.

Die trigger Node ist auch so definiert, wenn die Filterpumpen ausschalten, kommt ein false Signal, was den Trigger wieder zurücksetzt, sodass auch nicht 20 Minuten nach dem Ausschalten noch ein Einschaltsignal kommt.

Du kannst zwar nochmals überprüfen, ob die Filterpumpe läuft, aber das sollte nach der Logik ja nicht vorkommen und soweit ich in Erinnerung habe, prüfst Du das ja nochmal mit dem finalen Einschaltsignal.

[BF0911]

@mickym

Danke für die Ausführung.

Mein Flow sieht aktuell so aus:

Ich würde den Trigger ja hinter "Durchfluss vorhanden?" setzen.

Jetzt ist aber noch meine Frage offen, was passiert mit den Iobroker-Get-Nodes, wie "berechneter PH-Wert" oder "Filter-Pumpe", wenn ich den UI-Scheduler nicht mehr als 30 Sekunden aktualisieren lasse?

Dann würden die Werte doch nur bei jeder Werte-Änderung (True und False der Filter-Pumpe) aktualisiert oder?

Das macht natürlich wenig Sinn in so einer Logik.

Sollte man die Werte-Abfrage separieren und per Inject-Node, z. B. alle 30 SEkunden aktualisieren lassen und diese in Flow-Variablen schreiben lassen?

[mickym]

@bf0911 Nun ja ich denke, Du durchblickst das ja nun selbst nach Deinen Bedürfnissen. .

Ich würde den Trigger ja hinter "Durchfluss vorhanden?" setzen.

Ja wenn du den Scheduler so lässt, wie er ist, dann steuerst Du mit und ohne filter Node, ob alle 30s überprüft wird oder nur einmal.

Jetzt ist aber noch meine Frage offen, was passiert mit den Iobroker-Get-Nodes, wie "berechneter PH-Wert" oder "Filter-Pumpe", wenn ich den UI-Scheduler nicht mehr als 30 Sekunden aktualisieren lasse?

ja

Dann würden die Werte doch nur bei jeder Werte-Änderung (True und False der Filter-Pumpe) aktualisiert oder?

ja

Sollte man die Werte-Abfrage separieren und per Inject-Node, z. B. alle 30 SEkunden aktualisieren lassen und diese in Flow-Variablen schreiben lassen?

Kann man machen. Man kann aber auch, wenn die Pumpenautomatik aktiv ist, eine Triggernode alle 30 s triggern lassen.

Insgesamt glaube ich aber, dass Du das alles nun sehr gut verstanden hast und die Möglichkeiten nach Deinen Bedürnissen anzupassen.

[BF0911]

Ich hab nochmal eine eher allgemeinere Frage.

Wir fällt des öftern auf, dass sie die Einstellungen auf dem Dashboard auf "default" setzen.

Womit kann das zusammenhängen?

[mickym]

@bf0911 Keine Ahnung. Wo mache ich das denn?

[BF0911]

@mickym

Das wird meines Erachtens gar nicht gemacht, also irgendwelche Werte auf Default gesetzt.

Ich habe das Gefühl, dass sich das Dashboard die Werte nicht merkt bzw. die nicht mir mit dem Json übereinstimmt

[mickym]

@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:

@mickym

Das wird meines Erachtens gar nicht gemacht, also irgendwelche Werte auf Default gesetzt.

Ich habe das Gefühl, dass sich das Dashboard die Werte nicht merkt bzw. die nicht mir mit dem Json übereinstimmt

Ja das ist richtig. Das Dashboard zeigt nur an und hat auch nicht die Aufgabe sich irgendwas zu merken. Es ist Deine Aufgabe ggf. Werte zu speichern und bei einem Neustart von NodeRed die Werte wieder entsprechend zu initialisieren. Zum Speichern von Werten kannst Du ja entweder mqtt nehmen oder Datenpunkte im iobroker unter 0_userdata.0 erstellen.

Wobei ich bei dem Thema Hausautomation lieber bevorzuge aktuelle Werte zu haben und ggf. lieber die Dinge nicht initialisiert habe und weiß, dass sie aktuell sind. Aber das muss man von Fall zu Fall entscheiden.

Wenn Du aber zum Beispiel Deinen ui_scheduler nimmst, solltest Du bei jeder Änderungen im Dashboard Dir die Zeitpläne abspeichern und dann beim Neustart wieder einlesen. Deswegen hat der ui_scheduler ja auch einen Eingang.

Hier einfach mal die Hilfe zu der Node lesen:

Angeblich kann man zwar mit dem neuen Adapter ab 5.2 auf localfilesystem umstellen, aber ich hab das nicht gefunden. Deshalb bleibt das alles nur im Arbeitsspeicher und ist nach Neustart von NodeRed wieder weg. Wie gesagt, musst Du selbst dafür sorgen, ggf. die Zeitpläne in einem Datenpunkt abzuspeichern, dann bei Neustart wieder einzulesen und in den ui_scheduler einzuspeisen.

[BF0911]

@mickym

Entweder habe ich dich bzw. deine Antwort nicht ganz verstanden oder das Problem ist hier ein anderes.

Anbei drei Screenshots.

Zwei zeigen, das Dashboard, was sich willkürlich auf "Default" gesetzt hat.

Im Flow ist aber aus meiner Sicht, genau das, was du vorgeschlagen hast, bereits realisiert.

Es wird das "Objekt" Chlor-Parameter eingelesen und wenn dann über das Dashboard was geändert wurde, wieder in das Objekt geschrieben.

Die Werte im Objekt bleiben so, wie eingestellt, auch wenn das Dashboard sich auf "default" stellt.

z. B. der Redox-Grenzwert steht im Objekt auf 790 (gewünschte Einstellung) im Dashboard aber auf 750.

Ich hoffe, du verstehst was ich meine bzw. aus deiner Antwort verstanden habe.

[mickym]

@bf0911 Also ich kann Dir nur sagen, dass sich das Dashboard von sich aus nichts merkt. Wie gesagt werden die Defaultwerte nur gesetzt, wenn Du

1. Alle Flows neustartest
2. Den Adapter oder iobroker neu startest.

Wenn in den Objekten alles richtig ist, dann lies die halt beim Start von NodeRed ein.

So was sieht mir danach aus, als ob beim Start undefinierte Werte vorliegen.

Schau mal, ob Du beim Start von NodeRed das Objekt auch einliest.

Ansonsten musst Du schauen, woher die Werte kommen und wann das auftritt. Das Dashboard setzt sich nur bei Neustart oder beim Zurücksetzen aller Flows zurück.
Also Flows neustarten setzt auch das Dashboard zurück: