Hilfe bei debuggen einer übernommenen Funktion
-
Na von der Konfiguration des Scheduler wollte ich eigentlich nur sehen, aber ich gehe mal vom Standard aus - das werden wir dann ggf. noch optimieren. Den Zeitplan wollte ich gar nicht im Detail.
Da ich NICHT davon ausgehe, dass Du permanent Signale an Deine Pumpen schicken willst, sondern nur EIN- und AUSSCHALT-Signale würde ich mir auch nur die Ein- und Ausschaltsignale ausgeben lassen. Sonst würde der Flow alle 60s getriggert und ich glaube das willst Du nicht.
So ähnlich dürfte ja deine Konfiguration der Filter-Node aussehen.
@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:
Jetzt zum "doppelt", ich war der Meinung, dass ein Switch-Node zu einem bestimmten Ereignis einen bestimmten "Status" ausgeben kann. Umgekehrt dachte ich, wenn das Ereignis nicht eintrifft, dass das switch-Node nichts ausgibt.
Daher hab ich quasi einen "True" und einen "false"-Zweig erstellt, damit die Filter-Pumpe ein und ausgeschaltet werden kann.Um es kurz zu machen - eine Switch Node ist eine If-Then oder Case Abfrage und gibt selbstständig gar nichts aus, sondern interpretiert nur das Nachrichtenobjekt, dass ankommt und gibt es dann entweder weiter oder nicht oder sendet es an ein oder mehrere Ausgänge.
Die Idee dahinter war folgende:
Wenn der Zeitplan aktiv ist und die Pool-Automatik (jetzt ja nicht mehr notwendig) ebenfalls, dann soll die Filter-Pumpe laufen. Sollte der Zeitplan nicht aktiv sein und zu diesem Zeitpunkt weder die PH- noch die Chlor-Pumpe laufen, dann soll die Filter-Anlage ausgeschaltet werden. Dann hab ich im Flow noch, wenn die Pool-Automatik ausgeschaltet wird, sollen Ph- und Chlor-Pumpe sofort und die FIlter-Pumpe 1 Minuten später ausgeschaltet werden.
So nun formulierst Du das erste Mal, was Du überhaupt in der Gesamtheit erreichen willst.
Im Prinzip hast Du alle folgende Fälle bzw. musst folgendes untersuchen:
Ist Automatik aktiv - das erfährst Du am Ausgang 1 der Scheduler Node.
Ist der Zeitplan aktiv - das erfährst Du am Ausgang 2.Wenn Du den Zustand, ob Automatik aktiv oder inaktiv nicht mehr brauchst - dann brauchst Du auch keine Variable im Kontext speichern sondern erstellst den Flow direkt am Ausgang 1.
Also können wir die Change-Node vereinfachen und nur den Status der Automatik ermitteln und müssen das erst mal nicht in einer variablen speichern. Das können wir später wenn benötigt immer noch machen.
Na ich habe gerade gesehen, der Status der Automatik ist doch wichtig. Gut dann also zusätzlich in einer Flow-Variablen speichern.
Da die payload bereits false ist, kann man damit ja die Pumpe steuern.
So damit wäre der Fall, dass die Automatik deaktiviert wurde - komplett sauber in einem eigenen Ast ausformuliert.
Ich hab jetzt mal im iobroker - so Booleans für den Zustand Deiner Pumpen angelegt, damit kannst Du dann Dein gesamtes Szenario auch noch testen:
So ich habe den Flow mal soweit fertig gemacht, dass er die Logik, die Du geschrieben hast implementiert. Wenn Du den Flow importierst, dann solltest Du mit der Anpassung der iobroker-Datenpunkte nun weiter machen können. Aber so ist es einigermaßen sauber und übersichtlich, um die Logik zu sehen:
Hier der Flow zum Import mit dem Du weitermachen kannst:
Ganz sauber wäre es natürlich, wenn du die beiden Nodes aussen aus der Automatikgruppe aus entfernen würdest und einen Eingang in die Gruppe verwendest - dann ist es aus der Logiksicht am übersichtlichsten:
EDIT:
Ich habe den Import nochmals entsprechend angepasst!Deine Chlor- und PH Pumpe schaltest Du wohl in einer eigenen Logik - aber ich denke mal, Du verstehst das nun besser und ist auch nicht so schwierig. Und vielleicht verstehst Du nun, was Du Dir an Übersichtlichkeit mit function Nodes und Programmcode kaputt machst.
Wenn Du mehrfach auch Nodes zum Schalten der FilterNode verwendest, dann siehst Du auch ggf. welcher Flow bzw. welche Node geschaltet hat. In dem oberen Screenshot siehst Du dass die Automatik aus iobroker node noch gar nicht getriggert wurde und nur auf connected steht, während unten die Node auf false steht. Natürlich kannst Du noch debug Nodes oder machst erst debug Nodes hin, wenn Du Dir keine Testpunkte im iobroker erstellen willst, sondern lieber direkt im Debug-Fenster des Node-Red Editors anschauen willst.
-
Danke bisher für deine Zeit und Mühe. Der Flow sieht sehr aufgeräumt aus!
Ja, Chlor- und PH-Pumpe steuere ich noch gar nicht
Das wird aus meiner Sicht, der schwerste Teil. Siehe Eingangspost mit der function-Node.
Es soll deutlich mehr Logik drin stecken, als bei der Filterpumpe.
Da werde ich morgen mal versuchen, zu starten!
Dazu direkt auch eine Frage, bei dem ursprünglichen Flow werden die Werte wie folgt in den Flow geholt.
Ich gehe mal davon, dass das dort gemacht wurde, weil auch die Geräte dort per MQTT geschaltet wurden.
Wenn ich die Werte einzeln als Datenpunkte anlege, bin ich sicherlich sauberer her vom Flow und könnte die Werte direkt an der geeigneten Stelle einlesen?!
-
@bf0911 nein das passt schon, wie es gemacht wurde. Allerdings würde ich die Variablen erst bei Bedarf ins Nachrichtenobjekt holen bzw. kannst du die Variablen ja auch direkt in einer Switch Node abf
-
Kannst du mir das nochmal kurz erklären?
Die erste Regel ist quasi das ausfiltern, ob die Zeit-Automatik aktiv ist?!
Die zweite Regel ist mir nicht ganz klar.
Die dritte setzt in Abhängigkeit von Regel 1 die Variable Filter-Pumpe auf True oder false?!
Die Ph-Parameter kommen ja perr Mqtt in einem Array. Diese wollte und sollte ich ja (mutmaßlich) analog zum Zeitplan mit einem JSON-Node in Objekte umwandeln.
Das habe ich soweit gemacht.{"Pausenzeit_min":15,"Laufzeit_sec":60,"MaxTagesLaufzeit_min":5,"PH_Grenzwert":7.2,"PH_Pumpe_Automatik":"OFF"}Wie komme ich nun an die einzelnen Werte? Bedarf es da auch wieder einer JSONata?
-
Wobei ich, glaube verstanden zu haben, wie ich das Array zerkleine bzw. wie ich damit arbeite.
Habe auch verstanden, wie du das meintest, mit direkt in der Switch-Node nutzen.
-
Ich denke, dass das so gemeint war.
Aber scheinbar ist es nicht sinnvoll, mit 2 Mqtt-In zu arbeiten. Das basiert erstmal auf dem alten Skript.
So, ist es im Ursprungs-Skript gewesen.
Dort werden die entsprechenden Laufzeit etc errechnet!
-
Ich hab in der Zwischenzeit "versucht", die Laufzeit der Filterpumpe ohne Funktions-Node zu erstellen.
Jetzt stehe ich aber vor dem Problem, dass ich die "rechne Laufzeit in Minuten" und "rechne Laufzeit in Stunden" per MQTT an Pool/Filter.. senden möchte. Dieses Objekt beinhaltet aber beide Werte ({"minutes":3,"hours":"0.04"}).
Wie bekommen ich nun sowohl die Minuten als auch die Stunden in dieses eine Objekt? -
@bf0911 Natürlich kann es auch sinnvoll sein mit 2 mqtt Nodes zu arbeiten - nur vielleicht solltest du erst mal die Logik erläutern, wie Du es vorher ja auch gemacht hast.
-
@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:
Jetzt stehe ich aber vor dem Problem, dass ich die "rechne Laufzeit in Minuten" und "rechne Laufzeit in Stunden" per MQTT an Pool/Filter.. senden möchte. Dieses Objekt beinhaltet aber beide Werte ({"minutes":3,"hours":"0.04"}).
Welches Objekt enthält 2 Werte, warum reißt Du es auseinander, wenn Du es doch in einem Objekt haben willst. Ausserdem was ist das? Sollen 3 min 0.04 Stunden sein?
Wenn ich 0,04 * 60 nehme, dann kommen 2,4 Minuten raus und wenn ich 3/60 nehme kommen 0,05 Stunden raus?
Keine Ahnung was Du willst , was aus Deiner Node rauskommt und was Du in beiden ChangeNodes errechnest
-
Ja, mein Fehler:
Die Logik soll sein, dass wenn die Chlor-Pumpe nicht aktiv ist, Durchfluss vorhanden ist, die PH-Pumpe-Tageslaufzeit kleiner als die maximale Ph-Pumpe-Zeit ist, der PH-Wert größer als der PH-Grenzwert, die PH-Automatik und die Filter-Pumpe-Automatik die PH-Pumpe für eine über das Dashboard eingeschaltete Zeit einschalten soll, dann für eine übers Dashboard eingestellte Zeit werden soll und das so lange wiederholen, bis der entweder die maximale Tageslaufzeit (übers Dashboard) überschritten wurde oder der PH-Grenzwert unterschritten wurde.
Die Werte Ph-Grenzwert, Pausenzeit, Laufzeit, Max Tageslauf, und Automatik kommen per MQTT -> Ph-Parameter. Die Tageslaufzeit kommt ebenfalls per MQTT -> PH-Pumpe-Tageslaufzeit
-
Die Arrays der Pumpen-Laufzeiten geben das hier aus:
{"topic":"Pool/PHPumpe_Laufzeit_Total","payload":{"minutes":9,"hours":"0.15"},"qos":2,"retain":false,"_msgid":"900be7ba1d81a112"}Diese werden in dem altem Skript per Funktion berechnet und wieder per MQTT geschrieben.
var calculatedMinutes = Math.round(Number(msg.elapsed.millis)/60/1000); //var calculatedHours = Math.round(Number(msg.elapsed.millis)/60/60/1000); var calculatedHours = Number(msg.elapsed.millis)/3600000; calculatedHours = calculatedHours.toFixed(2); var PH_Pumpe_MaxTagesLaufzeit_min = flow.get('PH_Pumpe_MaxTagesLaufzeit_min'); global.set('PH_Pumpe_Laufzeit_Tag',calculatedMinutes); var newMsg = { payload: "{\"minutes\":}" }; newMsg.payload = {"minutes": calculatedMinutes,"hours": calculatedHours}; newMsg.topic = "Pool/PHPumpe_Laufzeit_Tag"; var newMsg1 = { payload: calculatedMinutes }; var newMsg2 = { payload: calculatedHours }; if (calculatedMinutes >= PH_Pumpe_MaxTagesLaufzeit_min) { newMsg1.color = "red"; newMsg2.color = "red"; } else { newMsg1.color = "white"; newMsg2.color = "white"; } return [newMsg,newMsg1,newMsg2];Ich wollte das Ganze jetzt ohne Funktion-Node machen und habe bei "rechne Laufzeit in Minuten" per Change-Node und JSONNata die Minuten berechnet und das selbe mit den Stunden.
Da haben ich bis jetzt noch gar nichts auseinander gerissen oder so.
-
@bf0911 Ok dann bleiben wir mal bei Deiner Berechnung.
Die Ausgabe dieser Laufzeit Nodes gibt also in msg.elapsed.millis die Anzahl an Milisekunden aus, die diese Node mit der Eieruhr berechnet hat.
Und Du willst nun mit JSONATA sowohl die Laufzeit in Minuten, als auch in Stunden in einem Objekt ausgeben, dass
so{"minutes":9,"hours":"0.15"}aussieht, wobei es in meinen Augen Schwachsinn ist, die Minuten als Zahl und die Stunden als String auszugeben.
Deshalb nochmal die Frage warum errechnest Du es in 2 Change Nodes und erstellst damit 2 Nachrichtenobjekte anstelle es in einer Change Node zu machen? Wie berechnest Du denn die Laufzeit in der ChangeNode und wieso verwendest Du 2 Change Nodes?
Mach doch mal einen Screenshot - was Du in einer Change Node berechnest?
Wenn das Dein Input aus der Eieruhr Node ist:
und Du möchtest daraus ein Objekt erstellen mit der Laufzeit in Minuten und in Stunden, dann trenne ich das nicht in 2 Nachrichten auf.
Wenn Du dann die Laufzeit in Stunden auf dem Dashboard ausgeben willst, referenzierst Du nur auf die Eigenschaft hours in Deinem Nachrichtenobjekt, wenn Du die Minuten ausgeben willst, dann halt auf die Eigenschaft minutes.
-
@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:
Ja, mein Fehler:
Die Logik soll sein, dass wenn die Chlor-Pumpe nicht aktiv ist, Durchfluss vorhanden ist, die PH-Pumpe-Tageslaufzeit kleiner als die maximale Ph-Pumpe-Zeit ist, der PH-Wert größer als der PH-Grenzwert, die PH-Automatik und die Filter-Pumpe-Automatik die PH-Pumpe für eine über das Dashboard eingeschaltete Zeit einschalten soll, dann für eine übers Dashboard eingestellte Zeit werden soll und das so lange wiederholen, bis der entweder die maximale Tageslaufzeit (übers Dashboard) überschritten wurde oder der PH-Grenzwert unterschritten wurde.
Die Werte Ph-Grenzwert, Pausenzeit, Laufzeit, Max Tageslauf, und Automatik kommen per MQTT -> Ph-Parameter. Die Tageslaufzeit kommt ebenfalls per MQTT -> PH-Pumpe-Tageslaufzeit
Und was soll diesen Flow triggern? Wann soll dieser Flow ausgeführt werden (nicht die Bedingungen des Einschaltens der Chlorpumpe), sondern wann soll geprüft werden, ob die Chlorpumpe ausgeschaltet ist, über die gleiche Scheduler Nodes - aber für die ChlorPumpe?
Also einfach ein neues Gerät dran machen?
So vielleicht und dann aber alle 60s überprüfen?
Für die Filterpumpe könnte man dann, um unnötige Schaltvorgänge zu vermeiden noch eine filter node hinten dran machen (wenn man alle 60s den Status der Geräte prüfen möchte).
das wäre ja erforderlich, da Du ja sowohl zyklisch überprüfen möchtest, als auch nur einmalig schalten.
Macht es vielleicht Sinn, wenn Du eh alle Pumpen auch noch zeitlich über das Dashboard steuern willst diese dann noch in den Scheduler aufzunehmen, anstelle über Inject Nodes zu triggern?
oder macht es Sinn, wenn man die Filternode Automatik triggern lässt, diese auch die Überprüfung der anderen Pumpen zu übernehmen. Sprich eine Überprüfung der anderen Pumpen erfolgt nur, wenn .... Dann könnte man auch mit trigger Nodes anstelle von Inject Nodes arbeiten.
-
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.
-
@bf0911 Gut dann habe ich Dir ja unten die Lösung geschickt, wie Du das alles in einer Change Node in einem Objekt machst.
Grundsätzlich gibt es bei JSONATA in Change Nodes einen Unterschied zu function Nodes:
Lass das msg weg - da habe ich gehört, dass das ggf. zu Problemen führen kann, du kannst also bei JSONATA direkt auf die Eigenschaften des Nachrichtenobjektes referenzieren ohne das Präfix msg
Auf jeden Falls siehst Du nun glaube ich bereits, wie vieles einfacher ohne ein Haufen Code in function NOdes funktionieren kann.
-
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.
-
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:
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.
-
@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:
-
@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.
