Flip Flop Logik an Hand nummerischen Wert
-
@codierknecht Leider ist das Blockly so noch nicht richtig.
Beispiel:- Der Wert steigt auf 60, der Trigger löst aus, notificationSent ist noch auf false.
-> Der Timeout wird gestartet, notificationSent wird auf true gesetzt. - Nun steigt der Wert auf 61, der Trigger löst aus, notificationSent ist auf true.
-> Der Timeout wird gelöscht, notificationSent wird wieder auf false gesetzt.
Wenn nun zwischen den beiden Auslösern mehr als 30 Minuten lagen, wurde die Nachricht gesendet, wenn im Anschluss der Wert dann auf 62 steigt wird eine weitere Nachricht gesendet.
Wenn weniger als 30 Minuten zwischen 1 und 2 lagen, wurde die Nachricht nicht gesendet und der Timer wird erst wieder gestartet, wenn sich der Wert erneut ändert (und >= 60 ist).Die Abfrage auf !notificationSend muss in ein eigenes if und darf nicht mit dem >= 60 per und verknüpft werden.
- Der Wert steigt auf 60, der Trigger löst aus, notificationSent ist noch auf false.
-
@zarello
Ich sehe das etwas anders:- Der Trigger feuert, der Wert ist > 60 und notificationSent ist false.
Nun wird notificationSent gesetzt und auch gleich der Timer gestartet. - Der Wert steigt auf 61, der Trigger feuert
Da notificationSent jetzt true ist, läuft der Timer einfach weiter (and !notificationSent), bis die 30 Minuten um sind.
Solange der Wert in der Zwischenzeit nicht unter 60 sinkt, wird nach 30 Minuten die Nachricht gesendet. - Falls der Wert innerhalb der 30 Minuten unter 60 sinkt, wird der Timer gestoppt und notificationSent auf false gesetzt.
... repeat
- Der Trigger feuert, der Wert ist > 60 und notificationSent ist false.
-
@zarello
In JS sähe das so aus:notificationSent = false; on({id: "0_userdata.0.Durchschnitt", change: "ne"}, async function (obj) { var value = obj.state.val; if (value >= 60) { if (!notificationSent) { notificationSent = true; (function () {if (timeout2) {clearTimeout(timeout2); timeout2 = null;}})(); // Timer löschen // Timer 30 Minuten starten timeout2 = setTimeout(async function () { console.log('bitte lüften'); }, 1800000); } } else { (function () {if (timeout2) {clearTimeout(timeout2); timeout2 = null;}})(); // Timer löschen notificationSent = false; } });[Edit]
Auch hier nach dem Hinweis von @Zarello korrigiert -
@codierknecht sagte in Flip Flop Logik an Hand nummerischen Wert:
Da muss ich Dir leider widersprechen.
Bei Deinem zweiten Punkt wird folgendes geschehen:- Der Wert steigt auf 61, der Trigger feuert
- Die Abfrage (falls) wird als Ergebniss der Und-Verknüpfung ein false erhalten, da:
(Wert >= 60 und nicht notificationSend) == (true und nicht true) == (true und false) == false ist.
Der weitere Verlauf geht also über den sonst-Zweig. Dort wird der Timer gestoppt und notificationSend auf false gesetzt. Das möchte man an der Stelle beides nicht.
- Die Abfrage (falls) wird als Ergebniss der Und-Verknüpfung ein false erhalten, da:
- Nun steigt der Wert auf 62 (oder sinkt auf 60), der Trigger feuert erneut aber notificationSend ist ja nun auf false, dementsprechend wird ein neuer Timer aufgesetzt (das Skript landet wieder im mache-Zweig).
- Der Wert steigt auf 61, der Trigger feuert
-
@zarello sagte in Flip Flop Logik an Hand nummerischen Wert:
Der Wert steigt auf 61, der Trigger feuert
Die Abfrage (falls) wird als Ergebniss der Und-Verknüpfung ein false erhalten, da:
(Wert >= 60 und nicht notificationSend) == (true und nicht true) == (true und false) == false ist.
Der weitere Verlauf geht also über den sonst-Zweig. Dort wird der Timer gestoppt und notificationSend auf false gesetzt. Das möchte man an der Stelle beides nicht.Korrekt - Denkfehler!
Danke für den Hinweis
- Ich werde das korrigieren.
Geht zwar hier immer noch speziell um NodeRed, daber trotzdem sollte das Blockly korrekt sein. -
@mickym Ich habe den Trigger über das Flip Flop nun auch für den Fenster Sensor erweitert der mir zwei Mail sendet:
- Fenster > 10 min offen
- Fenster wieder zu.
Jetzt habe ich aber folgendes Problem: Sobald ich ein deploy in Node-Red vornehme und ich die Einstellungen wie im Anhang
Am Fenstersensor eingestellt habe, kommt natürlich das False von Fenster zu. Durch den Filter wird dies aber nicht als gleiches Signal erkannt und somit kommt bei jedem Deploy nun für jedes Fenster "Info Mail = zu" 
Das ist natürlich ultra nervig aber vielleicht gibts ja hierfür eine Abhilfe, dass das Signal nur gesendet wird, falls sich der Wert von False auf True auch ändert.
Nur was muss ich da einstellen?Hier mal der exportiere Flow:
[ { "id": "a1771eb8a0b9a8ee", "type": "tab", "label": "Flow 1", "disabled": false, "info": "", "env": [] }, { "id": "9e9457e7023677ee", "type": "template", "z": "a1771eb8a0b9a8ee", "name": "E-mail Inhalt Fenster offen", "field": "payload", "fieldType": "msg", "format": "handlebars", "syntax": "mustache", "template": "<style>\n .Font_Topic {\n font-size: 20px;\n color: orange;\n font-weight: bold;\n }\n .Font_Msg {\n font-size: 14px;\n } \n .Font_ToDo {\n font-size: 16px;\n color: blue;\n font-weight: bold;\n } \n</style>\n<p class=\"Font_Topic\">Warnung</p>\n<p class=\"Font_Msg\">Das Fenster im WZ ist > 10 min. offen!</p>\n<p class=\"Font_ToDo\">Bitte Fenster wieder schließen!</p> ", "output": "str", "x": 1560, "y": 220, "wires": [ [ "d7ff26f38099bba4" ] ] }, { "id": "857e81b96ad7dfcd", "type": "delay", "z": "a1771eb8a0b9a8ee", "name": "Fenster-WZ-Auf-oder-Zu-Check", "pauseType": "delay", "timeout": "10", "timeoutUnits": "minutes", "rate": "1", "nbRateUnits": "1", "rateUnits": "second", "randomFirst": "1", "randomLast": "5", "randomUnits": "seconds", "drop": false, "allowrate": false, "outputs": 1, "x": 490, "y": 220, "wires": [ [ "170f9806e6f01888" ] ] }, { "id": "49ae3e4a58c56cf2", "type": "switch", "z": "a1771eb8a0b9a8ee", "name": "Fenster-Check-WZ", "property": "payload", "propertyType": "msg", "rules": [ { "t": "true" }, { "t": "false" } ], "checkall": "false", "repair": false, "outputs": 2, "x": 190, "y": 260, "wires": [ [ "857e81b96ad7dfcd" ], [ "4453e8e63d28a5a8", "6b4ab52a95d9dce4" ] ] }, { "id": "d7ff26f38099bba4", "type": "change", "z": "a1771eb8a0b9a8ee", "name": "Fenster-Offen-Msg-bearbeiten", "rules": [ { "t": "set", "p": "topic", "pt": "msg", "to": "Fenster WZ", "tot": "str" } ], "action": "", "property": "", "from": "", "to": "", "reg": false, "x": 1870, "y": 240, "wires": [ [ "fafdbd04107d19a0" ] ] }, { "id": "4453e8e63d28a5a8", "type": "change", "z": "a1771eb8a0b9a8ee", "name": "Reset-Timer-Fenster", "rules": [ { "t": "set", "p": "reset", "pt": "msg", "to": "reset", "tot": "str" } ], "action": "", "property": "", "from": "", "to": "", "reg": false, "x": 440, "y": 320, "wires": [ [ "857e81b96ad7dfcd" ] ] }, { "id": "216ea53d06a9149a", "type": "template", "z": "a1771eb8a0b9a8ee", "name": "E-mail Inhalt Fenster zu", "field": "payload", "fieldType": "msg", "format": "handlebars", "syntax": "mustache", "template": "<style>\n .Font_Topic {\n font-size: 20px;\n color: blue;\n font-weight: bold;\n }\n .Font_Msg {\n font-size: 14px;\n } \n .Font_ToDo {\n font-size: 16px;\n color: blue;\n font-weight: bold;\n } \n</style>\n<p class=\"Font_Topic\">Info</p>\n<p class=\"Font_Msg\">Das Fenster im WZ ist wieder zu.</p>", "output": "str", "x": 1550, "y": 260, "wires": [ [ "d7ff26f38099bba4" ] ] }, { "id": "170f9806e6f01888", "type": "change", "z": "a1771eb8a0b9a8ee", "name": "Setze-Payload1", "rules": [ { "t": "set", "p": "payload1", "pt": "msg", "to": "true", "tot": "bool" } ], "action": "", "property": "", "from": "", "to": "", "reg": false, "x": 760, "y": 240, "wires": [ [ "9666b4d36f96e798" ] ] }, { "id": "9666b4d36f96e798", "type": "rbe", "z": "a1771eb8a0b9a8ee", "name": "FlipFlop-Fenster", "func": "rbe", "gap": "", "start": "", "inout": "out", "septopics": true, "property": "payload1", "topi": "topic", "x": 1010, "y": 240, "wires": [ [ "5eec6b6ac953b891" ] ] }, { "id": "6b4ab52a95d9dce4", "type": "change", "z": "a1771eb8a0b9a8ee", "name": "Rücksetze-Payload1", "rules": [ { "t": "set", "p": "payload1", "pt": "msg", "to": "false", "tot": "bool" } ], "action": "", "property": "", "from": "", "to": "", "reg": false, "x": 780, "y": 300, "wires": [ [ "9666b4d36f96e798" ] ] }, { "id": "5eec6b6ac953b891", "type": "switch", "z": "a1771eb8a0b9a8ee", "name": "Auswahl-Msg-FlipFlop", "property": "payload1", "propertyType": "msg", "rules": [ { "t": "true" }, { "t": "false" } ], "checkall": "false", "repair": false, "outputs": 2, "x": 1240, "y": 240, "wires": [ [ "9e9457e7023677ee" ], [ "216ea53d06a9149a" ] ] }, { "id": "6b80a510f0f36535", "type": "comment", "z": "a1771eb8a0b9a8ee", "name": "Hilfswert speichern", "info": "Hilfswert payload1 speichern, sodass Meldung nur 1. kommt.", "x": 770, "y": 180, "wires": [] }, { "id": "fafdbd04107d19a0", "type": "debug", "z": "a1771eb8a0b9a8ee", "name": "Ab-Hier-E-mail Versand", "active": true, "tosidebar": true, "console": false, "tostatus": false, "complete": "payload", "targetType": "msg", "statusVal": "", "statusType": "auto", "x": 2160, "y": 240, "wires": [] } ] -
@_r_a_l_f_ sagte in Flip Flop Logik an Hand nummerischen Wert:
Sobald ich ein deploy in Node-Red vornehme und ich die Einstellungen wie im Anhang
- Kann man das deploy so einstellen, dass nur die veränderten Nodes neu initialisiert werden (dann passiert das nicht bei jedem Deploy).
- Kann man im filter einstellen, dass der Anfangswert ignoriert wird. Das dient genau dazu, dass nach Neustart vom Node-Red der Filter initialisiert wird, aber keinen Wert weiter schickt.
-
@mickym Ah perfekt, vielen Dank für den Tipp. An der falschen Stelle gesucht
-
@_r_a_l_f_ Bin zwar nicht so sicher, ob ich Deinen Flow - sonst so prickelnd finde, aber ich hoffe es hilft erst mal.
-
@mickym Gerne korrigieren, wenn du eine bessere Lösung hast
-
@_r_a_l_f_ sagte in Flip Flop Logik an Hand nummerischen Wert:
@mickym Gerne korrigieren, wenn du eine bessere Lösung hast
So ich arbeitete lieber mit der trigger Node- da du dort auch direkt die reset Bedingung definieren kannst. Ich komm da auch ohne Hilfsvariable aus - aber vielleicht habe ich auch einen Denkfehler.
Jedenfalls kommt es mit "cleaner" vor.
Der untere Vorschlag ist meiner - der obere war Dein Originalflow:
Hier mal zum Testen:
Noch eine Bemerkung: Wenn man in der Filter Node - den Anfangswertignoriert kann man auch oder sollte die Filter-Node gleich initialisieren - also in der iobroker_in Node den Datenpunkt gleich auslesen:
-
@mickym Sorry für die späte Rückmeldung. War seit dem nicht mehr on aber trotzdem vielen Dank für den Lösungsvorschlag
Beim ersten Test sind mir jetzt keine Auffälligkeiten zu anderne Lösung aufgefallen und es ist definitiv schlanker. Werde ich jetzt überall mal abändern und testen. -
@mickym Da die neue Situation recht ähnlicher dieser (Flip Flop Logik) ist und ich den Fehler nicht wirklich erkennen kann bräuchte ich mal deinen Input zu dem ganzen:
Es geht um eine Level Regelung, welche sich aus dem Switch Node Input ergibt.
Dann sollen verzögert Stufen aktiviert werden.
Stufe 0 ist quasi die Ausgangslage, wenn der nummerische Wert kleiner Stufe 1 ist (Basislevel).
Wenn verz. Stufe 1 aktiviert wird, soll Stufe 0 deaktiviert werden und Stufe 1 aktiviert.
Wenn verz. Stufe 2 aktiviert wird, dann soll Stufe 2 aktiviert, jedoch Stufe 1 auch weiterhin aktiv sein.
Wenn jedoch Stufe 1 wieder aktiviert wird (auf Grund vom fallenden Level) dann soll Stufe 2 deaktiviert werden.
Deaktiviert = payload = falseProblem ist bei diesem Flow, dass zwar Stufe 2 aktiviert (payload = true) wird, jedoch nicht mehr deaktiviert obwohl ich über den Change Node den payload = false sende.
Gleiches gilt für die Deaktivierung von Stufe 1.
Ich weiß nicht, wo bei der Konfig der Wurm bzw. ich nen Denkfehler drin hab. Eigentlich dachte ich, sollte es so funktionieren?[ { "id": "86b699fc65f0566c", "type": "tab", "label": "Flow 1", "disabled": false, "info": "", "env": [] }, { "id": "83c967f55180cc71", "type": "switch", "z": "86b699fc65f0566c", "name": "Level", "property": "payload", "propertyType": "msg", "rules": [ { "t": "lte", "v": "9", "vt": "num" }, { "t": "btwn", "v": "10", "vt": "num", "v2": "20", "v2t": "num" }, { "t": "btwn", "v": "21", "vt": "num", "v2": "50", "v2t": "num" } ], "checkall": "true", "repair": false, "outputs": 3, "x": 450, "y": 400, "wires": [ [ "45e1374c190cb520" ], [ "13927d8d45ca75cb" ], [ "295ea16dd1d33c31" ] ] }, { "id": "379d70bfb24cf060", "type": "inject", "z": "86b699fc65f0566c", "name": "", "props": [ { "p": "payload" }, { "p": "topic", "vt": "str" } ], "repeat": "", "crontab": "", "once": false, "onceDelay": 0.1, "topic": "", "payload": "9", "payloadType": "num", "x": 250, "y": 340, "wires": [ [ "83c967f55180cc71" ] ] }, { "id": "4d6d4ba517060abb", "type": "inject", "z": "86b699fc65f0566c", "name": "", "props": [ { "p": "payload" }, { "p": "topic", "vt": "str" } ], "repeat": "", "crontab": "", "once": false, "onceDelay": 0.1, "topic": "", "payload": "22", "payloadType": "num", "x": 250, "y": 440, "wires": [ [ "83c967f55180cc71" ] ] }, { "id": "ae3b15d743245f73", "type": "inject", "z": "86b699fc65f0566c", "name": "", "props": [ { "p": "payload" }, { "p": "topic", "vt": "str" } ], "repeat": "", "crontab": "", "once": false, "onceDelay": 0.1, "topic": "", "payload": "10", "payloadType": "num", "x": 250, "y": 380, "wires": [ [ "83c967f55180cc71" ] ] }, { "id": "13927d8d45ca75cb", "type": "trigger", "z": "86b699fc65f0566c", "name": "verz-Stufe-1", "op1": "", "op2": "true", "op1type": "nul", "op2type": "bool", "duration": "2", "extend": false, "overrideDelay": false, "units": "s", "reset": "", "bytopic": "all", "topic": "topic", "outputs": 1, "x": 1070, "y": 480, "wires": [ [ "457047e020452c79", "03596b8e2240fce5", "f312cd2583a1dce9" ] ] }, { "id": "6696c4033e0fcaab", "type": "comment", "z": "86b699fc65f0566c", "name": "Level Regelung Test", "info": "", "x": 490, "y": 340, "wires": [] }, { "id": "45fc70d55ae8d276", "type": "debug", "z": "86b699fc65f0566c", "name": "Stufe 1 verz", "active": true, "tosidebar": true, "console": false, "tostatus": false, "complete": "payload", "targetType": "msg", "statusVal": "", "statusType": "auto", "x": 1590, "y": 480, "wires": [] }, { "id": "295ea16dd1d33c31", "type": "trigger", "z": "86b699fc65f0566c", "name": "verz-Stufe-2", "op1": "", "op2": "true", "op1type": "nul", "op2type": "bool", "duration": "2", "extend": false, "overrideDelay": false, "units": "s", "reset": "", "bytopic": "all", "topic": "topic", "outputs": 1, "x": 1090, "y": 720, "wires": [ [ "d060922c7999cb68" ] ] }, { "id": "22decc37459730eb", "type": "debug", "z": "86b699fc65f0566c", "name": "Stufe 2 verz", "active": true, "tosidebar": true, "console": false, "tostatus": false, "complete": "payload", "targetType": "msg", "statusVal": "", "statusType": "auto", "x": 1590, "y": 720, "wires": [] }, { "id": "824dcc36a821c6e2", "type": "debug", "z": "86b699fc65f0566c", "name": "Stufe 0 verz", "active": true, "tosidebar": true, "console": false, "tostatus": false, "complete": "payload", "targetType": "msg", "statusVal": "", "statusType": "auto", "x": 1590, "y": 260, "wires": [] }, { "id": "03596b8e2240fce5", "type": "change", "z": "86b699fc65f0566c", "name": "Reset-Stufe-2", "rules": [ { "t": "set", "p": "payload", "pt": "msg", "to": "false", "tot": "bool" }, { "t": "set", "p": "reset", "pt": "msg", "to": "true", "tot": "bool" }, { "t": "set", "p": "topic", "pt": "msg", "to": "Reset-Stufe-2", "tot": "str" } ], "action": "", "property": "", "from": "", "to": "", "reg": false, "x": 1080, "y": 540, "wires": [ [ "295ea16dd1d33c31", "d060922c7999cb68" ] ] }, { "id": "b9463c3c604f8325", "type": "change", "z": "86b699fc65f0566c", "name": "Reset-Stufe-1", "rules": [ { "t": "set", "p": "reset", "pt": "msg", "to": "true", "tot": "bool" }, { "t": "set", "p": "payload", "pt": "msg", "to": "false", "tot": "bool" }, { "t": "set", "p": "topic", "pt": "msg", "to": "Reset-Stufe-1", "tot": "str" } ], "action": "", "property": "", "from": "", "to": "", "reg": false, "x": 1080, "y": 320, "wires": [ [ "13927d8d45ca75cb", "457047e020452c79" ] ] }, { "id": "45e1374c190cb520", "type": "trigger", "z": "86b699fc65f0566c", "name": "verz-Stufe-0", "op1": "", "op2": "true", "op1type": "nul", "op2type": "bool", "duration": "2", "extend": false, "overrideDelay": false, "units": "s", "reset": "", "bytopic": "all", "topic": "topic", "outputs": 1, "x": 1070, "y": 260, "wires": [ [ "477cea2901f824e9", "b9463c3c604f8325" ] ] }, { "id": "d060922c7999cb68", "type": "rbe", "z": "86b699fc65f0566c", "name": "Aktiv-Stufe-2", "func": "rbei", "gap": "", "start": "", "inout": "out", "septopics": false, "property": "payload", "topi": "topic", "x": 1370, "y": 720, "wires": [ [ "22decc37459730eb" ] ] }, { "id": "457047e020452c79", "type": "rbe", "z": "86b699fc65f0566c", "name": "Aktiv-Stufe-1", "func": "rbei", "gap": "", "start": "", "inout": "out", "septopics": false, "property": "payload", "topi": "topic", "x": 1370, "y": 480, "wires": [ [ "45fc70d55ae8d276" ] ] }, { "id": "477cea2901f824e9", "type": "rbe", "z": "86b699fc65f0566c", "name": "Aktiv-Stufe-0", "func": "rbe", "gap": "", "start": "", "inout": "out", "septopics": false, "property": "payload", "topi": "topic", "x": 1370, "y": 260, "wires": [ [ "824dcc36a821c6e2" ] ] }, { "id": "f312cd2583a1dce9", "type": "change", "z": "86b699fc65f0566c", "name": "Reset-Stufe-0", "rules": [ { "t": "set", "p": "payload", "pt": "msg", "to": "false", "tot": "bool" }, { "t": "set", "p": "topic", "pt": "msg", "to": "Reset-Stufe-1", "tot": "str" } ], "action": "", "property": "", "from": "", "to": "", "reg": false, "x": 1380, "y": 320, "wires": [ [ "477cea2901f824e9" ] ] } ] -
@_r_a_l_f_ Das Problem ist erkannt, da Du mit msg.reset=true nicht nur die Trigger-Node zurücksetzt, sondern auch die Filter-Node. Da diese aber darauf konfiguriert ist, dass der erste Wert ignoriert wird, wird die Nachricht, die von der Change-Node Reset-2 immer blockiert. Die einfachst Frage ist brauchst Du das zurücksetzen der Trigger Nodes denn?
Schau mal ob Du ohne Reset auskommst:
Falls aus irgendeinem mir momentan nicht ersichtlichen Grund Du nicht ohne Reset auskommst, dann musst Du den Reset vor den Trigger Nodes machen und nicht dahinter. Ich hab die Verbindung im Moment gekappt.
Falls Du an den Grenzen - ggf- Schwankungen haben solltest solltest Du halt ganz vorne noch eine Filter Node dazumachen.
-
@mickym Danke für den Tipp mit dem Reset und den geänderten Flow.
Das Problem ist (zumindest zeigt sich das Verhalten auch im neuen Flow von dir) dass wenn z.B. der Switch den Timer von z.B. verz-Stufe-2 aufzieht und dann innnerhalb der Zeit aber wieder auf Stufe 1 zurückfällt, wird der Timer nicht abgelöscht und es kommt trotzdem das msg.payload = true durch. Dafür wäre ja eigentlich der trigger node drin, dass erst wenn der Schwellwert > Zeit X ansteht, auch durchgeschaltet wird und umgekehrt, wenn der Wert < Zeit X ist auch wieder deaktiviert wird um unnötiges hin- und herschalten zu vermeiden. -
@_r_a_l_f_ Nun dann würde ich ggf. die Nachrichtenrate am Eingang begrenzen, dass die trigger Nodes fertig sind. damit sowas nicht passiert -
oder Du musst das resetten vor den trigger Nodes machen. Das habe ich hier gemacht. Das entspricht Deinem ursprünglichen Flow - nur dass Du nun nur die trigger NOdes resettest.
EDIT: Flow entspricht Deinem - nur dass du nun das msg.reset nur an die trigger Nodes sendest.
-
@mickym Vielen Dank für die Tipps ;). So klappts jetzt wie gewünscht
