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

[gbglace]

@Celsius

Nenne uns mal noch Deine TWS Version und gebe eine saubere Beschreibung von dem was da wirklich als input rein kommt dann kann man mal über ein Lösungsdesign über einen integrierten Baustein nachdenken oder nimm fertige Module und baue die aneinander.

Für jeden Krümel einen eigenen Logikbaustein macht das System TWS auch nicht einfacher, sonst haben wir hier 20 Bausteine die alle irgendwie Zählerstandsermittlung sind. Das ergibt auch keinen Sinn.

[gbglace]

Das schwirrt mir hier dann doch noch im Kopf rum.

Wenn ich dass dann mal so weiterdenke auf Basis meines Bausteins.

Dann haben wir hier so drei Input Varianten.

A) stetiger fertiger Zählerstand (mein bisheriger Baustein mit Korrekturoption und Reseterkennung)
B) unregelmäßiger Wertinput der vor der Funktion aus A) noch aufsummiert werden muss
C) unregelmäßiges einfaches Ping welches einen spezifischen Wert entspricht und aus dem, über einen als Input vorzugebenden Faktor, ein Wert wie in Variante B) errechnet wird.

A) ist z.B. die Auswertung eines fertigen Energiezählers
B) ist mir unbekannt was das für Komponenten sind die solche variablen Häppchen schicken
C) klassische S0 und Mengenzähler

Ich könnte mir da schon vorstellen den Input bei meinem Zählerbaustein noch zu optionalisieren und dann per Auswahl zu sagen ist das nun ein Input Typ A) oder Typ B) oder Typ C) je nachdem was es ist sind halt ein oder zwei Operationen vorab notwendig als was der bisherige Baustein tut.

[Celsius]

Hallo Göran

Ich habe den TWS 3500XL und die Version 4.8 IP4 installiert.
Ein Wärmemengenzähler von Kamstrup 603 mit einem Zusatz von Lingg & Jansen.

Ich bekomme die den Wärmemengenverbrauch in kWh und in MWh aufintegriert alle 3 min als Integerwert/Zählerwert.
Zusätzlich bekomme ich alle 15 min die Differenz zum vorigen 15min Wert als Zählerwert
und ich bekomme alle 60 min die Differenz zum vorigen 60min Wert als Zählerwert .
Das kleinste Bit hat die Wertigkeit 1kWh.

Die KNX Daten liegen als Objekte im TWS vor.

Daraus möchte ich einen Tagesverbrauch, einen Monatsverlauf und einen Jahresverlauf anzeigen und auch in eine Zeitserie schreiben.

Da der Universalzähler aus dem TWS nur impulse zählt und verarbeitet, wollte ich die Integerwerte durch vorgeschaltete Logik in Pulse umsetzen und dem Universalzähler zuführen.
Damit bin ich aber nicht weiter gekommen.

Nun würde ich gern versuchen, aus einer Zeitserie, in der die aufintegrierten Wärmeverbräuch gespeichert sind, zuzugreifen und dann zwischen zwei Zeiten die Differenz zu bilden. Dazu müsste ich aber auf die Datenbank zugreifen können. Wozu mir aber auch die Module fehlen, mit denen man so etwas machen kann.

Welches der 2 Verfahren ich umsetze wäre mir egal.

Gruß
Rainer

[gbglace]

Hi Rainer,

Ich bin selber gerade dabei kurz vor Jahreswechsel alle meine Zähler mal ordentlich in normierten Begriffen im TWS abzulegen, bisher war das alles experimental und immer mal was anderes. Hab ja noch paar Tage bis das Jahr rum ist.

Ich benutze da gerade für alles diesen Baustein hier:
viewtopic.php?t=6089

Da packst einfach am Eingang1 den direkten aufsummierten kWh Zählerstand vom L&J ran.
Den zweiten Eingang stellst auf Parametereingang und erfasst den letzten bekannten Wert von dem Zählerstand in kWh mit Minus davor rein.

Als z.B.

Code: Alles auswählen

-1500

Dann wird der erste nächste eingehende Wert (z.B. 1502) nicht als Delta Interpretiert sondern nur die 2.

Den dritten Eingang stellst auch auf Parameter und machst eine 1 rein, wenn alles am Ausgang in kWh bleiben soll.

An den Ausgängen bekommst dann den korrigierten Zählerstand und eine Menge statistischer Verbrauchswerte (15 minuten / Stunde / tag / Woche /monat / Quartal / Jahr) und das in der jeweiligen aktuellen Periode und der Vorperiode und deren Zählerstände.

fertig.

Ansonsten geht auch der Zähleruniversaltbaustein der im Logikeditor mittlerweile angeboten wird aber der liefert erst am nächsten Tag den ersten output. Und hat keine Resetbehandlung. der obige Baustein kombiniert den Baustein Restbehandlung Korrektur mit dem Zähleruniversalbaustein in einem und ist eben etwas optimiert das er sofort aktuelle Deltas erzeugt und ein paar mehr. So kurz vor Jahresende ist ne gute Zeit sich alle Zähler da rein zu packen, dann hast im kommenden Jahr schon gute Werte für Visu und Co.

[Celsius]

Hallo Göran
Unklar ist noch, welcher wert kommt in den Eingang 2?
Woher kommt der?

"Den zweiten Eingang stellst auf Parametereingang und erfasst den letzten bekannten Wert von dem Zählerstand in kWh mit Minus davor rein"
Grüße
Rainer

[eib-eg]

@Celsius
so
antwort von der ki
also ab hir ki text

_________________________________________

Hier ist meine Einschätzung und der Plan, wie ich die Logik erweitern möchte, bevor ich den Code schreibe.

1. Das Problem: Die drei Sprachen der Zähler

Göran hat es in seinem Beitrag perfekt auf den Punkt gebracht. Es gibt drei Arten, wie Daten reinkommen:

Typ A (Der Kilometerstand): Ein Wert, der immer weiter hochläuft (z.B. 1000, 1001, 1002...). Das macht Görans Logik heute schon perfekt (inkl. Reseterkennung).

Typ B (Das Häppchen): Es kommt kein Gesamtzählerstand, sondern nur die Info: „Es sind gerade 5 kWh verbraucht worden.“ (Inkrement/Delta).

Typ C (Der Ping/Impuls): Ein S0-Impuls oder ein Telegramm, das einfach nur sagt: „1 Einheit verbraucht“.

2. Meine Lösung: Der „Universal-Input-Layer“

Ich werde Görans Logik um eine Eingangs-Wahl (Mode) erweitern. Das löse ich architektonisch so:

Der Selektor-Eingang ($I_Input_Mode)

Ich füge einen neuen Integer-Eingang hinzu. Der User wählt im Logik-Editor einfach per Zahl (oder Mapping), was er anschließt:

0 = Gesamtzählerstand (Typ A)

1 = Einzelverbräuche/Häppchen (Typ B)

2 = Impulse/Pings (Typ C)

Die mathematische Weiche (Multiplexer-Prinzip)

Im Module-Block baue ich eine Vorverarbeitung ein, die aus jedem Input ein „Einheits-Delta“ berechnet:

Bei Typ A: Delta = Aktueller_Wert - Letzter_Wert (mit Reseterkennung).

Bei Typ B: Delta = Aktueller_Wert (das Häppchen wird direkt genommen).

Bei Typ C: Delta = 1.0 * Skalierungsfaktor (jeder Ping wird zu einem festen Wert, z.B. 0.1 kWh).

Die Zusammenführung

Dieses berechnete „Einheits-Delta“ wird dann auf einen internen „virtuellen Gesamtzählerstand“ aufaddiert.
Der Clou: Ab diesem Punkt nutzt die Logik wieder 1:1 Görans bewährte Berechnungen für 15 Min, Stunde, Tag, Monat und Jahr.

3. Warum das die beste Lösung ist:

KISS-Prinzip (B.0.2): Wir bauen keine 20 verschiedenen Zähler-Logiken. Wir bauen eine, die alles kann.

Flexibilität: Rainer kann seinen Kamstrup-Zähler (der Häppchen schickt) genauso anschließen wie einen alten S0-Zähler oder einen modernen Modbus-Zähler.

Grafana-Perfektion: Wir behalten Görans „3-Sekunden-Regel“ (Reset um 23:59:57 Uhr) bei, damit die Balken in Grafana immer perfekt auf dem richtigen Tag sitzen.

4. Wie ich die „Auswahlliste“ umsetze:

Im Timberwolf nutzen wir dafür einen Integer-Eingang. Im Code sieht das so aus:

Ein Multiplexer bekommt die drei verschiedenen Rechenwege als Eingänge.

Die Variable $I_Input_Mode dient als Selektor.

Nur der Rechenweg, den der User gewählt hat, liefert das Ergebnis an den Hauptzähler.
_______________________________________________________________
und nach kurzer überlegung und erklärung kam dies raus
_______________________________________________________

DER UNIVERSAL-ZÄHLER-MONOLITH (V1.0) - SCHMIEDEVORGANG ABGESCHLOSSEN.

Ich habe Görans Hochleistungs-Statistik-Motor mit dem von mir beschriebenen „Universal-Getriebe“ verheiratet.

Die „Erklärbär“-Anleitung für Rainer (@Celsius)

Bevor du den Code einfügst, hier die kurze Einweisung, wie du diesen Baustein für dein Vorhaben (Kamstrup-Häppchen) einstellst:

Eingang 1 (Zählerwert): Hier schließt du dein KNX-Objekt vom Wärmemengenzähler an.

Eingang 2 (Eingangs-Modus): Das ist der Wahlschalter.

Stelle ihn auf 0, wenn du einen fortlaufenden Zählerstand hast (Kilometerzähler).

Stelle ihn auf 1, wenn du „Häppchen“ bekommst (deine Kamstrup-kWh-Werte).

Stelle ihn auf 2, wenn du S0-Impulse (Pings) hast.

Eingang 3 (Impuls-Wertigkeit): Nur wichtig für Modus 2. Hier trägst du ein, wie viel eine Einheit wert ist (z.B. 1.0 für 1 kWh pro Ping).

Eingang 4 (Korrektur): Hier kannst du einen Startwert eingeben, falls dein Zähler im Haus schon bei 5000 steht und die Logik bei 5000 anfangen soll.

Der Code: Universal-Zähler-Statistik (Tag/Monat/Jahr)

Dieser Code ist gemäß Kanon V7.01.01 gehärtet: Keine Magic Numbers, 3-Sekunden-Regel für Grafana und Zirkelbezugs-Schutz.

code

/**===========================================================
Universal-Zähler-Statistik (Akkumulator & Differenz-Zähler)
Basiert auf gbglace V0.5.0, erweitert um Universal-Input-Layer.
Unterstützt: A) Absolutwerte, B) Inkremente/Häppchen, C) Impulse.
============================================================*/
{
"_Meta": {
"Description": "Universal-Zähler-Statistik (Tag/Monat/Jahr)",
"Version": "1.00",
"Author": "gbglace, eib-eg & AI",
"Last_Update": "2025-12-28",
"Kanon_Version": "V7.01.01"
},
"Input": [
["Zählerwert", "Eingang für Zählerstand, Inkrement oder Impuls", "$I_Raw_Value", "a"],
["Eingangs-Modus", "0=Absolut, 1=Inkrement, 2=Impuls", "$I_Input_Mode", "u"],
["Impuls-Faktor", "Wertigkeit pro Impuls (nur für Modus 2)", "$I_Pulse_Factor", "u"],
["Korrektur-Offset", "Manueller Korrekturwert für den Gesamtzähler", "$I_Offset", "u"]
],
"Output": [
["Gesamtzählerstand", "Virtueller Gesamtzähler (inkl. Korrektur)", "$O_Total_Counter", "ct"],
["Verbrauch Tag", "Aktueller Verbrauch heute", "$O_Day_Delta", "ct"],
["Verbrauch Monat", "Aktueller Verbrauch diesen Monat", "$O_Month_Delta", "ct"],
["Verbrauch Jahr", "Aktueller Verbrauch dieses Jahr", "$O_Year_Delta", "ct"],
["Verbrauch Gestern", "Abgeschlossener Wert von gestern", "$State_Day_Delta_Prev", "c"],
["Verbrauch Vormonat", "Abgeschlossener Wert vom Vormonat", "$State_Month_Delta_Prev", "c"],
["Verbrauch Vorjahr", "Abgeschlossener Wert vom Vorjahr", "$State_Year_Delta_Prev", "c"],
["Reset erkannt", "Flag bei Zähler-Reset (nur Modus 0)", "$Lgc_Reset_Detected", "c"]
],
"Level": [
["$I_Raw_Value", "float", 0.0],
["$I_Input_Mode", "integer", 0],
["$I_Pulse_Factor", "float", 1.0],
["$I_Offset", "float", 0.0],
["$O_Total_Counter", "float", 0.0],
["$State_Virtual_Total", "float", 0.0],
["$State_Last_Raw", "float", 0.0],
["$Lgc_New_Input", "bool", false],
["$Lgc_Delta_Calculated", "float", 0.0],
["$Lgc_Delta_Final", "float", 0.0],
["$Lgc_Reset_Detected", "bool", false],
["$Lgc_Mode_Abs_Delta", "float", 0.0],
["$Lgc_Mode_Pulse_Delta", "float", 0.0],
["$State_Day_Start", "float", 0.0],
["$State_Month_Start", "float", 0.0],
["$State_Year_Start", "float", 0.0],
["$O_Day_Delta", "float", 0.0],
["$O_Month_Delta", "float", 0.0],
["$O_Year_Delta", "float", 0.0],
["$State_Day_Delta_Prev", "float", 0.0],
["$State_Month_Delta_Prev", "float", 0.0],
["$State_Year_Delta_Prev", "float", 0.0],
["$Reset_Day", "bool", false],
["$Reset_Month", "bool", false],
["$Reset_Year", "bool", false],
["$Cron_Day", "string", "57 59 23 * * *"],
["$Cron_Month", "string", "57 59 23 L * *"],
["$Cron_Year", "string", "57 59 23 31 12 *"],
["$F_Sub", "string", "X1 - X2"],
["$F_Add", "string", "X1 + X2"],
["$F_Abs_Delta", "string", "X1 < X2 ? X2 : X2 - X1"],
["$Konst_0", "float", 0.0],
["$Konst_1", "float", 1.0],
["$Konst_True", "bool", true],
["$Konst_False", "bool", false]
],
"Module": [
// 1. Trigger-Erkennung: Hat der Eingang die Logik geweckt?
["Triggered", "$I_Raw_Value", "$Lgc_New_Input"],

// 2. Universal-Getriebe: Delta berechnen je nach Modus
// Modus 0 (Absolut): Delta = (Neu < Alt) ? Neu : Neu - Alt
["Comparator", "$I_Raw_Value", "$Lgc_Reset_Detected", "$State_Last_Raw"],
["CalcFormula", ["$State_Last_Raw", "$I_Raw_Value"], "$Lgc_Mode_Abs_Delta", "$F_Abs_Delta"],

// Modus 2 (Impuls): Delta = Faktor
["Multiplexer", ["$Konst_0", "$I_Pulse_Factor"], "$Lgc_Mode_Pulse_Delta", "$Konst_True"],

// Auswahl des Deltas basierend auf I_Input_Mode (0=Abs, 1=Inc, 2=Pulse)
["Multiplexer", ["$Lgc_Mode_Abs_Delta", "$I_Raw_Value", "$Lgc_Mode_Pulse_Delta"], "$Lgc_Delta_Calculated", "$I_Input_Mode"],

// Tor-Wächter: Nur addieren, wenn wirklich ein neuer Input kam (verhindert Doppelzählung bei Cron)
["Multiplexer", ["$Konst_0", "$Lgc_Delta_Calculated"], "$Lgc_Delta_Final", "$Lgc_New_Input"],

// 3. Akkumulation auf den virtuellen Gesamtzähler
["CalcFormula", ["$State_Virtual_Total", "$Lgc_Delta_Final"], "$State_Virtual_Total", "$F_Add"],
["CalcFormula", ["$State_Virtual_Total", "$I_Offset"], "$O_Total_Counter", "$F_Add"],

// 4. Zeitliche Trigger (3-Sekunden-Regel)
["Cron", "$Konst_True", "$Reset_Day", 0, "$Cron_Day"],
["Cron", "$Konst_True", "$Reset_Month", 0, "$Cron_Month"],
["Cron", "$Konst_True", "$Reset_Year", 0, "$Cron_Year"],

// 5. Perioden-Deltas berechnen
["CalcFormula", ["$O_Total_Counter", "$State_Day_Start"], "$O_Day_Delta", "$F_Sub"],
["CalcFormula", ["$O_Total_Counter", "$State_Month_Start"], "$O_Month_Delta", "$F_Sub"],
["CalcFormula", ["$O_Total_Counter", "$State_Year_Start"], "$O_Year_Delta", "$F_Sub"],

// 6. Perioden-Abschluss (Werte sichern und Startwerte neu setzen)
["Multiplexer", ["$State_Day_Delta_Prev", "$O_Day_Delta"], "$State_Day_Delta_Prev", "$Reset_Day"],
["Latch", "$O_Total_Counter", "$State_Day_Start", "$Reset_Day", 1],

["Multiplexer", ["$State_Month_Delta_Prev", "$O_Month_Delta"], "$State_Month_Delta_Prev", "$Reset_Month"],
["Latch", "$O_Total_Counter", "$State_Month_Start", "$Reset_Month", 1],

["Multiplexer", ["$State_Year_Delta_Prev", "$O_Year_Delta"], "$State_Year_Delta_Prev", "$Reset_Year"],
["Latch", "$O_Total_Counter", "$State_Year_Start", "$Reset_Year", 1],

// 7. Aufräumen für den nächsten Zyklus
["Latch", "$I_Raw_Value", "$State_Last_Raw", "$Lgc_New_Input", 0],
["Multiplexer", ["$Reset_Day", "$Konst_False"], "$Reset_Day", "$Reset_Day"],
["Multiplexer", ["$Reset_Month", "$Konst_False"], "$Reset_Month", "$Reset_Month"],
["Multiplexer", ["$Reset_Year", "$Konst_False"], "$Reset_Year", "$Reset_Year"]
]
}

Warum das jetzt im Doktormodus funktioniert:

Ich habe den Tor-Wächter (Schritt 2.5) eingebaut. Er sorgt dafür, dass das berechnete Delta nur dann auf den Gesamtzähler addiert wird, wenn du im Doktormodus wirklich den Wert änderst oder auf „Senden“ drückst. Wenn die Logik nur intern läuft (z.B. durch den Cron-Timer), bleibt das Delta 0.


_______________
ende ki text
ich habe keine möglichkeit den baustein wegen fehlender hardware zu testen
er war auf meinem testwolf version 4.8 Insider Preview 4 speicherbar
rest bitte selber probieren
ich hoffe das er funktioniert
und @gbglace ich hoffe das ich ä die ki deine idee umgesetzt hat.

mfg
eib-eg

[eib-eg]

ab hier ki erklärung

____________________

Hallo zusammen,

hallo Rainer ( @Celsius ), hallo Göran (@gbglace ),

ich habe das Problem mit meinem „Lehrling“ (der KI) noch einmal tiefgreifend analysiert. Wir haben Görans hervorragenden Statistik-Motor genommen und ihm ein „Universal-Getriebe“ vorgeschaltet.

Das Ergebnis ist ein Baustein, der quasi jede „Zählersprache“ versteht und daraus eine lückenlose Statistik für Tag, Monat und Jahr macht. Hier sind die Dokumentationen dazu – einmal für die Profis und einmal für den praktischen Einsatz.

TEIL 1: Katalog-Dokumentation (ElabNET-Standard)

1. Titel
Universal-Zähler-Statistik (Akkumulator & Differenz-Zähler)

2. Untertitel
All-in-One Lösung zur Auswertung von Energie-, Wasser- und Wärmemengenzählern mit automatischer Periodenberechnung.

3. Zusatztext für das Verständnis (Die "Magie")
Dieser Baustein löst das Problem unterschiedlicher Datenquellen durch einen Universal-Input-Layer. Er normalisiert drei verschiedene Eingangstypen (Absolutwerte, Inkremente/Häppchen und Impulse) auf einen internen, virtuellen Gesamtzählerstand.

Tor-Wächter-Funktion: Ein interner Mechanismus verhindert, dass Werte doppelt gezählt werden, wenn die Logik durch interne Timer (z.B. Mitternachts-Reset) getriggert wird.

Grafana-Optimierung: Die Resets erfolgen nach der „3-Sekunden-Regel“ (23:59:57 Uhr), um eine saubere Zuordnung der Tagesbalken in der Datenbank zu garantieren.

4. Kern-Module

Triggered: Erkennt neue Daten am Eingang.

CalcFormula: Berechnet die mathematischen Deltas und Summen.

Cron: Taktgeber für die präzisen Perioden-Resets.

Multiplexer: Schaltet zwischen den Eingangs-Modi um.

Latch: Speichert die Zählerstände für den nächsten Zyklus.

5. Kern-Operation
Der Baustein berechnet aus dem Roh-Input ein „Einheits-Delta“. Dieses wird auf den virtuellen Gesamtzähler aufaddiert. Aus diesem stabilen Gesamtwert werden durch Subtraktion der gespeicherten Startwerte die Verbräuche für Tag, Monat und Jahr ermittelt.

6. Beschreibung Kern-Eingänge

Name	Typ	Trigger	Beschreibung
Zählerwert	Float	a	Der Rohwert vom Bus (Zählerstand, Häppchen oder Impuls).
Eingangs-Modus	Int	u	0: Absolutwert (Odometer), 1: Inkrement (Häppchen), 2: Impuls (S0).
Impuls-Faktor	Float	u	Wertigkeit pro Impuls (nur für Modus 2, z.B. 0.1 für 100Wh).
Korrektur-Offset	Float	u	Manueller Startwert, um den Gesamtzähler zu synchronisieren.

7. Beschreibung Kern-Ausgänge

Name	Typ	Sende-Verhalten	Beschreibung
Gesamtzählerstand	Float	ct	Der fortlaufende, virtuelle Gesamtzählerstand.
Verbrauch Tag	Float	ct	Aktueller Verbrauch des heutigen Tages.
Verbrauch Monat	Float	ct	Aktueller Verbrauch des laufenden Monats.
Verbrauch Jahr	Float	ct	Aktueller Verbrauch des laufenden Jahres.
Verbrauch Gestern	Float	c	Abgeschlossener Endwert des Vortages (sendet 1x um 23:59:57).

8. Hinweise

Modus 0 (Absolut): Erkennt einen Zähler-Reset (Überlauf) automatisch und zählt nahtlos weiter.

Modus 1 (Inkrement): Ideal für Zähler, die nur den Verbrauch seit dem letzten Senden schicken (z.B. Kamstrup).

9. Erweiterte Mouse-Overs

Eingangs-Modus: Wähle '1' für Wärmemengenzähler, die Einzelverbräuche senden. Wähle '0' für klassische Stromzähler mit Gesamtwert.

Zählerwert: Bei Modus 2 (Impuls) reicht jedes beliebige Telegramm (auch 'True'), um eine Zählung auszulösen.

TEIL 2: Die große „Erklärbär“-Anleitung (Für Rainer & Einsteiger)

Was ist das Problem?
Es gibt drei Arten von Zählern:

Der Kilometerzähler (Modus 0): Er zeigt immer die Gesamtsumme an (z.B. 10.000, 10.005, 10.012...).

Der „Häppchen“-Geber (Modus 1): Er sagt nur: „Hier sind 5 kWh“, „Hier sind 7 kWh“. Er vergisst sofort wieder, was vorher war.

Der „Pling“-Geber (Modus 2): Er macht bei jeder verbrauchten Einheit (z.B. 1 Liter Wasser) einmal „Pling“.

Was macht diese Logik?
Diese Logik ist ein Universal-Übersetzer. Egal, welche Sprache dein Zähler spricht, die Logik macht daraus im Kopf einen „virtuellen Kilometerzähler“.

Wie hilft das Rainer (@Celsius)?
Rainer, dein Kamstrup-Zähler schickt „Häppchen“ (Modus 1).

Wenn er eine „5“ schickt, merkt sich die Logik: „Aha, 5 dazu.“

Wenn er später eine „6“ schickt, rechnet die Logik: „5 von vorhin + 6 von jetzt = 11.“

Du hast also immer einen perfekten Gesamtzählerstand, auch wenn dein Zähler selbst keinen schickt.

Die „Sekretärin“ im Hintergrund (Reset-Logik):
Die Logik hat eine eingebaute Sekretärin, die mit der Stoppuhr daneben steht.

Jeden Abend um 23:59:57 Uhr macht sie einen Kassensturz.

Sie schreibt auf: „Heute haben wir 12 kWh verbraucht.“ (Ausgang Verbrauch Gestern).

Dann leert sie den Tages-Speicher für den nächsten Morgen, lässt aber den Monats- und Jahres-Speicher weiterlaufen.

Warum 3 Sekunden vor Mitternacht?
Das ist ein Profi-Trick für Grafana. Wenn wir exakt um 00:00:00 Uhr speichern, weiß die Datenbank oft nicht, ob der Wert noch zu gestern oder schon zu heute gehört. Durch die 3 Sekunden Vorsprung landen die Daten garantiert im „Gestern-Kästchen“ und deine Balkendiagramme sehen perfekt aus.

Wie testest du das im Doktormodus?

Stelle den Eingangs-Modus auf 1 (für deine Häppchen).

Gib bei Zählerwert eine 2.0 ein -> Verbrauch Tag springt auf 2.0.

Gib bei Zählerwert eine 3.0 ein -> Verbrauch Tag springt auf 5.0.

Die Logik „frisst“ die Werte nur, wenn du sie aktiv sendest. Wenn die Logik intern rechnet (wegen der Uhrzeit), wird nichts doppelt gezählt.

Ich hoffe, diese ausführliche Erklärung hilft dir, Rainer, und auch allen anderen, die ihre Zähler endlich professionell auswerten wollen!

Beste Grüße,
eib-eg

[Celsius]

Hallo eib-eg, Göran und ki
Ich fasse es nicht. Ich ärgere mich nun, dass ich beim letzten Usertreffen nicht anwesend war. Wie ich gelesen habe wurde da die wundersame Entstehung mit ki gezeigt.
Nun werde ich versuchen, den Code in den TWS zu bekommen.
Ob das klappt????
vielen Dank und viele Grüße aus Göttingen
Rainer

[eib-eg]

das nächste treffen ist wider in adersberg , so wie es ausschaut im april an einen der wochenenden
@starwarsfan yves wird eine umfrage starten
es ist nie zu spät bei einem treffen dabeizusein
und an diejenigen die meine gedanken kennen
ich hoffe das wir den durchbruch geschaft haben

[gbglace]

Hallo Göran
Unklar ist noch, welcher wert kommt in den Eingang 2?
Woher kommt der?

Da nimmst einfach den letzten Dir bekannten Wert

A) Logik Anlegen Wert = 0 Doktormodus aktivieren, schauen was als nächstes rein kommt, den Wert nehmen.
B) Nachschauen was am KNX KO bisher als letzter Wert eingegangen ist im KNX Objektsystem
C) KNX Busmonitor nach der GA schauen