Hilfe bei debuggen einer übernommenen Funktion
-
Der Debug-Node "Chlor-Pumpe nicht aktiv?" gibt ein True aus, das soll ja durch "<max. Laufzeit" oder "max.Laufzeit nicht erreicht?" weitergeleitet werden, auf die Abfrage "PH-Automatik aktiv?" und dann ja die PH-Pumpe einschalten.
Die beiden Nodes sind jetzt aus Testgründen zusammen drin.
Nehme ich die Max-Tageslaufzeit-Abfrage raus, funktioniert die Logik und die PH-Pumpe schaltet
-
@bf0911 Wie gesagt teste es in dem Du Dir die Switches aus dem Flow einzeln testest:
Test Deine Switch Nodes halt getrennt vom Flow:
Oben lässt durch, weil die Automatik auf OFF steht.
und bei der Laufzeit das Gleiche - wie gesagt die Konstante unten rein.
Wie du siehst wird bei 8 Minuten geblockt und unter 7 Minuten nicht.
Was im Kleinen funktioniert, funktioniert dann auch im Flow.
Die Anzeige des Kontexts musst Du bei jeder Ansicht neu aktualisieren:
-
Node passt jetzt und der PH-Automatik-Zweig läuft (so wie er soll).
Danke!
Was ich eben noch festgestellt habe, ist dass wenn ich die Filter-Pumpe manuell per (Soft- oder Hardware)-Schalter einschalte, dass hier natürlich die Laufzeit auf eine Minute begrenzt ist, weil ja, die Zeitsteuerung nicht aktiv ist.
Das ist suboptimal. Was wäre hier ein sinnvoller Weg? Doch mit einem Betriebsmodus zu arbeiten?
Ideal wäre es, wenn ich die Pumpe zusätzlich zum Scheduler einschalten kann, sie dann aber so lange läuft bis der Scheduler ein False sendet.
-
@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:
Was ich eben noch festgestellt habe, ist dass wenn ich die Filter-Pumpe manuell per (Soft- oder Hardware)-Schalter einschalte, dass hier natürlich die Laufzeit auf eine Minute begrenzt ist, weil ja, die Zeitsteuerung nicht aktiv ist.
Das widerspricht sich doch in der Aussage?
Die Laufzeit ist doch nicht begrenzt, wenn die Zeitsteuerung nich aktiv ist?
Die Zeitsteuerung hat doch nur die ph-Pumpe gesteuert?Und wenn Du willst, dass die ph-Pumpen Steuerung immer aktiv ist, egal ob manuell oder automatisch geschaltet wird, dann musst Du halt einfach den ganzen Block rausnehmen und dann ist er unabhängig von der Filterpumpen automatik.
Ansonsten kannst Du oben ja nochmal gerne nur den Automatikmodus ermitteln und ggf. unten noch blockieren.
Ich würde jedoch sauberer die ph-Pumpen oder welche Pumpen auch immer aus dem Automatikast entfernen, wenn diese Logik auch erhalten bleiben soll unabhängig, ob die Filterpumpenautomatik aktiv ist.
Aber letztlich glaube ich, dass Du das selbst nun umsetzen kannst. Das sind ja nun keine technischen Probleme mehr.
Wie gesagt oben habe ich Dir nochmal die Nodes zur Verfügung gestellt mit der Du prüfen bzw. eine Flowvariable setzen kannst, um zu prüfen ob der Automatikmodus der scheduler Node für die Filterpumpe aktiv ist. -
Ich werde mich nächste Woche mal ransetzen, danke!
Doch, die Laufzeit der Filterpumpe ist ja auf 1 Minute begrenzt, wenn der Scheduler ein "False" ausgibt.
Das nur noch als Info.
Ich melde mich, wenn ich eine Lösung "programmiert" habe.
-
@bf0911 Ok ich habe Dir ja unten eine Lösung gepostet, der den ganzen Flow blockiert, wenn die Automatik abgeschaltet wurde.
-
ich hab am langen Wochenende festgestellt, dass die PH-Pumpe noch lief und die Filter-Pumpe sich aber schon ausgeschaltet hatte.
Jetzt stehe ich etwas auf dem Schlauch, woran, dass gelegen haben könnte.
Ich vermute mal, dass der PH-Pumpe-Logik-Pfad noch durch ein "True" der Filterpumpe getriggert wurde, dann entsprechend gepumpt hat. Was ich aber nicht verstehe, ist warum die PH-Pumpe, durch diesen Zweig, nicht ausgeschaltet wurde.
-
@bf0911 Na ja auf Deinem Screenshot sieht man ja nicht den Status der Nodes nicht. Du kannst ja auch noch mal die Zeitstempel in dem Shelly Adapter überprüfen, ob die PH Pumpe nach der Filter Pumpe nochmals eingeschaltet wurde.
Generell prüfst Du ja auch noch nach dem Ausschalten der Pumpe und vor dem Ausschalten der Filterpumpe, ob beide Pumpen ausgeschaltet sind.
Und dann sollten ja Debug Meldungen auftauchen. Vielleicht schreibst Du debug Meldungen wieder in das iobroker-log (Systemkonsole) (musst aber unbedingt die aktuelle Version drauf haben - in der 5.0.x Versionen hat man das leider fehlerhafterweise entfernt).
Auserdem kannst Du ja mal versuchen - den scheduler zu durch Durchtrennen der Kabel zu deaktivieren und mit Inject Nodes mit true und false dieses Verhalten mit Inject Nodes zu simulieren, wie Du dir das denkst.
Und ganz zuletzt kannst mit einer Inject Node - noch einen unabhängigen Scheduler erstellen, der Dir in bestimmten Zeitabständen den Zustand Deiner Pumpen überprüfst (zumindest testweise).
Ich vermute mal, dass der PH-Pumpe-Logik-Pfad noch durch ein "True" der Filterpumpe getriggert wurde, dann entsprechend gepumpt hat. Was ich aber nicht verstehe, ist warum die PH-Pumpe, durch diesen Zweig, nicht ausgeschaltet wurde.
Wenn dem so wäre, würde ich halt die Prüfung
ganz nach hinten machen - direkt vor dem true schalten - dann sollte das ja ausgeschlossen sein.
Dazu müsstest Du die Abprüfung ja nur nach in das orange markierte Kabel verlegen.
In die msg.reset Change Node kannst Du zur Sicherheit noch die payload löschen, damit (kann zwar in meinen Augen nicht) - da auf jeden Fall kein True der payload in den grauen Kasten gelangt:
Und wie bereits erwähnt - nutze die Debug Node nach der Filter Node, um Dir das triggern durch den Scheduler ins iobroker log zu schreiben:
Wenn Du das Debuggen in die Systemkonsole eingeschaltet hast, dann bekommt die Debug-Node so einen Pfeil
und Du siehst dann auch im Nachhinein - auch wenn Du den NodeRed Editor nicht offen hast, entsprechende Einträger im iobroker-log:
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.
Ganz zum Schluss kannst ja auch mal testen, indem Du mit einer Inject Node false hier manuell injizierst
ob der Shelly Adapter nicht überfordert ist, wenn beide Pumpen gleichzeitig ausgeschaltet werden. Wenn dem so sein sollte dann mach halt in einen Ast noch einen kleinen Delay von einer halben Sekunde rein. Glaub ich zwar nicht, aber kann man ja prüfen, ob die Adapter Befehle auch speichern oder quasi parallel abarbeiten.
Das Simulieren von Situation mit Inject nodes ist ja einer der wesentlichen Vorteile von NodeRed - anstelle von herkömmlicher Programmierung oder JS Code in function Nodes, da Du nun an jeder Stelle im Flow bestimmte Situation manuell triggern kannst.
-
Wow, wie immer eine ausführliche und verständliche Antwort.
Ich werde mir das mal mit deinen Tipps anschauen.
Danke!
-
@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.
-
@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.
-
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?
-
@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:
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.
-
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?
-
@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.
-
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?
-
@bf0911 Keine Ahnung. Wo mache ich das denn?
-
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
-
@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:
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.
-
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.
