Um das bei manueller Eingabe einigermaßen realistisch zu gestalten, müßtest du wahrscheinlich den Startwert am 01.06. entsprechend des durchschnittlichen Tagesverbrauchs schätzen und eintragen. Wenn du nur den Wert vom 25.05. überträgst, würdest du die 6 letzten Tage im Mai verbauchstechnisch "unterschlagen" und statt im Mai dem Juni hinzuschlagen.
Naja, es bleibt ein Kompromiß.
Natürlich bleibt es ein Kompromiss. Es hätte ja auch sein können, dass für den Fall, bei dem für den Monatsbeginn kein Wert vorhanden ist, man auf den letzten verfügbaren zurückgreifen würde. Aber das in Deinem Modul mit einzubringen macht nun wirklich keinen Sinn. Möglicherweise gibt es ja irgendwann Smart Meter flächendeckend oder ich muss mich um eine lokale Lösung kümmern.
Aber das ist dann auch eine wichtige Information für die Handhabung mit dem reduceLog im DBLog. Ausdünnen darf man, nur sollte dabei der erste und der letzte Wert im Monat stehenbleiben.
Aber nehmen wir mal folgende Situation:
2016-08-05_01-18-36__elektrische.Energie 621.81 2016-08-09 22:52:41
2016-08-05_03-23-35__elektrische.Energie 622.00 2016-08-09 22:52:41
Aus mir nicht erklärbaren Gründen wurden hier ein paar Zwischenwerte nicht gesendet; möglicherweise eine Störung im D-LAN. Das hätte natürlich auch zwischen dem 31.x. gegen 23:55 und dem 01.y. gegen 2:30 passieren können. Davon ausgehend dass das angeschlossene Gerät etwas konsumfreudiger bezüglich er elektrischen Energie ist, könnten so 1-2 kWh verloren gehen. Demnach würde ich Pauschal immer den letzten Monatswert als Anfangswert des kommenden Monats nehmen.
Das könnte man aber auch mit einem at Befehl in Kombination mit addLog lösen, der dann immer zum 1. eines Monats den aktuellen Wert in die DB schreibt. Mal sehen was das "Use perl function for timespec" da so bietet.
