93_DbLog.pm Fehler bei delta-h

Punkt · 16 März 2015, 13:13:14

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...

betateilchen · 16 März 2015, 13:30:54

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.

Punkt · 16 März 2015, 17:30:24

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

Tobias · 17 März 2015, 07:45:20

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

Punkt · 17 März 2015, 21:48:17

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.

Viele Grüße

Michael

Tobias · 13 April 2015, 13:17:52

Hi,
also ich habe bei mir dein "neues" DBLog mal Laufen lassen, bringt aber ohne Ende Fehler

Die ersten Zeilen spammen mein Log zu

Code Auswählen

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.

Punkt · 13 April 2015, 14:00:10

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...

Punkt · 13 April 2015, 14:04:12

...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...

Punkt · 13 April 2015, 14:09:40

nochmal kurz drübergeschaut:

für andere DB-Systeme müsste man wahrscheinlich auch das DATESUB aus Zeile 899 auslagern und DB-spezifisch anpassen.

Tobias · 13 April 2015, 14:46:42

ich nutze PostGreSql

Punkt · 13 April 2015, 14:56:44

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.

Tobias · 13 April 2015, 15:26:02

verstanden...
zum Anpassen und testen hab ich aber aktuell nicht wirklich viel Zeit bzw gerade andere laufende Projekte... Da bin ich auf Patches angewiesen...

Punkt · 13 April 2015, 15:31:57

...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

Code Auswählen

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...

Tobias · 13 April 2015, 15:54:37

folgende 2 Plotfunctions:

Wasserzaehler:A Wasserzaehler:A::delta-h Wasserzaehler:A::delta-d
SensorUmwelt:Sonne SensorUmwelt:Helligkeit SensorUmwelt:Luftdruck

Punkt · 14 April 2015, 14:12:23

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