NEWS
Einfache Funktion - Wertüberwachung mit 2 Verzögerungszeiten
-
Hallo Zusammen ,
ich bin schon Tage am basteln.
Eigentlich möchte ich eine für mich erstmal einfach klingende Funktion realisieren.
Ich scheitere aber an folgendem:Ich möchte einen Messwert ( der auch sauber rein kommt ) überwachen.
Größer -50 und kleiner -300 soll überwacht werden für beide Werte soll eine einstellbare Verzögerung ablaufen.
Die Verzögerung soll aber nicht aufaddiert werden sondern neu gestartet sobald der Wert aus dem entsprechenden Range war. Es soll nur einmal ein true oder ein false also Ausgang generiert werden.
Es darf erst wieder ein true kommen wenn der aktuelle wert auf false steht und umgekehrt.Das ganze soll einen Verbraucher starten , aufgrund von Daten des Netzzählers.
Wie gesagt der Messwert kommt sauber an.
Die Funktion schiebt aber mehrere True und mehrere false raus.
Auch verhält sie sich für micht nicht ganz nachvollziehbar mit den Zeiten ich glaube
die laufen nicht sauber ab :-(Weiss jemand woran das liegen kann ?
DANKE
// Holen der Grenzwerte und Zeitintervalle aus temporären Kontext-Variablen var upperLimit = context.get('upperLimit') || -50; // Standardwert -50 var lowerLimit = context.get('lowerLimit') || -300; // Standardwert -300 var timeUpper = context.get('timeUpper') || 60000; // Standardwert 60 Sekunden (60000 ms) var timeLower = context.get('timeLower') || 80000; // Standardwert 80 Sekunden (80000 ms) var currentValue = msg.payload; var startTime = context.get('startTime') || 0; var state = context.get('state') || ''; var sent = context.get('sent') || ''; // Track if we have sent true or false var currentTime = Date.now(); // Überprüfen, ob der Wert unter dem unteren Grenzwert liegt (für true) if (currentValue < lowerLimit) { // Wenn der Wert unter dem unteren Grenzwert liegt, prüfe, ob der Zustand "underLowerLimit" ist if (state !== 'underLowerLimit') { state = 'underLowerLimit'; startTime = currentTime; // Zurücksetzen des Startzeitpunkts, wenn der Zustand geändert wird // sent wird nur zurückgesetzt, wenn noch nicht 'true' gesendet wurde context.set('sent', sent !== 'true' ? '' : sent); } // Wenn der Wert für die definierte Zeit unter dem unteren Grenzwert bleibt und noch keine Nachricht gesendet wurde if (currentTime - startTime >= timeLower && sent !== 'true' && sent !== 'switching') { // Es wird nur 'true' gesendet, wenn vorher 'false' gesendet wurde if (sent === 'false' || sent === '') { msg.payload = true; // Sende true (bei Wert unter Grenzwert) context.set('sent', 'true'); // Markiere, dass true gesendet wurde return msg; } } } // Überprüfen, ob der Wert über dem oberen Grenzwert liegt (für false) if (currentValue > upperLimit) { // Wenn der Wert über dem oberen Grenzwert liegt, prüfe, ob der Zustand "overUpperLimit" ist if (state !== 'overUpperLimit') { state = 'overUpperLimit'; startTime = currentTime; // Zurücksetzen des Startzeitpunkts, wenn der Zustand geändert wird // sent wird nur zurückgesetzt, wenn noch nicht 'false' gesendet wurde context.set('sent', sent !== 'false' ? '' : sent); } // Wenn der Wert für die definierte Zeit über dem oberen Grenzwert bleibt und noch keine Nachricht gesendet wurde if (currentTime - startTime >= timeUpper && sent !== 'false' && sent !== 'switching') { // Es wird nur 'false' gesendet, wenn vorher 'true' gesendet wurde if (sent === 'true' || sent === '') { msg.payload = false; // Sende false (bei Wert über Grenzwert) context.set('sent', 'false'); // Markiere, dass false gesendet wurde return msg; } } } // Wenn der Wert weder unter dem unteren Grenzwert noch über dem oberen Grenzwert liegt, // aber der Zustand schon gesetzt ist, dann den Zustand und den Startzeitpunkt zurücksetzen. if (currentValue >= lowerLimit && currentValue <= upperLimit) { if (state !== 'normal') { state = 'normal'; startTime = currentTime; // Timer zurücksetzen, wenn der Wert wieder im normalen Bereich liegt context.set('sent', ''); // Zurücksetzen, um zu verhindern, dass fälschlicherweise eine Nachricht gesendet wird } } // Aktualisiere den Zustand und die Startzeit im Kontext context.set('state', state); context.set('startTime', startTime); return null; // Keine Nachricht senden, wenn die Bedingungen nicht erfüllt sind -
Hallo Zusammen ,
ich bin schon Tage am basteln.
Eigentlich möchte ich eine für mich erstmal einfach klingende Funktion realisieren.
Ich scheitere aber an folgendem:Ich möchte einen Messwert ( der auch sauber rein kommt ) überwachen.
Größer -50 und kleiner -300 soll überwacht werden für beide Werte soll eine einstellbare Verzögerung ablaufen.
Die Verzögerung soll aber nicht aufaddiert werden sondern neu gestartet sobald der Wert aus dem entsprechenden Range war. Es soll nur einmal ein true oder ein false also Ausgang generiert werden.
Es darf erst wieder ein true kommen wenn der aktuelle wert auf false steht und umgekehrt.Das ganze soll einen Verbraucher starten , aufgrund von Daten des Netzzählers.
Wie gesagt der Messwert kommt sauber an.
Die Funktion schiebt aber mehrere True und mehrere false raus.
Auch verhält sie sich für micht nicht ganz nachvollziehbar mit den Zeiten ich glaube
die laufen nicht sauber ab :-(Weiss jemand woran das liegen kann ?
DANKE
// Holen der Grenzwerte und Zeitintervalle aus temporären Kontext-Variablen var upperLimit = context.get('upperLimit') || -50; // Standardwert -50 var lowerLimit = context.get('lowerLimit') || -300; // Standardwert -300 var timeUpper = context.get('timeUpper') || 60000; // Standardwert 60 Sekunden (60000 ms) var timeLower = context.get('timeLower') || 80000; // Standardwert 80 Sekunden (80000 ms) var currentValue = msg.payload; var startTime = context.get('startTime') || 0; var state = context.get('state') || ''; var sent = context.get('sent') || ''; // Track if we have sent true or false var currentTime = Date.now(); // Überprüfen, ob der Wert unter dem unteren Grenzwert liegt (für true) if (currentValue < lowerLimit) { // Wenn der Wert unter dem unteren Grenzwert liegt, prüfe, ob der Zustand "underLowerLimit" ist if (state !== 'underLowerLimit') { state = 'underLowerLimit'; startTime = currentTime; // Zurücksetzen des Startzeitpunkts, wenn der Zustand geändert wird // sent wird nur zurückgesetzt, wenn noch nicht 'true' gesendet wurde context.set('sent', sent !== 'true' ? '' : sent); } // Wenn der Wert für die definierte Zeit unter dem unteren Grenzwert bleibt und noch keine Nachricht gesendet wurde if (currentTime - startTime >= timeLower && sent !== 'true' && sent !== 'switching') { // Es wird nur 'true' gesendet, wenn vorher 'false' gesendet wurde if (sent === 'false' || sent === '') { msg.payload = true; // Sende true (bei Wert unter Grenzwert) context.set('sent', 'true'); // Markiere, dass true gesendet wurde return msg; } } } // Überprüfen, ob der Wert über dem oberen Grenzwert liegt (für false) if (currentValue > upperLimit) { // Wenn der Wert über dem oberen Grenzwert liegt, prüfe, ob der Zustand "overUpperLimit" ist if (state !== 'overUpperLimit') { state = 'overUpperLimit'; startTime = currentTime; // Zurücksetzen des Startzeitpunkts, wenn der Zustand geändert wird // sent wird nur zurückgesetzt, wenn noch nicht 'false' gesendet wurde context.set('sent', sent !== 'false' ? '' : sent); } // Wenn der Wert für die definierte Zeit über dem oberen Grenzwert bleibt und noch keine Nachricht gesendet wurde if (currentTime - startTime >= timeUpper && sent !== 'false' && sent !== 'switching') { // Es wird nur 'false' gesendet, wenn vorher 'true' gesendet wurde if (sent === 'true' || sent === '') { msg.payload = false; // Sende false (bei Wert über Grenzwert) context.set('sent', 'false'); // Markiere, dass false gesendet wurde return msg; } } } // Wenn der Wert weder unter dem unteren Grenzwert noch über dem oberen Grenzwert liegt, // aber der Zustand schon gesetzt ist, dann den Zustand und den Startzeitpunkt zurücksetzen. if (currentValue >= lowerLimit && currentValue <= upperLimit) { if (state !== 'normal') { state = 'normal'; startTime = currentTime; // Timer zurücksetzen, wenn der Wert wieder im normalen Bereich liegt context.set('sent', ''); // Zurücksetzen, um zu verhindern, dass fälschlicherweise eine Nachricht gesendet wird } } // Aktualisiere den Zustand und die Startzeit im Kontext context.set('state', state); context.set('startTime', startTime); return null; // Keine Nachricht senden, wenn die Bedingungen nicht erfüllt sind@i0br0ker Ich kann es Dir nicht sagen - ich frage mich nur, warum Du NodeRed benutzt, wenn Du dann eh alles codierst.
So musst Du halt mit node.warn Nachrichten versuchen, ob Deine Logik funktioniert. NodeRed spielt aber gerade seine Stärken aus, in dem man diese ganzen Teilschritte in einem Flow packt und nicht die ganze Logik in Javascript programmiert.
Und ich gebe zu, dass mir die Logik durch den Code nachzuvollziehen, im Moment zu mühsam ist. Auch zum Debuggen ist es wesentlich einfacher vorhandene Nodes zu nutzen - als das alles selbst zu programmieren.Wenn Du nicht weißt, wie man einen Flow erstellt, um Deine Logik abzubilden, dann helfe ich Dir gerne, aber mich durch JS Code zu wurschteln - da findest Du sicher andere Leute, die gerne programmieren wollen.
-
@i0br0ker Ich kann es Dir nicht sagen - ich frage mich nur, warum Du NodeRed benutzt, wenn Du dann eh alles codierst.
So musst Du halt mit node.warn Nachrichten versuchen, ob Deine Logik funktioniert. NodeRed spielt aber gerade seine Stärken aus, in dem man diese ganzen Teilschritte in einem Flow packt und nicht die ganze Logik in Javascript programmiert.
Und ich gebe zu, dass mir die Logik durch den Code nachzuvollziehen, im Moment zu mühsam ist. Auch zum Debuggen ist es wesentlich einfacher vorhandene Nodes zu nutzen - als das alles selbst zu programmieren.Wenn Du nicht weißt, wie man einen Flow erstellt, um Deine Logik abzubilden, dann helfe ich Dir gerne, aber mich durch JS Code zu wurschteln - da findest Du sicher andere Leute, die gerne programmieren wollen.
@mickym Hi danke für das feedback ... ja ich hab versucht die ganzen Bausteine da mit Linien zu verbinden ;-)
Aber da hab ich noch weniger hin bekommen .. da sendet der da massenweise daten durch :-)
Das ist nicht meine Welt .. aber leider läuft auf dem Victron Wechselrichter nur das Node Red und ich dachte mir diese
Funktion dürfte relativ schnell programmiert sein .. aber ich sitz da schon Tage dran und komm nicht weiter ...
Die Zeit Verzögerungen in Node Red machen einfach nicht das was ich möchte . -
@mickym Hi danke für das feedback ... ja ich hab versucht die ganzen Bausteine da mit Linien zu verbinden ;-)
Aber da hab ich noch weniger hin bekommen .. da sendet der da massenweise daten durch :-)
Das ist nicht meine Welt .. aber leider läuft auf dem Victron Wechselrichter nur das Node Red und ich dachte mir diese
Funktion dürfte relativ schnell programmiert sein .. aber ich sitz da schon Tage dran und komm nicht weiter ...
Die Zeit Verzögerungen in Node Red machen einfach nicht das was ich möchte .@i0br0ker Wie gesagt - Du kannst ja selbst mit Inject Nodes triggern, um so verschiedene Szenarien zu simulieren. In den Code kannst Du über node.warn Meldungen im Debugfenster ausgeben.
Ansonsten wenn Du dieses Tool halt richtig nutzen willst, dann würde ich mich schon der Nodes bedienen und nicht Programmcode schreiben.
In manchen Situationen braucht man function Nodes aber wie gesagt auch wenn Du Deinen Code prüfen willst, dann würde ich halt mit Inject nodes die Situation zu simulieren und Dir das Ergebnis anzuschauen.Sprich wenn deine Timer nicht funktionieren und Du das programmieren möchtest, dann musst Du halt genau beschreiben, was Du erwartest. Ich kann ja nur Deine function Node importieren und versuchen das nachzustellen - sinnvoller ist es halt dich in diese tolle Welt einzuarbeiten. Wie gesagt ich helfe Dir gerne aber dann sollten wir das mit Inject Nodes simulieren.
-
Schau mal Folgendes.
Für eine fixe Verzögerung gibt es die delay Node. Wenn Du Dir die Hilfe kannst Du Dir das anpassen.
Die Verzögerung soll aber nicht aufaddiert werden sondern neu gestartet sobald der Wert aus dem entsprechenden Range war. Es soll nur einmal ein true oder ein false also Ausgang generiert werden.
Standardmässig wird jede Nachricht um einen fixen Zeitanteil verzögert, wenn Du also willst, dass die Verzögerung mit jeder Nachricht neu gestartet werden soll, dann musst Du vor jede Nachricht eine eigene Nachricht mit msg.reset setzen.
Für sowas nutzt man dann eine function Node.
Damit wird immer ein reset gesendet, bevor die payload gesendet wird. In dem Fall auch über delay noch mit einer variablen Verzögerung.
Schau mal ob der Flow das macht, was Du bzgl. Verzögerung macht, was Du willst, in dem Du die Inject Node nach Belieben betätigst.Hier mal zum Import:
Größer -50 und kleiner -300 soll überwacht werden für beide Werte soll eine einstellbare Verzögerung ablaufen.
Dazu lenkt man den Nachrichtenstrom einfach über eine switch Node an 2 verschiedene Ausgänge.
Es darf erst wieder ein true kommen wenn der aktuelle wert auf false steht und umgekehrt.
Das kannst Du über eine function Node machen oder einfach über den Flow Kontext und einer Switch Node filtern.
Der Vorteil von NodeRed - ist, dass Du jederzeit eine Debug Node an jede Stelle des Flows machen kannst und somit genau siehst, ob Deine Logik wie erwartet funktioniert.
-
Schau mal Folgendes.
Für eine fixe Verzögerung gibt es die delay Node. Wenn Du Dir die Hilfe kannst Du Dir das anpassen.
Die Verzögerung soll aber nicht aufaddiert werden sondern neu gestartet sobald der Wert aus dem entsprechenden Range war. Es soll nur einmal ein true oder ein false also Ausgang generiert werden.
Standardmässig wird jede Nachricht um einen fixen Zeitanteil verzögert, wenn Du also willst, dass die Verzögerung mit jeder Nachricht neu gestartet werden soll, dann musst Du vor jede Nachricht eine eigene Nachricht mit msg.reset setzen.
Für sowas nutzt man dann eine function Node.
Damit wird immer ein reset gesendet, bevor die payload gesendet wird. In dem Fall auch über delay noch mit einer variablen Verzögerung.
Schau mal ob der Flow das macht, was Du bzgl. Verzögerung macht, was Du willst, in dem Du die Inject Node nach Belieben betätigst.Hier mal zum Import:
Größer -50 und kleiner -300 soll überwacht werden für beide Werte soll eine einstellbare Verzögerung ablaufen.
Dazu lenkt man den Nachrichtenstrom einfach über eine switch Node an 2 verschiedene Ausgänge.
Es darf erst wieder ein true kommen wenn der aktuelle wert auf false steht und umgekehrt.
Das kannst Du über eine function Node machen oder einfach über den Flow Kontext und einer Switch Node filtern.
Der Vorteil von NodeRed - ist, dass Du jederzeit eine Debug Node an jede Stelle des Flows machen kannst und somit genau siehst, ob Deine Logik wie erwartet funktioniert.
@mickym hi vielen Dank für deine Ausführungen .. ich hab den code mal importiert ... zum testen.
Wenn ich injecte kommt nach 30 sek der payload raus .. wenn ich weiter injecte wird er neu gestartet ok und nach dem letzten klick eben läuft die zeit ... das muss ich nun abstrahieren für meine Anwendung ..
Ich hab einen Einspeisewert der schwankt angenommen ständig
wenn der länger als Zeit X kleiner -300 ist soll true resultieren .. wenn er jedoch länger als Zeit X größer -50 ist soll ein false resultieren. Das ganze müsste gegenseitig verriegelt sein , sodass halt das false nur kommt wenn das true aktiv ist und umgekehrt.Das ist meine Datenbasis
da schwirrt alle paar sekunden ein Wert ein[ { "id": "50ee6e8eb5c5f3a8", "type": "mqtt in", "z": "42d8e26124256b59", "name": "Netzübergabe", "topic": "openWB/evu/W", "qos": "2", "datatype": "auto-detect", "broker": "baede69d4c21ead9", "nl": false, "rap": true, "rh": 0, "inputs": 0, "x": 150, "y": 280, "wires": [ [ "8f78648a1939bd66" ] ] }, { "id": "71f9943a7d86393c", "type": "victron-input-system", "z": "42d8e26124256b59", "service": "com.victronenergy.system/0", "path": "/Ac/ConsumptionOnOutput/L1/Power", "serviceObj": { "service": "com.victronenergy.system/0", "name": "Venus system" }, "pathObj": { "path": "/Ac/ConsumptionOnOutput/L1/Power", "type": "float", "name": "Power on output of inverter/charger, L1 (W)" }, "initial": "", "name": "", "onlyChanges": false, "x": 290, "y": 340, "wires": [ [ "8f78648a1939bd66" ] ] }, { "id": "8f78648a1939bd66", "type": "function", "z": "42d8e26124256b59", "name": "Berechnung Einschaltbedingung", "func": "if (msg.topic === \"openWB/evu/W\") context.set(\"netz\",msg.payload);\nif (msg.topic === \"Venus system - Power on output of inverter/charger, L1 (W)\") context.set(\"verbrauchAC\",msg.payload);\nif (msg.topic === \"Venus system - VE.Bus charge power (W)\") context.set(\"verbrauchDC\",msg.payload);\n\nvar netz = context.get(\"netz\") || 0;\nvar verbrauchAC = context.get(\"verbrauchAC\") || 0;\nvar verbrauchDC = context.get(\"verbrauchDC\") || 0;\n\n// Wenn Wert C negativ ist, addiere A und B, sonst gebe nur B aus\nif (verbrauchDC < 0) {\n msg.payload = netz + verbrauchAC; // A + B wird ausgegeben\n} else {\n msg.payload = netz; // Nur B wird ausgegeben\n}\n\nmsg.topic = \"NETZberechnung\";\nreturn msg;", "outputs": 1, "timeout": 0, "noerr": 0, "initialize": "", "finalize": "", "libs": [], "x": 710, "y": 260, "wires": [ [] ] }, { "id": "5a65949a3ab516bd", "type": "victron-input-system", "z": "42d8e26124256b59", "service": "com.victronenergy.system/0", "path": "/Dc/Vebus/Power", "serviceObj": { "service": "com.victronenergy.system/0", "name": "Venus system" }, "pathObj": { "path": "/Dc/Vebus/Power", "type": "float", "name": "VE.Bus charge power (W)" }, "name": "", "onlyChanges": false, "x": 240, "y": 400, "wires": [ [ "8f78648a1939bd66" ] ] }, { "id": "baede69d4c21ead9", "type": "mqtt-broker", "name": "", "broker": "192.168.123.14", "port": "1883", "clientid": "", "autoConnect": true, "usetls": false, "protocolVersion": "4", "keepalive": "60", "cleansession": true, "autoUnsubscribe": true, "birthTopic": "", "birthQos": "0", "birthRetain": "false", "birthPayload": "", "birthMsg": {}, "closeTopic": "", "closeQos": "0", "closeRetain": "false", "closePayload": "", "closeMsg": {}, "willTopic": "", "willQos": "0", "willRetain": "false", "willPayload": "", "willMsg": {}, "userProps": "", "sessionExpiry": "" } ] -
@mickym hi vielen Dank für deine Ausführungen .. ich hab den code mal importiert ... zum testen.
Wenn ich injecte kommt nach 30 sek der payload raus .. wenn ich weiter injecte wird er neu gestartet ok und nach dem letzten klick eben läuft die zeit ... das muss ich nun abstrahieren für meine Anwendung ..
Ich hab einen Einspeisewert der schwankt angenommen ständig
wenn der länger als Zeit X kleiner -300 ist soll true resultieren .. wenn er jedoch länger als Zeit X größer -50 ist soll ein false resultieren. Das ganze müsste gegenseitig verriegelt sein , sodass halt das false nur kommt wenn das true aktiv ist und umgekehrt.Das ist meine Datenbasis
da schwirrt alle paar sekunden ein Wert ein[ { "id": "50ee6e8eb5c5f3a8", "type": "mqtt in", "z": "42d8e26124256b59", "name": "Netzübergabe", "topic": "openWB/evu/W", "qos": "2", "datatype": "auto-detect", "broker": "baede69d4c21ead9", "nl": false, "rap": true, "rh": 0, "inputs": 0, "x": 150, "y": 280, "wires": [ [ "8f78648a1939bd66" ] ] }, { "id": "71f9943a7d86393c", "type": "victron-input-system", "z": "42d8e26124256b59", "service": "com.victronenergy.system/0", "path": "/Ac/ConsumptionOnOutput/L1/Power", "serviceObj": { "service": "com.victronenergy.system/0", "name": "Venus system" }, "pathObj": { "path": "/Ac/ConsumptionOnOutput/L1/Power", "type": "float", "name": "Power on output of inverter/charger, L1 (W)" }, "initial": "", "name": "", "onlyChanges": false, "x": 290, "y": 340, "wires": [ [ "8f78648a1939bd66" ] ] }, { "id": "8f78648a1939bd66", "type": "function", "z": "42d8e26124256b59", "name": "Berechnung Einschaltbedingung", "func": "if (msg.topic === \"openWB/evu/W\") context.set(\"netz\",msg.payload);\nif (msg.topic === \"Venus system - Power on output of inverter/charger, L1 (W)\") context.set(\"verbrauchAC\",msg.payload);\nif (msg.topic === \"Venus system - VE.Bus charge power (W)\") context.set(\"verbrauchDC\",msg.payload);\n\nvar netz = context.get(\"netz\") || 0;\nvar verbrauchAC = context.get(\"verbrauchAC\") || 0;\nvar verbrauchDC = context.get(\"verbrauchDC\") || 0;\n\n// Wenn Wert C negativ ist, addiere A und B, sonst gebe nur B aus\nif (verbrauchDC < 0) {\n msg.payload = netz + verbrauchAC; // A + B wird ausgegeben\n} else {\n msg.payload = netz; // Nur B wird ausgegeben\n}\n\nmsg.topic = \"NETZberechnung\";\nreturn msg;", "outputs": 1, "timeout": 0, "noerr": 0, "initialize": "", "finalize": "", "libs": [], "x": 710, "y": 260, "wires": [ [] ] }, { "id": "5a65949a3ab516bd", "type": "victron-input-system", "z": "42d8e26124256b59", "service": "com.victronenergy.system/0", "path": "/Dc/Vebus/Power", "serviceObj": { "service": "com.victronenergy.system/0", "name": "Venus system" }, "pathObj": { "path": "/Dc/Vebus/Power", "type": "float", "name": "VE.Bus charge power (W)" }, "name": "", "onlyChanges": false, "x": 240, "y": 400, "wires": [ [ "8f78648a1939bd66" ] ] }, { "id": "baede69d4c21ead9", "type": "mqtt-broker", "name": "", "broker": "192.168.123.14", "port": "1883", "clientid": "", "autoConnect": true, "usetls": false, "protocolVersion": "4", "keepalive": "60", "cleansession": true, "autoUnsubscribe": true, "birthTopic": "", "birthQos": "0", "birthRetain": "false", "birthPayload": "", "birthMsg": {}, "closeTopic": "", "closeQos": "0", "closeRetain": "false", "closePayload": "", "closeMsg": {}, "willTopic": "", "willQos": "0", "willRetain": "false", "willPayload": "", "willMsg": {}, "userProps": "", "sessionExpiry": "" } ]@i0br0ker Ja ich habe weder ein Victron system noch habe ich Deine mqtt topics - also kann ich mit Dir nur zusammen die Logik entwickeln.
Ich hab einen Einspeisewert der schwankt angenommen ständig
wenn der länger als Zeit X kleiner -300 ist soll true resultieren .. wenn er jedoch länger als Zeit X größer -50 ist soll ein false resultieren. Das ganze müsste gegenseitig verriegelt sein , sodass halt das false nur kommt wenn das true aktiv ist und umgekehrt.
In diesem Fall würde ich nicht mit einer delay Node sondern einer trigger Node arbeiten. Ich werde also mal einen Flow entwerfen, in dem ich mit Inject Nodes den Wert -350, -200 und -30 in einen Flow injiziere.
-
@i0br0ker Ja ich habe weder ein Victron system noch habe ich Deine mqtt topics - also kann ich mit Dir nur zusammen die Logik entwickeln.
Ich hab einen Einspeisewert der schwankt angenommen ständig
wenn der länger als Zeit X kleiner -300 ist soll true resultieren .. wenn er jedoch länger als Zeit X größer -50 ist soll ein false resultieren. Das ganze müsste gegenseitig verriegelt sein , sodass halt das false nur kommt wenn das true aktiv ist und umgekehrt.
In diesem Fall würde ich nicht mit einer delay Node sondern einer trigger Node arbeiten. Ich werde also mal einen Flow entwerfen, in dem ich mit Inject Nodes den Wert -350, -200 und -30 in einen Flow injiziere.
-
hab sowas gerade mal gemacht
die Verzögerung müsste genau umgekehrt sein ... das heisst der wert müsst für zeit x ständig getriggert werden damit er auslöst -
hab sowas gerade mal gemacht
die Verzögerung müsste genau umgekehrt sein ... das heisst der wert müsst für zeit x ständig getriggert werden damit er auslöst -
@i0br0ker Ich gehe mal davon aus, dass wenn zwischen -50 und -300 kommt, dann soll der timer immer zurückgesetzt werden.
@mickym hmm .. ja genau sollte so sein ... heisst wenn die einspeisung länger weg fällt ( zeit X) also der wert angenommen 0 ist muss er false schalten und wenn er länger als zeit X einspeist also -400 muss true schalten - das ganze sollte die ganze zeit hin und her korrespondieren und nichts doppelt passieren.
-
@mickym hmm .. ja genau sollte so sein ... heisst wenn die einspeisung länger weg fällt ( zeit X) also der wert angenommen 0 ist muss er false schalten und wenn er länger als zeit X einspeist also -400 muss true schalten - das ganze sollte die ganze zeit hin und her korrespondieren und nichts doppelt passieren.
@i0br0ker sagte in Einfache Funktion - Wertüberwachung mit 2 Verzögerungszeiten:
@mickym hmm .. ja genau sollte so sein ... heisst wenn die einspeisung länger weg fällt ( zeit X) also der wert angenommen 0 ist muss er false schalten und wenn er länger als zeit X einspeist also -400 muss true schalten - das ganze sollte die ganze zeit hin und her korrespondieren und nichts doppelt passieren.
Du kannst es gleich probieren - einen kleinen Moment noch.
-
@mickym hmm .. ja genau sollte so sein ... heisst wenn die einspeisung länger weg fällt ( zeit X) also der wert angenommen 0 ist muss er false schalten und wenn er länger als zeit X einspeist also -400 muss true schalten - das ganze sollte die ganze zeit hin und her korrespondieren und nichts doppelt passieren.
@i0br0ker So dann schau mal, ob das so tut wie Du willst. Mit den Inject Nodes simulierst Du den Eingang.
Am Anfang den delay setzen mit der Inject Node. Später kannst Du den Flow kontext dann selbst modifizieren.
Hier der Import:
Wie Du siehst ohne function Nodes und ohne eine Zeile Code zu schreiben. ;)
-
@i0br0ker So dann schau mal, ob das so tut wie Du willst. Mit den Inject Nodes simulierst Du den Eingang.
Am Anfang den delay setzen mit der Inject Node. Später kannst Du den Flow kontext dann selbst modifizieren.
Hier der Import:
Wie Du siehst ohne function Nodes und ohne eine Zeile Code zu schreiben. ;)
@mickym krasses Konstrukt ;-) aber es scheint zu passen .. gut ich brauch halt 2 versch. Verzögerungen aber die kann ich ja hard rein coden in den trigger ...
Ich werde es morgen live testen wenn die Sonne scheint ;-)DANKE an der Stelle schonmal für die Hilfe und deine Zeit
-
@mickym krasses Konstrukt ;-) aber es scheint zu passen .. gut ich brauch halt 2 versch. Verzögerungen aber die kann ich ja hard rein coden in den trigger ...
Ich werde es morgen live testen wenn die Sonne scheint ;-)DANKE an der Stelle schonmal für die Hilfe und deine Zeit
@i0br0ker Du kannst den msg.delay auch an die unterschiedlichen Ausgänge setzen - dann brauchst die flow Variable nicht. Kommt halt darauf an, wie Du es modifizieren willst. Aber wie Du siehst ist es sehr transparent und man kann an jeder Node prüfen, ob die Logik funktioniert und muss sich nicht durch Code quälen.
Ja oder einfach in die trigger Nodes eintragen - das ist am einfachsten und dann kannst Dir den flow Kontext sparen. Wenn Du die Verzögerung direkt in die trigger Node einträgst, dann kannst Du diese Nodes wegschmeißen
-
Darf ich an dem Thema nochmal anknüpfen ;-)
Ich bin gerade am testen und habe noch folgendes Problem.
Ich bekomme von 3 quellen Werte mit unterschiedlichen datenraten.
Ich würde diese 3 Quellen gerne zeitgleich in eine Funktion einspeisen, die eine Berechnung macht.
Alles was ich bisher versucht habe funktioniert nicht wirklich ( Begrenzung der Nachrichten ) .. weil dann zufällig nur einzelne Quellen übertragen werden.Die Berechnung ist folgende:
Also ich würde gerne alle 3 Werte vorhalten und dann zeitgleich berechnen und ausgeben in einem 5 Sekunden Intervall zum Beispiel ...
-
Darf ich an dem Thema nochmal anknüpfen ;-)
Ich bin gerade am testen und habe noch folgendes Problem.
Ich bekomme von 3 quellen Werte mit unterschiedlichen datenraten.
Ich würde diese 3 Quellen gerne zeitgleich in eine Funktion einspeisen, die eine Berechnung macht.
Alles was ich bisher versucht habe funktioniert nicht wirklich ( Begrenzung der Nachrichten ) .. weil dann zufällig nur einzelne Quellen übertragen werden.Die Berechnung ist folgende:
Also ich würde gerne alle 3 Werte vorhalten und dann zeitgleich berechnen und ausgeben in einem 5 Sekunden Intervall zum Beispiel ...
@i0br0ker Also ich kann an dem Code nichts falsches finden und verstehe das Problem nicht wirklich. Natürlich kann man das alles mit weniger Code machen. ;)
Alles was ich bisher versucht habe funktioniert nicht wirklich ( Begrenzung der Nachrichten ) .. weil dann zufällig nur einzelne Quellen übertragen werden.
Das ist doch richtig, weil nur dann was ausgegeben wird, wenn sich was geändert hat. Ansonsten musst Du sagen was Du willst:
- Du wartest bis alle 3 topics einen Wert geliefert haben?
- Du möchtest generell eine kontunierliche Ausgabe der letzten Berechnung (auch wenn sich nichts geändert hat.
Zu Punkt 1 - würde ich das ganze dann nicht über den Kontext machen, sondern eine Nachricht mit allen Werten erzeugen, die Du dann von mir aus wieder mit Code für die Ausgabe behandeln kannst.
Zu Punkt 2: Einfach eine Trigger Node die letzte Nachricht im 5s Intervall ausgeben lassen.Zeitgleich passiert nur etwas in dem Du es sammelst - wie gesagt wenn Du warten willst, dass alle 3 topics geliefert haben müssen, um eine saubere Berechnung zu ermöglichen oder nicht? Es wird immer ms zeitliche Unterschiede geben, wenn die Dinge in das System kommen, da generell NodeRed oder auch andere Systeme alle Inputs nur sequentiell verarbeiten, wenn auch im ms Bereich.
Ich werde Dir wieder mal einen Flow mit den 3 Messgrößen mit Inject Nodes zur Simulation bereitstellen und Deinen Code zur Berechnung benutzen.
-
@i0br0ker Also ich kann an dem Code nichts falsches finden und verstehe das Problem nicht wirklich. Natürlich kann man das alles mit weniger Code machen. ;)
Alles was ich bisher versucht habe funktioniert nicht wirklich ( Begrenzung der Nachrichten ) .. weil dann zufällig nur einzelne Quellen übertragen werden.
Das ist doch richtig, weil nur dann was ausgegeben wird, wenn sich was geändert hat. Ansonsten musst Du sagen was Du willst:
- Du wartest bis alle 3 topics einen Wert geliefert haben?
- Du möchtest generell eine kontunierliche Ausgabe der letzten Berechnung (auch wenn sich nichts geändert hat.
Zu Punkt 1 - würde ich das ganze dann nicht über den Kontext machen, sondern eine Nachricht mit allen Werten erzeugen, die Du dann von mir aus wieder mit Code für die Ausgabe behandeln kannst.
Zu Punkt 2: Einfach eine Trigger Node die letzte Nachricht im 5s Intervall ausgeben lassen.Zeitgleich passiert nur etwas in dem Du es sammelst - wie gesagt wenn Du warten willst, dass alle 3 topics geliefert haben müssen, um eine saubere Berechnung zu ermöglichen oder nicht? Es wird immer ms zeitliche Unterschiede geben, wenn die Dinge in das System kommen, da generell NodeRed oder auch andere Systeme alle Inputs nur sequentiell verarbeiten, wenn auch im ms Bereich.
Ich werde Dir wieder mal einen Flow mit den 3 Messgrößen mit Inject Nodes zur Simulation bereitstellen und Deinen Code zur Berechnung benutzen.
@mickym ich hab es nun mal so gemacht
Ich speichere die 3 Werte in jeweils in einer Flow variable und triggere die Berechnung dann
alle Sekunde mit dem Inject.
So hab ich immer den zuletzt gemessenen Wert der 3 Datenquellen zur sekündlichen Berechnung -
@mickym ich hab es nun mal so gemacht
Ich speichere die 3 Werte in jeweils in einer Flow variable und triggere die Berechnung dann
alle Sekunde mit dem Inject.
So hab ich immer den zuletzt gemessenen Wert der 3 Datenquellen zur sekündlichen Berechnung@i0br0ker Ja und das ist halt Käse, weil Du nicht davon ausgehen kannst, dass sich alle Sekunden, welche Werte geändert haben und Du somit nur ein zufälligest Zustandsbild bekommst. Ausserdem belasstest Du das System nur unnötig mit dieser Inject Node und dem sekündlichen Trigger. Sinnvoller ist es die 3 Teile Einspeisung, AC und DC triggern zu lassen. Ich mach Dir mal einen Vorschlag in dem ich die 3 Nodes Einspeisung, AC und DC mit Inject Nodes simuliere - und du quasi den Rest des Flows mal hinter Deine Nodes machst.
-
@mickym ich hab es nun mal so gemacht
Ich speichere die 3 Werte in jeweils in einer Flow variable und triggere die Berechnung dann
alle Sekunde mit dem Inject.
So hab ich immer den zuletzt gemessenen Wert der 3 Datenquellen zur sekündlichen Berechnung@i0br0ker So hier mein Vorschlag:
Statt der Inject Nodes klemmst Du die Change Nodes zum Vereinfachen der topics hinter Deine function Nodes.
Die beiden Varianten unterscheiden sich wie folgt. Oben müssen alle 3 Werte aktualisiert werden, bevor eine erneute Berechnung stattfindet. Unten wird nachdem alle 3 Werte geliefert wurden, nach jeder Änderung eine Berechnung durchgeführt.
Unten ist einfach die blau markierte Option angehakt.
Hier zum Import:
Alle Sekunden zu triggern - ohne das eventuell eine Änderung stattgefunden hat, ist mE Unsinn. Wenn Du einen konstante Ausgabe willst, auch ohne das sich was geändert hat, kannst Du auch die letzte Berechnung dauernd mit einer Triggernode ausgeben. Keine Ahnung - vielleicht für einen Grafen.
Eine Triggernode - kann die letzte Berechnung dann kontinuierlich senden, falls Du das wünschst.
Ist aber meines Erachtens auch nur unsinniger Overhead - da brauche ich dann auch keine Begrenzung.
Support us
369
Online32.5k
Benutzer81.8k
Themen1.3m
Beiträge