Wartung am 15.11. – Forum ab 22:00 Uhr nicht erreichbar

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

[mickym]

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

@mickym

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

Sehr gut - dann machst Du erstmal debug Nodes dran, um zu sehen, ob das Ergebnis stimmt. Du kannst das wenn Du die Debug Nodes richtig benennst dann im Debug fenster sehen, Du kannst Dir aber gleichzeitig unter den Debug Node das Ergebnis im Flow anzeigen lassen:

Wenn Du die Option im Status ausgeben lassen siehst Du sofort im Flow wie die Pumpe durch was im Flow gesteuert wird.

Aus dem Post den ich unten gerade noch bearbeite siehst Du dann den Status nicht nur im Debugfenster sondern auch im Status der Node.

[mickym]

Ich hab den langen Erklärungspost um den Unterschied zwischen iobroker-In und iobroker-get abgeschlossen. Falls das immer noch nicht so klar sein sollte, dann sollten wir es später in Deinem Flow praktisch anwenden. Aber ich habe versucht Dir anhand von 2 Beispielen aufzuzeigen, wie das eingesetzt wird. Wenn Du vorher Blockly verwendet hast, kann ich Dir auch die Entsprechnungen zeigen.

Das entspricht einer iobroker-In Node:

und das entspricht einer iobroker-get Node:

Die iobroker-IN Node TRIGGERT also, während die iobroker-GET Node einen Wert zur Laufzeit/im Flow ausliest.

[BF0911]

@mickym

Den Erklärungs-Post habe ich gesehen. Erstmal vielen Dank dafür.

Ich hab das mal versucht, umzusetzen, so wie ich das verstanden habe.

Wäre das so korrekt?

Wobei mir der Debug-Output nicht richtig vorkommt?

{"payload":"{\"timers\":[{\"starttime\":1715583600000,\"days\":[1,1,1,1,1,1,1],\"output\":\"0\",\"endtime\":1715594400000},{\"starttime\":1715597820000,\"days\":[1,1,1,1,1,1,1],\"output\":\"0\",\"endtime\":1715616000000}],\"settings\":{\"disabledDevices\":[]}}","_msgid":"8d9646034ae84e63","aktiv":true,"acknowledged":false,"timestamp":1715597616699,"lastchange":1715597616699,"topic":"0_userdata.0.Pool.Automatik-Modus"}

Ich hätte erwartet, dass der ui-scheduler auch ein true oder false ausgibt.

Der Ui-Scheduler triggert, ich frage den Automatik-Modus ab, setzt den auf msg.aktiv und der Switch schaltet die Pumpe an.

Dann man auch mehrere iobroker.get hintereinander setzen und damit hier, die Switch "Chlor-Pumpe aus" und "PH-Pumpe aus" ersetzen?

[mickym]

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

Dann man auch mehrere iobroker.get hintereinander setzen und damit hier, die Switch "Chlor-Pumpe aus" und "PH-Pumpe aus" ersetzen?

Mit der Scheduler Node kenn ich mich nicht so gut aus, da ich die nicht verwende. Aber ja die Debug Node enthält ja noch die payload Deiner Schedler Node.

Ich muss mir die erste mal installieren, um zu sehen, ob ich die brauchbar finde. Ich habe sie damals aus irgendwelchen Gründen erst mal nicht verwendet. Also einen Augenblick Geduld damit ich mir die Scheduler Node genauer anschauen kann.

[mickym]

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

Dann man auch mehrere iobroker.get hintereinander setzen und damit hier, die Switch "Chlor-Pumpe aus" und "PH-Pumpe aus" ersetzen?

Mit den iobroker-get Nodes liest Du nur Datenpunkte aus und holst diese in dein Nachrichtenobjekt, mit der Switch Node filterst Du nachrichten oder verteilst sie im Flow - das eine hat mit dem anderen nichts zu tun. Du kannst alle Werte aus dem iobroker einlesen und dann mit dem Switch die Werte abfragen. In dem Du sie in Serie schaltest ist das wie eine UND verknüpfung. Schaltest Du die Switch Nodes parallel ist das wie eine ODER Verknüpfung.

Ich kümmere mich jetzt erst mal um Deine scheduler node.

[mickym]

Also die Scheduler Node hat mehrere Ausgänge Du musst halt bissi die Hilfe zu der Node anschauen und Du hast das falsch verstanden.

Am Ausgang 1 kommen nur Zeitpläne raus, die Du analysieren kannst. Also die Einstellungen zum Scheduler.

Also wie gesagt die Hilfe durchlesen.

Das true und false wird Dir je nach Refresh Intervall - hier alle 60 s geschickt. Du kannst Dir auch nur das true so oft schicken lassen und das false nur einmal - siehst Du ja alles in der Hilfe

Wie Du siehst ist das erste Gerät - ich habe es mal Pumpe genannt am Ausgang 2, falls Du noch ein Gerät hast am Ausgang 3 usw.

Das Signal für deine Pumpe ist also am unteren Ausgang und wird Dir alle Minuten geschickt.

Oben kommt nur was raus, wenn Du den Zeitplan änderst - das kannst ja erst mal ignorieren, ausser Du möchtest den Zeitplan analysieren für Folgeaktionen.

Wenn Du Deinen Zeitplan aber im Scheduler deaktivierst - dann brauchst aber dann keine Datenpunkte im iobroker mehr.
Dann kannst Du damit ggf. eine Flowvariable oder auch eine globale Variable setzen.

In diesem Fall erhälst jedesmal am oberen Ausgang eine Nachricht, die Du analysieren kannst.

Das ist ein JSON String der eine Array mit Deinen deaktivierten Geräten unter settings disabled devices enthält.

Nehmen wir mal an, Du willst 2 Geräte mit dem ui-Scheduler steuern.

In diesem Fall würde der Status für die Pumpe am Ausgang 2 und der für die Heizung am Ausgang 3 rauskommen.

[BF0911]

@mickym

Das mit der Hilfe hätte mir auch selbst einfallen können. Danke!

Der "Pumpe an"-Teil klappt. Das Ganze hab ich dann analog für den "Pumpe aus"-Teil auch gemacht.

Es ist korrekt, dass ich pro msg ein Switch brauche oder? Hier im Beispiel einen für msg.chlor und einen für msg.ph

Wenn ich den Scheduler im Dashboard deaktivere, könnte ich auf den Datenpunkt Pool-Automatik verzichten, weil das doppelt gemoppelt wäre?!

[mickym]

@bf0911

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

Wenn ich den Scheduler im Dashboard deaktivere, könnte ich auf den Datenpunkt Pool-Automatik verzichten, weil das doppelt gemoppelt wäre?!

Ich bin ja noch bei den Erklärungen. Also gemach ... gemach ...

Also wenn Du mehre Geräte steuerst kannst Du zum einen über die Zeitplanausgabe den JSON analysieren. Lass uns erst mal das machen.

Im Moment siehst Du das der Zeitplan für die Pumpe false und für die Heizung true ist.

Wenn ich im Dashboard nun die Heizung deaktivere, wird mir ein JSON-String in dem oberen Ausgang ausgegeben, der ein Array enthält mit disabled Devices und einem Eintrag "1", die Pumpe würde einen Eintrag "0" enthalten.

Wenn ich beide deaktiviere sind beide ausgegraut.

und Du erhälst folgenden JSON.

Also beide Geräte in einem Array in disabled devices.

Um mit dem JSON arbeiten zu können müssen wir diesen in ein Objekt überführen.

Dazu gibt es die JSON Node, die JSON-Strings in Objekte wandelt und vice versa

So um zu überprüfen, welche Zeitpläne der scheduler Node gerade aktiv sind, kannst Du mit den Change Nodes entsprechende Flow variablen setzen oder auch global wenn Dir das lieber ist und entweder direkt damit was anstossen oder als Filter in switch Nodes verwenden.

Hier an der Change Node siehst Du wie ich Dir mit dem entsprecheneden Topic den Zustand des Zeitplans aktiv = true oder fals aus geben und wie in dem Screenshot darüber das gleich als Kontextvariable speichere, die Du dann bei dem Gerät ggf. als filter verwenden kannst.

Der JSONATA Code ist etwas komplex um das Array der disabledDevices zu analysieren. Du kannst ja wenn Du lieber Javascript programmierst, dies dann mit einer function Node machen.

Der JSONATA Code, um zu überprüfen, ob ein Gerät im Array der disabledDevices enthalten ist, habe ich folgenden Code genommen:

$not(payload.settings.disabledDevices~>$reduce(function($result,$v){$v="0" or $result},false))

"0" steht für das 1. Gerät in der scheduler Node, "1" für das 2. Gerät usw.

Hier wieder das Ganze zum Testen für Dich zum Import:

Spoiler

[
   {
       "id": "678c75e771b741cf",
       "type": "ui_time_scheduler",
       "z": "d25606275138920f",
       "group": "3979c1d87146b072",
       "name": "",
       "startDay": 0,
       "refresh": 60,
       "devices": [
           "Pumpe",
           "Heizung"
       ],
       "singleOff": false,
       "onlySendChange": false,
       "customPayload": false,
       "eventMode": false,
       "eventOptions": [],
       "sendTopic": false,
       "lat": "",
       "lon": "",
       "customContextStore": "",
       "outputs": 3,
       "order": 1,
       "width": 0,
       "height": 0,
       "x": 210,
       "y": 1920,
       "wires": [
           [
               "289ed99985ad7e4d"
           ],
           [
               "cbb8275a30eae9ec"
           ],
           [
               "697279c39e5c99c1"
           ]
       ]
   },
   {
       "id": "7c8c6774be13b33b",
       "type": "debug",
       "z": "d25606275138920f",
       "name": "Aktive Zeitpläne",
       "active": true,
       "tosidebar": true,
       "console": false,
       "tostatus": false,
       "complete": "payload",
       "targetType": "msg",
       "statusVal": "",
       "statusType": "auto",
       "x": 780,
       "y": 1840,
       "wires": []
   },
   {
       "id": "cbb8275a30eae9ec",
       "type": "debug",
       "z": "d25606275138920f",
       "name": "Pumpe",
       "active": false,
       "tosidebar": true,
       "console": false,
       "tostatus": false,
       "complete": "payload",
       "targetType": "msg",
       "statusVal": "",
       "statusType": "auto",
       "x": 380,
       "y": 1920,
       "wires": []
   },
   {
       "id": "697279c39e5c99c1",
       "type": "debug",
       "z": "d25606275138920f",
       "name": "Heizung",
       "active": false,
       "tosidebar": true,
       "console": false,
       "tostatus": false,
       "complete": "payload",
       "targetType": "msg",
       "statusVal": "",
       "statusType": "auto",
       "x": 380,
       "y": 1960,
       "wires": []
   },
   {
       "id": "289ed99985ad7e4d",
       "type": "json",
       "z": "d25606275138920f",
       "name": "",
       "property": "payload",
       "action": "",
       "pretty": false,
       "x": 390,
       "y": 1840,
       "wires": [
           [
               "b72cf3fd45869c96",
               "0bdc192669181073"
           ]
       ]
   },
   {
       "id": "b72cf3fd45869c96",
       "type": "change",
       "z": "d25606275138920f",
       "name": "",
       "rules": [
           {
               "t": "set",
               "p": "payload",
               "pt": "msg",
               "to": "$not(payload.settings.disabledDevices~>$reduce(function($result,$v){$v=\"0\" or $result},false))",
               "tot": "jsonata"
           },
           {
               "t": "set",
               "p": "topic",
               "pt": "msg",
               "to": "Pumpe",
               "tot": "str"
           },
           {
               "t": "set",
               "p": "Pumpe",
               "pt": "flow",
               "to": "payload",
               "tot": "msg"
           }
       ],
       "action": "",
       "property": "",
       "from": "",
       "to": "",
       "reg": false,
       "x": 570,
       "y": 1820,
       "wires": [
           [
               "7c8c6774be13b33b"
           ]
       ]
   },
   {
       "id": "0bdc192669181073",
       "type": "change",
       "z": "d25606275138920f",
       "name": "",
       "rules": [
           {
               "t": "set",
               "p": "payload",
               "pt": "msg",
               "to": "$not(payload.settings.disabledDevices~>$reduce(function($result,$v){$v=\"1\" or $result},false))",
               "tot": "jsonata"
           },
           {
               "t": "set",
               "p": "topic",
               "pt": "msg",
               "to": "Heizung",
               "tot": "str"
           },
           {
               "t": "set",
               "p": "Heizung",
               "pt": "flow",
               "to": "payload",
               "tot": "msg"
           }
       ],
       "action": "",
       "property": "",
       "from": "",
       "to": "",
       "reg": false,
       "x": 570,
       "y": 1860,
       "wires": [
           [
               "7c8c6774be13b33b"
           ]
       ]
   },
   {
       "id": "3979c1d87146b072",
       "type": "ui_group",
       "name": "Scheduler",
       "tab": "5fb772105c6cc8b7",
       "order": 2,
       "disp": true,
       "width": "6",
       "collapse": false,
       "className": ""
   },
   {
       "id": "5fb772105c6cc8b7",
       "type": "ui_tab",
       "name": "Home",
       "icon": "dashboard",
       "disabled": false,
       "hidden": false
   }
]

[mickym]

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

@mickym

Das mit der Hilfe hätte mir auch selbst einfallen können. Danke!

Der "Pumpe an"-Teil klappt. Das Ganze hab ich dann analog für den "Pumpe aus"-Teil auch gemacht.

Es ist korrekt, dass ich pro msg ein Switch brauche oder? Hier im Beispiel einen für msg.chlor und einen für msg.ph

Wenn ich den Scheduler im Dashboard deaktivere, könnte ich auf den Datenpunkt Pool-Automatik verzichten, weil das doppelt gemoppelt wäre?!

So schnell komm ich nicht mit, wenn ich dir einerseits was erklären soll und dann kommen neue Probleme auf.

Also was soll dieser Flow eigentlich, wo bestimmte Dinge gleichzeitig ohne Abhängigkeiten passieren. Was soll das mit dem Automatikmodus, wenn Du unten dann alles wieder umgehst? Ich würde sowas vermeiden, ausser es steckt eine bestimmte Logik dahinter, die sich mir aber auf Anhieb nicht erschließt.

Du kannst die switch Nodes schön in Reihe schalten so wie du es getan hast und musst halt einen sinnvollen Namen geben.

Du kannst das auch in eine switch Node machen, dann wirds aber schon wieder unübersichtlicher. Wenn Du es nicht in zwei switch nodes sondern in einer machen willst, dann überprüfst Du eben nicht eine Nachrichteneigenschaft, sondern die "UND" Verknüpfung zweier Nachrichteneigenschaften.

Das musst Du halt wissen, ist halt dann wieder etwas schwerer zum verändern oder debuggen.

Also überprüfst Du in diesem Fall in der Switch Node nicht EINE Nachrichteneigenschaft, sondern die logisch UND Verknüpfung zweier Nachrichteneigenschaften mit JSONATA.

Ich finde die untere Methode leichter zu durchschauen (s. Diskussion mit function Nodes)

Hier zum Test:

Spoiler

[
   {
       "id": "53a2f06873cbfef6",
       "type": "switch",
       "z": "d25606275138920f",
       "name": "ph and chlor = true",
       "property": "ph=true and chlor=true",
       "propertyType": "jsonata",
       "rules": [
           {
               "t": "true"
           }
       ],
       "checkall": "true",
       "repair": false,
       "outputs": 1,
       "x": 510,
       "y": 1620,
       "wires": [
           [
               "c5b12c20e36dda6f"
           ]
       ]
   },
   {
       "id": "c5b12c20e36dda6f",
       "type": "debug",
       "z": "d25606275138920f",
       "name": "ph and chlor = true",
       "active": true,
       "tosidebar": true,
       "console": false,
       "tostatus": false,
       "complete": "payload",
       "targetType": "msg",
       "statusVal": "",
       "statusType": "auto",
       "x": 710,
       "y": 1620,
       "wires": []
   },
   {
       "id": "aa59a70cd6ef8804",
       "type": "inject",
       "z": "d25606275138920f",
       "name": "",
       "props": [
           {
               "p": "ph",
               "v": "true",
               "vt": "bool"
           },
           {
               "p": "chlor",
               "v": "true",
               "vt": "bool"
           },
           {
               "p": "payload"
           }
       ],
       "repeat": "",
       "crontab": "",
       "once": false,
       "onceDelay": 0.1,
       "topic": "",
       "payload": "Meine payload",
       "payloadType": "str",
       "x": 280,
       "y": 1620,
       "wires": [
           [
               "53a2f06873cbfef6",
               "7f2af878c5e93a07"
           ]
       ]
   },
   {
       "id": "e2cb3bbe06ec059b",
       "type": "debug",
       "z": "d25606275138920f",
       "name": "ph and chlor = true",
       "active": true,
       "tosidebar": true,
       "console": false,
       "tostatus": false,
       "complete": "payload",
       "targetType": "msg",
       "statusVal": "",
       "statusType": "auto",
       "x": 850,
       "y": 1680,
       "wires": []
   },
   {
       "id": "7f2af878c5e93a07",
       "type": "switch",
       "z": "d25606275138920f",
       "name": "ph = true ?",
       "property": "ph",
       "propertyType": "msg",
       "rules": [
           {
               "t": "true"
           }
       ],
       "checkall": "true",
       "repair": false,
       "outputs": 1,
       "x": 470,
       "y": 1680,
       "wires": [
           [
               "f8611c02cdcb83b6"
           ]
       ]
   },
   {
       "id": "f8611c02cdcb83b6",
       "type": "switch",
       "z": "d25606275138920f",
       "name": "chlor = true ?",
       "property": "chlor",
       "propertyType": "msg",
       "rules": [
           {
               "t": "true"
           }
       ],
       "checkall": "true",
       "repair": false,
       "outputs": 1,
       "x": 650,
       "y": 1680,
       "wires": [
           [
               "e2cb3bbe06ec059b"
           ]
       ]
   }
]

[BF0911]

@mickym

Sorry, ich bin etwas schnell.

Grundsätzlich soll bei dem Flow die Pumpe laufen, wenn der Automatik-Modus und der Scheduler "true" ist.

Über die "Get"-Node hole ich doch über den Trigger "ui scheduler" den Status Pool-Automatik und dann per Switch auf true.

Das Ganze wollte ich auch zum ausschalten nutzen.

Switch (Wenn Zeitplan false) als Trigger, über Get-Objekte Ph- und Chlor-Pumpe und jeweils als Switch ob beide false.

Heißt die Pumpe soll nicht abgeschaltet werden, wenn eine der beiden Dosierpumpen noch laufen.

[mickym]

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

Grundsätzlich soll bei dem Flow die Pumpe laufen, wenn der Automatik-Modus und der Scheduler "true" ist.

Ja dann trotzdem in einem Flow und warum brauchst Du einen Datenpunkt Automatik Modus, wenn Du im Scheduler den Zeitplan aktivieren und deaktivieren kannst. Ich bin gerade dabei, Dir das mit dem Scheduler im unteren Post noch zu erklären. Bissi Geduld.