Schrittwerk mit einer Bedingung begrenzen
-
Hallo zusammen,
ich benötige Hilfe bei einem Flow.In node-red habe ich ein Schrittwerk, welches 14 Ausgänge der Reihe nach (hoch oder runter) schaltet. Dies kann ich über die +1 oder -1 nodes auch gut machen.
Nun stehe ich aber vor der Aufgabe, dass ich unter einer weiteren Bedingung die Schritte begrenzen will (z.B. auf 0-7), und wenn zuweit gezährt ist, der höchste Wert ( 7 ) genommen wird.
if (flow.get('counter') === undefined) { flow.set('counter', 0); } if (flow.get('counter') >13) { flow.set('counter', 0); } if (flow.get('counter') <= 12) { if (msg.action === '+1') { flow.set('counter', flow.get('counter') + 1); } } if (flow.get('counter') >= 1) { if (msg.action === '-1') { flow.set('counter', flow.get('counter') - 1); } } msg.payload = flow.get('counter'); return msg;ich bin neu in node-red - steht es mir nach, wenn ich es komliziert angehe
danke vorab.
Rico -
@hawell Nun weil Du programmierst anstelle einfach die Nodes zu verwenden, die Dir zur Verfügung stehen machst Du Dir es kompliziert. Ich werde Dir mal einen Flow zeigen, wie Du das ganze ohne viel Programmtext schreiben kannst.
Hier der Import:
Tipp: Versuche function Nodes nur zu verwenden, wenn unbedingt erforderlich.
Wie gesagt Du kannst auch alles in eine function Node packen - aber es macht es halt nur kompliziert um Programmtext zu schreiben. Außerdem tust Du Dir bei der Fehlersuche viel schwerer - wenn Du mit node.warn innerhalb einer function Node Fehler suchen musst. Wenn Du einzelne Nodes hast - kannst Du die schneller mal abkabeln oder eine debug Node dahinter hängen.
Den einzigen Vorteil hättest Du wenn Du in einer function Node den Node Kontext für Deinen counter verwenden könntest, dann brauchst aber auch keinen flow Kontext.
Wenn du bei deinem Flow halt die Begrenzung in der function Node einfügen willst musst Du halt entweder über die Nachricht (das topic oder die Eigenschaft innerhalb der Nachricht) kenntlich machen, ob der Ursprung aus Deinen Begrenzungs-Inject Nodes oder den Action Inject Nodes kommt. Wie gesagt - Du fängst nur an unnötig viel Code zu schreiben.
Im Übrigen arbeitest Du wohl in Deinen msg.action Inject Nodes mit Strings - anstelle gleich mit Zahlen zu arbeiten:
Also einfach schauen, was Du für einen Datentyp verwendest - das muss kein String sein. Somit könntest Du Deinen counter gleich mit der msg.action in einer Anweisung erhöhen oder erniedrigen.
-
Was im Flow noch fehlt ist eine Initialisierung der Begrenzung Flowvariablen. Dazu einfach die gewünschte Inject-Node einmal triggern lassen.
-
@mickym
es ist frustrierend zu sehen, dass man immer vieeeeel zu kompliziert denktich habe nun mal deinen Code in meinen Flow eingebettet.
anbei das Ergebniss. sicher auch zu komliziert ?
ich bin in der Funktion Node hängen geblieben wegen dem if/else - dass es aber auch anders geht - hatte ich noch nicht gewusst.
danke schon mal - fürs helfen
Gruß Rico
-
@hawell Nun dieses Gewirr in der Mitte - geht es darum dass für 5s stabil ist?
-
korrekt, poduktiv sind es aber 60Sek. anstatt 5
es soll der flippen zwischen 2 Zuständen verhindern,
die Eingangswerte kommen von einen Energiezähler, und diese Werte können bekanntlich durch eine PV-Anlage auf dem Dach etwas schwanken.
-
@hawell Aber wenn der gleiche Ast kommt soll alle 5s (bzw. 60s) der counter eines hochgezählt werden?
-
ja, wenn die die Bedingung zum hochzählen 5 sec gegeben ist, dann einen Schritt hochzählen (am Schrittwerk hängen Heizstäbe, welche dann den Eingangswert (Stromüberschuss) reduzieren).
wenn Bedingung nicht erfüllt, dann nichts machen.
die Britte Bedingung ist runterzählen und somit Leistung abschalten. -
@hawell Ok - ich meine es funktioniert bei Dir ja. Insofern ist es doch OK. Ich mach mal eine Alternative ohne 100% sicher zu sein, ob das dann tut.
Die erste Regel kannst Dir natürlich sparen - da Du ja mit der nächsten Regel die payload neu setzt - damit ist das was vorher in der payload war sowieso egal.
-
@mickym sagte in Schrittwerk mit einer Bedingung begrenzen:
@hawell Ok - ich meine es funktioniert bei Dir ja. Insofern ist es doch OK. Ich mach mal eine Alternative ohne 100% sicher zu sein, ob das dann tut.
ich bin mit dem Konstruckt auch nicht glücklich, da ich atkuell auch an einem "Doppelsprung" arbeite - wenn genug leistung ansteht, dann kann um "2" gesprugen werden.
Übersichtlicher wird es damit aber nicht -
@hawell Schau mal, ob das tut was Du brauchst:
Falls der Energiemanager aus irgendeinem Grund gar nicht mehr tut - kannst Du das periodische Senden ja dann auch unterbinden.
-
@mickym sagte in Schrittwerk mit einer Bedingung begrenzen:
erschreckenderweise tut es was es soll ...
bis auf, dass es immer die gleichen Zeiten nimmt, ich konnte schneller runterschalten, als hoch. -
@hawell Ja gut - die Zyklik bleibt gleich - aber Du könntest ja in der Switch Node noch andere Werte einsetzen, um schneller hoch und runter zu schalten.
Sobald Du an der Rändern bist - wird ja durch die hintere filter Node die Nachrichtenanzahl beschränkt.
Aber soweit ich verstanden habe - kommt aus dem Energiemanager ja alle Sekunden ein trigger - insofern ist es ja egal, ob Du einen eigenen Taktgeber verwendest und nicht den vom Energiemanager.
Aber ist ja nur ein Alternativvorschlag. Deines hat ja funktioniert.
-
@hawell Wenn Du den Takt vom Energiemanager behalten willst - dann kannst Du dieses Mal auch eine function Node verwenden. Ich mach Dir mal einen Vorschlag.
-
@mickym
das skalieren mit größeren Schritten hatte ich schon getestet das geht super.zwei Sachen verstehe ich aber nicht.
wieso sendet der letzte Trigger nur bei Zahlen außer "0" alle 5 sek ? und bei 0 Macht er nichts ??und leider gibt der Trigger den Wert aus, welcher "auf den Weg bebracht wurde", auch wenn sich schon die Richtung geändert wurde.
also wenn +1 wiederholt wird, und dann auch 0 umspringt, wird trotzdem noch einmal hochgeschaltet und dann erst gestoppt.man müsste den laufenden Tigger bei Wertänderung unterbrechen.
und zwei unterschiedliche zeitliche Trigger paralell laufen lassen (einen fürs hochschalten und einen fürs runter Schalten.
-
@hawell sagte in Schrittwerk mit einer Bedingung begrenzen:
@mickym
das skalieren mit größeren Schritten hatte ich schon getestet das geht super.zwei Sachen verstehe ich aber nicht.
wieso sendet der letzte Trigger nur bei Zahlen außer "0" alle 5 sek ? und bei 0 Macht er nichts ??Na das hatte ich aus Deinem alten Flow so verstanden, da alles rückgesetzt wurde - das dann nichts mehr gesendet werden soll.
und leider gibt der Trigger den Wert aus, welcher "auf den Weg bebracht wurde", auch wenn sich schon die Richtung geändert wurde.
also wenn +1 wiederholt wird, und dann auch 0 umspringt, wird trotzdem noch einmal hochgeschaltet und dann erst gestoppt.Nun ja - da musst aber mal logisch überlegen - dass ja EXTRA eine Zeit abgewartet wird, bis eine Änderung registriert wird.
man müsste den laufenden Tigger bei Wertänderung unterbrechen.
In dem Fall werde ich Dir mal mit einer function Node helfen, die Du dann wieder nur vom Energiemanager getriggert wird und nur bei +1 oder -1
und zwei unterschiedliche zeitliche Trigger paralell laufen lassen (einen fürs hochschalten und einen fürs runter Schalten.
Nein das ergibt Chaos.
-
@mickym sagte in Schrittwerk mit einer Bedingung begrenzen:
@hawell sagte in Schrittwerk mit einer Bedingung begrenzen:
@mickym
das skalieren mit größeren Schritten hatte ich schon getestet das geht super.zwei Sachen verstehe ich aber nicht.
wieso sendet der letzte Trigger nur bei Zahlen außer "0" alle 5 sek ? und bei 0 Macht er nichts ??Na das hatte ich aus Deinem alten Flow so verstanden, da alles rückgesetzt wurde - das dann nichts mehr gesendet werden soll.
das ist auch richtig, aber wieso macht die Node das - ich ich finde die entsprechende Einstellung nicht. oder liegt es am dem Befehl "0" dieser Stoppt den Trigger?
und leider gibt der Trigger den Wert aus, welcher "auf den Weg bebracht wurde", auch wenn sich schon die Richtung geändert wurde.
also wenn +1 wiederholt wird, und dann auch 0 umspringt, wird trotzdem noch einmal hochgeschaltet und dann erst gestoppt.Nun ja - da musst aber mal logisch überlegen - dass ja EXTRA eine Zeit abgewartet wird, bis eine Änderung registriert wird.
man müsste den laufenden Tigger bei Wertänderung unterbrechen.
In dem Fall werde ich Dir mal mit einer function Node helfen, die Du dann wieder nur vom Energiemanager getriggert wird und nur bei +1 oder -1
und zwei unterschiedliche zeitliche Trigger paralell laufen lassen (einen fürs hochschalten und einen fürs runter Schalten.
Nein das ergibt Chaos.
geht das nicht so ? 0 hat immer Priorität und setzt die Laufenden Trigger zurück?
-
gelöscht
-
Na ich glaube Du behälst Deinen ursprünglichen Flow.
-
@mickym
ich schau mir das morgen mal genauer an.
aber der letzte flox ist buggy, der gibt teilweise nur 1 aus egal was man drückt (mit oder ohne warten; mit oder ohne 0 drücken)
