Hilfe bei debuggen einer übernommenen Funktion
-
Danke, habe den Flow direkt deaktiviert.
-
@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:
Danke, habe den Flow direkt deaktiviert.
Wie gesagt auch für später ist es immer wichtig die Stellen, wo Du was ausgibst möglichst übersichtlich hälst. Im Idealfall einmal - manchmal auch an mehreren Stellen, um das Ganze übersichtlich zu halten.
-
Ich verabschiede mich dann mal, wenn Du noch was auf dem Herzen hast dann schreibs rein. Entweder bekommst dann eine Antwort direkt, aber ich geh ja mal davon aus, dass Du am Nachmittag dann wieder ins reale Leben abtauchst.
-
Ich bedanke mich total bei dir!
Ich habe soviel gelernt und verstanden! Stark!
Ja, genau, ich bin gleich auch erstmal wieder in der echten Welt.
Werde mich aber sicherlich nochmal melden, spätestens wenn der Flow komplett ist!
-
Es scheint immer noch ein Problem mit dem "Vergleich" ist zu Gesamt-Laufzeit Ph-Pumpe zu geben
Egal, welche deiner beiden Nodes ich nutze, es wird kein true weitergeleitet.
Es kommt auf jeden Fall von "Chlor-Pumpe nicht aktiv?" noch ein True. Das habe debuggt.
-
@bf0911 Na sowas kann ich doch gar nicht beantworten.
Du verdoppelst die Nachricht und deaktivierst die Tageslaufzeit.
Was kommt den wo raus?
-
Und bei den Schaltern für den Automatik-Modus Chlor und PH gibt es Problem.
Die Schalter werden bei den Strings "ON" und "OFF" geschaltet.
Da muss offensichtlich was anderes rein
-
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.
