[Beantwortet] Logik zur Werteaggregierung

[Robert_Mini]

Eine Erklärung davon (größerer Versatz) steht hier: app.php/kb/viewarticle?a=89
Gleichwertiger Tiefpass muss halbe Zeitkonstante des Fensters für den gleitenden Mittelwert haben.

Das 2. was ich noch Dunkel im Kopf habe: der Tiefpass gewichtet neuere Werte höher im Gegensatz zum Mittelwert (alle Werte gleich gewichtet), das erklärt vielleicht die "schlechtere" Glättung.

Lg
Robert

[EarlBacid]

@Robosoc
nochmals vielen Dank für das Erstellen der Custom Logik!

Letzte Woche ist nun meine PV Anlage in Betrieb gegangen und nun ist passiert, was du bereits befürchtet hast. Die Werte meiner Wechselrichter kommen in sehr unterschiedlichen Intervallen und ohne Timestamp. Zwischen zwei Werten kann es zwischen 600ms und 3 Sekunden alles geben.
Das bringt natürlich die Herausforderung, hier einen Vernünftigen Durchschnittswert zu bilden.

Mein "manueller" Ansatz war jetzt, eine primitive Logik zu verwenden die den Eingang einfach auf den Ausgang weiter gibt und diese dann mit einem 1s Trigger zu versehen.
Damit erreiche ich zwar bereits mein Ziel, aber die Anzahl der Logiken die ich hierfür benötige macht die Sache etwas unübersichtlich. Daher die Frage, ob das nicht auf einfachem Wege auch in der Custom Logik bereits abgebildet werden könnte.
Sprich anstelle jede Änderung am Eingang zu als eigenen Wert anzusehen eben stattdessen ein Trigger zu verwenden und immer zum Triggerzeitpunkt den gerade anliegenden Wert am Eingang in das Array zu übernehmen?

Der Vollständigkeitshalber: so sieht es jetzt bei mir aus:


By the Way: es ist natürlich Phenomenal, was da auch so bereits möglich ist, und mein Wolf noch nicht im Ansatz ins Schwitzen kommt, obwohl hier ein konstanter Datenstrom von meinen Wechselrichtern kommt, diese von einem Container aus einem seriellen Datenstrom in MQTT gewandelt werden, dann in einen ebenfalls im Container laufenden MQTT Broker übertragen und von da über das TWS eigene MQTT Subsystem in ein paar dutzend Logiken weitergeleitet und anschließend in unterschiedliche Zeitserien geschrieben wird.

[Robosoc]

Moin Earl.
Vielleicht steh ich selber gerade auf dem Schlauch, aber m.E. müsstest Du das gleiche Ergebnis von Deinen zwei Logik-Zellen auch erreichen, wenn Du in der Custom-Logik-Zelle das machst, was Du in der AND Logik gemacht hast

- Den Messwert-Eingang auf U setzt
- Einen Triggereingang spendieren
- Ausgang mit T

[EarlBacid]

Moin Sven,

das war zuerst auch mein Gedanke, bin damit aber nicht ganz zum Ziel gekommen.
Wenn ich das genau so mache, dann wird der Ausgang ja bei jedem Trigger, also jede Sekunde, ausgegeben.
Die Alternative ist, den Ausgang auf C zu setzen, dann bekomme ich schön jede Minute einen Wert, vorausgesetzt der Wert hat sich auch geändert, was durchaus nicht immer der Fall sein muss.

Eigentlich bräuchte ich zwei Trigger. Einen für den Eingang (jede Sekunde) und einen für den Ausgang (bei mir alle 60s). Geht das irgendwie? Einen zweiten Trigger kann ich ja als Eingang definieren. Ich sehe nur keine Möglichkeit festzulegen, wo welcher Trigger verwendet werden soll. Meine Vermutung wäre daher, dass die Trigger über ein logisches ODER verknüpft wie ein einzelner Trigger arbeiten, korrekt?

VG
Earl

[Robosoc]

Sorry Earl ,habe schon mehrfach angefangen zu antworten, aber nie richtig voran genommen...

Erstmal hast Du recht und mein letzter Vorschlag war natürlich keine Lösung.
Einen Timer im Code kann man easy machen, aber dass ist auch noch nicht die optimale Lösung.

Denn dann würde man ja über z.b. 60 Auslösungen den Mittelwert der Eingangswerte bilden, aber unsynchron dazu alle 60 Sekunden den Wert senden...aus meiner Einschätzung wäre das eher eine Verschlechterung als Verbesserung.

Mit ein wenig mehr CodeÄnderung würde man natürlich Abstand von der festen Anzahl der Werte nehmen und den Durchschnitt nach Ablauf der 60 Sekunden nehmen, egal ob es 55, 60 oder 67 Telegramm waren, und das Aufsummieren dann von Neuem beginnen.

Aber wenn man dann schon dabei ist, könnte man auch die Zeiten berücksichtigen wie lange ein Wert anliegt ....

Und dann weiß man aber wieder nicht, ob denn diese gemessenen Zeiten auch mit den Messintervallen im Messgerät übereinstimmen oder nur von etwaigen Busjittern abhängen.

Fazit , Keep it simple und mach es mit einem Tiefpass.

Oder können wir dich dafür begeistert Dich auch ein wenig in CustomLogiken einzuarbeiten?

[EarlBacid]

Hi Sven,

zuerst einmal brauchst du dich bitte beim besten Willen nicht dafür rechtfertigen, wenn eine Antwort mal etwas länger dauert. Du machst das hier schließlich freiwillig in deiner Freizeit und ich bin froh, überhaupt jemanden zu haben, mit dem ich mich hierrüber austauschen kann, und der mir dann auch noch so kompetent hilft und sogar custom Code erstellt!!!

Bevor ich auf die verschiedenen Möglichkeiten eingehe, vielleicht nochmal etwas zum Messintervall und Messgerät. Das Messgerät ist Bestandteil eines Wechselrichters. Das genau Messintervall steht nicht in den Datenblättern, muss aber im Millisekunden Bereich liegen. Leider kann der WR die Werte nicht pushen, sodass sie von einem Script aus einem Container heraus über ein proprietäres Protokoll gepollt werden und an den MQTT Broker gepusht werden. Von dem was ich bisher sehen konnte, erhalte ich auch bei zwei Polls innerhalb von 400ms unterschiedliche Werte, daher meine Annahme, dass das messinterwall recht gering sein müsste (schon alleine, da das selbe Messinstrument ja auch verwendet wird um den Verbrauch bzw. erzeugte Leistung kumuliert zu messen).
Am Ende kann dementsprechend niemals ein exaktes Ergebnis herauskommen, da ich definitiv nicht alle einzelnen Messergebnisse des Messgeräts erhalte, und die, die ich erhalte auch noch zu unterschiedlichen Intervallen bekomme (lieg am Script, da bei jedem durchlauf nicht immer alle Parameter gepollt werden und somit die Laufzeit unterschiedlich ist). Es ist also nur die Frage wie ich mich möglich gut mit möglichst geringem Aufwand dem tatsächlichen Wert annähern kann. Am nächsten dran wäre ich wohl, wenn ich jeden Wert in eine TS schreiben würde, da wir diese automatisch mit einem Zeitstempel versehen und die gesamte Auswertung kann im Nachgang erfolgen. Das wollte ich aber meiner armen Datenbank und SSD nicht antun
Ich glaube am besten wäre für meinen Anwendungsfall über einen fixen Zeitraum einfach alle einkommenden Werte aufzuaddieren und nach Ablauf des Zeitraums den Durchschnitt zu bilden.
Wenn ich das recht verstehe, kommt hier die fertige Tiefpass Logik dem schon recht nahe, insbesondere, da dieser, soweit ich das recherchieren konnte, auch den zeitlichen Verlauf der einkommenden Werte berücksichtigt.
Ich werde den Tiefpass nochmals hierauf ansetzten und schauen wie mir das Ergebnis "gefällt".

Zum Thema Custom Logiken, da bin nicht wirklich abgeneigt. Bisher fehlte es mir nur an einem echten Anwendungsfall. Dazu kam bisher noch die Abschreckung, dass ich als jemand, der zu mindestens halbwegs Script- und Hochsprachen programmieren kann, beim Syntax der Custom Logiken bei den ersten Blicken nur Bahnhof verstanden habe. Hier bedarf es wohl einfach eines erneuten Anlauf meinerseits

Viele Grüße
Earl

[Robosoc]

mindestens halbwegs Script- und Hochsprachen programmieren kann, beim Syntax der Custom Logiken bei den ersten Blicken nur Bahnhof verstanden habe.

da stand ich auch mal

Aber du hast einen riesen Vorteil wenn Du schon mit verschiedenen Script- oder Programmierspracheb Berührungspunkte hattest, Du weißt schon, dass es Variablen- und Konstanten-deklarationen braucht! Und Funktionen haben interne Variable und natürlich Solche die nach aussen quasi Schnittstellen sind.

Bei Custom-Logiken im TWS nehmen diese Deklarationen nicht selten mehr Zeilen ein, als der eigentliche Ablaufcode.

Das hat zwei Gründe
1. Im TWS muss für die nach aussen wirkenden Variablen (Ein- und Ausgänge) auch die GUI ( grafische Bedienerschnittstelle) bedacht werden. Das machst Du bei Script oder Programmiersprachen meist nicht im Code.
2. Wer zum Bespiel von Formeln in Excel ( als ganz simples Beispiel, ist ja keine Programmiersprache) daran gewöhnt ist, dass man direkt in die Formel als Parameter einen Werte (konstante Zahl) schreiben kann, musst sich aktuell damit abfinden, dass konstante Zahlenwerte oder auch ein TRUE immer als Variable deklariert werden muss und man verwendetdann die Variable. Aber das ist sehr schnell verkraftet und tut nicht weh.

So ,wenn Du das bis hierin verstanden hast (hab ich keinen Zweifel) dann versuche mal den Code, den ich Dir geschrieben habe zu verstehen.

Das Custom Logik Grundgerüst hat vier Elemente
{
"Level": [
Hierin findet ausschließlich die Variablendeklaration statt
],
"Module": [
Hier steht der eigentliche Code
],
"Input": [
Hier wird eingestellt, welche Variable in der GUI als Eingänge dienen, wie sie dort heißen, wie sie sich als solche verhalten und man kann optional Beschriebungen vergeben.
],
"Output": [
Hier wird eingestellt, welche Variable in der GUI als Ausgänge dienen, wie sie dort heißen, wie sie sich als solche verhalten und man kann optional Beschriebungen vergeben.
]
}

Nun wird Dir wahrscheinlich klar geworden sein, dass das eigentliche Gedankengut meiner Hilfe im Abschnitt "Module" steckt...damit ist die Aufgabe gerade auf 10 Zeilen geschrumpft, die Du versuchen solltest zu verstehen. Alles andere ist Syntax und Variablendeklaration.

Code: Alles auswählen

["Break", ["$VAR<Inhibit?>"]], 	
["Polynomial", "$In", "$Integral",["$Integral", "$const_1"]], 	
["Polynomial", "$const_1", "$counter",["$counter","$const_1"]], 	
["Ratio" , "$Integral" , "$Zwischenwert" , "$counter"], 	
["Polynomial", "$const_1", "$counter+1",["$counter", "$const_1"]], 	
["Comparator" , "$counter+1" , "$Reset" , "$n"], 	
["Latch","$Zwischenwert","$Mittel","$Reset",1], 	["Latch",0,"$counter","$Reset",1], 	
["Latch",0,"$Integral","$Reset",1]

Das break am Anfang hat mit der eigentlichen Logik nichts zu tun und ist nur das Konstrukt für die optionalen Inhibit (Sperr)-eingänge.

Und nun hast Du vielleicht schon erkannt, dass der Code gerade einmal aus 4! unterschiedlichen Funktionen besteht.
Polynomial (Addition und Multiplikation), Ratio (Division), Comperator (Vergleich) und Latch (Zuweisung).

Versuche doch jetzt im nächsten Schritt Zeile für Zeile zu verstehen was im Initialen Durchgang der Zelle passiert...usw.

Die initialen Variablenwerte wirst Du denke ich jetzt schon sehr schnell selber aus dem Abschnitt Level herauslesen.
Alles was ein $-Zeichen am Anfang hat, sind Variable.
Bei Latch steht am Ende eine Zahl (1), das ist keine Variable, sondern eine Einstellung.
Auch "$counter+1" ist eine Variable...das +1 im Variablennamen ist jetzt vielleicht nicht die genialste Idee gewesen.

Am besten lege Dir dafür die KB Kapitel 4.6.6 in ein Browsertab. Das mache ich meist auch noch, wenn ich eine Logik schreibe.

《Edit: nachfolgende Aussage war falsch, sorry. Habe es gelöscht, damit es nicht irritiert...aber falls es schon jemand gelesen hatte und jetzt vermisst... es began mit
Die 4 Zeilen nach dem Break hätte man auch mit....》

Hoffe dies motiviert Dich, es ist wirklich super simpel.
Wenn Du Fragen hast, hau raus

[Robosoc]

Jetzt nochmal zum eigentlichen Anwendungsfall:
Manchmal sieht man ja den Wald vor lauter Bäumen nicht.

Bekommst Du den eigentlichen Energiezählerwert auch in gleichem Zyklus im MQTT Server?

Dann könntest Du ja einfach jede 60 Sekundn eine Logik triggern, die die Differenz aus dem letzten und dem neuen Wert bildet und diese dann durch 60 Sekunden teilen oder in W/h umrechnen...