NEWS
Hilfe bei debuggen einer übernommenen Funktion
-
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.
-
@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
- Alle Flows neustartest
- 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: