Einfache Funktion - Wertüberwachung mit 2 Verzögerungszeiten
-
@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 scheintDANKE 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 ...
-
@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 -
@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.
-
@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.
-
Vielleicht schaffe ich es ja noch, Dich von der Codiererei wegzubringen und Dich von den Vorteilen der grafischen Programmierung mittels NodeRed zu überzeugen.
-
@mickym ja so langsam aber sicher verstehe ich die funktionsweise
Super hab es eingebaut und es läuft ... aber eine Frage:
Hinten raus variieren die Topics - dort finde ich immer mal wieder alle 3 eingangs Topics.
Was sagt mir das dann? der Topic der da drin steht hat auch getriggert zu dem Zeitpunkt? -
@i0br0ker Ja der topic der da drin steht, war der letzte - das war ja die letzte Nachricht die getriggert hat. Wie gesagt, wenn Du willst, dass alle 3 immer neue Werte geliefert haben wollen, dann musst Du die Option auslassen. Du könntest theoretisch auch mit einer Switch Node filtern, dass Du nur dann eine Berechnung durchlässt, wenn ein bestimmter topic getriggert hat. Wie gesagt eine Parallelverarbeitung wirst Du in keinem Hausautomationssystem finden, sondern es wird immer einen zeitlichen Abstand zwischen den einzelnen Triggern geben.
Das topic dass Du hinten siehst, stammt also von einem der 3 Change Nodes mit dem Du die topics festlegst.
Das ist ja Bestandteil des Nachrichtenobjektes - auch wenn Du in der payload alle 3 Werte in einem Objekt zur Berechnung immer mitschleppst.
Am Besten siehst Du das, in dem Du Dir das gesamte Nachrichtenobjekt hinter der JOIN Node ausgeben lässt.
In der Berechnung überschreiben wir ja dann das payload Objekt wieder mit einem skalaren, numerischen Wert.
Das topic wird aber nicht angefasst. Du könntest das topic auch löschen oder einfach ein neues Topic Netzberechnung setzen, wenn es Dich verwirrt.
-
@mickym Wenn Du sagts die Einspeisung ist immer konstant, Du willst aber nur dann eine neue Berechnung machen, wenn sich verbrauchAC und verbrauchDC getriggert wurden, dann kannst Du das auch kaskadieren. Aber wie gesagt, Du musst Dich entscheiden - WANN Du eine Berechnung durchführen willst. Einen definierten Zeitpunkt musst Du festlegen und kann nicht das System für Dich festlegen.
-
@mickym soo ich will deine Geduld ja nicht überstrapazieren
Ich habe immer wieder kurze Ausreißer drin , die meine Zeiten im obigen Beispiel für false immer wieder zu schnell Resetten.
Kann ich mit einfachen mitteln den Wert "glätten" bzw einen Mittelwert über zeit x berechnen mit dem ich weiter arbeite? -
-
@i0br0ker Du kannst auch die Filternode nehmen, die kann Ausreiser über das narrow band ausfiltern, dann brauchst du keine neue Node installieren.
Hier kannst Du auch einen Prozentwert oder eine absolute Zahl angeben und mit der letzten Aus- oder Eingabe vergleichen.
Einfach mal die Hilfe so mancher Nodes anschauen.
Und bevor Du die average Node installierst, schau Dir mal die aggregate Node an - die kann auch den median verwenden - und Ausreißer werden damit gänzlich ignoriert.
-
@mickym Hi ich scheitere aktuell an einer "einfachen" UND Verknüpfung wenn beide Pfade auf TRUE Sind soll ein TRUE ausgegeben werden .... ich bekomm es ohne Function nicht geregelt
-
@i0br0ker beide pfade vereinst du wieder mit unterschiedlichen topics in ein nachrichtenobjekt mit den topic eigenschaften mit einer join node, wie wir es beim letzten flow gemacht haben. Anschließend kannst du die Eigenschaften des Objektes mit „and“ und JSONATA verknüpfen. Wenn Dir die Erklärung nicht langt, mache ich Dir später wieder ein Beispiel mit Inject Nodes.
ich bin nur gerade nicht am Rechner. wie gesagt wichtig ist alles in einem payload Objekt zu sammeln, da du ja alle aktuellen Zustände zum Zeitpunkt der Analyse brauchst. ich schicke Dir dann noch ein paar Change und Switch nodes mit den du beliebig viele Eigenschaften eines Objektes logisch verknüpfst. ich nutze das viel zur Überwachung von Geräten bzw. Zuständen.
-
@mickym Okay ich hab die 2 pfade schon über join zusammengeführt wie in dem Flow von dir der auch schon läuft bei mir.
Und dann die msg.topics schon eindeutig geändert ... ok dann google ich mal weiter ist ja eigentlich nicht so das ich mir alles erschnorren möchte Aber wenn ich grundlegend meine Funktionen mal habe kann ich damit arbeiten.
DANKE -
@i0br0ker Ich stell Dir mal meine Logiknodes zur Verfügung- sitze am Rechner. Und nein mach Dir keine Gedanken zum "Erschnorren" - ich mach das gerne und habe im Moment eh keine Lust an meinen eigenen Projekten zu arbeiten. Deshalb sind solche Hinweise für mich eine willkommene Abwechslung. Ausserdem glaube ich, dass Du vielleicht doch langsam ein Fan von NodeRed wirst und es für Dich nicht eine Last ist, weil es auf der Victron nichts anderes gibt.
-
Hier mal meine Logiknodes zum Import und zum Ausprobieren:
Im Prinzip kann auch eine JOIN Node Dir aus mehreren Eigenschaften eines Objektes EIN Ergebnis ermitteln (nicht nur logische Verknüpfungen).
Das benötigt zwar mehr Einarbeitung - aber damit kann man auch selbst Durchschnitte etc. berechnen und ist nicht unbedingt auf fertige Nodes der Community angewiesen - auch wenn man die natürlich nutzen kann. Es gibt auch fertige Boolean Nodes - aber wie gesagt, wenn man mit Standardnodes und JSONATA hinkommt, dann ziehe ich diese Vorgehensweise vor.
