Gut's Nächtle allerseits,
habe seit ein paar Wochen eine neue Viessmann-Heizung.
Deren Mobile-App ist für meine Zwecke zum 'kleinen Einstellen zwischendurch' suppi zu gebrauchen.
Aber: ich möchte gerne in mein FTUI eine Grafik einbauen, die langfristig den zeitlichen Verlauf der Aussentemperatur und den jeweils gestrigen Gesamt-Tages-Verbrauch in Kilowatt darstellt.
Dazu habe ich im installierten Modul "Vitoconnect" folgende Attribute eingebaut:
DbLoginclude .*(Aussentemperatur|Gasverbrauch_gestern)
userReadings Gasverbrauch_gestern:Gasverbrauch_Total/Tag.* { (split /,/, ReadingsVal("vitoconnect","Gasverbrauch_Total/Tag",0))[1] }
Mein Abfrage-Intervall der Daten beträgt 3600 Sekunden.
Mein Problem ist, dass auf diese Art meiner Abfrage 24mal am Tag der Wert für den gestrigen Gasverbrauch ins Log geschrieben wird. Ist 1. unnütz und 2. schlecht für die grafische Darstellung :)
Nun bin ich auf das userReading 'DbLogValueFn' gestoßen.
Ich hänge jetzt leider fest mit folgender Annahme:
Wenn...
READING 'Gasverbrauch_gestern' mit 'DATE_von_heute' schon im Log vorhanden ist,
Dann...
IGNORE=1
Ich selber kann dies leider programmtechnisch nicht umsetzen.
Ich bitte um Eure Hilfe mit Dank im Voraus.
Eine Möglichkeit wäre im Quellendevice ein Userreading als Statusreading erstellst. Also z.B. ein Reading "alreadyLogged" zusätzlich zu deinem "Gasverbrauch_gestern" mit der gleichen Bedingung. "alreadyLogged". Du setzt es dabei einfach auf "1".
Dann könntest du das Reading nur in 'DbLogValueFn' (oder valueFn) auf Vorhandensein bzw. den Wert "1" testen:
{
if ($READING eq "Gasverbrauch_gestern" && ReadingsVal("vitoconnect", "alreadyLogged", 0) {
$IGNORE=1;
}
Wenn das Reading "alreadyLogged" mit einem Wert ungleich 0 existiert wird ein Loggen von 'Gasverbrauch_gestern' verhindert.
Jetzt musst du nur noch das Reading "alreadyLogged" mit einem geeigneten Verfahren (ein simples at) täglich zu einer dir genehmen Zeit wieder auf 0 setzen um das Logging freizuschalten.
Grüße,
Heiko
userReading monotonic und/oder delta-d im gplot?
Wow - rasend schnelle Antworten. Vielen Dank !
@Beta-User: no, ich nutze nicht gplot sondern generell das FTUI Chart Widget zwecks Darstellung aller FHEM-Anzeigen auf Tablets/Monitoren
@DS-Starter
hi Heiko,
ich bin nicht sicher, ob ich Dich richtig verstanden habe.
Hintergrund (ich muss es auch mal für mich noch mal runterschreiben):
o Da ich mein Abruf-Intervall auf 3600 gesetzt habe, bekomme ich täglich 24 Werte zur Temperatur und zum Vortags-Gasverbrauch.
o Viessmann scheint den "Gasverbrauch_gestern" zwischen 00:00 Uhr und 01:00 Uhr zu aktualisieren. Ab dann bekomme ich derzeit dieses Reading stündlich, also noch 23mal mit dem gestrigen Verbrauchswert geliefert.
Das bedeutet: um 00:00 Uhr muss "alreadyLogged" auf "0" gesetzt werden, ab 01:00 Uhr muss "alreadyLogged" auf "1" gesetzt werden.
Du hattest geschrieben "...nur noch das Reading "alreadyLogged" mit einem geeigneten Verfahren (ein simples at) täglich zu einer dir genehmen Zeit wieder auf 0 setzen..." ähem, ich habe keinen blassen Schimmer, wie :( . Wäre ein Vorgabe Deinerseits möglich???
Noch ne Kleinigkeit: in Deinem Code steht in der 2. Zeile hinten "{". Ist das korrekt oder ein Tippfehler?
Wenn's um's Codieren geht, bin ich doch noch sehr unsicher.
Nochmals vielen Dank für Deine Mühen.
lg
Ulf
Hallo Ulf,
gestern war es doch schon etwas spät um nochmal drüber nachzudenken und (Tipp)Fehler zu bereinigen und
habe es mir jetzt nochmal durch den Kopf gehen lassen.
Du erstellst das Attr 'DbLogValueFn' in dieser Form:
{
if ($READING eq "Gasverbrauch_gestern" {
if (ReadingsVal("vitoconnect", "alreadyLogged", 0)) {
$IGNORE=1;
}
else {
fhem("setreading vitoconnect alreadyLogged 1");
}
}
}
Was passiert ? Wird der Event "Gasverbrauch_gestern" erzeugt/verarbeitet und ist das Reading "alreadyLogged" mit einem Wert ungleich 0 vorhanden, wird kein Logging ausgeführt. Im anderen Fall wird der Event in die DB geschrieben und "alreadyLogged" mit dem Wert "1" gesetzt.
Danach auftrende Events "Gasverbrauch_gestern" werden nicht mehr geloggt.
Nun brauchst du noch das at um das Reading täglich auf "0" zu setzen.
Ein solches at wäre z.B.:
define enable_Gasverbrauch_logging at *00:00:30 setreading vitoconnect alreadyLogged 0
Jeden Tag 30 Sekunden nach Mitternacht wird das Reading auf 0 gesetzt. Genau um 00:00:00 würde ich so etwas nicht tun.
Das wäre ein einfacher Vorschlag um dein Szenario zu realisieren.
Jetzt musst du es natürlich erstmal ausprobieren. Ich hoffe keinen Syntaxfehler eingebaut zu haben. ;)
Grüße,
Heiko
Evtl. noch ein etwas anderer Ansatz:
userReadings Gasverbrauch_gestern:Gasverbrauch_Total/Tag.* { (split /,/, ReadingsVal($name,'Gasverbrauch_Total/Tag',0))[1] if (localtime)[2] < 1 }(Unterstellt, das Ausgangsreading gehört auch zu "vitoconnect").
Damit wird das Reading nur in der Zeit zwischen 00:00 Uhr und 01:00 Uhr aktualisiert.
Klasse, danke! Beide Vorschläge sehen sehr gut aus.
Und vielen Dank an DS-Starter für die Ablauf-Erklärungen. Genau das Richtige für einen "so gut wie gar nicht"-Programmierer wie mich :)
@ Beta-User: wow - ein nettes Shorty! 8)
Und JA, das Ausgangsreading gehört auch zu "vitoconnect".
Werde jetzt beide Versionen testweise für je 3 Tage/Nächte verwenden.
Meine bisherige Erkenntnis, dass 'Gasverbrauch_Total/Tag' immer zwischen 00 und 01 Uhr durch Viessmann aktualisiert wird, möchte ich auch noch absichern.
In ca. 1 Woche füge ich dann für die Nachwelt einen Screenshot der FTUI-Grafik hier ein und werde das Thema als GELÖST abschließen.
Nochmals ein großes Dankeschön an Euch Beide.
lg
Ulf
:) Gerne.
Vielleicht noch eine Ergänzung: Falls - warum auch immer - die Aktualisierung ausfällt, könntest du zusätzlich noch "oder"-prüfen, ob ReadingsAge() auf das Reading > DAYSECONDS ist (evtl. etwas weniger). Dann passiert das mit deutlich erhöhter Wahrscheinlichkeit wenigstens einmal am Tag...
(Bitte melden, wenn du das nicht in Code umgesetzt bekommst).
@Beta-User
Klasse Variante + 10.000mal besser als eine optische Kontrolle (wozu gibt's denn die EDV?!) ...
Ich muss aber leider Dein Angebot annehmen und Dir melden, dass ich den Code nicht hinbekomme :( .
Hab' zwar jetzt einiges in der FHEM-Referenz gelesen zum Thema 'ReadingsAge' sowie im WIKI zu 'Verfahren zum Rechnen mit Zeitangaben, die als Zeichenkette vorliegen' ... aber ich scheitere an der Umsetzung, dies alles in passenden und korrekten Code umzusetzen.
Please help :-[
lg
Ulf
Ungetestet:
userReadings Gasverbrauch_gestern:Gasverbrauch_Total/Tag.* { (split /,/, ReadingsVal($name,'Gasverbrauch_Total/Tag',0))[1] if (localtime)[2] < 1 || ReadingsAge($name,'Gasverbrauch_gestern', DAYSECONDS) > DAYSECONDS - 1800 }
Erläuterungen zur Ergänzung:
"||" ist (u.a. in Perl) "oder"
ReadingsAge fragt das Alter eines Readings ab, Rückgabe ist ein Sekundenwert. Gibt es kein Reading, greift das ins Leere, hier wird dann eben die Länge eines Tages in Sekunden zurückgegeben (das ist eine in FHEM (im main-Kontext) verfügbare Konstante).
Ist das dann "zu alt" (also knapp einen Tag alt), darf aktualisiert werden...
Falls es übrigens nur ums Loggen geht, gäbe es eine weitere Variante: einfach via "addLog" einen Wert ins Log-File bzw. die Datenbank schreiben (kann u.a. ein "at" machen)...
@Beta-User
Danke.
Hatte Dein userReading von 11:19 Uhr gegen 13:00 Uhr "eingebaut" (per STRG+C/STRG+P) ;). Funzt suppi.
Seither gibt es in der DB keine Werte mehr, die die Grafik verhunzen.
Okay, Einträge in der DB erfolgen noch, die sind aber ohne Werte.
Einen Screenshot davon habe ich angehängt.
Da ich jährlich meine DB säubere, werden die dann auch verschwinden.
Bin mal auf morgen früh gespannt, ob und wann der Eintrag zum gestrigen Gasverbrauch erscheint.
Werde mich morgen früh noch mal melden und übers Ergebnis berichten.
Ja, es geht mir nur ums Logging.
Aber ich würde gern bei Deiner aktuellen Version bleiben. Es sei denn, der Experte rät mir zur neuen Version (...mit "at" machen...).
Bis hierhin erst mal tsd. Dank
lg
Ulf
Zitat von: ulobo60 am 24 November 2021, 17:00:05
Es sei denn, der Experte rät mir zur neuen Version (...mit "at" machen...).
Weiß nicht, ob ich damit gemeint gewesen war, aber:
- die "at"/addLog-Sache hat den Vorteil, dass man ggf. "ein at für alle solche Fälle" basteln kann und die Event-Verarbeitung nicht mit weiteren Verarbeitungslogiken belastet;
- dafür "kauft" man sich den Nachteil, dass ggf. komplett veraltete Daten in die DB geschrieben werden (es sei denn, das at würde das Alter des Ausgangsreadings prüfen).
Kurz-Summary: Da hier zum einen ein sauberer Trigger exisitiert und zum anderen das update-Intervall für die Ausgangsdaten eher als "mäßig" bezeichnet werden kann, halte ich _hier_ den userReadings-Weg für vorzugswürdig (falls man nicht doch z.B. LogProxy auch für FTUI-Zwecke einsetzen kann und damit einfach den Zeitstempel der Ausgangsdaten passend umbiegen kann... Daten, die man bei Bedarf errechnen kann, sind m.E. vorzugswürdig gg. denen, die man für's Darstellen erst erzeugen und mit loggen muss ;) ).
Ich denke auch es ist eine Frage der persönlichen Vorliebe. Das in DbLog eingebaute addlog hat noch den Charme dass du in diesem Fall die leeren Datensätze in der DB vermeidest. In dem Fall kann das Userreading auch komplett ohne Event arbeiten.
addLog braucht es nicht.
Andererseits lässt sich eine DB auch leicht bereinigen. Einfach regelmäßige Läufe mit DbRep eingeplant wirft alles raus was man nicht mehr braucht (richtig eingestellt natürlich).
Jetzt hast du wirklich einige Varianten verfügbar :)
Liebe beiden Helper,
bin beeindruckt ob Eurer Kompetenz.
Was würden wir 'normale' FHEM-Anwender ohne Euch machen?
Für mich gültige Antwort: nur Stückwerk.
Ich belasse es auf jeden Fall erst mal bei der bisher eingebauten Programmierung und liefere morgen Vormittag meinen Bericht ab.
lg
Ulf
@Beta-User und DS_Starter:
Alles ist gut.
Es wird nur 1 Wert täglich für das reading 'Gasverbrauch_gestern' in der Datenbank gespeichert (siehe Screenshot 'vitoconnect_mysql.jpg').
Habe mal ermittelt, dass die Einträge ohne Wert jährlich gerade mal 0,8 MB in der DB belegen werden.
Trotzdem werde ich sie natürlich beim jährlichen Bereinigungsdurchgang löschen.
Die aktuelle Ansicht meines FTUI-Charts siehe unten ('vitoconnect_chart.jpg').
Eigentlich müßte ich die Werte für 'Gasverbrauch_gestern' um 1 Tag nach vorn verschieben. Aber 1. weiß ich wieder mal nicht, wie man das anstellt. Und 2. macht das Chart für mich erst dann richtig Sinn, wenn hier Vergangenheitsdaten von 1 bis 2 Jahren vorliegen. Dann aber ist der 1-Tages-Versatz unerheblich.
Euch Beiden danke ich recht herzlich für die tollen und kompetenten Programmier-Tipps und Erklärungen.
Wenn Ihr nichts dagegen habt, werde ich heute Nachmittag das Thema als "Gelöst" kennzeichnen.
Beste Grüße
Ulf
ZitatEigentlich müßte ich die Werte für 'Gasverbrauch_gestern' um 1 Tag nach vorn verschieben. Aber 1. weiß ich wieder mal nicht, wie man das anstellt.
Den Timestamp des DB Eintrages kannst du direkt beim Logging verändern. Dazu gibt es die Variable $TIMESTAMP im Attr DbLogValueFn.
{
if ($READING eq "Gasverbrauch_gestern" {
$TIMESTAMP = "yyyy-mm-dd hh:mm:ss";
}
}
Jetzt braucht es nur ein wenig Hirnschmalz wie man "yyyy-mm-dd hh:mm:ss" bei jedem Log-Vorgang bestinmmt, ist aber auch kein großes Problem.
LG
...vielleicht werfe ich jetzt doch mal das Stichwort "statistics" in den Raum. Das kann uU. auch helfen, Tages- oder Monatsendwerte zu loggen.
Na wenn wir schon dabei sind braucht man auch nur ein diffValue Auswertung für einen beliebigen Zeitraum (Tag, Woche, Monat, Jahr etc. ) mit DbRep über die Datenbank zu fahren. :)
hmmmm...
[Exkurs-Anfang]
Ein Student (ich) steht auf dem Flur vor der Mensa zwischen 2 Professoren und lauscht der Diskussion der beiden.
Beide Profs haben ihren linken Arm angewinkelt, in der linken Handfläche ruht der rechte Ellbogen.
Mit Daumen und Zeigefinger der rechten Hand stützen die Profs ihr Kinn ... und fachsimpeln.
Der Student hat den Kopf leicht nach links geneigt und sein Mund steht halb offen.
Der Student stellt nach kurzer Zeit fest, dass er von der Diskussion nicht so richtig viel versteht.
Er bemerkt, dass es ihm wohl nicht an Hirnschmalz fehlt. Ihm fehlt einfach nur Hirn. ???
[Exkurs-Ende]
@DS_Starter:
Klar, Du hast mich wieder am Haken.... ;)
Habe mal so'n Stündchen nach 'perl change timestamp' und ähnlichem gegoogled und nichts gefunden, das ich verstehe.
Könntest Du mir evtl. zum Thema "dd-1 im Timestamp" die letztliche Codierung verraten?
;D
Hmmm, also bis zu einem gewissen Grad ist so ein Hirn auch nur ein Muskel, der mit etwas Training wächst...
(Bei manchem, was ich vor Jahren geschrieben habe, denke ich heute auch: nun ja, ... also, öhm ::) )
Das Format ist doch das "normale" Zeitstempelformat in FHEM => ergo gibt's auch eine Funktion dafür in fhem.pl...
{FmtDateTime(time)}
Könnt mich schmeißen ... ;D
Zitat
Habe mal so'n Stündchen nach 'perl change timestamp' und ähnlichem gegoogled und nichts gefunden, das ich verstehe.
Könntest Du mir evtl. zum Thema "dd-1 im Timestamp" die letztliche Codierung verraten?
Es müßte so gehen (Attr valueFn !!, nur valueFn wird bei addLog ausgewertet wenn du addLog verwenden willst):
{
if ($READING eq "Gasverbrauch_gestern" {
$TIMESTAMP = strftime "%Y-%m-%d %H:%M:%S", localtime(time-86400);
}
}
time gibt die Anzahl der Sekunden seit Beginn der Epoche (1970) zurück. Das substrahiert mit 86400 (1 Tag) vermindet den Timestamp um einen Tag. Das strftime (POSIX) wandelt den Timstamp zurück und formatiert ihn wie benötigt.
Hoffe es stimmt alles so wie ich es schnell ausgedacht habe ...
LG
Zitat von: DS_Starter am 25 November 2021, 15:07:56
Könnt mich schmeißen ... ;D
[...]
Das substrahiert mit 86400 (1 Tag) [...]
;D ... da war doch was mit der Zeitumstellung...
*duck und weg*
Äh , ja ... Wenn man den Wert früh vor um 02:00 loggt sollte eine Subtraktion von 86400 immer im Vortag landen wenn ich keinen Knoten im Hirn habe. Eigentlich ist es egal wenn man nicht gerade am Abend 23:00 loggt und ausgerechnet die Zeitverschiebung mit dem 23-Stundentag erwischt ... Da wird einem ja ganz schwindelig ;)
;D ja, müßte passen, wenn man das Zeitfenster zwischen 00:00 Uhr und einschl. 02:00:00 Uhr erwischt. Hatte nur neulich "Spaß" mit dem Thema bei statistics, offenbar ist da der Knoten in meinem Hirn noch nicht ganz weg (das Problem in statistics aber hoffentlich schon, *Kinnreib*)...
... komme gerade aus der Mensa...
Im Ernst - habe in den letzten 2 Stunden erfolglos versucht, das Tag-Verschiebungsproblem mit Euren bis dato - Hinweisen zu lösen.
Keine Chance für mich...
Dann kam mir der entscheidende Gedanke: schau doch mal in's Forum, vielleicht gibt's was Neues. Und siehe da - es gab was Neues: die Copy/Paste-Hilfe von DS_Starter. Thx a lot dafür. Wenn man den Programm-Schnipsel mit POSIX dann so vor sich sieht, macht alles Sinn. Es ist dann so einleuchtend.
Habe die Codierung gerade perfekt eingebaut ;).
Jetzt heißt's wieder warten auf morgen früh und das Ergebnis begutachten.
Melde mich morgen früh wieder.
Thx a lot Euch Beiden.
P.S.: Bin jetzt wieder in der Mensa...
Zitat von: DS_Starter am 25 November 2021, 15:20:42
Äh , ja ... Wenn man den Wert früh vor um 02:00 loggt sollte eine Subtraktion von 86400 immer im Vortag landen wenn ich keinen Knoten im Hirn habe. Eigentlich ist es egal wenn man nicht gerade am Abend 23:00 loggt und ausgerechnet die Zeitverschiebung mit dem 23-Stundentag erwischt ... Da wird einem ja ganz schwindelig ;)
...offenbar doch zu schwindelig: 00:nn Uhr minus DAYSECONDS ergibt vorgestern, wenn man nach der Zeitumstellung im März (23 h-Tag) prüft...
Vielleicht habe ich jetzt wieder einen Dreher drin, vielleicht auch nicht, wer weiß...
if ($READING eq "Gasverbrauch_gestern" {
my $now = time;
my $then = $now - 86400 - 3600*((localtime($now))[8] - (localtime($now - 86400.))[8]);
$TIMESTAMP = FmtDateTime($then);
}(Ohne das "use POSIX;", aber ggf. muss man dann die fhem.pl-Funktion importieren, wenn man gepackaged ist :P ...)
Guten Appetit in der Mensa!
EDIT: Man könnte aber auch der Einfachheit halber nur 23 h abziehen, wenn man sicher ist, dass man nicht nach 22:00 Uhr dran ist...
DbLog habe ich nicht gepackaged, da sind die fhem.pl Funktionen verfügbar. Und POSIX wird in fhem.pl geladen.
Passt soweit. Die Zeitumstellung sollte mal kassiert werden. Dann wäre uns allen geholfen. :)
Zitat von: DS_Starter am 25 November 2021, 17:42:24
DbLog habe ich nicht gepackaged, da sind die fhem.pl Funktionen verfügbar.
Habe zwischenzeitlich alles gepackaged, was ich als Maintainer zu verantworten habe, und kann das nur weiterempfehlen... Kein Hackel mit unbeabsichtigten Doppelbenennungen bei Variablen (oder gar Code-Referenzen), teilweise "atomisierter Code", "use List::Util 1.45 qw(max min uniq);"
Zitat
Und POSIX wird in fhem.pl geladen.
...was Rudi wohl heute nicht mehr so lösen würde, wenn ich seine diesbezüglichen Äußerungen richtig deute (und dass das (ohne Einschränkung via qw) auch noch x andere Module in main ziehen, ist auch nicht glücklich...).
ZitatHabe zwischenzeitlich alles gepackaged, ...
Ja mache ich bei auch so. Außer bei DbLog, da bin ich sehr vorsichtig.
DbRep kommt noch dran, aber auch da keine Eile.
Wird jetzt aber langsam OT ;)
[Exkurs-Anfang]
Als der Student am frühen Nachmittag aus der Mensa kam, waren die beiden Profs verschwunden.
Der Student beschloss, noch schnell mal in die Sauna zu gehen.
Als er die Saunatür öffnete, teilte sich die heiße Luft vor ihm.
Er sah die beiden Profs in entspannter Kutscherhaltung auf der höchsten Pritsche sitzen.
Der Student suchte sich einen Platz auf der untersten Reihe.
Die 2 Profs diskutierten unter anderem über das Posix. Das kannte der Student - aus seiner Bodybuilder-Zeit.
Der Student erfuhr auch noch so nebenbei, dass einer der Profs gepackaged sei, der andere aber nicht.
Es wurde viel diskutiert über das Problem mit der Zeitumstellung im März, und dass "00:nn Uhr minus DAYSECONDS vorgestern ergibt".
Für einen kleinen Augenblick nahm der Student seine gewohnte Haltung ein: Kopf leicht nach links geneigt und Mund halb offen.
Dies aber nur für eine sehr kurze Zeit.
Die heiße Luft machte den Studenten schläfrig.
Er nahm sein Handtuch, ging auf seine Bude und dort direkt zu seinem Schreibtisch.
Darüber hängt seine Pinnwand mit den wichtigsten Notizen - so ca. 127 Stück.
Er nahm seine Einkaufsliste von der Pinnwand. Der letzte Punkt - erst vor kurzem hinzugefügt - war: "1kg Gehirnschmalz kaufen".
Auf die Rückseite des Zettels schrieb er:
"Nach der Zeitumstellung im März 2022 prüfen, ob der Einfachheit halber nur 23 h abzuziehen sind, wenn man sicher ist, dass man nicht nach 22:00 Uhr dran ist."
Mit einem zufriedenen Lächeln im Gesicht schlief der Student ein - mit der Gewissheit, die beiden Profs morgen wieder vor der Mensa zu treffen.
[Exkurs-Ende]
cu tomorrow !
Ich glaub ich komme vor Lachen nicht in den Schlaf ;D
gute Nacht !
Schade, hat leider nicht funktioniert (siehe angehängter Screenshot).
Im log ist natürlich nix zu erkennen, da aktuell Verbose=1.
Hier das aktuelle Listing der attributes von 'vitoconnect':
Attributes:
DbLogInclude .*(Aussentemperatur|Gasverbrauch_gestern)
DbLogValueFn {
if ($READING eq "Gasverbrauch_gestern" {
$TIMESTAMP = strftime "%Y-%m-%d %H:%M:%S", localtime(time-86400);
}
}
room Heizung
userReadings Gasverbrauch_gestern:Gasverbrauch_Total/Tag.* { (split /,/, ReadingsVal($name,'Gasverbrauch_Total/Tag',0))[1] if (localtime)[2] < 1 || ReadingsAge($name,'Gasverbrauch_gestern', DAYSECONDS) > DAYSECONDS - 1800 }
Es wäre schön, wenn Ihr mein Coding mal prüfen könntet.
Muss jetzt gleich leider meinen 92jährigen Schwiegervater ins Heim bringen :'(.
Bin daher leider heute erst gegen 22:00 Uhr wieder in der Nähe meines PCs.
Vorausgesetzt im Code sind keine Fehler - soll ich kurz vor Mitternacht verbose auf 5 stellen und morgen berichten?
Euch einen schönen Tag +
lg
Ulf
Hallo Ulf,
da hatte ich eine Klammer vergessen "..."Gasverbrauch_gestern") " , sorry ... und baue in das DbLogValueFn mal ein Log ein:
{
if ($READING eq "Gasverbrauch_gestern") {
my $told = $TIMESTAMP;
$TIMESTAMP = strftime "%Y-%m-%d %H:%M:%S", localtime(time-86400);
Log(1, "DbLogValueFn > alter TS: $told / neuer TS: $TIMESTAMP");
}
}
Damit sieht man den originalen und den adaptierten Timestamp. Stelle außerdem im DbLog Device verbose 2.
Das reicht aus um eventuelle Fehler zu sehen.
Grüße,
Heiko
hi Heiko,
bin früher zurück - Schwiegervater ist im Heim gut und problemlos gelandet.
Neee, das mit der Klammer ist meine Schuld.
Die Prüfung auf Klammer-Vollzähligkeit und -Art ist eigentlich das mindeste, das wir als Nutzer Eurer Experten-Tipps und -Vorlagen durchführen sollten.
Ich habe Deine Codierung ungeprüft übernommen. Mea culpa !
Habe gerade Deine aktuellen Optimierungen eingebaut (Klammern überprüft: okay) und Verbose = 2.
Deine Idee mit dem Logging des originalen und des adaptierten Timestamps ist klasse.
Ich melde mich morgen Vormittag und werde berichten.
Gut's Nächtle
Ulf
hi Heiko,
das Leben hat doch in der Tat manchmal seine eigenen Gesetze...
Schwiegervater war gestern froh, im Heim zu sein - heute will er wieder nach Hause... etc., etc.
Das Ganze spielt sich derzeit in meiner Familie auch noch über 70km Entfernung ab.
1 Stunde mit dem Auto hin, 1 Stunde zurück, zwischendurch mit Caritas und Heimleitungen verhandeln, diskutieren ....
Rin in die Kartoffeln, raus aus die Kartoffeln...
Ich muss leider das Thema hier erst mal mindestens für ein paar Tage ruhen lassen.
Was empfiehlst Du mir: diesen Beitrag als GELÖST kennzeichnen oder einfach offen lassen?
lg
Ulf
Mach dir keinen Stress und lass es laufen ... wir werden sehen.
Dir / euch alles Beste bis dahin !
LG,
Heiko
Mach ich.
Danke Dir
lg
Ulf
[Exkurs-Anfang]
...komme gerade aus der Mensa.
Seit heute Mittag hängt dort ein Schild:
"Verkauf von Toilettenpapier nur an Geimpfte und Genesene !"
Seit heute Mittag ist die Schlange vor dem Corona-Impfzelt auf dem Campus ca. 10mal so lang wie heute morgen...
[Exkurs-Ende]
Ich werde heute Nacht den Beitrag als gelöst abschließen, da alles zu meiner Zufriedenheit funktioniert.
Habe noch ein paar kleinere Änderungen vorgenommen.
Hintergrund: Vissmann hat wohl in den letzten Nächten 2mal die Aktualisierung des Readings "Gasverbrauch_Total/Tag" erst ab 1:00 Uhr vorgenommen.
Also habe ich...
1. das Aktualisierungs-Intervall von 'Vitoconnect' auf 10800 (3 Stunden) gesetzt und es...
2. so gestartet, dass es vor Mitternacht gegen 22:14 Uhr und nach Mitternacht 01:14 Uhr die Daten abholt.
(MYSQL-Daten-Auszug siehe unten 1_mysql.jpg)
Es werden damit zwar nur 8 Daten je Tag gespeichert, aber das Chart dazu wird ja erst nach 1 Jahr so richtig interessant (Vergleich zum Vorjahr , u.ä.)
(Aktuelle Grafik siehe unten 2_chart.jpg).
Das Loggen von altem und neuem Timestamp klappt zwar nicht (habe Verbose=2). Ist m.E. aber auch nicht unbedingt nötig.
Der Ordnung halber hier das aktuelle Coding meiner Vitoconnect-Attribute:
attr vitoconnect DbLogInclude .*(Aussentemperatur|Gasverbrauch_gestern)
attr vitoconnect DbLogValueFn {\
if ($READING eq "Gasverbrauch_gestern") {\
my $told = $TIMESTAMP;;\
$TIMESTAMP = strftime "%Y-%m-%d %H:%M:%S", localtime(time-86400);;\
Log(1, "DbLogValueFn > alter TS: $told / neuer TS: $TIMESTAMP");;\
}\
}
attr vitoconnect userReadings Gasverbrauch_gestern:Gasverbrauch_Total/Tag.* { (split /,/, ReadingsVal($name,'Gasverbrauch_Total/Tag',0))[1] if (localtime)[2] < 2 || ReadingsAge($name,'Gasverbrauch_gestern', DAYSECONDS) > DAYSECONDS - 1800 }
@DS_Starter + Beta-User:
Vielen , vielen Dank für Eure Mühen mit mir und Eure für mich wertvollen Anregungen, Hinweise, Codings + Erläuterungen.
Ihr habt mir sehr geholfen.
Da du mit 86400 hantierst. Hast du an die Zeitumstellung zweimal im Jahr gedacht?
@damian
ja, ist hier ab 'Anwort #21' hier ergiebig behandelt worden ;)
Ich werde es nach dem Moto "EDV zu Fuß" lösen:
Habe mir bereits 2 Erinnerungen in meinem Kalender für's nächste Jahr angelegt, une werde die Werte manuell ändern :).
Danke Dir, Damian