93_DbLog.pm Fehler bei delta-h

[Punkt]

Hallo zusammen,

ich habe gerade festgestellt, daß die Funktion delta-h in der 93_DbLog.pm scheinbar fehlerhaft ist.
Es scheint so als würde das Delta nur aus dem letzten Wert der aktuellen Stunden und dem ersten Wert der aktuellen Stunde berechnet werden.

Ich denke das ist nicht korrekt.
Das Delta sollte aus dem letzten Wert der aktuellen Stunde und dem letzten Wert der vorhergehenden Stunde berechnet werden...

Anbei habe ich ein Beispiel meiner Gaszähler-Auswertung:

Als Vergleich habe ich delta-h aus dem Filelog und aus der DBLog gelesen.
In beiden stehen die gleichen Werte (siehe 006.jpg aus der DB und folgende Liste aus dem Filelog):

Code Auswählen Erweitern

2015-02-17_23:45:41 Zaehler_GaWa Gas_m3: 16730 4.7
2015-02-18_00:00:41 Zaehler_GaWa Gas_m3: 16730 0
2015-02-18_05:42:47 Zaehler_GaWa Gas_m3: 16730.1 0.1
2015-02-18_05:47:55 Zaehler_GaWa Gas_m3: 16730.2 0.2
2015-02-18_05:54:04 Zaehler_GaWa Gas_m3: 16730.3 0.3
2015-02-18_06:02:07 Zaehler_GaWa Gas_m3: 16730.4 0.4
2015-02-18_06:34:21 Zaehler_GaWa Gas_m3: 16730.5 0.5
2015-02-18_06:39:21 Zaehler_GaWa Gas_m3: 16730.6 0.6
2015-02-18_06:43:21 Zaehler_GaWa Gas_m3: 16730.7 0.7
2015-02-18_06:47:21 Zaehler_GaWa Gas_m3: 16730.8 0.8
2015-02-18_06:52:21 Zaehler_GaWa Gas_m3: 16730.9 0.9
2015-02-18_06:58:21 Zaehler_GaWa Gas_m3: 16731 1
2015-02-18_07:28:57 Zaehler_GaWa Gas_m3: 16731.1 1.1
2015-02-18_08:16:23 Zaehler_GaWa Gas_m3: 16731.2 1.2
2015-02-18_08:45:36 Zaehler_GaWa Gas_m3: 16731.3 1.3
2015-02-18_08:51:36 Zaehler_GaWa Gas_m3: 16731.4 1.4
2015-02-18_08:55:36 Zaehler_GaWa Gas_m3: 16731.5 1.5
2015-02-18_08:59:36 Zaehler_GaWa Gas_m3: 16731.6 1.6
2015-02-18_09:03:36 Zaehler_GaWa Gas_m3: 16731.7 1.7
2015-02-18_09:06:36 Zaehler_GaWa Gas_m3: 16731.8 1.8
2015-02-18_09:10:42 Zaehler_GaWa Gas_m3: 16731.9 1.9
2015-02-18_09:15:50 Zaehler_GaWa Gas_m3: 16732 2
2015-02-18_09:20:53 Zaehler_GaWa Gas_m3: 16732.1 2.1
2015-02-18_09:35:56 Zaehler_GaWa Gas_m3: 16732.2 2.2
2015-02-18_09:47:56 Zaehler_GaWa Gas_m3: 16732.3 2.3
2015-02-18_10:22:52 Zaehler_GaWa Gas_m3: 16732.4 2.4
2015-02-18_11:12:35 Zaehler_GaWa Gas_m3: 16732.5 2.5
2015-02-18_11:45:48 Zaehler_GaWa Gas_m3: 16732.6 2.6
2015-02-18_11:49:53 Zaehler_GaWa Gas_m3: 16732.7 2.7
2015-02-18_11:57:58 Zaehler_GaWa Gas_m3: 16732.8 2.8

Wenn ich nun auf beiden ein delta-h für den aktuellen Tag ausgeben lasse bekomme ich folgende Ergebnisse:

aus Filelog (get FileLog_Zaehler_Gas Zaehler_Gas-2015.log - 2015-02-18 2015-02-19 4:Zaehler_GaWa.*:0:delta-h):

Code Auswählen Erweitern

2015-02-18_00:30:00 0.1
2015-02-18_01:30:00 0
2015-02-18_02:30:00 0
2015-02-18_03:30:00 0
2015-02-18_04:30:00 0
2015-02-18_05:30:00 0.3
2015-02-18_06:30:00 0.7
2015-02-18_07:30:00 0.1
2015-02-18_08:30:00 0.5
2015-02-18_09:30:00 0.7
2015-02-18_10:30:00 0.1
2015-02-18_11:30:00 0.3
#4:Zaehler_GaWa.*:0:delta-h
(wobei ich hier die Rechnerei auch nicht ganz nachvollziehen kann wie der Wert 0.1 bei 00:30:00) herauskommt...

und aus DBLog (get myDbLog - - 2015-02-18 2015-02-19 Zaehler_GaWa:m3::delta-h:):

Code Auswählen Erweitern

2015-02-18_05:30:00 0.2
2015-02-18_06:30:00 0.6
2015-02-18_07:30:00 0
2015-02-18_08:30:00 0.4
2015-02-18_09:30:00 0.6
2015-02-18_10:30:00 0
2015-02-18_11:30:00 0.3
#Zaehler_GaWa:m3::delta-h:

für mich sieht es so aus als würde delta-h aus dem DBLog immer die Differenz aus dem letzten und ersten Wert einer jeweiligen Stunde berechnen...
...könnt ihr das auch nachvollziehen?


Viele Grüße

Michael

[gero]

Es scheint so als würde das Delta nur aus dem letzten Wert der aktuellen Stunden und dem ersten Wert der aktuellen Stunde berechnet werden.

Ich denke das ist nicht korrekt.
Das Delta sollte aus dem letzten Wert der aktuellen Stunde und dem letzten Wert der vorhergehenden Stunde berechnet werden...l

Ich habe auch gemerkt, dass die delta-h bei zu sporadisch geloggten Daten nicht den erwarteten Wert zurück gibt (sowohl bei FileLog als auch DbLog)

Welche Berechnungsart die korrekte ist, ist allerdings fraglich.
Im Endeffekt müsste man die Werte zum Stundenwechsel interpolieren und mit diesen Werten delta-h berechnen. Und auch gegen eine Interpolation kann es je nach Art der Daten Argumente geben.

Gruß,
Gero

[Tobias]

Das ist korrekt so erkannt das dblog den ersten und letzten Wert der Stunde nimmt. Bisher wird von gleichmäßig angelieferten Werten wie von ks300 ausgegangen.
Interpolation wird schwierig, gar unmöglich

Gesendet von meinem ALCATEL ONE TOUCH 997D mit Tapatalk

[Punkt]

danke erstmal für deine Antwort.

Ich kenne jetzt die KS300 nicht weil ich bei mir erstmal alles per 1wire angebunden hab.
Der erste Gedanke war jetzt: Ich könnte ja einfach zum Beginn jeder Stunden nochmal ein Reading erzwingen - dann wäre ja der erste Wert der Stunde gleich dem letzten der vorhergehenden Stunde.

Nur kam mir da dann direkt das Problem in den Sinn: Was ist wenn sich dabei gerade der Wert geändert hat?

Also - wenn ich z.B. um 09:59 den Wert 100 habe könnte ich den für 10:00 Uhr auch nochmal reinschreiben.
Ist der Wert um 10:00 Uhr aber wieder angestiegen (z.B. 101) fehlt mir ja wieder der Wert zwischen den beiden Minuten.
Das Problem müsste dann bei der KS300 auch existieren und zu falschen Ergebnissen führen?
Kann aber auch sein daß das dort anders läuft - da hab ich wie gesagt keine Erfahrungen.

Was mich noch beschäftigt: per FileLog ging/geht das ja korrekt - ich meine auch in der FileLog.pm ne Stelle ausfindig gemacht zu haben die genau das prüft und zum Berechnen den letzten Wert der vorhergehenden Stunde bestimmt...

Sind die beiden Module an der Stelle so unterschiedlich?


Viele Grüße

Michael

[Tobias]

Mir ist nicht bekannt das Im filelog Dummy Einträge gemacht werden,  Kann das changelog aber übersehen haben.  Beide Module sind unabhängig implementiert
Patches sind aber immer willkommen

Gesendet von meinem ALCATEL ONE TOUCH 997D mit Tapatalk

[Punkt]

Das war anders gemeint. 

Mit nem Dummyeintrag zu jedem Stundenanfang könnte ich mir evtl behelfen damits direkt so funktioniert (unabhängig von FileLog).


Filelog ermittelt den letzten Wert der vorhergehenden Stunde beim berechnen von delta-h (_glaube_ ich zumindest).

Ich schau mirs mal an ob ich was verwendbares finde... 

[Punkt]

Hallo Tobias,

ich hab jetzt mal die halbe Nacht davor gesessen und mir das angeschaut (so ne Erkältung hat auch seine Vorteile).

Aaaalsooo... 

folgenden Lösungsvorschlag habe ich ersonnen (ist erstmal nur ein Vorschlag der bisher für mich funktioniert):

Nehmen wir an wir wollen für die Daten vom 13.03.2015 die Stundendaten erhalten.
Das bedeutet, daß wir bei jedem Stundenwechsel uns als MINVAL den MAXVAL der Vorgängerstunde merken müssen und mit diesem rechnen - das wäre die erste Voraussetzung für korrekte Stundenwerte.

Nun haben wir aber ein Problem bei der ersten Stunde des Tages - hier fehlt uns ja der Wert der vorhergehenden Stunde weil diese ja nicht in der Selektions-Range liegt (Wert vor 13.03.2015 00:00:00).

Dies habe ich gelöst indem ich einfach die eigentliche Datenbankselektion erweitert habe.

Was benötigen wir also?

Ganz einfach:
Zusätzlich zu den Werten der aktuellen Zeitraum-Selektion benötigen wir zusätzlich einen einzelnen Datensatz mit dem Max-Wert aus der Datenbank mit dem Timestamp vor der Selektions-Zeitrange.

Wie kriegen wir das hin?

Hier hilft uns die Datenbank mit nem UNION ALL.
Hiermit können wir einfach den Datensatz mit dem Maxwert vor der Zeitrange hinzuselektieren.
Für das aktuelle Beispiel sieht das so aus:

Code Auswählen Erweitern

SELECT
    max(DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H:%i:%s')) as TIMESTAMP,
    max(DEVICE) as DEVICE,
    max(TYPE) as TYPE,
    max(EVENT) as EVENT,
    max(READING) as READING,
    max(VALUE) as VALUE,
    max(UNIT) as UNIT
FROM
    `history`
WHERE
    `TIMESTAMP` < '2015-03-13 00:00:00' AND
    `DEVICE` = 'Zaehler_GaWa' AND
    `READING` = 'm3'
UNION ALL
SELECT
    DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H:%i:%s'),
    DEVICE,
    TYPE,
    EVENT,
    READING,
    VALUE,
    UNIT
FROM
    `history`
WHERE
    `TIMESTAMP` >= '2015-03-13 00:00:00' and
    `TIMESTAMP` <= '2015-03-13 23:59:59' AND
    `DEVICE` = 'Zaehler_GaWa' AND
    `READING` = 'm3'
ORDER BY TIMESTAMP

Jetzt haben wir aber ja natürlich einen zusätzlichen Datensatz in unserer Selektion mit drin der außerhalb unserer Zeitrange liegt.
Von diesem benötigen wir außer dem Wert eigentlich nichts - er soll noch nicht einmal mit ausgegeben werden.

Außerdem könnte es sein daß in der Datenbank gar kein Eintrag existiert der vor der Zeitrange liegt - in diesem Fall haben wir eben keinen zusätzlichen Eintrag in der DB der hinzuselektiert wird.

Das behandeln wir damit daß wir nachsehen ob der aktuelle Eintrag der bearbeitet wird VOR der FROM-Variable liegt und in dem Fall einfach nur den Wert merken und mit diesem Satz sonst nichts weiter machen:

Code Auswählen Erweitern

      if($sql_timestamp lt $from) {
        if(Scalar::Util::looks_like_number($sql_value)){
          #nur setzen wenn nummerisch
          $minval = $sql_value if($sql_value < $minval);
          $maxval = $sql_value if($sql_value > $maxval);
          $lastv[$i] = $sql_value;
        }
      } else {
        .....hier der ganze bisherige Code.....
      }

Es gibt zusätzliche Anpassungen die von mir vorgenommen wurde - zum einen um "0"-Werte für Stunden dazwischen einzufügen für die es keine Werte gibt, zum andern um die SUM-Variable bei delta-h entsprechend korrekt zu setzen (hier wurden die Zählerwerte addiert anstatt die Stundenwerte).

Das ganze kann so ähnlich dann auch für delta-d umgesetzt werden - der Fall ist ähnlich gelagert.

Jetzt die Gretchen-Frage:

Meine Anpassungen funktionieren jetzt erstmal natürlich bei mir.
Um diese Punkte in das Modul einzuarbeiten wäre es u.U. sinnvoll wenn wir per PN oder Email kontakt aufnehmen würden - ich denke du kannst besser beurteilen ob das auch für andere Readings usw. korrekt wäre oder ob das evtl. doch weitere Probleme erzeugen würde...


Ich habe auch noch andere Ansätze (evtl. Die Berechnung der Stunden- bzw. Tageswerte in die Datenbank auszulagern) - aber die aktuelle Vorgehensweise war meines Erachtens mit den wenigsten Eingriffen in die generelle bisherige Vorgehensweise verbunden.


So - sehr viel Text - muss erstmal verdaut werden.

Wenn also generelles Interesse besteht an meinen Anpassungen kann ich dir diese sehr gerne zur Verfügung stellen - vielleicht ist es ja doch ein hilfreicher Ansatz...


Viele Grüße

Michael

[Tobias]

Hi Punkt,
hört sich gut an, bremst aber FHEM-Installtionen auf langsamen Rechnern aus.
Anstatt den letzte Datensatz aus der DB mit max(...) zu holen (Hier muss die DB durch ALLES durchlesen da nur ein < angegeben wurde) ist es besser, auf jede volle Stunde einen eigenen Datensatz in die DB zu schreiben.

Der letzte Wert wird vom DBLog Modul im betreffenden zu loggenden Objekt in den helper- Varaiblen abgespeichert. Also muss man nur noch schauen ob seit der letzten speicherung bis jetzt eine oder mehrere Stunden übersprungen wurde und dann exakt auf die Stunde genau einen linear interpolierten Datensatz schreiben.

Der Vorteil hier, es kommt ohne zusätzliche Select Anfragen auf die DB aus. DbLog wirk blockierend, dh. alles was zu lange dauert bremst FHEM komplett aus.

[justme1968]

ist es denn überhaupt der richtige ansatz delta-h zu verwenden? bzw. ist es nicht sinnvoller die werte vor dem loggen aufzubereiten? z.b. mit event-aggregator oder auch addLog.

die delta-x methoden haben auch den nachteil das sie nicht richtig funktionieren wenn man weiter in den plot hinein zoomt.

hier könnte vielleicht logProxy besser helfen. hier gibt es schon funktionalität um den abriss am anfang und ende zu vermeiden. auch mit interpolation wenn gewünscht. vielleicht wäre ein ansatz hier eine delta-x funktion einzubauen die in allen zoom stufen funktioniert. das hätte zusätzlich den vorteil das es wie logProxy auch nicht DbLog spezifisch ist.

gruss
  andre

[Punkt]

Hallo Tobias,

das Max benötigt natürlich um einiges länger - bei mir auf nem lahmen NAS ca. 2 Sekunden (immer noch nicht sooo lange - aber im Vergleich zu 0,002 Sekunden bei der normalen Zeitbereich-Einschränkung entsprechend...).

Die Frage ist, ob man wirklich linear interpolieren Muss um den Wert exakt zur vollen Stunde zu schreiben - damit keine Werte verlorengehen bei der Delta-Berechnung würde es vermutlich schon ausreichen den letzten Wert noch einmal einzutragen - dies hätte aber vermutlich Auswirkungen auf die normalen Standard-Get-Aufrufe und würde im Extremfall Stufen im Plot verursachen...

Noch dazu käme daß bei einem interpolierten Wert um genau 00:00:00 Uhr z.B. dann wieder der Bereich von dem letzten Tageswert bis zum interpolierten Wert fehlt weil der letzte interpolierte Wert nicht mit in die Selektion einfliesst...

Das schwierige beim Schreiben des Wertes zu jeder vollen Stunde ist zusätzlich daß u.U. vorkommen kann daß genau zu diesem Zeitpunkt ein neuer Wert geschrieben wird durch ein Reading - dann hast du auch wieder das Problem daß zwischendrin Werte fehlen.

Das blöde an der Sache ist, daß das tatsächlich ja nur für den ersten Wert benötigt wird - bei einem Stundenwechsel innerhalb der verfügbaren Daten klappt das mit dem Merken des Maxval der vorhergehenden Stunde als aktuellen Minval...

Ich hab noch ein paar weitere Ansätze - ich mach mir mal noch ein paar Gedanken dazu...vielleicht fällt mir ja noch was ein...

Ein Ansatz um die ganze Rechnerei mit Minval und Maxval zu sparen wäre noch folgender:
Mit folgender Abfrage kannst du dir die Max-Werte zu jeder vollen Stunde (funktioniert auch mit Tagen oder Jahren) selektieren:

Code Auswählen Erweitern

select
  max(TIMESTAMP) as 'TIMESTAMP',
  max(DEVICE) as 'DEVICE',
  max(TYPE) as 'TYPE',
  max(EVENT) as 'EVENT',
  max(READING) as 'READING',
  max(VALUE) as 'VALUE',
  max(UNIT) as 'UNIT'
from
  `history`
where
  `DEVICE` = 'Zaehler_GaWa' and
  `READING` = 'm3' and
  timestamp> '2015-01-01 00:00:00'
group by
  DATE_FORMAT(TIMESTAMP, "%y-%m-%d %h")
order by timestamp

Das läuft relativ flott und du hast aber tatsächlich nur noch die Daten übers Netzwerk zu übertragen (bei ner entfernten DB) die du wirklich benötigst - das kann bei nem Selekt über ein Jahr extrem viel ausmachen...

Aber auch hier bleibt das Problem daß man den Max-Wert für die Anfangsberechnung ermitteln muss...

[Punkt]

Der Vorschlag von andre hört sich natürlich auch nicht schlecht an - müsste man sich mal ansehen - da hab ich allerdings keine Erfahrung mit logProxy.

An AddLog hatte ich ja auch gedacht - war ja ein erster Gedanke von mir gewesen den Wert zu schreiben...

Ich brauche delta-h / delta-d in der Regel bei größeren Plotzeiträumen (ab 1 Tag) um Jahresverbräuche auszuwerten.
Hier habe ich eher das Problem daß ich weniger Daten haben möchte anstatt alle Werte ins Plot fliessen zu lassen - daher habe ich bei meiner Anforderung das Problem mit dem "Hineinzoomen" erst einmal nicht...aber ist natürlich auch ein Argument...

[Tobias]

Hi Andre,
ich versteh nicht was du meinst mit dem Aufbereiten vor dem loggen. Du weißt ja beim Loggen garnicht, auf welcher Detailstufe man später auswerten will...
Und ein zu loggender Wert muss ja auch nicht aussteigend sein wie zb. ein counter

[justme1968]

hallo tobias,

natürlich geht das nicht in jedem fall.

worauf ich eigentlich hinaus will ist das es nicht ins db oder file log modul gehört die werte aufzubereiten oder zu interpolieren. und es erst recht schlecht ist wenn so etwas nur in eins der beiden module eingebaut wird. es ist meiner meinung nach besser die werte vor dem loggen aufzubereiten wenn das geht (event-aggregator, user readings,...) oder nach der abfrage aus dem log device (logProxy, eventuell mit eigener funktion zum interpolieren).

und mit den delta-x funktionen bin ich noch nie richtig warm geworden. das raster und das rein zoomen passt bei mir nie wirklich.

[Punkt]

die Delta-Funktionen sind ja in beiden Modulen vorhanden (FileLog und DbLog).

Das Problem nur: Sie haben bisher nicht korrekt gerechnet (meiner Meinung nach).
Auch im FileLog rechnen die Delta-Funktionen nicht korrekt - dort wird der erste Wert einfach hochgezählt und am letzten Wert abgezogen.
Aber das ist ne andere Baustelle

Zusätzliche Log-Einträge finde ich prinzipiell nicht die beste Alternative weil es ja eigentlich nur darum geht vorhandene Daten aufzubereiten - und das gehört meines Erachtens auf die Datenbank-Seite. Von daher wäre das im DbLog schon richtig aufgehoben denke ich.

Wie gesagt benötige ich die Stunden- bzw. Tagesdaten um Stunden-, Tages-, Wochen-, Monats- oder Jahresplots anzuzeigen - bei Zoomstufen unterhalb der Stunden macht zum Beispiel ein Delta-h keinen Sinn mehr...

[Punkt]

Ich frage mal kurz vorsichtig in die Runde (bitte nicht töten - ich glaube da wurde schonmal ne Diskussion drüber geführt):

Es ist nicht angedacht / eine Möglichkeit die Daten aus eigenen Tabellen lesen zu können?
Dann würde ich mir für die Stunden- bzw. Tageswerte einfach Trigger auf der Datenbank schreiben und würde dann nur auf genau diesen Daten arbeiten.
Das wären dann so wenige daß die Max-Funktion beim Select keine signifikanten Laufzeiteinbußen bedeuten würde - und ich könnte noch weiteren Schabernack treiben... *hust*

Eigene Tabellen habe ich in der DB sowieso schon - allerdings um die Werte mit anderen Shell-Scripten auszulesen - wenn ich von FHEM aus darauf zugreifen könnte wäre das schon geil....

...man kann ja als Prämisse angeben daß die weiteren Tabellen immer die FHEM-Struktur haben müssen...