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. 
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.
Ja, die beiden Dosierpumpen brauche nur überprüft werden, wenn die Filterpumpe und der Durchflussschalter aktiv.
@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.
@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.
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.
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:
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:
