Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)

[DS_Starter]

Jo, das wars.
Jetzt sieht es so aus wir erwartet.
Nun werde ich mal versuchen das Ganze in eine Testversion des Moduls zu gießen. Mal sehen wie Perls DBI mit so einem Kontrukt klarkommt.
Das wird aber eine Weile dauern. Komme sicherlich erst ab Montag wieder zu mehr.

Aber erstmal danke Jo für die Ansätze !

Schönes WE
Heiko

[JoeALLb]

Das freut mich... ich bin eh auch unterwegs, aber ich denke gerade dass diese Lösung die Performance auf dem rpi mit mysql
verbessern sollte...Ich habe übrigens das Layout der mysql-Datenbank angepaßt und hätte auch vorschläge im dblog zu verbessern, aber das wird glaub
ich recht weniggemaintenanced...

[DS_Starter]

Hallo Joe, @all,

habe die diffValue-Funktion im Modul entsprechend umgebaut und als Version 4.7 im Eingang hinterlegt.
Es hat anfangs etwas gehapert, aber nun läuft die Version.

Dadurch dass nun Nulldurchgänge erlaubt sind und entsprechend mit ausgewertet werden ist ein Nebeneffekt deutlich geworden der vorher keine Bedeutung hatte und nicht auffiel. Ich habe bei mir festgestellt, dass aus nicht erkennbaren Gründen immer mal wieder ein Nullwert durch DbLog in die DB geschrieben wird.  Es kann also zu kleinen Aussetztern in der Zahlenfolge kommen, die natürlich nicht als normale Differenz anzusehen sind und behandelt werden müssen.
Zum Beispiel:

 MjAxNi0wNA== 2016-04-13 10:03:20 8085.267 0.04399999999986903
 MjAxNi0wNA== 2016-04-13 10:04:27 8085.313 0.046000000000276486
 MjAxNi0wNA== 2016-04-13 10:05:34 8085.362 0.04899999999997817
 MjAxNi0wNA== 2016-04-13 10:06:41 8085.413 0.05099999999947613
 MjAxNi0wNA== 2016-04-13 10:07:48 8085.459 0.046000000000276486
 MjAxNi0wNA== 2016-04-13 10:08:55 8085.510 0.051000000000385626
  MjAxNi0wNA== 2016-04-13 10:10:02 0.000 0
 MjAxNi0wNA== 2016-04-13 10:11:09 8085.600 8085.6
 MjAxNi0wNA== 2016-04-13 10:12:16 8085.643 0.042999999999665306
 MjAxNi0wNA== 2016-04-13 10:13:23 8085.692 0.04899999999997817
 MjAxNi0wNA== 2016-04-13 10:14:30 8085.741 0.04899999999997817
 MjAxNi0wNA== 2016-04-13 10:15:37 8085.792 0.051000000000385626
 MjAxNi0wNA== 2016-04-13 10:16:44 8085.839 0.04699999999957072

(die letzte Zahl ist immer die Differenz, die signifikante Diff in dem Beispiel ist 8085.6)

Dabei soll nunmehr ein normales Setzen eines Energiezählers auf Null natürlich berücksichtigt werden.
Durch diesen Umstand habe ich den SQL-Select etwas verändert. Die Differenzen werden durch den DB-Server geliefert, aber die Bewertung der einzelnen Diffs auf Sinnhaftigkeit wird durch die Modullogik übernommen.

Nun kann das Modul nicht ganz allein feststellen welche Differenz ok ist und welche eventuell nicht mit einbezogen werden darf.
Um das zu lösen habe ich zunächst einen Schwellenwert (Limit) eingeführt, bis zu dessen Erreichen eine Differenz zwischen zwei unmittelbar aufeinander folgenden Messwerten als ok angesehen wird.
Sollte dieser Wert überschritten werden, passiert folgendes :

 1. dieser Differenzwert nicht berücksichtigt
 2. ein Reading mit allen Datensätzen,  die im diffValue-Lauf das diffLimit überschrittenhaben, wird generiert
 3. mit verbose=3 wird dieses Ergebnisarray ins Logfile geschrieben

 (siehe Screenshots im Anhang)

Das bedeutet also, dass man als Nutzer darauf hingeweisen wird wenn Auslassungen auftreten. Entweder igrnoriert man diese Datensätze, oder löscht sie wenn sie fehlerhaft sind und räumt so gleich die DB auf. Die relevanten Datensätze die diese Differenz verursachen sind im Reading
"diff-overrun_limit-<diffLimit>" bzw. im Log leicht ersichtlich.

Als weitere Möglichkeit kann der Nutzer das Differenzlimit mit dem Attribut "diffAccept" individuell anpassen um so eine größere Varianz zuzulassen.
Das Reading "diff-overrun_limit-<diffLimit>" zeigt im Teil <diffLimit> immer das aktuell eingestellte Limit an (als Standard habe ich 20 gewählt).

Wenn ihr also das neue Modul anwendet achtet bitte auf diese Ausgaben und macht entsprechende Justagen falls nötig/sinnvoll.
Das klingt jetzt vielleicht etwas kompliziert, aber wenn man ein paar Läufe gemacht und das Prinzip verinnerlicht hat ist es gut anwendbar und man kann dadurch auch ziemlich schnell Unregelmäßigkeiten in seinen Daten feststellen.

Es wäre schön wenn ihr auch SQLite bzw. PostgreSQL testen würdet. MySQL habe ich momentan schon gut durchgetest.

viele Grüße
Heiko

[JoeALLb]

Hallo,

Vielen Dank, das sieht schon ganz gut aus!!
Das mit den 0-Einträgen habe ich nicht, vielleicht hängt das mit dem Modul deines Zählers zusammen?
Was ich sehe ist dass ich öffter doppelte Einträge in DBLog bekomme, also selbes Datum, reading, device und value.
Das verhindere ich iom Moment über einen primary key auf die Tabelle über alle diese spalten, aber vermutlich sollte ich mal in das dblog-modul reinschauen.

Was mir auffällt, das ist mir aber auch schon in der vorherigen Version aufgefallen, ist, dass
er hie raus mir unverständlichen Gründen kein Reading für  11.2015 erstellt, und stattdessen 2 Monate zusammenfasst. Hast Du dafür eine Erklärung?

Code: [Auswählen]

2015-09-28_16-31-54__powersolar__total__DIFF__2015-09 348.7024
2015-11-30_23-57-05__powersolar__total__DIFF__2015-10 642.4555
2015-12-16_21-14-49__powersolar__total__DIFF__2015-12 169.2405
Edit 1: Nachtrag: diffAccept ist ein tolles Feature, vielen Dank dafür!!

[JoeALLb]

Ich weiß ja nicht ganz, wie es gedacht ist,
aber anbei  Daten von einer Mauellen Ablesung (also sehr lückenhaft!!)

Code: [Auswählen]

"TIMESTAMP" "DEVICE" "TYPE" "EVENT" "READING" "VALUE" "UNIT" "Longterm"
"2008-01-11 00:00:00" "Manuell" "typ" "event" "Wasser" "335.61" "u" "0"
"2008-02-04 00:00:00" "Manuell" "typ" "event" "Wasser" "342.8" "u" "0"
"2008-02-29 00:00:00" "Manuell" "typ" "event" "Wasser" "349.635" "u" "0"
"2008-03-04 00:00:00" "Manuell" "typ" "event" "Wasser" "350.87" "u" "0"
"2008-03-27 00:00:00" "Manuell" "typ" "event" "Wasser" "356.581" "u" "0"
"2008-04-17 00:00:00" "Manuell" "typ" "event" "Wasser" "361.507" "u" "0"
"2008-05-07 00:00:00" "Manuell" "typ" "event" "Wasser" "366.283" "u" "0"
"2008-05-25 00:00:00" "Manuell" "typ" "event" "Wasser" "370.028" "u" "0"
"2008-06-03 00:00:00" "Manuell" "typ" "event" "Wasser" "371.447" "u" "0"
"2008-06-19 00:00:00" "Manuell" "typ" "event" "Wasser" "371.68" "u" "0"
"2008-06-20 00:00:00" "Manuell" "typ" "event" "Wasser" "372.251" "u" "0"
"2008-06-21 00:00:00" "Manuell" "typ" "event" "Wasser" "372.748" "u" "0"
"2008-07-13 00:00:00" "Manuell" "typ" "event" "Wasser" "377.134" "u" "0"
"2008-07-22 00:00:00" "Manuell" "typ" "event" "Wasser" "378.956" "u" "0"
"2008-07-23 00:00:00" "Manuell" "typ" "event" "Wasser" "379" "u" "0"
"2008-08-27 00:00:00" "Manuell" "typ" "event" "Wasser" "390.713" "u" "0"
"2008-09-18 00:00:00" "Manuell" "typ" "event" "Wasser" "396.529" "u" "0"
"2008-10-14 00:00:00" "Manuell" "typ" "event" "Wasser" "403.731" "u" "0"
"2008-10-30 00:00:00" "Manuell" "typ" "event" "Wasser" "408.307" "u" "0"
"2008-11-17 00:00:00" "Manuell" "typ" "event" "Wasser" "413.849" "u" "0"
"2008-12-03 00:00:00" "Manuell" "typ" "event" "Wasser" "417.307" "u" "0"
"2008-12-19 00:00:00" "Manuell" "typ" "event" "Wasser" "421.655" "u" "0"
"2008-12-31 00:00:00" "Manuell" "typ" "event" "Wasser" "425.871" "u" "0"

Hier ist der erste Eintrag 335,61 und der letzte ist 425,871.
Nun würde ich davon ausgehen, dass das Modul als Summe aller Monate irgendwas um die 90 aus gibt, da due Summe der Monate ja
weitestgehend der Differenz aus Jahresende-Jahresanfang entsprechen sollte.

Was ich jedoch erhalte ist: bei der monatlichen Zusammenfassung

Code: [Auswählen]

0 7 6 0 4 1 2 0 0 5 0 9  sum(33)also eine grobe Verzerrung der Daten.

Mir ist schon bewußt, dass diese großen Lücken das problem sind, dennoch sollte das Modul (meiner Meinung nach)  keine solchen
Ergebnisse liefern.
Auch sollte der April hier im Beispiel niemals eine 0 liefern!
Die Ergebmisse waren übrigens mit der alten Version ebenfalls nicht korrekt.

Lösungsvorschlag:
Egal wie fein die Dateneinträge sind, denke ich, muss man die Lücken die differenzwerte in Minuten ausrechnen und auf jedes Ende eines Zeitblocks entsprechend die Minuten aufteilen.
Ansonsten verlierst du immer Werte dazwischen und die Gesamtzahl stimmt nicht!
Wenn der März also 31 Tage hat und die letzte Messung am 27.3. war, sollten vom nächsten Wert

Beispielsrechnung:

Code: [Auswählen]

27.03.2008 356,58
17.04.2008 361,51
diffenzWert 4,93
differenzTage 21
diff in Minuten 30240
Betrag/Minute 0,000162897

TageMärz 5
TageApril 16
MinutenMärz 7200 (5*24*60)

EndstandMärz31.3.23:59:59   356,58 + 7200*0,000162897 = 357,7538571


Anbei noch meine Testdaten, falls Du damit direkt testen möchtest.

Code: [Auswählen]

INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2008-01-11 00:00:00', 'Manuell', 'typ', 'event', 'Wasser', '335.61', 'u');
INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2008-02-04 00:00:00', 'Manuell', 'typ', 'event', 'Wasser', '342.8', 'u');
INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2008-02-29 00:00:00', 'Manuell', 'typ', 'event', 'Wasser', '349.635', 'u');
INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2008-03-04 00:00:00', 'Manuell', 'typ', 'event', 'Wasser', '350.87', 'u');
INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2008-03-27 00:00:00', 'Manuell', 'typ', 'event', 'Wasser', '356.581', 'u');
INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2008-04-17 00:00:00', 'Manuell', 'typ', 'event', 'Wasser', '361.507', 'u');
INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2008-05-07 00:00:00', 'Manuell', 'typ', 'event', 'Wasser', '366.283', 'u');
INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2008-05-25 00:00:00', 'Manuell', 'typ', 'event', 'Wasser', '370.028', 'u');
INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2008-06-03 00:00:00', 'Manuell', 'typ', 'event', 'Wasser', '371.447', 'u');
INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2008-06-19 00:00:00', 'Manuell', 'typ', 'event', 'Wasser', '371.68', 'u');
INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2008-06-20 00:00:00', 'Manuell', 'typ', 'event', 'Wasser', '372.251', 'u');
INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2008-06-21 00:00:00', 'Manuell', 'typ', 'event', 'Wasser', '372.748', 'u');
INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2008-07-13 00:00:00', 'Manuell', 'typ', 'event', 'Wasser', '377.134', 'u');
INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2008-07-22 00:00:00', 'Manuell', 'typ', 'event', 'Wasser', '378.956', 'u');
INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2008-07-23 00:00:00', 'Manuell', 'typ', 'event', 'Wasser', '379', 'u');
INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2008-08-27 00:00:00', 'Manuell', 'typ', 'event', 'Wasser', '390.713', 'u');
INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2008-09-18 00:00:00', 'Manuell', 'typ', 'event', 'Wasser', '396.529', 'u');
INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2008-10-14 00:00:00', 'Manuell', 'typ', 'event', 'Wasser', '403.731', 'u');
INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2008-10-30 00:00:00', 'Manuell', 'typ', 'event', 'Wasser', '408.307', 'u');
INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2008-11-17 00:00:00', 'Manuell', 'typ', 'event', 'Wasser', '413.849', 'u');
INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2008-12-03 00:00:00', 'Manuell', 'typ', 'event', 'Wasser', '417.307', 'u');
INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2008-12-19 00:00:00', 'Manuell', 'typ', 'event', 'Wasser', '421.655', 'u');
INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2008-12-31 00:00:00', 'Manuell', 'typ', 'event', 'Wasser', '425.871', 'u');


[DS_Starter]

Guten Abend JoeAllb,

ich versuche mal deine beiden Einträge von oben nach unten zu beantworten.

Das mit den 0-Einträgen habe ich nicht, vielleicht hängt das mit dem Modul deines Zählers zusammen?

Ja, davon gehe ich auch aus. Im speziellen Fall ist es SMAUtils da die Werte von einem Solar-WR stammen. Möglicherweise hat der WR nicht geantwortet oder Null-Werte geliefert. Doch es ist gut dass ich auf diesen Fehler gelaufen bin. So konnte ich gleich entsprechenden Gegenmaßnahmen einbauen. Es ist ja nicht so abwegig dass andere User auch vor ähnlichen Problemen stehen könnten.

Das verhindere ich iom Moment über einen primary key ...

Den primary key vermisse ich ebenfalls. Wenn es ihn gäbe könnte ich z.B. dem User sehr einfach eine Löschfunktion eines einzelnen Datensatzes über den Key in der GUI anbieten. Momentan müßte man zur eindeutigen Identifikation eines Datensatzes etliche Daten eingeben.

Was mir auffällt, das ist mir aber auch schon in der vorherigen Version aufgefallen, ist, dass
er hie raus mir unverständlichen Gründen kein Reading für  11.2015 erstellt, und stattdessen 2 Monate zusammenfasst. Hast Du dafür eine Erklärung?

Noch nicht, aber eine gewisse Ahnung. Ich vermute hier einen Zusammenhang mit dem Wechsel von Sommer- zu Winterzeit.
Um das genauer zu sehen grenze deine Selektion temporär  zum Beispiel auf 20.10 - 30.11. ein (oder kopiere dir ein weiters DbRep-Device). Nur damit nicht so viele Daten geschrieben werden. Dann mache bitte ein verbose=5 log.

Kopiere alles ab dem Start des Selekts der im Log so ähnlich aussieht:

2016.11.16 18:54:58.661 4: DbRep Rep.Energy - -------- New selection ---------
2016.11.16 18:54:58.662 4: DbRep Rep.Energy - Aggregation: day
2016.11.16 18:54:58.662 4: DbRep Rep.Energy - Command: diffValue
2016.11.16 18:54:58.663 5: DbRep Rep.Energy - Timestamp begin epocheseconds: 1479279948
2016.11.16 18:54:58.663 4: DbRep Rep.Energy - Timestamp begin human readable: 2016-11-16 08:05:48
2016.11.16 18:54:58.663 5: DbRep Rep.Energy - Timestamp end epocheseconds: 1479318898
2016.11.16 18:54:58.663 4: DbRep Rep.Energy - Timestamp end human readable: 2016-11-16 18:54:58
2016.11.16 18:54:58.663 5: DbRep Rep.Energy - weekday of start for selection: Mi  ->  wdadd: 432000
...........................

Wahrscheinlich ist es dann gut ein separates File hier anzuhängen.
Dann schauen wir uns die Zeitgrenzen der einzelnen Statements an. Wenn meine Vermutung stimmt, haben wir einen Sprung im Oktober sodaß statt dem 31.10.  der 30.11 angezogen wird. Das Modul berücksichtigt DST von sich aus auf der Grundlage von Perl Standard localtime ob Sommer/Winterzeit (DST-Bit) vorliegt.

Auf welchem BS läuft dein FHEM ?  Wird Sommer/Winterzeit vom BS berücksichtigt ?

diffAccept ist ein tolles Feature, vielen Dank dafür!!

Danke sehr  .... gebe mir Mühe das Modul mit deiner/eurer Hilfe weiter zu verbessern.

Auch sollte der April hier im Beispiel niemals eine 0 liefern!

Wenn wir mit Aggregationen arbeiten, also mit Zeitperioden (Tag, Woche, Monat) innerhalb der gegebenen Zeitgrenzen für Start / Ende MUSS das Modul PRO Periode, in deinem Fall pro Monat, MINDESTENS zwei Werte zur Verfügung gestellt bekommen. Ansonsten kann es keine Differenz berechnen die somit "0" ist.  So wie bei dir im Januar, April, August, September ....

Wenn man bei automatischen Logvorgängen Probleme hat diese Rahmenbedingung einzuhalten, gibt es im Wiki einen Beschreibung für eine addLOg-Funktion mit der man zu jeder vollen Stunde, Tag etc. einen definierten Logeintrag schreiben lassen kann (http://www.fhemwiki.de/wiki/Plot-Abriss_vermeiden). Es ist eine kleine Sub in der myUtils.pm mit etwas AT, NOTIFY drumherum.

Bei manuellen Eingaben muß man leider selbst darauf achten dies zu tun. Ich würde dir also vorschlagen an den Monatsgrenzen z.B. um 23:00:00 bzw. am nächsten Monat um 01:00:00 den gewünschten Ende- bzw. Startwert zu vermerken. Dann klappt es auch mit deinen Diffs und den daraus folgenden Summen.
Solltest du aber mal Tages- oder Wochenauswertungen anstoßen wollen, stehst du vor demselben Problem -> es wären keine Werte vorhanden.
Das ist ein generelles Manko der manuellen Eingabe. Der Nutzer muß dann wissen was er will und sich an bestimmte Regeln halten.

Lösungsvorschlag:
Egal wie fein die Dateneinträge sind, denke ich, muss man die Lücken die differenzwerte in Minuten ausrechnen und auf jedes Ende eines Zeitblocks entsprechend die Minuten aufteilen.
Ansonsten verlierst du immer Werte dazwischen und die Gesamtzahl stimmt nicht!

Danke für deinen Vorschlag Joe. Ich finde diesen Wunsch auf jeden Fall nachvollziehbar und bedenkenswert.
Allerdings vertrete ich mit dem Modul einen anderen Ansatz bzw. eine andere Rollenverteilung zwischen der Datenbereitstellung und Datenauswertung.
D.h. die Datenbank ist die Etität die alle notwendigen Daten zur Verfügung stellt .... DbRep wertet diese Daten aus.

Man verliert also keine Werte .... sie werden schlichtweg nicht geliefert ! Also genau andersherum.

Das heißt auch, das schreibende Devicemodul bzw. der Nutzer selbst ist in der Rolle diese Daten je nach dem Auswertungsbedürfnis in die DB zu schreiben. Das Modul quasi zu "missbrauchen" unzulängliche oder fehlende Daten per se auszubügeln halte ich persönlich für etwas fragwürdig und in manchen Fällen vllt. sogar für schädlich.

Zwei Beispiele die mir adhoc einfallen:
Stell dir vor du bist 3 Wochen im Urlaub. Irgendwann später machst du eine Auswertung über den wöchentlichen Wasserverbrauch und wunderst dich wer in eurer Abwesenheit Wasser gezapft hat.  Oder schlimmer noch du wertest remote den Wasserverbrauch aus und vermutest ein Wasserleck weil dir gerade nicht mehr einfällt dass das Modul eine Schätzung in diesem Zeitraum ausführt. Der arme Nachbar der sich nach dem vermutlichen Leck totsucht .... 
Oder zum Beispiel meine Solardaten. Der WR arbeitet nur während der Sonnenstunden, sonst nicht. Würden wir einfach mit Durchschnittswerten Fehlzeiten ausffüllen kämen zweifelhafte Werte heraus.

Ich möchte deine Idee trotzdem aufgreifen und könnte mir vorstellen dass man eine neue Funktion im Modul implementiert die, wenn vom Nutzer explizit gewünscht, fehlende Daten in einem beliebig festzulegenden Raster (10 Minuten, 1 Stunde, was auch immer ... ) in der Datenbank mit Durchschnittswerten auffüllt.
Wichtig für mich ist dass der Nutzer es ausdrücklich wünscht (er muß die Funktion ausführen) und er weiß was er tut.

Die Aussagekraft einer solchen Auffüllung würde ich allerdings eher mäßig bewerten und macht m.M. nach, wenn überhaupt, nur bei Messwerten Sinn die sich im Normalfall auch tatsächlich relativ gleichförmig über den Zeitraum verteilen.

Hmm ... mein Ethusiasmus den Programmieraufwand zu betreiben hält sich momentan in Grenzen 

Aber ich könnte den User dahingehend unterstützen eine Warnung z.B. im "state" auszugeben wenn Rahmenbedingungen, wie nur ein Messwert pro Periode, oder die Überschreitung von diffAccept, vorliegen. Dann kann entsprechend reagiert werden.

Ich schlage vor wir lösen erst einmal noch dein Novemberproblem und wenn ich den aktuellen Enwicklungsstand noch dokumentiert sowie eingecheckt habe schauen wir weiter.  Deine manuellen Werte würde ich wie beschrieben als Workaround ergänzen. Das dauert schätzungsweise 15 Minuten. Dann passt das.

Grüße
Heiko



 


 
 

[JoeALLb]

Hallo Heiko,

Danke für deine Nachricht.

Danke für deinen Vorschlag Joe. Ich finde diesen Wunsch auf jeden Fall nachvollziehbar und bedenkenswert.
Allerdings vertrete ich mit dem Modul einen anderen Ansatz bzw. eine andere Rollenverteilung zwischen der Datenbereitstellung und Datenauswertung.
D.h. die Datenbank ist die Etität die alle notwendigen Daten zur Verfügung stellt .... DbRep wertet diese Daten aus.
 

Ich gebe Dir da völlig recht, ich bin selbst Datentechniker!
Aber ich hoffe, dass Du mit mir übereinstimmst, dass die Summe aller Monatssumme, eines Jahres zumindest gerundet den selben Wert ergeben sollte,
wie die Subtraktion von Max-Min. Ich denke, dass dies zentral wichtig ist für die Funktion dieses Moduls.


GGf. kann man ja auch den Operator auswählen, also ob man die Werte roh nimmt, oder ob man eben diese mittelwerte berechnet...
Evetuell wäre es auch hilfreich, den "errechneten" werten einen Prefix im Reading zu geben, sodass man diese farblich kennzeichnen kann?

Ich bin heute unterwegs, sehe es mir aber morgen wieder genauer an! Danke für die Rückmeldung!!

lG
Joe

PS: Du könntest ja vorschlagen, für dein Modul einen primary key zu definieren. Andere Module geben auch Indexe vor!
Ich arbeite übrigens zusätzlich mit partitionierten Tabellen, das macht da slöschen alter Einträge deutlich einfacher.

[DS_Starter]

Hi Joe,

Aber ich hoffe, dass Du mit mir übereinstimmst, dass die Summe aller Monatssumme, eines Jahres zumindest gerundet den selben Wert ergeben sollte, wie die Subtraktion von Max-Min.

Ja, klar. Keine Frage.

Ich arbeite übrigens zusätzlich mit partitionierten Tabellen, das macht da slöschen alter Einträge deutlich einfacher.

Das habe ich jetzt nicht wrklich verstanden. Kannst du mir mal erläutern wenn du wieder Zeit hast.

Bis dann und schönen Abend !

LG
Heiko

[JoeALLb]

Zur Partition: Meine History-Tabelle sieht so aus!
Damit erreiche ich folgende Vorteile:
1. Durch den primary Index bekomme ich keine doppelten Werte in die DB.
2. Durch die mehreren Partitionen (mehrere SQL-Tabellen) habe ich seit 5 Jahren keinen Ausfall auf der SD-Speicherkarte.
3. Alle Daten die das Flag "Longterm haben" haben, bleiben dauerhaft erhalten. Kurze Zwischendaten bekommen bei Longterm eine 0.

Ich kann somit die Partition aller 6 älteren Logeinträge ohne Verzögerung (also in ca. 0 sekunden) löschen.

Code: [Auswählen]

ALTER TABLE history DROP PARTITION monNolong ;löscht zum beispiel alle Logdaten die ich nicht dauerhaft speichern möchte, und an einem Montag abgespeichert wurden.
Da eben die ganze Partitionstabelle (=Datei) gelöscht wird, funktioniert dies auf einem RPI viel schneller.
Dadurch behalte ich zB alle Daten die jünger sind, also DI oder MI gespeichert wurden.

Code: [Auswählen]

CREATE TABLE `history` (
`TIMESTAMP` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
`DEVICE` VARCHAR(40) NOT NULL DEFAULT '',
`TYPE` VARCHAR(32) NULL DEFAULT NULL,
`EVENT` VARCHAR(512) NULL DEFAULT NULL,
`READING` VARCHAR(45) NOT NULL DEFAULT '',
`VALUE` VARCHAR(32) NULL DEFAULT NULL,
`UNIT` VARCHAR(32) NULL DEFAULT NULL,
`Longterm` TINYINT(4) NOT NULL DEFAULT '0',
PRIMARY KEY (`DEVICE`, `READING`, `TIMESTAMP`, `Longterm`),
INDEX `Reading_Time_Idx` (`READING`, `TIMESTAMP`) USING BTREE
)
COLLATE='latin1_swedish_ci'
PARTITION BY RANGE (WEEKDAY(timestamp))
SUBPARTITION BY HASH (Longterm)
(PARTITION mon VALUES LESS THAN (1)
 (SUBPARTITION monNolong ENGINE = MyISAM,
  SUBPARTITION monLong ENGINE = MyISAM),
 PARTITION tue VALUES LESS THAN (2)
 (SUBPARTITION tueNolong ENGINE = MyISAM,
  SUBPARTITION tueLong ENGINE = MyISAM),
 PARTITION wed VALUES LESS THAN (3)
 (SUBPARTITION wedNolong ENGINE = MyISAM,
  SUBPARTITION wedLong ENGINE = MyISAM),
 PARTITION thu VALUES LESS THAN (4)
 (SUBPARTITION thuNolong ENGINE = MyISAM,
  SUBPARTITION thuLong ENGINE = MyISAM),
 PARTITION fri VALUES LESS THAN (5)
 (SUBPARTITION friNolong ENGINE = MyISAM,
  SUBPARTITION friLong ENGINE = MyISAM),
 PARTITION sat VALUES LESS THAN (6)
 (SUBPARTITION satNolong ENGINE = MyISAM,
  SUBPARTITION satLong ENGINE = MyISAM),
 PARTITION sun VALUES LESS THAN (7)
 (SUBPARTITION sunNolong ENGINE = MyISAM,
  SUBPARTITION sunLong ENGINE = MyISAM))  */;

Bei gewissen Werten kann man übrigens wurderbar über eine Stored-Procedure direkt sicherstellen, dass diese als Longterm abgespeichert werden.



Für mich funktioniert dieses System wunderbar, vielleicht ist es aber nicht für jeden das optimale.

sG joe.

PS: Ich bin auf Dienstreise und mein Serverzugang ist leider versehentlich geschlossen, kann also kein Log4 machen! Ich habe dir aber oben meine Testdaten direkt angehängt, du kannd damit also einfach testen und sie ja danach leicht wieder aus deiner DB löschen...

Edit1:
Diese Fehlermeldung ist zwar gut gemeint, trifft bei mir aber nicht zu, da ich die Tabelle erweitert habe... könnte man das zumindest einstellbar machen (oder aber du fragst die Tabellenbreite direkt aus der DB ab?)

Code: [Auswählen]

Length of "reading" is too big. Maximum lenth for database type MYSQL is 32

[DS_Starter]

Hallo Joe, @ all,

danke für deine Erläuterungen.
Das ist doch schon eine Individuallösung, klingt aber auf jeden Fall interressant. Ich kann jetzt nicht beurteilen ob alle durch DbLog (jetzt nicht meine Baustelle) unterstützten Datanbanktypen so etwas supporten würden.

Aber der DbLog-Maintainer hat kürzlich die Feldlängen angepasst / vereinheitlicht. Ich habe das jetzt auch im DbRep nachgezogen. Es sind jetzt 64 Zeichen für Reading usw. Später will ich mal schauen ob man das über das Perl DBI direkt aus der Tabelle abfragen kann. Allerdings hab ich, als ich die get -Metadatenabfrage des Moduls gebaut habe, eine solche Möglichkeit nicht gesehen weil ich in diesem Rahmen schon mal danach gesucht habe. Muß aber nicht heißen dass es die nicht gibt.  Vielleicht hat jemand einen Tipp !!

Ich habe wieder eine neue Version 4.7.1 hinterlegt in der folgendes geändert ist:

 * Feldlängen auf den derzeitigen DbLog-Standard angepasst
 * es werden die Readings check diff-overrun_limit , not_enough_data_in_period erzeugt wenn das diffAccept-Limit überschritten wird bzw.
   falls  in einem Aggregationszeitraum für diffValue nur ein Datensatz gefunden wird und deswegen kein Diff-Wert errechnet werden kann.
   Das Reading enthält dann die betroffenen Perioden.
 * im Logfile werden mit verbose 3 die Inhalte der obigen Readings protokolliert

Joe, deine Testdaten habe ich bei mir importiert und diffValue Auswertungen gemacht. Es funktioniert bei mir auch für den November.
D.h. ist sehr wahrscheinlich ein Prob mit der DST auf deinem Rechner.

Grüße
Heiko

[JoeALLb]

Hallo Heiko,

danke! Werde das testen, sobald ich wieder Zugriff auf meinen Rechner habe. Leider habe ich versehentlich sshd beendet ;-)


Das mit den Partitionen ist eine Speziallösung, da gebe ich dir recht, und das kann auch kein sqlite!
Das schöne ist ja, dass man die Tabelle diesbezüglich verändern kann, ohne dass es den Rest von fhem tangiert.

Anbei ein SQL, mit welchem man die Spaltenbreite herausfinden kann... ob das nötig ist, kann ich gerade nicht beurteilen.
Danke für die Anpassung der Werte... ich hatte 4.7 diesbezüglich auch schon "gepatcht".

Code: [Auswählen]

show COLUMNS from history like 'device';

Ich verwende übrigens normales Debian 8 x86  als Distribution, habe noch ein auf einem kleinen Backupgerät ein Raspbian drauf,
da werde ich es mir auch mal ansehen.

[DS_Starter]

Hi Joe,
Danke für den Tipp. Ich hatte vom Perl DBI bei der Funktion Tableinfo erwartet dass diese Info mitgeliefert würde.
Tut sie nicht, aber so komme ich sicherlich auch weiter. Sehe ich mal in der Zukunft mit vor.

Dann erstmal ein schönes WE !

Grüße,
Heiko

[DS_Starter]

Hallo zusammen,

habe gerade festgestellt dass die neuen SQL-Statements (V 4.7.x) in diffValue für SQLite NICHT funktionieren.
Wer SQLite benutzt, sollte erstmal weiterhin die eingecheckte Version benutzen. Sobald ich dazu komme werde ich im Modul noch eine Fallunterscheidung innerhalb der diffValue-Funktion einbauen damit SQLite weiterhin die bisherigen SQL-Statements benutzt.
Ich wollte die neue Version heute schon einchecken und habe das Wiki bereits angepasst ... das dauert nun leider etwas....

VG
Heiko

[JoeALLb]

Hallo Heiko,

danke...
Ich verwende leider kein sqlite, da es keine gleichzeitigen mehrfachen Zugriffe erlaubt, und für mich das Grundvoraussetzung ist.

Ich habe wieder Zugriff auf meinen Debian, musste ihn neu installieren, und nun findet er auch für den November Einträge.
Ich werde mir das morgen nochmal genauer ansehen....


sG Joe

[JoeALLb]

habe gerade festgestellt dass die neuen SQL-Statements (V 4.7.x) in diffValue für SQLite NICHT funktionieren.

Nur als Idee:
Geh die einzelnen Datensätze in einer perl-schleifew mit prepare und fetchrow durch und berechnest den diffvalue dort.
Sollte von der performance her kaum einen unterschied machen und es bliebe für beide datenbanktypen gleich...