ElabNET Technik Forum

Universal-Zähler-Statistik V1.50 - "Göran Edition" (Der Präzisions-Monolith)

Hinweis: Dieser Beitrag wurde von der KI unter strikter Einhaltung der physikalischen Korrekturvorgaben von gbglace und der Blackbox-Diagnose-Doktrin erstellt.

Hallo Göran (@gbglace ), hallo Christian (@CHD ),

vielen Dank für euer gnadenloses und extrem hilfreiches Feedback zu den Vorversionen! Wir haben die "Operation Kristallklar" abgeschlossen und den Monolithen komplett neu aufgebaut. Die Version 1.50 ist nun erfolgreich speicherbar und bereit für den Härtetest im Reallabor.

Was wurde in V1.50 geändert?

1. Integral-Präzision (Physik-Fix):
Wir folgen Görans Korrektur: Das Integral (Modus 3) berechnet das Energie-Delta nun korrekt mit der Leistung des vorherigen Intervalls (P_alt * dt). Der aktuelle Messwert wird erst nach der Berechnung für den nächsten Zyklus gespeichert.

2. Vorzeichen-Filter (Bezug/Einspeisung):
Ein neuer Parameter "Vorzeichen-Wahl" ermöglicht die saubere Trennung am selben Messpunkt:
• 0: Alles zählen (Zisterne/Füllstand).
• 1: Nur positive Werte (Bezugszähler).
• 2: Nur negative Werte (Einspeisezähler - Werte werden intern positiv gewandelt).
Vorteil: Einfach zwei Instanzen der Logik an denselben Shelly hängen – fertig ist die saubere Statistik für beide Richtungen.

3. Dynamische Formel-Wahl (Göran-Trick):
Wir nutzen Görans Entdeckung: Der Formel-String in der CalcFormula wird nun via Multiplexer zur Laufzeit getauscht. Dadurch kann die Logik zwischen Skalierung (Multiplikation) und Quotierung (Division für kWh/kWp) umschalten, ohne redundante Module zu benötigen.

4. Blackbox-Diagnose (Bitmaske):
Der Status-Code wurde auf eine additive Bitmaske umgestellt, um gleichzeitige Ereignisse im Grafana (Step After) sichtbar zu machen:
• 1: Neuer Daten-Input empfangen.
• 2: 15-Minuten-Reset gefeuert.
• 4: Inhibit (Sperre) aktiv.
• 8: Vorzeichen-Sperre aktiv (Delta verworfen).
• 16: Kritisch: Wertabfall erkannt (Modus 0).
• 32: Manueller Offset-Wechsel erkannt.

5. Syntax-Härtung:
• Alle integer wurden konsequent auf int korrigiert.
• Vollständiges Variablen-Audit: Alle 82 Level-Variablen sind sauber deklariert.
• Keine "Magic Numbers" in Arrays – alles über Variablen-Referenzen gelöst.

Bitte um Überprüfung
Die Logik ist ein echtes "Schlachtschiff" geworden. Ich bitte euch, besonders die neue Vorzeichen-Schleuse und das Integral-Verhalten zu testen.

Ziel erreicht: Ein Fels in der Brandung für Görans 50 Instanzen!

Beste Grüße,
eib-eg (Georg)

So vom drüber lesen erstmal OK.

Was mich aber noch stört ist das sekündliche Clocksignal. Das führt doch zu einer sekündlichen Ausführung des Bausteins. Oder täuscht mich das?

Kann die Zeitdifferenz nur darüber sauber ermittelt werden?
Funktioniert das nicht gut wenn das Einfach die Echtzeiten bei eingehenden Daten oder eben den 15-Minuten erreicht verwendet und daraus die Differenz rechnet?
Da die Zeitdifferenzen auch in floats gespeichert sind und die Reste der Sekunden damit als Nachkommastellen vorliegen passt das auch bei der Benutzung mit dem Integralfaktor. Das muss da kein ganzzahliger Sekundenwert sein um zu passen.

genauere Tests dann heute Abend.


Und wenn wir dann funktional sauber sind, müssen die Variablen nochmal im Naming angepasst werden. Die KI übernimmt da zu viel aus dem Anwendergespräch deutsch in die Variablennamen und macht dann einen Mix aus beiden Sprachen. Ich bin da nun auch kein Englisch-Experte aber in solchen Kandidaten für offizielle Bausteine sollte das dann sauber und einheitlich im Code sein.
Das was die Metadaten im Kopf der Logik sind und bei den Ein und Ausgangs Angaben für die Oberfläche im Logikeditor sind, das darf gerne in deutsch daher kommen.

Hallo zusammen,
Ich habe immer noch die Version 1.11 am Laufen und Testen.
Die Frage ist, machen die Tests noch Sinn, wenn der Code grundsätzlich geändert wird?

Die Version 1.11 hat alle Funktionen, die Ich verwende richtig behandelt.
Die Einstellungen:
Eingangsmode =1
Inhibit = false
Input Faktor = 1
Korrekturoffset = 351.

Ich hatte ja das Glück, dass Monatsende, Quartals ende und Jahresende stattfanden.
Alle Berechnungen waren richtig.

Gruß
Rainer

Hallo
Sorry, ich habe nicht die Version 1.11 am Laufen und Testen, Sondern die Version 1.32
Gruß
Rainer

Das war ja auch der Grund warum ich noch möglichst schnell dir den Code noch zum Jahreswechsel zum Testen geben wollte.
Jede weitere Entwicklung dieses Codes bzw. dieser Logik hilft elabnet bzw. den Nutzern die diese Logik verwenden wollen.

So kommen wir mal wieder zum Inhalt des Codes.

ich bin gerade mal wieder dabei das intensiv gegen zu lesen und die variablen wieder im Namen zu korrigieren und ein paar Kommentare an den Logikzeilen zu ergänzen. Bin aber nur bis zu den Eingangsvariablen gekommen und bin stutzig geworden.

Ist das bei dem Tarif-Umschaltungs Inhibit Eingang eigentlich die korrekte Vorgehensweise den auf nur update zu belassen?

Zumindest im Modus 3 Leistungseingang der zu integrieren ist, passt das nicht und müsste daher besser auf c change stehen und dann kann wenn kommend von "offen" auch der letzte empfangene Leistungswert bis zu diesem Zeitstempel umgerechnet werden und dem Zähler zugerechnet werden. Ist der Wechsel auf der Flanke geschlossen zu offen passiert nix weiter als den Vorgänger Zeitstempel zu aktualisieren aber noch nichts wegzuschreiben.

Bei den anderen Modus-Varianten ist es wie bisher da wird der inhibit nur im Zusammenhang mit einem Dateneingang ausgewertet und keine Berechnung bei einem Eingang auf dem Eingang der Tarifumschaltung getriggert.

Hier müssen wir also die Logik zum Trigger Berechnung aktiv verfeinern bzgl. Modus 3 und den Eingang auf c statt u stellen.



Der zuletzt anstehende Leistungswert wird dann auch einfach unverändert in den State-Werten fortgeschrieben, denn wenn das haus gerade 500W zieht tut es das ja vorerst auch weiter egal ob Tarif A oder Tarif B. die Änderungen folgen dann ggf aus anderen Logiken die dann was ab oder anschalten, aber dann kommt auch ein neuer Leistungswert vorne rein. Aber zeitanteilig muss da bei Wechsel des Tarifes noch was mit dem Leistunsgwert bis zu dem Zeitpunkt gemessen werden.

@Celsius

Das beste ist schon die V1.5 und ja sie kann schon wieder mehr als 1.11 und 1.32.

Aber in Details muss es noch reifen.

siehe die eben gefundene Anmerkung Integral zur Tarifumschaltung und immer noch dieses Clocksignal. Da ist die KI immer sehr hartnäckig am nutzen...

Schreib alles rein was dir auffällt und was du geändert haben möchtest
Du warst ja einer derjenigen der gleich mit der ki beim Treffen angefangen hat
Somit weist du ja auch wie mein Vorgehen ist mit der ki
Ich warte dann mal bis von dir oder Celsius das Go kommt
Du weist ja
Ich gebe ihr den kompletten Verlauf sowie dann die 1.50 Version

Die beiden Zeitkonstanten K_58 und K_22 sind falsch das soll die letzte Minute je Stunde sein und die letzte Stunde je Tag, daher sind die bei mir als C_Min_59 und C_Hour_23 benannt. Und stehen jeweils als integer mit Minute 59 und Stunde 23 in der level definition.

Bei der Stunde könnte es ja ein Versuch der KI gewesen sein da irgendwie Sommer/Winterzeit abzufangen aber bei der Minute ist es falsch das Zwei Minuten vor Ende der Stunde zu triggern.


Die Integralformel war noch hart verdrahtet und hat den Inputparameter als Integralfaktor nicht berücksichtigt im String.
Der Aufruf der Formel war korrekt mit drei Input Variablen im String gab es aber nur X1 und X2 und die 3600000 um von W über Sekunden auf kWh zu kommen.
Da käme direkt der nächste Fehler denn der Default-Wert für diesen Integralfaktor sind nur die Zeitkomponente also 3600 Sekunden in der Stunde. 1000 als Faktor kommen dann über den Scale Faktor, da der errechnete Delta Betrag dann als Wh noch durch den anderen Faktor auf die kWh skaliert wird. Der user kann natürlich auch den Scale Faktor bei 1 belassen und auch die 3600000 als Integralfaktor setzen. Da ist er frei.
Wir sollten aber als Default die 3600 setzen und in der Stringdefinion das X3 unbedingt beachten.


Den gesamten Verlauf der Diskussion wieder vorne rein bewirkt womöglich das er immer wieder diesen Herzschlag erfindet.
Das muss ihm da mal ordentlich ausgetrieben werden. Die Zeitmessung ist OK wenn das mit der Stopwatch funktioniert.
Aber passende Zeitpunkte haben wir mit dem Crontrigger zum 15 Minutenauslöser in Sekunde 57 und wenn ein Datenwert rein kommt. fertig.
Nochmal extra jede Minute/Sekunde braucht es keinen Berechnungszyklus.

// 1. ZEITMESSUNG & HERZSCHLAG
["Clocksignal", "$C_True", "$Lgc_Heartbeat_Pulse", "$K_60_f"],


Bei der Ermittlung ob eine Berechnung erlaubt ist ist er mittlerweile zu unsauber.
["And", ["$Lgc_Triggered_By_Value_Input", "-$I_Inhibit"], "$Lgc_Eingang_Erlaubt"],

Das bedeutet ja am Ende das er nur bei neuem Dateneingang auch das Delta zum neune Zähler drauf addiert.
Aber auch im reinen 15 Minuten Zeittrigger darf er drauf addieren denn im Modus 0 und 4 ist das Delta dann einfach 0, also unkritisch und im Modus 3 Integral ergibt das einfach eine weitere zeitscheibe und damit einen integrierten Wert für den Zählerstand.
Nur im Modus 1 und 2 wo von extern Zähler Deltas und impulse daher kommen darf der input nicht einfach nochmal drauf addiert werden.

Nach dem lesen dessen was da war habe ich mich dann doch noch ran gemacht und die Variablennamen wieder alle umbenannt.
Während dessen habe ich dann auch noch die fehlenden neuen diskutierten Abhängigkeiten eingebaut.

Daher neuer Baustein fertig für intensive Test

So hier ein extra Beitrag für den Testaufruf: Was kann das Ding jetzt:

Eingang1
Er nimmt einen primären Input Wert entgegen ($I_Raw_Value)

Eingang1
Der Wert aus Eingang1 wird je ausgewähltem Eingangs-Modus ($I_Input_Mode) unterschiedlich interpretiert
0 >> Ein fortlaufender Zählerstand wird erwartet (kann vorzeichenbehaftet sein, Auswertung dazu per separaten Parameter)
1 >> Ein Delta-Betrag wird erwartet (kann vorzeichenbehaftet sein, Auswertung dazu per separaten Parameter)
2 >> Ein Impulstrigger wird erwartet (alles was eingeht wird als Ping interpretiert)
3 >> Ein Wert, der erst über Zeitintegral zu einem Zähler-Delta wird, wird erwartet (kann vorzeichenbehaftet sein, Auswertung dazu per separaten Parameter)
4 >> Analog zu Modus 0, nur die Skalierung erfolgt hier per Division

Eingang3
Um mit vorzeichenbehafteten Eingangswerten sinnvoll umgehen zu können, ist dann noch die Zählerrichtung vorzugeben ($I_Counter_Direction).
0 >> egal: ermittelte Deltabeträge werden immer addiert je Vorzeichen verringert sich damit auch der Zähler
1>> vorwärts/aufwärts: ermittelte oder direkt angelieferte Delta-Beträge müssen positiv sein. Negative Werte werden ignoriert.
2 >> rückwärts/abwärts: ermittelte oder direkt angelieferte Delta-Beträge müssen negativ sein. Positive Werte werden ignoriert.
Die Vorzeichenlogik wirkt bei allen Eingangsvarianten außer Mode 2 Impuls (hier wird immer unabhängig vom Vorzeichen des Impuls-Wertes der Zählerstand verändert.
Damit kann man das Logikmodul z.B. als reinen Bezugs- oder Einspeise-Zähler aufbauen auch wenn nur ein quasi gemischter/wechselnder Input vorliegt. Eine externe Prüfung des Vorzeichenwechsels und dann setzen einer Sperre an diesem Baustein (analog der Tarifumschaltung) ist nicht notwendig.

Eingang4
Der nächste Input ist ein Sperrsignal ($I_Inhibit)
0 false >> der aktuelle Input-Wert wird gezählt
1 true >> der aktuelle Input-Wert wird nicht gezählt
Mit diesem Eingang kann man das Logikmodul auch für unterschiedliche Tarife benutzen, wo die Sperre entsprechend durch die Tarifumschaltung auszulösen / zu deaktivieren ist.
Bei der Verwendung im Modus 3 wird bei einem Wechsel von Sperre false zu true noch eine Aktualisierung der Zählers errechnet.

Eingang5
Der nächste Eingang ist der Skalierungs- / Quotierungsfaktor ($I_Scale_Factor)
Der intern als relevant ermittelte Delta Betrag wird mit diesem Faktor multipliziert, im Modus 4 durch diesen "Faktor" geteilt.
Hiermit lassen sich Eingangswerte von z.B. W nach kW transformieren und/oder Werte gewichten z.B. zur Ausgabe von Ertrag kWh je kWp Modulleistung.

Eingang6
Der nächste Eingang ist ebenfalls ein Faktor ($I_Pulse_Factor), der entweder als Impulswert oder Zeit-Multiplikator bei der Integralberechnung verwendet wird.
Ist das Logikmodul im Eingangs-Modus 2 wird quasi bei jedem Signaleingang am Eingang 1 dieser Wert 1:1 als Delta zum Zähler berücksichtigt.
Es ist also egal ob eine 0 eine 1 oder eine 5,23 am Eingang1 eingeht, es wird immer der Wert (z.B. 500 [I_Pulse_Factor]) als Delta zum Zähler berücksichtigt.
Ist das Logikmodul im Eingangs-Modus 3 wird dieser Faktor dazu verwendet die im Baustein ermittelte Zeitdifferenz in Sekunden auf die Zielperiode umzurechnen. Bei einer Gewünschten Berechnung von kWh also dem Bezug zu Stunden ist der Wert mit 3600 (Anzahl Sekunden je Stunde) zu erfassen.
Wird der Eingangsparameter nicht gesetzt oder mit 0.0 angeben wird mit den 3600 als Default das Integral berechnet.
Nach dem Spielen im Docktormodus daher darauf achten den Wert für ein neutrales Verhalten auf 0 zu setzen, gerade wenn man auch mal zwischen Modus 2 und drei Wechselt im Test.

Ist der Eingangswert1 in W und es sollen kWh als Zähler berechnet werden, kann mit einem Skalierungsfaktor von 1 und einem Integralfaktor 3600000 gearbeitet werden. Aber auch übersichtlicher mit den 3600 als Integralfaktor und einem Skalierungsfaktor von 1000.
Im Modus 2 und 3 werden beide Faktoren parallel angewendet.

Eingang7
Der letzte Eingang ist ein Zähler-Korrekturbetrag ($I_Offset).
Mit diesem Eingangswert kann ein Korrekturwert berücksichtigt werden, der z.B. notwendig wird wenn man im Modus 0 oder 4 einen neuen Zählermontiert, der aber selbst nicht direkt bei 0 gestartet ist und entsprechend würde dieses Logik-Modul einen falschen kumulierten Zählerstand ermitteln.
Hinweise zum Offset:
- Der Offset wird auf den Zählerstand vor Skalierung angewendet.
- Der Offset wird stets nur einmalig angewendet, sofern er sich ändert.
- Beim Offset Wert findet keine Vorzeichenprüfung statt, man kann den finalen Zählerstand daher gut über den Docktormodus korrigieren.

Ausgänge
Am Ausgang gibt es:

• 2 Zählerstände unskaliert und skaliert (O2 ist dann meist der relevante für eine Timeserie)

• 21 abgeleitete Werte aus dem Zähler, jeweils drei Werte zu sieben Perioden

• drei abgeleite Werte
  • Delta in der Vorperiode
  • Endstand am Ende der Vorperiode
  • Delta in der laufenden Periode

• zu sieben verschiedenen Perioden
  • 15-Minuten
  • Stunde
  • Tag
  • Woche
  • Monat
  • Quartal
  • Jahr

• eine Debug-Ausgabe aus einem Binärmultiplexer zusammengesetzt

Debug Code ist die Summe aus allen erkannten Triggern
1=Daten-Input
2=15m-Trigger
4=Zählersperre aktiv
8=Eingangswert verworfen wegen falscher Zählerrichtung
16=Zählerreset erkannt
32=neuer Offset/Korrekturwert erkannt

gerne Testen und Berichten was einem auffällt, wo Unklarheiten im Verhalten sind und ob noch ein Feature fehlt.

@eib-eg
gerne die KI damit füttern für saubere Variablennamen, kein Clocksignal notwendig, Kommentare im Code was da abgeht.