ElabNET Technik Forum

So jetzt habe ich festgestellt das das Victron-Datenuniversum schon sehr detailliert ist aber einige Werte kommen dann doch nicht in fertigen Wh oder kWh raus. Die gibt es nur in momentanen Leistungswerten (Lynx Shunt rein/raus Batterie).
Ich will das natürlich auch in einem sauberen Zählerstand haben.

Nun haben wir hier ja einen Baustein in der Konzeptionsphase mit verschiedenen Inputformaten.

A) stetigen Zählerwert
B) Zählerhäppchen
C) Impulse die zu Zählerhäppchen mit einem Faktor umgerechnet werden können.

Jetzt neue Anforderungen:

D) Messwert der per Integral über Zeit zu einem Inputwert gemäß B) wird

Ich habe mir dazu auch schon diese Logik hier angeschaut: viewtopic.php?t=5628&start=10#p64453

Die erstellt recht schlank ein Integral.
Ich werde mal sehen die dortige Logik zu reduzieren auf die Berechnung des Integrals, dafür aber den Multiplikator der dort hart auf WS zu kWh steht, als Inputparameter zur Verfügung zu stellen.
Dann bleibt das da weiter ein generischer Baustein und ist nicht nur auf Strom begrenzt in seinen variablen Namen und Formelerklärungen.

Die Rückwärtssperre und Zählerreset sind ja im Zählerbaustein schon enthalten.

Die Begrenzung der Datenflut durch Minimaldelta werde ich mal auch noch übernehmen.
Das Victron MQTT schießt die Daten da auch im 2s Takt. Was aber auch für ein hochaufgelöstes Integral sorgt und einen relativ genauen Ergebniswert in kWh bietet.


E) weitere Variabilisierung des Skalierungsfaktors ggf auch mit Formelwechsel Division statt Multiplikation.

Hier kam mir die Notwendigkeit in die Finger den bestehenden Zählerbaustein nochmal anzupassen, um die Umrechnung von absoluten Ertrag der PV-Anlage auf den relativen spezifischen Ertrag zu erreichen.
Also kWh zu kWh/kWp. Nur mit diesem Wert lassen sich ja PV Anlagen und Standortqualitäten untereinander sinnvoll vergleichen.

Normal würde man da den kWh Wert durch die Wp der Module / 1000 rechnen.
Da wir bisher nur einen Skalierungsfaktor vorgesehen haben kommen da bei z.B. 450W p Modulen Werte raus die man nur ungenau als Faktor erfassen kann. Also brauchen wir da eine Möglichkeit auch einfach nur z.B. die 450 bzw. 0,45 zu erfassen, dafür dann aber per Markierung die Division zuzulassen.

Hier bin ich mir noch etwas unsicher wie man da am besten den Inputteil bzgl. des Faktors gestaltet, um den Baustein an der Stelle nicht zu überfrachten.

Es ist dann ja ein Eingangsparameter der je nach Modus recht verschiedenen Input erwartet (fachlich interpretiert zumindest).

Also da bin ich doch für Vorschläge offen.
Denn da braucht es gute Beschreibungstexte für diesen Eingang.


Hat sonst noch wer eine Variante an Input im Kopf die zu berücksichtigen wäre?
F)....

@AndererStefan
Konntest Du den Integral-Baustein jetzt noch weiter beobachten und tut das weiterhin was es soll?

so @gbglace Göran
mal ohne ki text

ist speicherbar

bitte testen




mfg
eib-eg

und jetzt werden meine projekte für dieses jahr mal weiter nach vorne gestellt
hm
das jahr ist ja nicht mehr lange

in diesem sinne noch einen guten rutsch

eib-eg hat geschrieben: ↑Mi Dez 31, 2025 12:25 am und jetzt werden meine projekte für dieses jahr mal weiter nach vorne gestellt

Ich wünsche gutes Gelingen!

Ab hier KI-Text: Dieser Beitrag entstand aus einer tiefgehenden Analyse von Schaltfehlern im Reallabor und der daraus abgeleiteten „Blackbox-Doktrin“ für den Timberwolf Kanon V7


Die „Blackbox“ für Custom Logiken: Ein neuer Standard für Diagnose und Transparenz?**

Hallo zusammen,

während der letzten Tage habe ich zusammen mit meinem „KI-Lehrling“ intensiv an der Integration meines Daly BMS und der AC-THOR Steuerung getüftelt. Dabei sind wir über ein Problem gestolpert, das vermutlich jeder kennt, der komplexe Logiken baut:

**Das „Warum-hat-er-das-getan?“-Rätsel.**

Man sieht im Grafana, dass ein Aktor geschaltet hat oder ein Zähler zurückgesetzt wurde, aber man kann im Nachhinein oft nicht mehr zweifelsfrei sagen, *welcher* Teil der Logik den Befehl gegeben hat. War es das Delta-T? War es der Sicherheits-Watchdog? Oder war gerade das Inhibit-Gate aktiv?

**Die Idee: Ein standardisiertes Status-Register (Integer-Output)**

Wir haben bei meinem „AC-THOR Transfer-Master“ testweise ein Status-Register eingeführt und in Grafana (als *Step After*) aufgezeichnet. Das Ergebnis war ein „Aha-Erlebnis“: Ein kurzer Blick auf die rote Linie im Diagramm genügte, um einen „Kaltstart-Fehler“ der Watchdogs sofort zu entlarven, ohne 80 interne Variablen prüfen zu müssen.

**Vorschlag zur Standardisierung (am Beispiel der „Göran-Edition“ Zähler-Statistik):**

Ich stelle mir vor, dass komplexe Logiken (wie Görans neuer Statistik-Monolith) einen additiven Status-Code ausgeben könnten. Ein einziger Integer-Wert liefert das komplette Logbuch:

1. **Die 10er Stellen (Betriebsmodus):** 10=Absolut, 20=Delta, 30=Impuls, 40=Leistung.
2. **Die 1er Stellen (Gate-Zustand):** +0=OK, +1=Inhibit aktiv, +2=Leerlauf.
3. **Die 100er Stellen (Ereignis-Blitze):** 100=15min-Reset, 300=Tages-Reset, 700=Jahres-Wechsel.
4. **Die 900er Stellen (Alarme):** 900=Wertabfall (Odometer), 999=Systemfehler.

**Der Vorteil:**
Wenn Göran 50 Instanzen seiner Logik laufen hat und in Grafana den Wert **41** sieht, weiß er sofort: „Modus Leistung (**40**), aber zählt gerade nicht, weil Inhibit (**1**) aktiv ist“. Eine Spitze auf **340** um Mitternacht beweist: „Tages-Reset (**300**) im Modus Leistung (**40**) erfolgreich gefeuert“.

**Meine Frage an euch:**
Macht es Sinn, so ein „Diagnose-Fenster“ als festen Bestandteil in unsere Kanon-Regeln für komplexe Logiken aufzunehmen? Würde das nicht auch den Support (z.B. für Mathias) massiv beschleunigen, wenn man bei Problemen einfach nur auf den Status-Code-Graphen schauen muss?

Ich bin gespannt auf eure Einschätzung!

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

Hallo Georg,

Ich habe den Zähler V1.42 aus #42 getestet. Der Zähler hat aber noch einen Fehler vermute ich. Bei Eingangs Modus 0 = Abs, also z.B. einfach der Zählerstand eines Stromzählers inkl. Korrekturwert durchreichen und dann hochzählen, rechnet der Baustein nicht die Differenz auf das Ergebnis sondern summiert jeden Zählerwert absolut… Hier einfach mal zwei Bilder, dass ist einfacher:





Da hat die KI wohl schon etwas viel vorgefeiert mit selbstgebrautem Strom oder so…

@CHD
Schaue ich mir an bzw wird erledigt wenn ich ä die ki die anderen 15 cods erledigt hat die noch aktuell erledigt werden müssen

Danke fürs testen

Und noch ein gesundes frohes neues

@CHD
ihr wisst
speicherbar
aber nicht getestet

Hier ist die offizielle Dokumentation für das „Schlachtschiff“ **V1.44 - Göran Edition**. Diese Beschreibung folgt exakt dem **StefanW-Standard ** und integriert die **Blackbox-Doktrin ** zur fehlerfreien Analyse.

***

### Katalog-Dokumentation: Universal-Zähler-Statistik PRO+ (V1.44)

**1. Titel**
Universal-Zähler-Statistik PRO+ (Göran Edition)

**2. Untertitel**
7-fache Perioden-Statistik mit W->kWh Integration, Tarif-Gate und Blackbox-Forensik.

**3. Zusatztext für das Verständnis (Die "Magie")**
Diese Logik ist der ultimative Energie-Buchhalter für den Timberwolf Server.
* **Präzisions-Integral:** Wandelt über ein „Alternating Stopwatch“-Pattern Leistungswerte (W) sekundengenau in Arbeit (kWh) um.
* **3-Sekunden-Regel:** Nutzt das gbglace-Timing (Sekunde 57), um Perioden-Abschlüsse sauber in der InfluxDB zu verankern, bevor der Zeitstempel umspringt.
* **Tarif-Gate:** Über den Inhibit-Eingang können Zählvorgänge (z.B. für HT/NT) pausiert werden, ohne die Zeit-Kaskade der Statistik zu unterbrechen.
* **Blackbox-Forensik:** Ein additiver Status-Code ermöglicht die lückenlose Rekonstruktion aller internen Schalt- und Reset-Ereignisse im Grafana.

**4. Kern-Module**
Clocksignal (Herzschlag), Stopwatch (Integral), CalcFormula (Mathematik), Cron (Reset-Timer), Localtime (Zeit-Referenz), Multiplexer & Latch (Speicher).

**5. Beschreibung Kern-Eingänge**

Name	Typ	Trigger	Beschreibung
Zählerwert / Leistung	float	a	Rohdaten (Zählerstand, Impulse oder Watt).
Eingangs-Modus	int	u	0=Absolut, 1=Delta, 2=Impuls, 3=Leistung(W).
Inhibit (Sperre)	bool	u	True = Zähler pausiert (Tarif-Umschaltung).

**6. Beschreibung Kern-Ausgänge (Auszug der 24 Objekte)**

Name	Typ	Sende-Verhalten	Beschreibung
Gesamtzählerstand	float	ct	Aktueller Stand inkl. manuellem Offset.
Verbrauch [Periode]	float	ct	Laufender Verbrauch (15m, 1h, Tag, ... Jahr).
[Periode] Vorher	float	c	Fixierter Endwert der letzten Periode.
Status-Code	int	c	**Blackbox-Diagnose (Zwingend aufzeichnen!)**

---

### Fehleranalyse: Aufschlüsselung des Status-Codes

Um die Logik im Grafana zu analysieren, muss der Ausgang **Status-Code** als **„Step After“** visualisiert werden. Der Wert ist additiv aufgebaut ($Ereignis + Modus + Gate$):

**A. Die 100er Stellen (Reset-Ereignisse - Kurze Blitze im Graph)**
* **100:** 15-Minuten-Reset hat gefeuert.
* **200:** Stunden-Reset hat gefeuert.
* **300:** Tages-Reset (Mitternacht) hat gefeuert.
* **400:** Wochen-Reset hat gefeuert.
* **500:** Monats-Reset hat gefeuert.
* **600:** Quartals-Reset hat gefeuert.
* **700:** Jahres-Reset hat gefeuert.

**B. Die 10er Stellen (Aktiver Betriebsmodus)**
* **10:** Modus 0 (Absolutwert / Odometer)
* **20:** Modus 1 (Delta-Häppchen)
* **30:** Modus 2 (Impuls-Zählung)
* **40:** Modus 3 (Leistungs-Integration W -> kWh)

**C. Die 1er Stellen (Gate-Zustand)**
* **+0:** Normalbetrieb (Tor offen, Daten fließen).
* **+1:** **Inhibit aktiv** (Tor zu, Zähler pausiert).

**D. Der Alarm-Bereich**
* **900:** **KRITISCH: Wertabfall erkannt!** (Zählerstand im Modus 0 ist gesunken).

**Beispiel für die Diagnose:**
Siehst du im Grafana den Wert **341**, bedeutet das: Es ist Mitternacht (**300**), die Logik arbeitet im Leistungs-Modus (**40**), aber der Zähler hat den Sprung nicht mitgenommen, weil das Inhibit-Gate (**1**) aktiv war.

***

Moin, das mit dem Diagnose-Objekt finde ich interessant.

Ich habe den Baustein noch nicht verbaut aber beim Code-Review sind mir folgende Sachen aufgefallen:

Die Offset-Behandlung kam mir da auch etwas komisch vor beim Durchlesen des Codes.
Auch hat die KI mir etwas viel Deutsch Englisch bei den Variablennamen vermischt.

Mit den zeitbasierten Modulen fällt es mir immer noch schwer das inhaltlich und ihre Wirkung zu verstehen.
Aber das Clocksignal muss da raus. Das hatte die KI auch früher immer eingebaut und jede Sekunde den Baustein getriggert zur Berechnung.
Das ergibt nur eine unnötige last auf dem System.

Die Stopwatch ist noch so ein unverstandener Baustein aber der könnte so Sinn ergeben, um das Delta der Zeitpunkte jetzt und letzter Logikdurchlauf zu ermitteln.

Auch die Beiden Outputs Error vs Zähler zählt Rückwärts konnte ich keinen sinnvollen Unterschied als solchen erkennen und würde vorerst auf die simple comparator-Regel setzen: Vorerst weil es da noch unberücksichtigte Entscheidungen gibt, dazu unten mehr.

Die Berechnung des Integrals:
Aktuell berechnet das Ding mit dem aktuell eintreffenden Leistungswert das Integral aus dem Zeitraum vom letzten Input bis jetzt.
Müsste das Ding aber nicht eigentlich wenn jetzt 5W kommt, das Integral aus der vergangen Zeit und dem damals zuletzt empfangenen Wert ( z.B. 4W) als neues Zählerstandsdelta berechnen? Und die 5W erst beim nächsten Inputsignal verwenden?



Die von Stefan @StefanW erwähnte Berücksichtigung eines inhibits zur temporären Aussetzung des Zählens bei der Verwendung als Tarifzähler, ist soweit berücksichtigt.

Eine analoge Berücksichtigung bei der Nutzung als getrennter Einspeise vs Bezugszählers funktioniert mit dem einfachen inhibit aber noch nicht ohne vorgeschaltete Logiken.

Gerade bei der Benutzung im Modus 3 ist da deutlich mehr zu berücksichtigen.

Denn ein Wechsel des Vorzeichens ist ja nicht unbedingt ein Fehler im Input. Aber in Anbetracht meines Kommentares zur Integralberechnung, wird es spannend.
Denn beim Szenario positive Leistung = Bezug und negative Leistung = Einspeisung und einer Abfolge T0 5W, T1 6W, T2 4W, T3 -8W, T4 -2W, T5 20W muss bei T3 die Berechnung des Integrals noch für den Bezugszähler erflogen, auch wenn zu T3 der Vorzeichenwechsel stattgefunden hat. Ab T4 erfolgt die Berücksichtigung dann zum Einspeisezähler, wo dann ein entsprechender inhibit zu setzen ist.

Da sind dann also im Modus3 noch mehr Werte zum vorherigen Logikdurchlauf abzugleichen und zu berücksichtigen.

Und ein solcher Betragswechsel darf dann natürlich keine Auswirkung auf den Ausgang Lgc_Found_Counter_Reset haben, da der eigentlich nur im Modus 0 erkannt werden kann.
Die Vorzeichen Wechsel bei Modus 1 und 3 sollten dann eher zu einem automatischen inhibit aber eher aus dem Gedanken Bezugs/Einspeise Zähler sein.

und da kommt man dann ggf auch auf den Gedanken das man entsprechend zwei Inputs benötigt um den Zähler als Bezugs/Einspeise Zähler und dazu noch zum Tarifxy zu definieren.

Man kann die Bildung des Integrals und die Zuordnung zum Tarif auch außerhalb des Bausteins separat machen, dann ist man bei einem reinen Baustein mit Modus 1 und liefert den inhibit gesamthaft mit rein.

Dann halt auch die Frage ob die Vorzeichenerkennung nur bei Mode 3 (Input muss integriert werden) oder auch bei Mode 1 (Anlieferung Zählerhäppchen) interessant ist. Wenn ja dann muss berücksichtigt werden das bei mode 3 dieser inhibit quasi erst zur Folgeberechnung wirkt im Mode 1 aber direkt beim Vorzeichenwechsel.

Vorzeichenwechsel beim reinen Impulseingang sehe ich da jetzt nicht. Oder kennt da jemand Zähler outputs die da sinnvoll zu berücksichtigen wären?

Zum Mode 2 Impuls Eingang, da wird aktuell der Eingansgwert direkt mit dem Impulsfaktor multipliziert und das dann als Zählerdelta berücksichtigt. das kann auch ganz komische Ergebnisse ergeben oder gewollt sein.
Wenn der Input nicht einfach nur 0/1 ist sondern ein beliebiger integer dann kann das ziemlich hohe Werte ergeben.
Da stellt sich mir die Frage, kommen da aus solchen Impulszählern immer nur irgendwelche Telegramme immer wenn da z.B. 100ml Regen oder 0,1m³ Gas erkannt wurden? Oder hat man da wirklich eher das Szenario da kommt nach konstanten x Zeiteinheiten entsprechende integer zahlen wie ne 5 für 0,5m³ Gas?
Ich hätte da jetzt gedacht, dass man da egal was ankommt, mit jedem Signal den Impulsfaktor nur mit 1 Multipliziert oder eben 1:1 aufaddiert. Aber wirklich nur bei einem Werteingang am Input, nicht zu den hinterlegten Cron-Signalen wie zu den bestimmten 3 Sekunden vor der viertel Stunde.

Ich sehe dann zwei Mögliche Berechnungswege: Das erste Latch wäre die Version ein Datenwert als input berücksichtigt genau den pulse-Faktor als Delta. (Enge Auslegung des Bausteins)
die anderen zwei Zeilen würden den Input als pulse interpretieren und erst einen Wert errechnen und den dann als Delta berücksichtigen.
beides geht, der Zweite muss dann aber einen saubereren Input bekommen.

Meinungen dazu?
Ich habe dazu noch keine Impulszähler angebunden, wäre dann aber glaube bei Version 1 der engen Auslegung, jedes Ping ergibt die per impuls-faktor definierte Menge an Delta Zählerstand.

Zur Debugausgabe:

Bei der Ausgabe des jeweilige erkannten Periodenendes muss man natürlich beachten das zum Jahresende bis auf das Wochenende auch alle anderen Periodenenden realisiert sein sollten, aber manchmal auch das Wochenende dazu.

Bei einer entsprechenden additiven Betrachtung und der damit einhergehenden Mehrfachnennung ist eine reine Addition der fixen Werte kein guter Ausgabewert. In reinen Zahlen müsste man dann Werte der Potenzen zu 2 aufaddieren um eindeutige Mehrfachtreffer identifizieren zu können.

0 : Dateninput-Trigger
1 : 15-Minuten-Trigger
2 : Stunden-Trigger
4 : Tages-Trigger (Mitternacht)
8 : Wochen-Trigger
16 : Monats-Trigger
32 : Quartals-Trigger
64 : Jahres-Trigger

Maximal kann das bei allen gleichzeitigen Triggern sich zu 127 aufaddieren.

Spannend sind dann aber auch im Hinblick auf die obigen weiteren Ausbaustufen zum Bezugs/Einspeisezähler und Tarifzähler, die möglichen inhibits die erkannt werden.

Da wären dann also gewollte Werte

128 : inhibit Input erhalten ( Tarifwechsel)
256 : Vorzeichenwechsel erkannt
512 : inhibit Bezugs/Einspeisezähler ermittelt ( je nach Modus ist das ja nicht in Periodengleich zum Vorzeichenwechsel)
1024 : Zähler Reset erkannt (kommt hoffentlich eher selten vor, wobei ich hier gerade auch Anwendungen habe die direkt in Wh messen und ausgeben aber das tgl. resetten OpenDTU)
2048 : Error

Damit landen wir dann bei insgesamt 4095 als maximale Statusmeldung basierend auf dynamische Werte.

Die eher statischen Merkmale wie der Eingangs-Modus und ob der Zähler sich selbständig bzgl. Vorzeichenwechsel (Bezug und Einspeisung) sperren soll. Sollten dann irgendwie anderweitig ausgegeben werden.

Durch eine andere Reihenfolge könnte man halt überlegen ob das eine bessere Optik in der Auswertung ergibt.

Die anderen Varianten sind additiv nicht überschneidungsfrei oder können keine Mehrfachergebnisse ausgeben.


Oder man gibt es nicht ganz nummerisch aus, und stellt stattdessen jeder Ausprägung ja nein eine Stelle zur Verfügung.
Das wäre dann bei der aktuellen Ausbaustufe ein 15 stelliger String der rauskommen würde, wenn man bei den Stellen für Modus nicht mit einem binären Output arbeiten würde.