Hilfe bei debuggen einer übernommenen Funktion
-
@bf0911 Na wenn du es wirklich übernommen hast, dann sollte es nicht passieren.
Schau mal ob du die Nachrichten nicht durchreichst?
das muss natürlich deaktiviert sein.
Ggf. musst DU natürlich bei ALLEN Dashboard Feldern schauen, dass Du die Nachrichten nicht durchreichst!!! (Also auch nicht bei Schaltern(switches) etc.)
-
@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:
Ich hab den Flow mit dem Dashboard zu übernommen, aber es lassen sich keine Zahlen einstellen
Das springt immerUnd ggf. immer Debug Nodes an die letzte Node vorne und direkt dahinter machen. Prüfen, wenn Du das Kabel vorne trennst, ob es an ankommenden Nachrichten liegt oder nicht. Das ist ja nun das schöne, dass Du sowas gut debuggen kannst.
-
Ist es bei mir!
Ich hab deinen Flow natürlich mit meinen Variablen angepasst.
Jetzt scheint es zu funktionieren, obwohl ich nichts geändert habe
-
@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:
Jetzt scheint es zu funktionieren, obwohl ich nichts geändert habe
Na dann weiß ich auch nicht - und lässt sich ja auch nicht mehr nachvollziehen.
Wenn ein undefined drin ist (wie bei der Pumpe ) oder was das für eine Node ist
kann ich dir nicht sagen.
-
@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:
Jetzt scheint es zu funktionieren, obwohl ich nichts geändert habe
Vielleicht war auch noch was von Deinem alten Flow aktiv - dass den Kontext gesetzt hat? - Ich würde Dir raten den alten Flow komplett zu deaktivieren - damit Du nur noch die Nodes ggf. hast, um die raus zu kopieren.
-
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.
