UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[BF0911]

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?

[mickym]

@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.

[mickym]

@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

[BF0911]

@mickym

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

[BF0911]

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.

[mickym]

@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.

[mickym]

@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:

@mickym

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.

[BF0911]

@mickym

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.

[mickym]

@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.

[BF0911]

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]

Ich bekomme folgende Fehlermeldung bei der Verwendung der Change-Node.

"Cannot set property of non-object type: payload.hours"

[mickym]

@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.

[mickym]

@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:

[mickym]

@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]

@mickym

Danke, mit der "Regel" davor klappt es.

Hast du bewusst auf das runden verzichtet?

JSONNata wird sicherlich noch dauern.

[mickym]

@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:

@mickym

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.

[BF0911]

Ja, die beiden Dosierpumpen brauche nur überprüft werden, wenn die Filterpumpe und der Durchflussschalter aktiv.

[mickym]

@mickym sagte in Hilfe bei debuggen einer übernommenen Funktion:

@bf0911 sagte in Hilfe bei debuggen einer übernommenen Funktion:

@mickym

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.

[mickym]

@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]

@mickym

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?