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):
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):
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:):
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
Zitat von: Punkt am 18 Februar 2015, 12:36:12
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
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
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
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
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... :)
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:
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:
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
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.
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
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:
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...
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...
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
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.
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...
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...
ooook....ich rudere mal voooorsichtig zurück... ::)
Das mit dem Auslesen von eigenen Tabellen lassen wir mal aus der Diskussion raus denke ich - hab mir grade mal logProxy angesehen und denke wenn man so aus dem Standard raus will (weitere Tabellen einlesen) kann man das ja einfach in ne eigene Funktion / Modul auslagern und dann über logProxy einbinden.
Bleibt halt die Frage nach den Delta-Funktionen im DbLog-Modul.
Wenn diese dort weiterhin zur Verfügung stehen sollen sollten sie überarbeitet werden.
Was mir noch aufgefallen war ist, dass auch die Werte für $sum und $avg falsch ermittelt werden wenn die Delta-Funktionen verwendet werden - das wäre relativ leicht zu fixen.
Zusätzlich fehlt dann noch die Möglichkeit generell Funktionen im SVG einzubinden wenn man die Plots mit dem Frontend bearbeitet.
Wenn man Funktionen im .gplot-file eingetragen hat und dieses über das Frontend editiert werden die Funktionen einfach rausgenommen.
Bleibt nur erstmal die Frage im Raum ob eben Funktionen von DbLog unterstützt werden sollen...
Nach meiner unmaßgeblichen Meinung gehören in Modul, deren Funktion dem Namen nach das Loggen von Daten ist, keinerlei Berechnungsfunktionen. Weder vor dem Loggen noch nach dem Auslesen.
Sowas sollte immer in dem jeweiligen Modul geschehen, das Daten aus dem Log anfordert.
Hallo zusammen,
ich habe das Modul bei mir jetzt soweit mal angepasst daß es die Delta nun korrekt berechnet, $sum und $avg korrekt setzt und das ganze auch noch performant.
Für mich funktioniert das so - wenn du willst schicke ich dir das Modul gerne mal zu Tobias - mit nem Diff-Tool siehst du die Unterschiede ja direkt.
Ich habe das Problem mit der Performance jetzt erstmal recht pragmatisch gelöst:
1. wird der Max-Wert von vor der Zeitrange jetzt nur noch in das SQL-Statement eingefügt wenn überhaupt eine Delta-Funktion ausgeführt werden soll.
2. ich bin einfach hingegangen und habe ein "Delta-From-Date" hinzugefügt für welches ich einfach vom angefragten From-Zeitpunkt einen Monat nach hinten gegangen bin - das schien mir aktuell erstmal am simpelsten (lässt sich aber auch beliebig nach hinten verlagern je nachdem).
Wie gesagt - ungeachtet dessen ob die Delta-Funktionen da reingehören oder nicht (sie waren ja bisher auch da) rechnen diese jetzt korrekt und setzen auch die korrekten Variablen.
Andere Get-Anfragen oder Funktionen sind von der Anpassung nicht betroffen - haben also auch keine Auswirkungen auf die Performance ansich...
Wie gesagt - wenn du willst schick ich dir das angepasste Modul gerne mal zu.
Viele Grüße
Michael
Ich habe damals ein für mich unbrauchbares DBLog Modul übernommen und es erstmal soweit hinbekommen, das es für eine Plotauswertung überhaupt benutzbar ist. Die komplette "Get" Methode als Grundlage für Plots musste erst implementiert werden. Für mich war damlas der Anspruch, meine FileLogs gegen DBLog auszuwechseln. Und da Filelog die Delta-x Methoden anbot, musste dies demzufolge auch in DBLog mit rein. Eben kurz mal historisch erklärt warum die da drin sind.
@Punkt, schick mal bitte rüber.
Zu 2) ich wäre jetzt nur einen Tag nach hinten gegangen. Hast du solche Konstellationen das du an einem Tag überhaupt keine LogWerte bekommst?
Ich habe auch gesehen das du 1wire benutzt. Und da hast du definitiv Abfrageintervalle weil du ja explizit die Werte abfragst. Kann das sein das du per event-on-change die identischen Werte herausfilterst?? Das dürftest du natürlich nciht machen. Entweder arbeitest du zusätzlich mit dem Attr event-min-interval oder nur per DBLogExclude. Dieses stellt explizit ein minintervall zur verfügung, siehe Commandref:
DbLogExclude
set <device> DbLogExclude regex:MinInterval [regex:MinInterval] ...
Wenn DbLog genutzt wird, wird in alle Devices das Attribut DbLogExclude propagiert. Der Wert des Attributes wird als Regexp ausgewertet und schliesst die damit matchenden Readings von einem Logging aus. Einzelne Regexp werden durch Kommata getrennt. Ist MinIntervall angegeben, so wird der Logeintrag nur dann nicht geloggt, wenn das Intervall noch nicht erreicht und der Wert des Readings sich nicht verändert hat.
Beispiele
attr MyDevice1 DbLogExclude .* attr MyDevice2 DbLogExclude state,(floorplantext|MyUserReading):300,battery:3600
Hallo Tobias,
ich hab das jetzt auch angepasst und gehe jetzt nur einen Tag nach hinten - außer wenn es sich um den 1. handelt - dann gehe ich im Monat 1 zurück und mit dem Tag auf den 28. (wegen Februar). Ähnlich beim Jahreswechsel...
Du hast recht - ich schreibe die Werte die von meinen 1-wire-Sensoren kommen nur weg wenn diese sich ändern (event-on-change-reading).
Das mache ich damit ich nicht das Log mit unnötigen Werten vollschreibe.
Das ist aber meines Erachtens nicht unbedingt das Problem. MinIntervall würde ja auch nur einen Eintrag schreiben wenn sich der Wert des Reading verändert hat.
Im ersten Beitrag hab ich ja exemplarisch die Werte von meinem Gaszähler aufgelistet - das sind ja noch relativ einfache Werte, veranschaulichen das Ganze aber eigentlich ganz gut. Man kommt bei den Delta-Berechnungen einfach nicht umhin den Vorgängerwert zu ermitteln (denke ich).
Was man noch beachten sollte und was mir jetzt bei meiner Konstellation aufgefallen ist:
Ich hab meine FHEM-Installation auf einem anderen Server wie die Datenbank.
Wenn ich jetzt die Datenbankabfrage starte ist es ja so, daß erstmal alle Daten für den Zeitbereich von der Datenbank angefordert und übers Netzwerk übertragen werden.
Erst auf dem FHEM-Server werden die Daten dann stunden- bzw. tagesweise aufbereitet.
Ich bin aktuell gerade noch dabei die Abfragen im "Delta-Fall" so abzuändern daß schon von der Datenbank nur die Stunden- bzw. Tageswerte angefordert werden.
Das würde die Bearbeitung meines Erachtens auch nochmal um einiges beschleunigen, da dann wirklich nur die Daten übertragen würden die benötigt werden.
Eventuell würde das auch die ganze Berechnung auf FHEM-Seite wesentlich vereinfachen - aber das bin ich momentan wie gesagt noch am ausprobieren.
Wenn du mir ne PM schickst mit deiner Mailadresse schick ich dir mal das Modul zu - oder ich schick dir nen Download-Link von meinem Server.
Hier veröffentlichen wollte ich jetzt noch nicht direkt weil das alles ja noch im Umbau bzw. Versuchsstadium ist...es sei denn es muss sein. ;D
Viele Grüße
Michael
Hi,
also ich habe bei mir dein "neues" DBLog mal Laufen lassen, bringt aber ohne Ende Fehler :(
Die ersten Zeilen spammen mein Log zu :(
Use of uninitialized value $retvaldummy in concatenation (.) or string at ./FHEM/93_DbLog.pm line 1115.
Use of uninitialized value $retvaldummy in concatenation (.) or string at ./FHEM/93_DbLog.pm line 1115.
Use of uninitialized value $retvaldummy in concatenation (.) or string at ./FHEM/93_DbLog.pm line 1115.
Use of uninitialized value $retvaldummy in concatenation (.) or string at ./FHEM/93_DbLog.pm line 1115.
Use of uninitialized value $retvaldummy in concatenation (.) or string at ./FHEM/93_DbLog.pm line 1115.
Use of uninitialized value $retvaldummy in concatenation (.) or string at ./FHEM/93_DbLog.pm line 1115.
Use of uninitialized value $sqlspec{"order_by_hour"} in concatenation (.) or string at ./FHEM/93_DbLog.pm line 929.
DBD::Pg::st execute failed: ERROR: syntax error at or near "1"
ZEILE 6: ...4-13 00:00:00', 'YYYY-MM-DD HH24:MI:SS'),INTERVAL 1 DAY) UNI...
^ at ./FHEM/93_DbLog.pm line 941.
mit welcher Funktion?
Nutzt du die delta-h bzw. delta-d?
Ich hab das bisher noch nicht mit anderen Funktionen getestet - wie gesagt hab ich das bisher nur auf die delta-Funktionen angepasst.
Ich habe bisher auch nur diese bei mir getestet weil ich die anderen nicht verwende bisher.
Das ist aktuell ja auch nur ein Vorschlag wie man die anpassen kann damit die Berechnungen erstmal korrekt sind...
...kann es sein daß du was anderes als mySQL verwendest?
Ich hab die Anpassungen bisher für mySQL gemacht.
In den anderen DB-Teilen fehlt noch das $sqlspec{order_by_hour} welches in Zeile 836 definiert ist...
nochmal kurz drübergeschaut:
für andere DB-Systeme müsste man wahrscheinlich auch das DATESUB aus Zeile 899 auslagern und DB-spezifisch anpassen.
ich nutze PostGreSql
wie geschrieben: für alles andere als mySQL müssen die DB-spezifischen Sachen noch angepasst werden.
aber nochmal kurz zum Nachvollziehen:
Ich habe das angepasst damit das bei mir mit den delta-X-Funktionen auf mySQL funktioniert.
Vor allem geht es mir um das SQL-Statement und wie die Daten verarbeitet werden in den delta-X-Funktionen.
Das was ich dir geschickt hatte ist ein Vorschlag wie das angepasst werden kann und wie es bei mir mit meiner Konstellation funktioniert.
Ich schrieb ja auch daß das so noch nicht fertig ist und entsprechend für andere Systeme angepasst werden müsste.
Wenn du eine andere Systemkonstellation hast und u.U. noch andere Funktionen nutzt ausser delta-X dann sind Fehler sehr wahrscheinlich wenn du das von mir geschickte Modul einsetzt - deswegen habe ich das auch nicht hier eingestellt.
verstanden...
zum Anpassen und testen hab ich aber aktuell nicht wirklich viel Zeit bzw gerade andere laufende Projekte... Da bin ich auf Patches angewiesen...
...ok.
Ich hab mir schon was rausgesucht was man zumindest für PostgreSQL anpassen müsste.
Wenn du magst kann ich das mal noch mit einbauen.
...wo ich mir noch nicht ganz sicher bin ist mit der Zeile
Use of uninitialized value $retvaldummy in concatenation (.) or string at ./FHEM/93_DbLog.pm line 1115.
Hierzu müsste ich wissen ob du evtl. noch eine andere Funktion ausser delta-X verwendest.
Wenn nicht muss ich nochmal genauer nachsehen wieso der Fehler noch auftreten könnte...
...das mit der knappen Zeit / den anderen Projekten haben wir wahrscheinlich alle gepachtet. ::)
Ich bin aber durch meine Anpassung quasi ja grade da drin und kann die oben genannten Sachen noch mit aufnehmen...
folgende 2 Plotfunctions:
Wasserzaehler:A Wasserzaehler:A::delta-h Wasserzaehler:A::delta-d
SensorUmwelt:Sonne SensorUmwelt:Helligkeit SensorUmwelt:Luftdruck
ich habe das Modul mal versucht entsprechend zu ergänzen.
Der Teil der dein Log vollgespammt hat sollte nun angepasst sein.
Auch die DB-Spezifischen Teile für PostgreSQL hab ich soweit es mir möglich war versucht anzupassen.
Ich hab dir mal ne neue Version geschickt - vielleicht kannst du diese bei Gelegenheit ja mal antesten...
Hab dir die neue Version auch nochmal erst per Mail zugeschickt...
Viele Grüße
Michael
hier gehts es weiter... Test-Modul gibt es dort zum Testen vor dem Check-In
http://forum.fhem.de/index.php/topic,30998.msg291196.html#msg291196