Hilfe bei debuggen einer übernommenen Funktion

[mickym]

Ok ich verabschiede mich dann mal - und wir können dann weiter machen, wenn Du wieder da bist.

mach mal in Deine function Node - zum Debuggen noch folgende Zeile an 1. Stelle bzw. nach dem Setzen der Variablen rein und schau was im Debug Fenster auftaucht.

node.warn(msg.payload.ph_current);

Wenn Du das siehst, dann sehen wir ja woher das kommt bzw. ob die Eigenschaft definiert ist:

Am Besten Du fügst das node.warn(...) direkt vor die Anweisung, die die msg.payload.ph setzt. Eventuell hast Du die ganze function Node an die falsche Stelle gesetzt

[mickym]

Ansonsten wenn das der Fehler ist, dass dein flow nicht funktioniert, dann setze hinter die iobroker get node eine Change node und verschiebe die payload auf payload.ph_current.

ich glaube ich weiß wo das Problem liegt. mit deiner iobroker get überschreibst du deine payload, die du von einem anderen Flow hast und deshalb funktioniert deine function node nicht mehr, weil du dein Objekt überschrieben, weggeschmissen hast. wenn du eine debug node direkt an die link in node machst, ist das objekt vielleicht noch vorhanden.

Am besten du machst eine debug node vor und nach der iobroker get node hin und du siehst den unterschied

[mickym]

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

Um Dir kurzfristig quick&dirty zu helfen,

änderst Du Deinen Code einfach wie folgt:

var FilterPumpeStatus = global.get('FilterPumpe'); 
var DurchflussschalterStatus = global.get('Paddelschalter');
var PH_Pumpe_Laufzeit_Tag = global.get('PH_Pumpe_Laufzeit_Tag'); 
var PH_Pumpe_Pause = global.get('PH_Pumpe_Pause'); 
var PH_Pumpe_Laufzeit_ms = flow.get('PH_Pumpe_Laufzeit_sec') * 1000; 
var Chlor_Pumpe_Status = global.get('Chlor_Pumpe'); 
var PoolAutomatikModus = global.get('PoolAutomatikModus'); 
var PH_Pumpe_MaxTagesLaufzeit_min = flow.get('PH_Pumpe_MaxTagesLaufzeit_min'); 
var PH_Pumpe_Grenzwert = flow.get('PH_Pumpe_Grenzwert'); 
var PH_Pumpe_Automatik =  flow.get('PH_Pumpe_Automatik');
var PH_Pumpe_Session_Laufzeit =  flow.get('PH_Pumpe_Session_Laufzeit');

var myStunde = Number(msg.myhour);
msg.payload.ph = Number((msg.ph_current + 0.2).toFixed(2));

flow.set('PH_Actual',msg.payload.ph); 
flow.set('ORP_Actual',msg.payload.orp_current); 

if (myStunde >= 20 && myStunde <= 23  )
{

msg.delay = PH_Pumpe_Laufzeit_ms;

// for test without Logic
//return [msg];

if (PoolAutomatikModus == "ON" && PH_Pumpe_Automatik == "ON")
{
        if (msg.payload.ph_current < 6 || msg.payload.ph_current > 8 )
        {
            return [null];
        }
        else if (msg.payload.ph_current >= PH_Pumpe_Grenzwert && FilterPumpeStatus == "ON" && PH_Pumpe_Laufzeit_Tag < PH_Pumpe_MaxTagesLaufzeit_min && PH_Pumpe_Pause == "NO" && Chlor_Pumpe_Status == "OFF" && DurchflussschalterStatus == "ON" && PH_Pumpe_Session_Laufzeit > 10) 
            {
                return [msg];
            }
        else
            {
                return [null];
            }
}
else
 {
    return [null];
}
}
else
 {
    return [null];
}

Der Rest muss das originale payload Objekt bringen. Und damit Dein payload Objekt nicht mehr überschrieben wird, speicherst Du den ausgelesenen ph-Wert nicht in der payload, sondern in ph_current.

Die anderen payload Eigenschaften müssen dann aus Deinen anderen Flowteilen kommen, also aus der link-in Node.

[BF0911]

@mickym

So, kurze Rückmeldung, mit leider sehr wenig Zeit heute.

Ich bekomme mit der node.warn auch undefined.

Dann hab ich die Change-Node eingefügt, siehe Bild.

Und deinen Code ebenfalls.

[BF0911]

Es scheint aber auch außerhalb der Funktion einiges im Argen zu liegen.

Der PoolAutomatikModus macht auch nicht das was, er soll.

Das aber nur am Rande.

[mickym]

@bf0911 Weißt Du die Frage ist halt immer, warum macht "ihr" das immer mit dem zusammenkopieren von Codefragmenten und probiert nicht mal selbst von Anfang an.

Ich habe vor 3 Jahren auch hier mit einem User eine Poolsteuerung mit NodeRed implementiert.

Schau mal, ob das in etwa vergleichbar ist:
https://forum.iobroker.net/topic/43480/gelöst-poolsteuerung-anfänger-braucht-e-hilfe

Ich will Dich damit nicht ermutigen, das genauso zu kopieren, aber vielleicht hast Du ja den Mut, so was von vorne selbst zu beginnen. Ich würde Dich dabei genauso unterstützen wie damals.

Ich halte das ggf. für sinnvoller, als diese Dinge einfach zu kopieren. Wenn Du es selbst machst, dann kannst Du es von Beginn nach Deinen Vorstellungen implementieren.

[BF0911]

@mickym

Tatsächlich aus Bequemlichkeit. Ich bin davon ausgegangen, dass ich den Flow nur auf meinen Gegebenheiten (Datenpunkte etc.) anpassen muss und es dann laufen würde.

GRundsätzlich bin ich gerne bereit, das Ganze selbst und von vorne aufzubauen.

Die verlinkte Poolsteuerung muss mich mir mal in Ruhe anschauen, wobei ich auf den ersten Blick gesehen habe, dass es sich dort eher um die "Wärme-Steuerung" handelt.

[BF0911]

Ich hab mal komplett neu anzufangen:

Hier soll der Automatik-Modus gesetzt werden und falls dieser ausgeschaltet wird, sollen die Chlor- und Ph-Pumpe sofort und die Filter-Pumpe nach einer 1 Minute stoppen.

Dafür habe ich den Switch wie folgt gesetzt:

[BF0911]

weiter gehts:

Der erste Teil wurde nochmal etwas optimiert (Aus meiner Sicht) und soll den Automatik-Modus setzen.

Der zweite Teil soll meine Filter-Pumpe in Abhängigkeit des Zeitplans und Pool-Automatik "aktiv" steuern.

Wenn der Zeitplan ein "false" sendet, soll noch überprüft werden, ob Ph- und Chlor-Pumpe gerade laufen.

[BF0911]

Was ist eigentlich genau der Unterschied zwischen iobroker.in und iobroker.get?

Und wann nutzt man sinnvollerweise was?

[mickym]

@bf0911 Na das ist doch schön, dass angefangen hast. Ich sehe nun auch, dass Du das NodeRed Dashboard nutzen willst.

Ein paar Verbesserungsvorschläge habe ich bereits bzw. sind mir noch nicht klar.

1. Standardmässig wird in dem Adapter nun (und das ist auch gut so), die Option in Zeichenfolgen zu konvertieren ausgeschaltet.

Das ist auch richtig so, damit Du richtige Datentypen verwenden kannst und nicht dauern hin und her konvertieren musst.

2. Wenn Du dann allerdings auf Booleans prüfst und musst Du auch den richtigen Datentyp verwenden.

Hier vergleichst Du mit einem String und nicht mit einem Logikwert.

[BF0911]

@mickym

Diese Option ist bei mir auch ausgeschaltet.

Dann muss das vermutlich so sein?

[mickym]

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

Was ist eigentlich genau der Unterschied zwischen iobroker.in und iobroker.get?

Und wann nutzt man sinnvollerweise was?

Eigentlich brauchst Du nicht alles über globale Variablen regeln.

Bei der iobroker.in Node siehst Du, dass die nur einen Ausgang aber keinen Eingang hat.

Sprich der Flow wird getriggert oder ausgelöst durch eine Aktualisierung oder Änderung eines Datenpunktes im iobroker.

Da Du nicht soviele globale Variablen brauchst (die müssen ja auch bei jedem Neustart gesetzt werden), kannst Du, wenn ein Flow getriggert wurde, die mit der get Node andere Datenpunkte aus dem iobroker auslesen. Zum Beispiel ob der Automatik Modus eingeschaltet ist, dann muss man das nicht über globale Variablen lösen. Das belastet das System etwas mehr, weil quasi immer wieder der iobroker abgefragt wird - also hängt ein bisschen von der Häufigkeit ab.

Sprich wenn sich z.Bsp Dein ph Wert ändert und dieser triggern soll, dann verwendest Du einen iobroker-In Node. Möchtest Du dann eine Aktion in Abhängigkeit eines Logikwertes prüfen, nimmst Du anschliessend eine iobroker-get Node und liest den Wert aktiv zu dem Zeitpunkt aus, zudem Dein ph Wert sich geändert hat.

Wichtig ist, dass Du mit der get Node nicht die payload - deiner iobroker-IN Node überschreibst!!!

Deshalb musst Du den Wert mit der ausgelesenen Eigenschaft nicht der Nachrichteneigenschaft "payload" sondern einem anderen Eigenschaft zuweisen. Hier active.

Damit enthält Dein Nachrichtenobjekt beide Eigenschaften und Du kannst beide Eigenschaften zu Vergleichen nutzen.

Hier zum Import:

Spoiler

[{"id":"38663d6d60bd9893","type":"ioBroker in","z":"289f539dcc33814e","name":"","attrname":"payload","topic":"0_userdata.0.Test.Zahl","payloadType":"value","onlyack":"","func":"all","gap":"","fireOnStart":"true","outFormat":"MQTT","x":280,"y":6700,"wires":[["802306ee3fdee39f"]]},{"id":"802306ee3fdee39f","type":"ioBroker get","z":"289f539dcc33814e","name":"","topic":"0_userdata.0.Test.aktiv","attrname":"active","payloadType":"value","errOnInvalidState":"nothing","x":570,"y":6700,"wires":[["527348828b6c739d"]]},{"id":"527348828b6c739d","type":"debug","z":"289f539dcc33814e","name":"Ergebnis","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":780,"y":6700,"wires":[]}]

[mickym]

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

@mickym

Diese Option ist bei mir auch ausgeschaltet.

Dann muss das vermutlich so sein?

Korrekt!!!

[BF0911]

@mickym

Das habt ich nur so halb verstanden.

Iobroker.in löst immer aus, wenn das "Objekt" geändert wurde (Filter-Pumpe ein oder ausgeschaltet?). Das habe ich hoffentlich richtig verstanden.

Das mit dem get leider nicht so. mir leuchtet das Beispiel mit der Automatik nicht so ein.

[mickym]

Das hast Du nun korrekt aufgelöst, da Du den Datenpunkt nun zur Statusanzeige im Dashboard nutze und andere Dinge damit tust, zum Beispiel eine globale Variable setzt.

Die Bezeichnung des Switch musst Du nochmal überlegen, ob Du wirklich mit dem Schalten, ob Automatik Mode oder nicht gleich die Pumpe schalten willst oder ob es erst mal nur eine Betriebsart festlegen soll. Das musst Du ggf. nochmals von der Logik überlegen.

Im Dashboard, wenn Du den gleichen Datenpunkt schreibst wie liest - fängst Du Dir sofort eine Endlosschleife ein. Hier darauf achten, dass Du die Eingangsnachricht von dem Switch erst mal blockierst und nur den Eingang zur Statusanzeige verwendest.

[mickym]

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

@mickym

Das habt ich nur so halb verstanden.

Iobroker.in löst immer aus, wenn das "Objekt" geändert wurde (Filter-Pumpe ein oder ausgeschaltet?). Das habe ich hoffentlich richtig verstanden.

Die iobroker.in Node löst immer aus, wenn der Datenpunkt im iobroker aktualisiert wurde (nicht nur geändert) - also neu geschrieben wurde. (Stelle in Deiner Objektansicht im iobroker auf Zeitstempel um, dann siehst Du das).

Wenn nur Änderungen triggern sollen, dann musst Du das in der iobroker IN Node konfigurieren.

Mit dem Modus hast Du alle Möglichkeiten:

1. Send all events: der Flow wird getriggert, sobald der Datenpunkt neu geschrieben wurde (auch wenn sich der Wert NICHT geändert hat.
2. Block unless value changes; Es wird nur der Flow getrigggert, wenn der Datenpunkt neu geschrieben wurde UND sich der Wert geändert hat.
3. Wie 2. nur dass bei Neustart des Adapter schon mal der Datenpunkt gelesen wird, um zu wissen wann sich ein Datenpunkt verändert hat.

Das mit dem get leider nicht so. mir leuchtet das Beispiel mit der Automatik nicht so ein.

Also wenn der Flow über eine Datenpunkt bereits getriggert hat und Du willst dann den Flow durch einen anderen Wert im iobroker steuern oder vergleichen, dann holst Du dir den anderen Wert in den Flow. Du kannst in NodeRed nur immer Werte miteinander verarbeiten, die sich zeitgleich in einem Nachrichten objekt befinden. Ich werde Dir gleich 2 Beispiele geben.

Nimm an 2 iobroker Datenpunkt mit Zahlen die wir addieren wollen:

Im Datenpunkt Zahl steht der Wert: 7.44, in dem Datenpunkt Wert steht die Zahl 5. Wir wollen nun beide Zahlen addieren, der Flow soll getriggert werden durch eine Aktualisierung des Datenpunktes Zahl. Also wenn der neu geschrieben wird, soll der Flow losrennen.

In der payload bei Aktualisierung des Datenpunktes Zahl also 7.44 wird der Flow gestartet und nun der Wert des 2. Datenpunktes ausgelesen und in die Eigenschaft "summand" eingelesen. Nun hast Du beide Eigenschaften in Deinem Nachrichtenobjekt und kannst diese addieren. Wir werden also die payload so modifizieren, dass beide Eigenschaften des Nachrichtenobjektes addiert werden.
Die Nachrichteneigenschaften müssen aber mit einem Zeichen und keiner Zahl beginnen.

Über eine Change Node bilden wir also die Summe, in dem wir über JSONATA die beiden Werte addieren.

Wie Du siehst und das hat NICHTS mit NodeRed zu tun, hat Javascript manchmal ein Problem, dass die mathematischen Ergebnisse nicht exakt sind, sondern da was dazukommt. Deswegen wird oft aktiv gerundet. Wir runden also in JSONATA das Ergebnis noch mit der round Funktion.

Das können wir auf zweierlei Art machen. Entweder direkt das Ergebnis runden:

oder und das ist sehr wichtig - eine Change Node ist wie eine kleine "function Node" in der die Regeln sequentiell abgearbeitet werden. Man kann auch 2 Change nodes machen oder Change Nodes über Regeln zusammen fassen.

Ursprünglich stand also in der Change NOde 12.00000000001 und man kann diese payload auch in einer anschließenden Regel runden. Das kommt also auf das Gleiche raus.

Hier wieder der Import:

Spoiler

[{"id":"38663d6d60bd9893","type":"ioBroker in","z":"289f539dcc33814e","name":"","attrname":"payload","topic":"0_userdata.0.Test.Zahl","payloadType":"value","onlyack":"","func":"all","gap":"","fireOnStart":"true","outFormat":"MQTT","x":140,"y":6640,"wires":[["802306ee3fdee39f"]]},{"id":"802306ee3fdee39f","type":"ioBroker get","z":"289f539dcc33814e","name":"","topic":"0_userdata.0.Test.Wert","attrname":"summand","payloadType":"value","errOnInvalidState":"nothing","x":390,"y":6640,"wires":[["527348828b6c739d","ac7e466c2aba72a7"]]},{"id":"527348828b6c739d","type":"debug","z":"289f539dcc33814e","name":"Ergebnis","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":640,"y":6640,"wires":[]},{"id":"a619854fade9a857","type":"debug","z":"289f539dcc33814e","name":"Summe","active":true,"tosidebar":true,"console":false,"tostatus":true,"complete":"payload","targetType":"msg","statusVal":"payload","statusType":"auto","x":840,"y":6700,"wires":[]},{"id":"ac7e466c2aba72a7","type":"change","z":"289f539dcc33814e","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"payload +  summand","tot":"jsonata"},{"t":"set","p":"payload","pt":"msg","to":"$round(payload,2)","tot":"jsonata"}],"action":"","property":"","from":"","to":"","reg":false,"x":650,"y":6700,"wires":[["a619854fade9a857"]]}]

=============================================

Nun das 2. Beispiel warum man nicht immer globale Variablen braucht und eben einfach zur Laufzeit einen 2. Wert sich in das Nachrichtenobjekt holen kann.

Wir nehmen wieder 2 Datenpunkte im iobroker:

In der Zahl steht 7.44 - könnte Dein ph Wert sein und nur wenn der Datenpunkt aktiv auf true steht, soll ein Flow was machen (also zum Beispiel könnte das auch Dein Automatikdatenpunkt sein).

Die Zahl 7.44 triggert also einen Flow und der Flow soll nur "aktiv" sein, wenn der Datenpunkt "aktiv" true ist. Also lesen wir den mit der iobroker-get Node DIREKT ZU DEM ZEITPUNKT aus, nachdem die der Datenpunkt "Zahl" getriggert hat und wir haben beide Werte in einem Nachrichtenobjekt. Siehst Du ja in der Debugausgabe.

Diese Eigenschaft im Nachrichtenobjekt können wir nun direkt zum Filtern mit einer Switch Node verwenden.

Nun erhalten wir nur eine Ausgabe, wenn der Datenpunkt "aktiv" auf true steht, anderenfalls ist der Flow blockiert:

und Du erhälst keine Ausgabe.

Ich hoffe damit ist es nun klar geworden.

[BF0911]

@mickym

Der Flow Automatik war so gedacht, dass dort nur der "Betriebszustand" gesetzt wird und nur, wenn dieser deaktiviert wird, die Pumpen ausgeschaltet werden.

Das muss aber auch nicht zwingend sein.

[mickym]

@bf0911 Ok - kannst Du alles machen -

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

@mickym

Der Flow Automatik war so gedacht, dass dort nur der "Betriebszustand" gesetzt wird und nur, wenn dieser deaktiviert wird, die Pumpen ausgeschaltet werden.

Das muss aber auch nicht zwingend sein.

Ist ja OK - kannst Du alles machen. Dann mach es so. Kein Problem - Du musst dann halt nur noch das Kommando zum ausschalten der Pumpen an den richtigen Datenpunkt setzen.

[BF0911]

@mickym

Die sind bewusst nocht nicht verbunden, um fehlerhaftes einschalten der Pumpen zu verhindern.