NEWS
Hilfe bei debuggen einer übernommenen Funktion
-
Hier der Screenshot für eine Change-Node.
Die Frage wird wohl noch öfters von dir kommen, warum ich etwas so mache, meistens wird die Antwort lautet: Weil ich es nicht besser wusste.
Auch in diesem Fall. Deine Erläuterung dazu sind für mich mehr als nachvollziehbar.
Was soll diesen Flow triggern?
Gute Frage, ich hätte jetzt gesagt, die Variable "Pool-Automatik".Die Dosierpumpen brauchen aus meiner Sicht nicht mit in den Scheduler aufgenommen werden und soll auch zeitlich nicht gesteuert werden, weil diese ja eh nur dosieren sollen, wenn der Filter-Pumpe läuft.
Im ursrünglichen Skript wurde das wohl mit Inject-Node (alle 30 Sekunden) getriggert.
-
Was soll diesen Flow triggern?
Gute Frage, ich hätte jetzt gesagt, die Variable "Pool-Automatik".Die Dosierpumpen brauchen aus meiner Sicht nicht mit in den Scheduler aufgenommen werden und soll auch zeitlich nicht gesteuert werden, weil diese ja eh nur dosieren sollen, wenn der Filter-Pumpe läuft.
Im ursrünglichen Skript wurde das wohl mit Inject-Node (alle 30 Sekunden) getriggert.
-
Was soll diesen Flow triggern?
Gute Frage, ich hätte jetzt gesagt, die Variable "Pool-Automatik".Die Dosierpumpen brauchen aus meiner Sicht nicht mit in den Scheduler aufgenommen werden und soll auch zeitlich nicht gesteuert werden, weil diese ja eh nur dosieren sollen, wenn der Filter-Pumpe läuft.
Im ursrünglichen Skript wurde das wohl mit Inject-Node (alle 30 Sekunden) getriggert.
@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:
Die Dosierpumpen brauchen aus meiner Sicht nicht mit in den Scheduler aufgenommen werden und soll auch zeitlich nicht gesteuert werden, weil diese ja eh nur dosieren sollen, wenn der Filter-Pumpe läuft.
Wäre es im Sinne der Logik und Nachvollziehbarkeit einfacher dann die Überprufung der anderen Pumpen nur dann zu machen, wenn man die Filter-Pumpe einschaltet? Allerdings würde ich den scheduler dann auf zyklischem Senden belassen und halt ggf. wenn Du das unbedingt willst auf 30s runtersetzen.
-
Ich bekomme folgende Fehlermeldung bei der Verwendung der Change-Node.
"Cannot set property of non-object type: payload.hours"
@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:
Ich bekomme folgende Fehlermeldung bei der Verwendung der Change-Node.
"Cannot set property of non-object type: payload.hours"
Dann mach vorher noch eine Regel, in der Du die payload als leeres payload Objekt initialisierst:
-
Ich bekomme folgende Fehlermeldung bei der Verwendung der Change-Node.
"Cannot set property of non-object type: payload.hours"
@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:
Ich bekomme folgende Fehlermeldung bei der Verwendung der Change-Node.
"Cannot set property of non-object type: payload.hours"
Wenn Du bissi mehr mit JSONATA gemacht hast dann kannst Du das Ganze auch in einer JSONATA Regel zusammenfassen. ;)
-
@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:
Ich bekomme folgende Fehlermeldung bei der Verwendung der Change-Node.
"Cannot set property of non-object type: payload.hours"
Wenn Du bissi mehr mit JSONATA gemacht hast dann kannst Du das Ganze auch in einer JSONATA Regel zusammenfassen. ;)
-
Danke, mit der "Regel" davor klappt es.
Hast du bewusst auf das runden verzichtet?
JSONNata wird sicherlich noch dauern. :-)
@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:
Danke, mit der "Regel" davor klappt es.
Hast du bewusst auf das runden verzichtet?
JSONNata wird sicherlich noch dauern. :-)
Nein das kannst Du schon davor machen, wenn Du willst. Ich zeige Dir trotzdem, wie du so ein Objekt super einfach mit JSONATA machst. Du wirst stauen. ;)
-
Danke, mit der "Regel" davor klappt es.
Hast du bewusst auf das runden verzichtet?
JSONNata wird sicherlich noch dauern. :-)
-
@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:
Danke, mit der "Regel" davor klappt es.
Hast du bewusst auf das runden verzichtet?
JSONNata wird sicherlich noch dauern. :-)
Nein das kannst Du schon davor machen, wenn Du willst. Ich zeige Dir trotzdem, wie du so ein Objekt super einfach mit JSONATA machst. Du wirst stauen. ;)
@mickym sagte in Hilfe bei debuggen einer übernommenen Funktion:
@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:
Danke, mit der "Regel" davor klappt es.
Hast du bewusst auf das runden verzichtet?
JSONNata wird sicherlich noch dauern. :-)
Nein das kannst Du schon davor machen, wenn Du willst. Ich zeige Dir trotzdem, wie du so ein Objekt super einfach mit JSONATA machst. Du wirst stauen. ;)
Also über JSONATA kannst Du Objekte gleich direkt definieren und auch gleich berechnen, in einem Zug:
Wenn Du auf die 3 Punkte klickst, kannst Du es im JSONATA Editor auch noch übersichtlich eingeben.
-
Ja, die beiden Dosierpumpen brauche nur überprüft werden, wenn die Filterpumpe und der Durchflussschalter aktiv.
@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:
Ja, die beiden Dosierpumpen brauche nur überprüft werden, wenn die Filterpumpe und der Durchflussschalter aktiv.
Also wenn das so ist, dann kannst Du doch das obere Scheduler Signal direkt verwenden.
Du deaktivierst die Blockfunktion und erhälts alle 30 Sekunden einen Trigger und musst nicht extra überprüfen, ob die Filternode läuft.
Vielleicht langen aber auch die 60 sekunden, wie gesagt ich würde für den Filter trotzdem vielleicht einen Filter einbauen, damit der Filter nicht alle 30 oder 60s ein Ein- oder Ausschaltsignal bekommt.
Wenn Du also permanent Dir ein Signal ausgeben lässt, dann filterst du hinten und greifst vorne das true Signal für die Filternode ab.
Sprich gleichzeitig mit dem Einschaltsignal für die Filternode (das ja nun zyklisch alle 30s oder alle 60s) von der scheduler Node ausgegeben wird überprüfst Du nun ob die anderen beiden Pumpen eingeschaltet werden, wenn die Filternode ausgeschaltet wird passiert nicht.
Vielleicht sollten die dann aber auch ausgeschaltet werden. Dann musst Du nicht die Bedingungen abfragen, sondern machst das Gleiche als ob du die Automatik ausschaltest. Ich bin mir nicht sicher, warum man das unterschiedlich behandelt und es nicht sinnvoller ist grundsätzlich beim Ausschaltsignal für die Filternode, die beiden anderen Pumpen zuerst auszuschalten und dann mit 1 Minute Verzögerung die Filternode.
-
@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:
Ja, die beiden Dosierpumpen brauche nur überprüft werden, wenn die Filterpumpe und der Durchflussschalter aktiv.
Also wenn das so ist, dann kannst Du doch das obere Scheduler Signal direkt verwenden.
Du deaktivierst die Blockfunktion und erhälts alle 30 Sekunden einen Trigger und musst nicht extra überprüfen, ob die Filternode läuft.
Vielleicht langen aber auch die 60 sekunden, wie gesagt ich würde für den Filter trotzdem vielleicht einen Filter einbauen, damit der Filter nicht alle 30 oder 60s ein Ein- oder Ausschaltsignal bekommt.
Wenn Du also permanent Dir ein Signal ausgeben lässt, dann filterst du hinten und greifst vorne das true Signal für die Filternode ab.
Sprich gleichzeitig mit dem Einschaltsignal für die Filternode (das ja nun zyklisch alle 30s oder alle 60s) von der scheduler Node ausgegeben wird überprüfst Du nun ob die anderen beiden Pumpen eingeschaltet werden, wenn die Filternode ausgeschaltet wird passiert nicht.
Vielleicht sollten die dann aber auch ausgeschaltet werden. Dann musst Du nicht die Bedingungen abfragen, sondern machst das Gleiche als ob du die Automatik ausschaltest. Ich bin mir nicht sicher, warum man das unterschiedlich behandelt und es nicht sinnvoller ist grundsätzlich beim Ausschaltsignal für die Filternode, die beiden anderen Pumpen zuerst auszuschalten und dann mit 1 Minute Verzögerung die Filternode.
-
Hole ich mir das dann mit der Link-In-Node in den Zweig?
Dann ist dass das TRigger-Signal, wie bekomme ich dann die beiden MQTT-Arrays dazu? Einfach mit hier drauf?
@bf0911 Na über die mqtt-In Nodes spreicherst Du die entweder im Kontext oder wenn es eh im iobroker ist - holst Du Dir die Werte zur Laufzeit rein.
Wie gesagt ich bin mit Deiner Filterpumpenlogik s. unten noch nicht so klar.
Warum gibt es also unterschiedliche Vorgehensweisen, ob die Filterpumpe bei Deaktivieren der Automatik oder durch den Zeitplan ausgeschaltet werden soll??? - Das erschließt sich mir als Laie erst mal nicht.
-
@bf0911 Na über die mqtt-In Nodes spreicherst Du die entweder im Kontext oder wenn es eh im iobroker ist - holst Du Dir die Werte zur Laufzeit rein.
Wie gesagt ich bin mit Deiner Filterpumpenlogik s. unten noch nicht so klar.
Warum gibt es also unterschiedliche Vorgehensweisen, ob die Filterpumpe bei Deaktivieren der Automatik oder durch den Zeitplan ausgeschaltet werden soll??? - Das erschließt sich mir als Laie erst mal nicht.
Das ist ein sehr gute Anmerkung.
Ich hatte jetzt so gedacht, dass die Deaktivierung der Pool-Automatik direkt bzw. nach 1 Minute ausschalten soll, z. B. man stellt eine Undichtigkeit etc fest.
Und der Zeitplan ist der Regel-Betrieb, wobei halt da nur darauf geachten werden soll, dass die Dosierpumpen zu dem Zeitpunkt nicht laufen, damit die Chemie nicht in den Rohren bleibt.
Vielleicht denke ich auch zu kompliziert.
Wir können daher (erstmal) eine Vorgehensweise nutzen.
-
Das ist ein sehr gute Anmerkung.
Ich hatte jetzt so gedacht, dass die Deaktivierung der Pool-Automatik direkt bzw. nach 1 Minute ausschalten soll, z. B. man stellt eine Undichtigkeit etc fest.
Und der Zeitplan ist der Regel-Betrieb, wobei halt da nur darauf geachten werden soll, dass die Dosierpumpen zu dem Zeitpunkt nicht laufen, damit die Chemie nicht in den Rohren bleibt.
Vielleicht denke ich auch zu kompliziert.
Wir können daher (erstmal) eine Vorgehensweise nutzen.
@bf0911 Na ja dann schadet es aber auch nicht, wenn Du grundsätzlich die Filterpumpe immer erst 1 Minute nach dem Abschalten der Dosierpumpen abschaltest.
Und nochmal - Du wirst später sehen, dass es viel einfacher ist, wenn man die Logik zu Beginn so einfach wie möglich hält. Mit den Konfigurationsänderungen der ui schedulers können wir das nun wie folgt vereinfachen:
So nun wird grundsätzlich die Filterpumpe 1 Minuten nachdem die Dosierpumpen ausgeschaltet wurden, egal ob die Automatik deaktiviert wurde oder der Zeitplan das vorgibt.
Wenn die Filterpumpe eingeschaltet wird, werden die beiden Dosierpumpen mitein geschaltet. Und nun kannst Du noch die Bedingungen einfügen, ob die wirklich eingeschaltet werden oder ggf. wieder ausgeschaltet werden. Ist das für Dich nachvollziehbar?
Und hier der Import des Flows:
EDIT: So hier nochmal der überarbeitete Flow. Oben filtern wir die periodischen Signale mit der filter Node für die Filter-Pumpe zum ein- und ausschalten weg, so dass nur noch die Ein- und Ausschaltsignale durchkommen.
Unten hingegen werden die periodischen "true"" Signale für die Dosierpumpen verwendet.
-
@bf0911 Na ja dann schadet es aber auch nicht, wenn Du grundsätzlich die Filterpumpe immer erst 1 Minute nach dem Abschalten der Dosierpumpen abschaltest.
Und nochmal - Du wirst später sehen, dass es viel einfacher ist, wenn man die Logik zu Beginn so einfach wie möglich hält. Mit den Konfigurationsänderungen der ui schedulers können wir das nun wie folgt vereinfachen:
So nun wird grundsätzlich die Filterpumpe 1 Minuten nachdem die Dosierpumpen ausgeschaltet wurden, egal ob die Automatik deaktiviert wurde oder der Zeitplan das vorgibt.
Wenn die Filterpumpe eingeschaltet wird, werden die beiden Dosierpumpen mitein geschaltet. Und nun kannst Du noch die Bedingungen einfügen, ob die wirklich eingeschaltet werden oder ggf. wieder ausgeschaltet werden. Ist das für Dich nachvollziehbar?
Und hier der Import des Flows:
EDIT: So hier nochmal der überarbeitete Flow. Oben filtern wir die periodischen Signale mit der filter Node für die Filter-Pumpe zum ein- und ausschalten weg, so dass nur noch die Ein- und Ausschaltsignale durchkommen.
Unten hingegen werden die periodischen "true"" Signale für die Dosierpumpen verwendet.
Ich sag mal so halb. Das Trigger-Signal für die Logik der Dosierpumpen ist jetzt das "True"-Signal der Zeitsteuerung.
So wie es in dem Beispiel-Flow ist, würden die Dosierpumpen aber direkt laufen, richtig?
Das würde bedeuten, dass die Logik für die Dosier-Pumpen ganz unten im Flow vor der jeweilige Iobroker-out-Node ist, richtig?
Was noch fehlt, ist ob die Filter-Pumpe wirklich läuft. Das muss ich mir ebenfalls noch in den unteren Zweig holen.
-
Ich sag mal so halb. Das Trigger-Signal für die Logik der Dosierpumpen ist jetzt das "True"-Signal der Zeitsteuerung.
So wie es in dem Beispiel-Flow ist, würden die Dosierpumpen aber direkt laufen, richtig?
Das würde bedeuten, dass die Logik für die Dosier-Pumpen ganz unten im Flow vor der jeweilige Iobroker-out-Node ist, richtig?
Was noch fehlt, ist ob die Filter-Pumpe wirklich läuft. Das muss ich mir ebenfalls noch in den unteren Zweig holen.
@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:
So wie es in dem Beispiel-Flow ist, würden die Dosierpumpen aber direkt laufen, richtig?
Ja - aber das hab ich ja gesagt, du sollst jetzt die Bedingungen in diesen Ast einfügen, ja und vor die iobroker-Out Nodes eingefügt werden. :+1: :+1: :+1:
Jeder Flow bzw. jedes Script, das ich hier poste implementiert jeder auf eigene Gefahr. Flows und Scripts können Fehler aufweisen und weder der Seitenbetreiber noch ich persönlich können hierfür haftbar gemacht werden. Das gleiche gilt für Empfehlungen aller Art.
-
@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:
So wie es in dem Beispiel-Flow ist, würden die Dosierpumpen aber direkt laufen, richtig?
Ja - aber das hab ich ja gesagt, du sollst jetzt die Bedingungen in diesen Ast einfügen, ja und vor die iobroker-Out Nodes eingefügt werden. :+1: :+1: :+1:
-
Ich sag mal so halb. Das Trigger-Signal für die Logik der Dosierpumpen ist jetzt das "True"-Signal der Zeitsteuerung.
So wie es in dem Beispiel-Flow ist, würden die Dosierpumpen aber direkt laufen, richtig?
Das würde bedeuten, dass die Logik für die Dosier-Pumpen ganz unten im Flow vor der jeweilige Iobroker-out-Node ist, richtig?
Was noch fehlt, ist ob die Filter-Pumpe wirklich läuft. Das muss ich mir ebenfalls noch in den unteren Zweig holen.
@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:
Was noch fehlt, ist ob die Filter-Pumpe wirklich läuft. Das muss ich mir ebenfalls noch in den unteren Zweig holen.
Wie gesagt, Du kannst jetzt unten soviel abprüfen, wie Du willst. Da der Scheduler das Signal ja periodisch ausgibt, werden die Zustände des Gesamtsystem nun alle 30 oder 60 Sekunden ausgegeben.
-
Macht es sind, der Übersichtlichkeit, das Signal des Schedulers per Link-in und Link-out in die jeweilige Logik-Gruppe zu holen oder sollte man das komplett in eine Gruppe packen?
@bf0911 Im Moment würde ich nicht mit Links arbeiten - und ja die Logik für die einzelnen Dosierpumpen kannst Du dann Gruppieren, um das besser zu sehen. Mit Link Nodes würde ich erst dann arbeiten, wenn Dir der Platz nicht ausreicht. Die Gruppierung machst Du dann aber einfach später drum rum.
Ich würde dann wenn das zu komplex werden sollte - dann kann man mit Link Call Nodes arbeiten, um quasi Unterprogramme in einem Flow zu erzeugen. Aber im Moment würde ich alles zusammenhalten, das ist jetzt noch viel übersichtlicher.
-
Ich sag mal so halb. Das Trigger-Signal für die Logik der Dosierpumpen ist jetzt das "True"-Signal der Zeitsteuerung.
So wie es in dem Beispiel-Flow ist, würden die Dosierpumpen aber direkt laufen, richtig?
Das würde bedeuten, dass die Logik für die Dosier-Pumpen ganz unten im Flow vor der jeweilige Iobroker-out-Node ist, richtig?
Was noch fehlt, ist ob die Filter-Pumpe wirklich läuft. Das muss ich mir ebenfalls noch in den unteren Zweig holen.
@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:
Was noch fehlt, ist ob die Filter-Pumpe wirklich läuft. Das muss ich mir ebenfalls noch in den unteren Zweig holen.
In dem Fall würde ich sogar gar nicht auf die payload des Schedulers abprüfen, sondern mir für beide Pumpen den Status der Filter-Pumpe reinholen!!
Also so:
Damit überschreibst Du die payload aus der ui-scheduler Node und verwendest gleich den Status der Filterpumpe als Filter.
Du brauchst dann also kein extra Attribut für die get Node.
Support us
666
Online32.5k
Users81.6k
Topics1.3m
Posts