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

[gbglace]

Eingangs Modus 0 Absolut ist ein fertiger Zählerstand der geprüft wird und bestenfalls durchgereicht wird.

Du beschreibst eher einen Impuls Zähler das ist Modus 2, insofern sind alle Werte unplausibel die da rauskommen.

[Celsius]

Das wollte ich auch so. Modus 0. Der Zählerstand soll durchgereicht werden. Ich was der Meinung, dass aus dem absoluten Zählerstand dann die Perioden gerechnet werden.
Gruß
Rainer

[Celsius]

Hallo Göran
Ich habe bewußt den Modus 0 eingegeben und am Eingangs-Rohwert liegt der vom Zähler kommende Absolutwert an, also alles wwas bis heute gezählt wurde. Wenn ich eure Beschreibungen richtig gelesen habe, dann habe ich den richtigen Modus, "0" eingetragen.

Eingangs Modus 0 Absolut ist ein fertiger Zählerstand der geprüft wird und bestenfalls durchgereicht wird.

Du beschreibst eher einen Impuls Zähler das ist Modus 2, insofern sind alle Werte unplausibel die da rauskommen.

Die Frage ist, ob ich noch weiter testen soll, oder warten, bis eine fertige Version vorliegt.

Gruß Rainer

[gbglace]

Ich habe da derzeit auch einige solcher Bausteine am Laufen und kann da derzeit keine Probleme sehen.

Hast Du da öfters Reset Erscheinungen im Zeitablauf?

[Celsius]

Reseterscheinungen sind mir bisher nicht aufgefallen.
Gibt es irgendwelche Debugmöglichkeiten, um den Ablauf nachzuverfolgen?
Grafana nutze ich schon. den Doctor Modus auch.

[gbglace]

Es hat ja das Debug Ausgangs-Objekt, da steht quasi zu jeder Berechnung welche Sondererscheinungen er durchführt. Das solltest mal in eine TS packen. Dann siehst da recht genau ob es resets und der gleichen gibt.

Ich bin die Tage nur per mobilen Geräten am TWs da ist es nicht so gut den code zu bearbeiten, dauert noch ein paar tage bis ich da wieder zu Hause am Rechner bin.

[gbglace]

Habe mir nochmal Deinen letzten Beitrag mit den Werten und Screenshot angeschaut.

Du hast immer noch eine falsche Erwartung an die drei Werte.

Zählerstand Vorperiode ist der Endstand des Zählers zum Ende der Vorperiode. Also aktueller Zählerstand - Zähler Vorperiode = Delta aktuelle Periode.

Die Erwartung das dieser Wert also bei 15 Minuten nur kleine einstellige Zahlen hat ist falsch. Diese kleinen Zahlen gibt es nur in den beiden Delta-Spalten.

Und dieser Wert Zählerstand Vorperiode kann erst nach Ablauf einer solchen Periode gefüllt sein.

Wenn die Datenquelle eher selten Werte sendet kann der Wert auch im 15-Minuten und Stundenbereich identisch zum aktuellen Zählerstand sein. Und natürlich auch in den größeren Perioden, sofern der Periodenwechsel gerade erst gewesen ist.

In dem letzten Screenshot kann ich da auch noch keine Fehler entdecken. Letzter Wert am Eingang sind 887, das findet sich an den beiden Werten aktueller Zählerstand. Gab also nix zu skalieren und nicht per offset zu verschieben und einen Reset scheint es auch nicht gegeben zu haben. Ob das alles stimmt musst mit der Aufzeichnung des Debug-Objektes klären.

Dann stehen auch die beiden Werte Zählerstand Vorperiode 15 Minute und Stunde auf 887. das sagt mir das es im Laufe der angebrochenen Stunde und angebrochenen 15 Minuten noch keinen angestiegenen Zählerstand gibt. Deswegen sind auch die beiden Werte Delta_Aktuell = 0. Die beiden Werte Delta_Vorperiode sind für 15_Minuten und Stunde auch 0, das bedeutet das auch für mehr als eine Stunde kein neuer inputwert geliefert wurde. Ob das stimmt kannst auch nur über die TS klären ob da wirklich so lange keinen neune Werte geliefert wurden. Das können wir hier nicht beurteilen.

Erst auf Tagessicht wird es bunter. Da ist jetzt die Anzeige in dem Screenshot undeutlich aber wenn das 866 bei Zählerstand Vorperiode Tag steht, dann passt das zu dem Delta Aktuell des Tages mit 21, denn 866 + 21 = 887. Die 37 in Delta Vorperiode sind halt was gestern als Delta angekommen ist. Ob das stimmt musst in der TS prüfen. Da muss es also gestern 0:00 Uhr 866-37 als Zählerstand Aktuell gegeben haben um mit einem Delta von 37 auf 866 zu landen.

Und da bei den Perioden Woche, Monat, Quartal, Jahr nur die aktuellen 887 als Delta Aktuell erscheinen ist das alles korrekt.
Da wird der Baustein im Laufe der Woche das letzte mal neu gespeichert worden sein. einmal auf Diskette drücken ist bei diesen Bausteinen eben ein Totalverlust und kompletter neuer Zähler.
Wenn Du die Delta 887 nicht als Jahreswert im Januar 2026 sehen möchtest (kann ich nachvollziehen) dann musst halt mal genauer abschätzen was war denn am 1.1.2026 um 0:00 Uhr der reale Zählerstand und diesen als -xxx im Offset eintragen.

Deswegen meinte ich ja es bot sich an den Baustein noch in den letzten Tagen Dezember zu aktivieren und ggf einfach die TS, um alle Einträge aus 2025 zu bereinigen.

Um, jetzt oder später in einem laufenden Jahr, sich mit der Inbetriebnahme eines solchen Logikbausteines, zu einem schon 5 Jahre alten technischen Zähler, keinen absurden Verbrauch in den ersten jeweiligen Periodenzyklen zu bauen, kann der Offset Betrag verwendet werden.
Für einen recht konsistenten Start bietet es sich dann natürlich an, den Offset direkt innerhalb der ersten 15 Minuten nach Aktivierung des Logikbausteines zu setzen.


Bzgl. des Missverständnisses was der Wert Zählerstand Vorperiode meint, wo in meinen Beschreibungen zum Baustein, hast Du das rausgelesen, dass dort jeweils nur ein so kleiner Wert bei den 15 Minuten / Stunden stehen sollte?


Und zum besseren Verständnis, was für ein Zähler ist das, das der offensichtlich nicht unbedingt sehr gleichverteilt über den Tag Verbrauch registriert?

[CHD]

Also ich habe bei mir zwei Zähler mit dem Stand V1.50 RC1 im Modus 0 laufen und einen auch noch mal verglichen mit dem bei mir parallel laufenden Zähler Universalbaustein V6 von Robosoc. Das scheint mir schon so korrekt in den neuen Zählern zu rechnen. Und damit ich nicht die Diskette drücken muss, habe ich auch nicht auf RC2 geupdated - ist für diesen Modus ja nicht relevant.