[Beantwortet] [V4.8 IP4] Verbrauchszähler aus kleinen Einzelverbräuchen

[eib-eg]

Danke fürs Testen
Werde deine Infos der ki geben und den neuen Code wider einstellen
Die hat gerade das Vorgänger Model deines Eintrages erstellt und nun ist dein nächster Eintrag schon da
Ich darf also ein wenig langsamer arbeiten mit der ki

[CHD]

Hallo Georg,

der Baustein rechnet immer noch nicht korrekt. Allerdings habe ich jetzt auf die schnelle noch nicht mitbekommen, was genau da vor sich geht, der läuft noch nicht so lange. Als ob der intern den Gesamtzähler mit 1 runterzählt und bei den Verbräuchen immer 1 dazu addiert. Siehe K-Offset zu Gesamtzählerstand und Verbrauch. Alle 15min wird 1 abgezogen (also da der Korrekturwert negativ ist wird 1 dazuaddiert) und der Zählerwert am Eingang wird immer noch ignoriert.



Und der Statuscode ist sehr lang: 5301855232.00 - das steht in der Beschreibung doch auch anderes erklärt, oder?

[gbglace]

Ja ich bin ja selbst auch per Hand dabei mir den anzuschauen und zu korrigieren.

Vorsicht mit dem loslaufen. bei dem Bezugs/Einspeise Zähler müssen wir uns noch über ein gewolltes Verhalten unterhalten und entscheiden was umzusetzen ist. Das sind da noch keine eindeutigen Bauvorgaben für die KI.

[gbglace]

Ich habe mir da jetzt auch mal eine Instanz manuell angepasst und ja den offset im Delta berücksichtigen führt im Modus 0 dazu, dass der mit jedem Input fälschlicher Weise drauf addiert wird.

Im Modus 0 ist das Delta selbst aber soweit sauber nur der input Zählerstand ist falsch.
Da muss das offset also an anderer Stelle berücksichtigt werden oder darf nur einmalig angewendet werden.

Im Modus 1 uns 2 hingegen wäre der Offset korrekt am Delta in jedem Durchlauf anzuwenden.

Insofern nun die Frage wie im Design berücksichtigen das offset bei Modus 0. nur einmalig im Delta oder am neu ausgerechneten roh Zählerstand.
letzteres macht es etwas komplizierter da dies zu zwei neue zu speichernde Werte ergibt die im neuen Durchlauf zu berücksichtigen sind.

Bei einer delta zentrierten Logik wie sie derzeit umgesetzt ist scheint es mir dann einfacher den Offset nur einmalig zu verwenden. Man muss sich dann allerdings einen Trigger bauen, ob es einen neuen Wert bis zum neuen Rechnen gegeben hat, denn der Eingang soll ja auch U update only bleiben.

[eib-eg]

Betreff: Re: Universal-Zähler-Statistik PRO+ (Göran Edition) – Konzept-Check & Generierungs-Pause

Ab hier KI-Text:

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

Konzept-Check: Der Zähler-Monolith V1.50 – Erst denken, dann rechnen!

Zuerst ein großes Dankeschön für euer gnadenloses Code-Review! Christian, dein Screenshot mit dem astronomischen Status-Code und dem „Rückwärtszählen“ war der nötige Warnschuss. Mein „KI-Lehrling“ hat hier schlichtweg die Orientierung verloren, weil wir versucht haben, zu viele komplexe Anforderungen gleichzeitig in den Code zu pressen.

Göran, dein Einwand in Post #53 ist der entscheidende Punkt: Wir haben aktuell keine eindeutigen Bauvorgaben für das Verhalten bei Vorzeichenwechseln.

Bevor wir die nächste „gehärtete“ Version (V1.50) angehen, möchte ich die Generierung stoppen und folgende Punkte mit euch klären:

1. Das Integral-Dilemma (Modus 3):
Wie soll sich der Baustein verhalten, wenn er z.B. als „Bezugszähler“ (nur positive Werte) konfiguriert ist, aber mitten im Intervall die Leistung negativ wird?
• Option A: Er rechnet das Integral bis zum Nulldurchgang und stoppt dann (Inhibit-Effekt).
• Option B: Er ignoriert das Vorzeichen und bildet den Absolutwert (energetisch meist falsch).
• Option C: Wir trennen das Integral-Modul komplett von der Statistik-Einheit (zwei separate Logik-Zellen).

2. Die „Magischen 24“ Ausgänge:
Göran, du hast die Bitmaske für den Status-Code vorgeschlagen (Post #50). Sollen wir diese additive Bitmasken-Logik (1, 2, 4, 8...) als festen Diagnose-Standard für alle 24 Ausgänge (7 Perioden à Start/Prev/Delta + Alarme) durchziehen?

3. Impuls-Logik (Modus 2):
Bleiben wir bei der „engen Auslegung“: Ein Telegramm am Eingang = Ein Impuls (multipliziert mit dem Faktor)?

Mein Vorschlag:
Wir nehmen die Version 1.42 (aus Post #42) als stabilen Ankerpunkt zurück. Ich werde erst dann eine neue Version durch die KI jagen, wenn ihr mir ein „Go“ für das konzeptionelle Verhalten gebt.

Ziel ist ein Fels in der Brandung, kein Kieselstein im Getriebe.
"Was ist eure Meinung zur Vorzeichen-Trennung und der Integral-Berechnung (Leistung_alt * Zeitdelta)?"

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

[gbglace]

So, ich habe im Hinterkopf ja auch noch eine Version mit einem weiteren Rechenmodus der sehr an Modus 0 angelehnt ist. Nur muss bei dem nicht mit einem Skalierungsfaktor multipliziert werden, sondern eben ein Quotient ermittelt werden. klar kann man das auch als Faktorabbilden aber das ist schwer zu erklären. Das ist dann Modus 4 also nicht verwundern wenn da wer den Code hier anbei sich anschaut zum testen.

Eingebaut ist da auch die Reparatur, das er den offset nur bei einem Wechsel dessen einmalig im Delta im mode 0 und mode 4 berücksichtigt.

Offene Punkte:

• Berechnung des nachlaufenden Integrals statt des zeitgleichen.

• Einspeise/Bezugszähler definition und entsprechend intern inhibit Setzung je nach Richtungswechsel des Vorzeichens (bei mode 1,2,3).

Göran, du hast die Bitmaske für den Status-Code vorgeschlagen (Post #50). Sollen wir diese additive Bitmasken-Logik (1, 2, 4, 8...) als festen Diagnose-Standard für alle 24 Ausgänge (7 Perioden à Start/Prev/Delta + Alarme) durchziehen?

Nein für alle 24 Ausgänge ergibt das keinen Sinn das geht zu weit, drei der Ausgänge reagieren ja jeweils gleichartig zu einem der 7 zeitbasierten Trigger.

Aber in Anbetracht meiner Überarbeitung anbei sehe ich da dann jetzt neben den reinen Logik Auslösetriggern (Daten input und die 7 Zeitpunkte) die folgenden dynamischen trigger, die für das Debuggen sehr erhellend sind.

Code: Alles auswählen

        // a counter reset was identified
    ["$Lgc_Found_Counter_Reset","bool",false],
        // new offset value detected
    ["$Lgc_New_Offset", "bool", false],
       // offset override flag
    ["$Lgc_Offset_Override", "bool", false],

Und die dann noch notwendigen zwei für
Vorzeichenwechsel und ermittelte Zählersperre bei Bezug/Einspeise Zählerdefinition

Universal-Zähler-Statistik V1.49 - Göran.txt

[eib-eg]

Hinweis: Dieser Beitrag wurde von der KI unter strikter Einhaltung der physikalischen Korrekturvorgaben von gbglace erstellt.

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

Ehrliche Antwort vom Meister: Ich lasse rechnen!

Göran, ich sag’s wie es ist: Bei der Integral-Mathematik und den Bitmasken-Verschachtelungen steige ich fachlich aus – dafür habe ich ja meinen „KI-Lehrling“. Aber ich verstehe die Physik dahinter und sehe, wo die Probleme in der Praxis liegen.

Dein Code-Review zur V1.49 ist Spitzenklasse. Besonders der Punkt mit dem nachlaufenden Integral (Leistung_alt * Zeitdelta) ist physikalisch der einzig richtige Weg.

Zum Thema Bezug vs. Einspeisung (Vorzeichen-Wechsel):
Ich habe das mit der KI besprochen. Wir wollen den Baustein nicht mit zwei internen Zählern überfrachten, um die Stabilität nicht zu gefährden.

Unser Vorschlag für V1.50:
Wir bauen einen einfachen „Vorzeichen-Filter“ als Parameter ein:
• Modus 0: Zählt alles (wie bisher).
• Modus 1 (Nur Positiv): Ignoriert alles Negative (perfekt für den Bezugszähler).
• Modus 2 (Nur Negativ): Ignoriert alles Positive und wandelt negative Werte in positive Zähler-Häppchen um (perfekt für den Einspeisezähler).

Der User nutzt dann einfach zwei Instanzen der Logik am selben Shelly-Objekt. Das ist übersichtlich, modular und jeder Zähler hat seine eigene saubere 24-fache Statistik.

Zum Status-Code (Bitmaske):
Göran, ich folge deinem Rat. Wir beschränken die Bitmaske auf die dynamischen Ereignisse (Reset erkannt, Offset-Wechsel, Inhibit aktiv, Vorzeichen-Sperre aktiv). Das hält den Graphen im Grafana sauber und liefert trotzdem die nötige Forensik.

Wie sieht’s aus? Wenn ihr mit dem „Vorzeichen-Filter“ d’accord geht, lasse ich die KI die V1.50 auf Basis deiner V1.49 (mit dem korrigierten Integral) bauen.

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

[gbglace]

Wenn wir die 7 Statistik-Zeitrigger weglassen (das ist ja soweit stabil getestete Funktion), dann nimm aber noch die beiden Trigger

["$Lgc_Triggered_By_Input","bool",false],
["$Lgc_15Min_Period_End_Trigger", "bool", false],

Die anderen Periodentrigger sind ja immer nur mit dem 15 Minuten Trigger gemeinsam gültig.


Bezüglich dem Vorzeichen Filter.

Ist das soweit eine korrekte Beschreibung.

Nur ist halt Modus 0 eher die Ausnahme.
Das wäre dann der Aufbau eines Stromzählers ohne Rücklaufsperre. Zumindest mit dem Scope Energiezähler wäre das in der aktuellen zeit kein sinnvoller Baustein.

Aber wir wollen den Baustein ja insgesamt doch generisch halten und irgendwo hat da ggf auch jemand dafür einen Anwendungszweck.
(Wasserstand Zisterne und zwei Deltas gehen da rein, Regenmenge auf Dachfläche und Entnahme durch Pumpe. Der Baustein hier würde dann quasi indirekt den Füllstand angeben.

Bei der Reihenfolge würde ich dann aber als Default. Zähler erwartet stetig aufwärtszählend positive Werte. gefolgt von stetig negative Werte und drittens offen für alles. Einfach weil das eher selten gebraucht wird.

Aber mit genau diesem einen Input Parameter und der dann selbst erkannten Sperre / Verwerfen des Deltas wenn es das falsche Vorzeichen hat haben wir die Anforderung von Stefan genau getroffen. Und damit sind das eben auch wieder zwei Werte für den Status Code, a) welches Vorzeichen, b) Delta verworfen)


Und wie gesagt in dem Baustein 1.49 steckt auch noch der zusätzliche Modus drinnen der auch quotieren statt skalieren kann.

Die beiden Input Faktoren haben damit jeweils zwei mögliche Bedeutungen.

[gbglace]

Und noch ein kleiner Hinweis.

in irgendeiner Doku habe ich gelesen man könne die Formel in den Bausteinen Calcformula nicht dynamisch setzen.

Das geht schon.
In dem Code V1.49 habe ich davon gebrauch gemacht um genau die Berechnung Mods 0 vs Modus 4 zu gestalten.

Es gibt die Formeldefiniton:
// formula variable for selected formula to scale or quote depending on mode
["$F_Scale_Quote", "string", ""],

und später die effektive Zuordnung:
// scaling or quoting of calculated delta value depending of input mode
["Multiplexer", ["$F_Mul", "$F_Mul", "$F_Mul", "$F_Mul", "$F_Div"], "$F_Scale_Quote", "$I_Input_Mode"],

Solange die innere Anordnung der Input Werte für die ausgewählten Werte passen (hier jeweils X1 und X2 einmal X1+X2 und einmal X1/X2) kann man sich so die Art der Berechnungen steuern.

Nur mal so als Anregung, ggf auch als Input für die KI ist ggf auch etwas neues was sie so noch nicht aus dem Handbuch herausgelesen hat.

[CHD]

In Falle des Einspeise-/Bezugszählers ist es ja auch eine Definitionsfrage, ob ein Zähler negativen Bezug = Einspeisung ausgeben kann/darf. So wie die alten Drehstromzähler sich einfach rückwärts gedreht haben. Aber da es sowas ja wahrscheinlich irgendwo so auch gibt, fände ich eine interne inhibit-Setzung angebracht und sinnvoll. Eine gute Idee! Dazu eine Vorwahl zur einmaligen Initialisierung, was der Baustein berücksichtigen soll fände ich am logischsten. Dann legt man sich zwei Logiken an - die eine Zählt positive Werte, die andere die negativen und das kann man dann getrennt weiterverarbeiten.

OK, zu langsam, ihr habt dazu ja schon was geschrieben...

Aber was mir noch aufgefallen ist in V1.49: bei I1 steht Eingangs-Rowwert anstelle von Eingangs-Rohwert. Und rechnet die Logik den Wert Stunde Delta Vorperiode korrekt? Oder wie ist der Wert gemeint? Wenn dort das Delta seit Start mit Wert 0 gemeint ist, müsste er ja passen, da die Logik noch keine Stunde in Betrieb ist. Verstehe ich das richtig? Erwartet hätte ich dort eigentlich den um den Offset korrigierten Wert, aber wie gesagt, im Code steht halt ["Stunde Delta Vorperiode", "Verbrauch der letzten Stunden-Periode", "$State_Hour_Delta_Prev", "t"], .