DbLog, bitte testen

[tobias.faust]

Hi,
habe das DbLogModul soweit erweitert, das ich denke in den Mainstream gehen zu könnnen.
Doku ist gepflegt, Supportwille ist auch da ;)
Allerdings würde ich mich über Rückmeldungen freuen ob geht oder noch Bugs drin sind.
Geplant ist, das die Entwicklung in contrib weiter geht, und erst bei einem "stable release" wieder erneut in den mainstream wandert.
Was ich hier noch fehlt, in der Doku muss ich die Umlaute noch HTML-codieren.
Der aktuelle Anhang ist auch der Stand im contrib/dblog von heute morgen

gruss

[Andy Fuchs]

Hi Tobias,

Wenn Du noch die Sache mit dem Encoding in den Griff bekommst, dann fände ich das super. Andernfalls habe ich immer '?C' als Temperatur-Angabe in der Datenbank stehen. (Und auch bei Deinem Anhang ist das Encoding wieder kaputt).

Grüße

andy

> --
>
>
> <93_DbLog.pm>

[Daniel Krappen]

Hallo Tobias,

super Arbeit DbLog funktioniert.
Leider habe ich ein kleines Problem, wenn ich "get 2012-01-01 2012-12-31 wetter:Temp-inside" eingebe bekomme ich alle daten aus der DB ausgelesen.
Auch der Plot ist nur ein gemisch aus rot und grün.
Habe ich etwas falsch eingestellt oder ?
Mein DB ist eine MySQL-DB DEVICE=>wetter und READING=>Temp-inside

Gruß
Daniel

[tobias.faust]

besser? ich benutze "Sublime Text 2" und habe es als UTF8 gespeichert....

[tobias.faust]

so rum zb. :

get DbLog - - 2012-01-01 2012-12-31 wetter:Temp-inside

[Daniel_K]

Ja, man bin ich blöd, abschreiben müsste man können!

ich gebe natürlich "get logdb - - 2012-01-01 2012-12-31 wetter:Temp-inside" ein.
Meine DbLog heist logdb.
Nur das Erbebniss bleibt das gleiche, ich bekomme alle Daten aus der Datenbank ausgelesen und nicht nur die Temp-inside

Daniel

[Andy Fuchs]

Nö...

Versuch' mal die Datei zu zippen und dann anzuhängen...

Der Anhang scheint nämlich korrekt zu sein: Content-Type: text/x-perl; charset=UTF-8; name=93_DbLog.pm

Deine Mail wird allerdings als Multipart verschickt und beides Mal mit charset=ISO-8859-1

1. Content-Type: text/plain; charset=ISO-8859-1
2. Content-Type: text/html; charset=ISO-8859-1

Vermutlich kommen da die Mailer durcheinander...

Andy


On 05.12.2012, at 13:56, tobias.faust <tobias...@gmx.net> wrote:

> <93_DbLog.pm>

[tobias.faust]

stell mal bitte im logdb device das loglevel auf 0, danach Log kontrollieren und wenns immer noch  unklar ist und das SQL hier posten.

im anhang das pm file gzippt

[Andy Fuchs]

Hi Tobias,

jo - das war's!! Jetzt passt alles!

Gruß

andy

[Daniel_K]

Hallo Tobias,

so also ich hab jetzt noch mal alles neu gemacht mit loglevel 0 zum kontrollieren, ich finde das müsste eigentlich passen:

2012.12.05 20:31:59 0: Executing SELECT
        DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H:%i:%s'),
        DEVICE,
        READING,
        VALUE
		
       FROM history
       WHERE 1=1
        AND (DEVICE || '|' || READING) = ('wetter|Temp-inside')
        AND TIMESTAMP > STR_TO_DATE('2012-01-01 00:00:00', '%Y-%m-%d %H:%i:%s')
        AND TIMESTAMP < STR_TO_DATE('2012-12-31 00:00:00', '%Y-%m-%d %H:%i:%s')
       ORDER BY TIMESTAMP

Das Problem ist egal was bei "AND (DEVICE || '|' || READING) = ('wetter|Temp-inside') "steht, ob ('*| ') oder ('wetter|Temp-inside'), ausgelesen wird immer die gesammte DB.

Die SQL datenbank habe ich frisch angelegt nach "db_create_mysql" und wenn ich mit Putty "perl fhemdb-get.pl wetter Temp-inside" eingebe bekomme ich "Temp-inside:21.2"

Also ich weis nicht mehr was ich noch probieren könnte.

Danke schonmal für die Arbeit.
Daniel

[tobias.faust]

probier mal bitte auf der DB folgendes SQL: vieleicht hat Mysql ein Problem mit den ||

SELECT
        DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H:%i:%s'),
        DEVICE,
        READING,
        VALUE		
       FROM history
       WHERE 1=1
        AND CONCAT(DEVICE, '|' ,READING) = 'wetter|Temp-inside'
        AND TIMESTAMP > STR_TO_DATE('2012-01-01 00:00:00', '%Y-%m-%d %H:%i:%s')
        AND TIMESTAMP < STR_TO_DATE('2012-12-31 00:00:00', '%Y-%m-%d %H:%i:%s')
       ORDER BY TIMESTAMP

[Daniel_K]

Juhu ich habs!!

nach langen probieren und unter zuhilfenahme aus dem Beitrag "DbLog goes to gplot SVG..." von Erwin, hab ichs hinbekommen.

die SELECT sieht jetzt so aus:

  my $stm= "SELECT
        $sqlspec{get_timestamp},

        DEVICE,
        READING,
        VALUE
       FROM history
       WHERE 1=1

        AND CONCAT(DEVICE,'|',READING) IN ('".$readings[$i]->[0]."|".$readings[$i]->[1]."')
        AND TIMESTAMP > $sqlspec{from_timestamp}
        AND TIMESTAMP < $sqlspec{to_timestamp}
       ORDER BY TIMESTAMP, READING, TIMESTAMP";

naja ich denke das wird jetzt bestimmt zu Problemen bei PostgreSQL führen?
Danke für die Hilfe!!!

Gruß
Daniel

[Erwin]

Hello all,
sorry, ich lese zwar hier mit, hab aber wegen eines PC-desasters momentan nicjht sehr viel Möglichkeit zu testen.
Ich hab versucht, das SQL statement - in phpmyadmin (also ohne Variablen) zu testen...
eine funtionierende Variante (für mysql) schaut z.b. bei mir soo aus:
SELECT REPLACE(TIMESTAMP,' ','_'), DEVICE, READING, VALUE
       FROM `history`
       WHERE 1=1
        AND CONCAT(DEVICE,'|',READING) = 'AussenTempHum|temperature'
        AND TIMESTAMP BETWEEN '2012-12-01_15:00:00' AND '2012-12-06_23:00:07'
       ORDER BY TIMESTAMP


ps: damit kann ich das Timestamp-string-format von FHEM direkt verwenden und muß nicht umbauen.
Ich hoffe, ich kann ab nächster Woche wieder produktiv mitmachen....

l.g. erwin

[tobias.faust]

bitte mal testen....

[Daniel_K]

Ja super, geht!!
Super arbeit!!
Danke

Daniel

Am Donnerstag, 6. Dezember 2012 10:39:44 UTC+1 schrieb tobias.faust:

bitte mal testen....

[Erwin]

Hi Tobias,

Feedback von ersten tests:
logging funktioniert....
beim get gibts ein paar Fehlermeldungen:

1) Use of uninitialized value in concatenation (.) or string at /opt/lib/FHEM/93_DbLogMH.pm line 649.
Wobei die Zeilennummer NICHT mit deinem File übereinstimmt, ich hab da noch etliches anderes drin...
das hab ich gefixt mit:
  if(uc($outf) eq "ALL") {
    $sqlspec{all}  = ",TYPE,EVENT,UNIT";
  } else {
    $sqlspec{all}  = "";
  }

2)

Odd number of elements in hash assignment at /opt/lib/FHEM/93_DbLogMH.pm line 380.
Use of uninitialized value within @_ in list assignment at /opt/lib/FHEM/93_DbLogMH.pm line 380.
Odd number of elements in hash assignment at /opt/lib/FHEM/93_DbLogMH.pm line 380.
Use of uninitialized value within @_ in list assignment at /opt/lib/FHEM/93_DbLogMH.pm line 380.

wobei die Zeile 380 bei mir dort ist:

sub
DbLog_explode_datetime($%) {
  my ($t, %def) = @_;   <--- zeile 380
  my %retv;

Die Weblink-definition schaut soo aus:

define testwl weblink dbplot my_DbLog:TempHum_db
attr testwl fixedrange 2012-12-01 2012-12-31
attr testwl label "AussenTempMonat- min: $data{min1}, max: $data{max1}, last: $data{currval1}, Feuchte- min: $data{min2}, max: $data{max2}, last: $data{currval2}"
attr testwl plotfunction AussenTempHum
attr testwl room test

l.g. erwin

[tobias.faust]

Hi Erwin,

ein Test zu deinem Problem...

[Erwin]

Hi Tobias,
danke für die schnelle Reaktion, ein erster Test ergibt:
eine message ist weg,

was nach wie vor da ist:

Odd number of elements in hash assignment at /opt/lib/FHEM/93_DbLogMH.pm line 380.
Odd number of elements in hash assignment at /opt/lib/FHEM/93_DbLogMH.pm line 380.

... jeweils beim Aufruf des weblinks wie im vorigen post beschrieben.
...der resultierende plot schaut nach meinem Gefühl dennoch richtig aus!

Vielen Dank
erwin

[tobias.faust]

ich frag mich wo du die fehlermeldung siehst. Mein Log ist leer

[Daniel_K]

Hallo Tobias,

es stimmt ich habe sie auch, habe gerade meine Log geprüft uns siehe da, sie kommt vor jeder Abfrage:

Odd number of elements in hash assignment at /opt/fhem//FHEM/93_DbLog.pm line 304.
2012.12.06 16:58:13 0: Executing SELECT
        DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H:%i:%s'),
        DEVICE,
        READING,
        VALUE
		
       FROM history
       WHERE 1=1
        AND CONCAT(DEVICE,'|',READING) = ('wetter|Temp-inside')
        AND TIMESTAMP > STR_TO_DATE('2012-12-06 00:00:00', '%Y-%m-%d %H:%i:%s')
        AND TIMESTAMP < STR_TO_DATE('2012-12-07 00:00:00', '%Y-%m-%d %H:%i:%s')
       ORDER BY TIMESTAMP

bei mir steht das gleiche in Zeile 304 wie bei Erwin in Zeile 380

[Erwin]

Sorry, ich hatte gestern Abend anderweitige Verpflichtungen.
Die Meldung kommt in der Konsole, wenn du fhem über die Konsole startest (stderr - nehme ich an)

l.g. erwin

Am Donnerstag, 6. Dezember 2012 16:36:47 UTC+1 schrieb tobias.faust:

[tobias.faust]

nächster Test. Bei mir ist die Fehlermeldung jetzt weg...

[Erwin]

Hi Tobias,

jep, Fehlermeldung weg, alles funktioniert, soweit ich das sehen kann.

Danke für deinen support!!!

Wenn du interessiert bist, hab ich da noch  ein code snippet um WEATHER auch zu unterstützen....
im sub DbLog_ParseEvent als letztes elseif:

  # Weather
  elsif($type eq "WEATHER") {
     if($event =~ m(^wind_condition)) {
        @parts= split(/ /,$event); # extract wind direction from event
        if(defined $parts[0]) {
           $reading = "wind_direction";
           $value= $parts[2];
#           $unit= "";
        }
     }
     if($reading =~ m(^wind)) { $unit= "km/h"; } # wind, wind_speed
     if($reading eq "wind_chill") { $unit= "°C"; }
     if($reading eq "wind_direction") { $unit= ""; }
     if($reading =~ m(^temperature)) { $unit= "°C"; } # wenn reading mit temperature beginnt
     if($reading =~ m(^humidity)) { $unit= "%"; }
     if($reading =~ m(^pressure)) { $unit= "hPa"; }
     if($reading =~ m(^pressure_trend)) { $unit= ""; }
  }





l.g. erwin

[tobias.faust]

ist ergämzt. Bitte weiter testen. Ansonsten werd ich es am Wochenende in den FHEM-Mainstream einchecken.

[tobias.faust]

jetzt auch mit Anhang

[Erwin]

Danke nochmal,
melde mich morgen, nur falls ich Bugs sehe....;-)
Am Wochenende bin ich unterwegs - Weihnachtsstress .... ;-)))

Am Freitag, 7. Dezember 2012 14:36:39 UTC+1 schrieb tobias.faust:

jetzt auch mit Anhang

[Erwin]

Eines ist mir noch aufgefallen:
ein:
get my_DbLog - all 2012-12-04 2012-12-04_03:00:00 AussenTempHum:temperature:

...bringt folgenen output:
Timestamp: Device, Type, Event, Reading, Value, Unit =====================================================
2012-12-04 00:16:56: AussenTempHum, CUL_WS, C, temperature, -0.5,
....
da ist die Unit an der falschen Position...
l.g. erwin

[tobias.faust]

Hmm,

kann ich nicht bestätigen...
Wer kann das mal bitte gegenchecken??

Timestamp: Device, Type, Event, Reading, Value, Unit
=====================================================
2012-05-30 11:48:02: KS300, KS300, temperature: 15.3, temperature, 15.3, °C
2012-05-30 11:53:08: KS300, KS300, temperature: 15.2, temperature, 15.2, °C

[Daniel_K]

HalloTobias,

hab es bei mir geprüft, Ergebniss wie bei Dir => °C an letzter stelle.

MfG
Daniel

[Erwin]

Hi Tobias,

sorry für die Verwirrung, das war mein Fehler.....
Nachdem ich das EVENTS-feld nicht in die history-db schreibe, muß ich das auch beim auslesen berücksichtigen... (und zwar mehrmals...)

Sorry und danke für den Support!

l.g. erwin

Am Sonntag, 9. Dezember 2012 19:22:06 UTC+1 schrieb tobias.faust:

[tobias.faust]

Darf man fragen was du an dem dblog Modul verändert hast und warum?

[Erwin]

Hi Tobias,

Im wesentlichen:
1) ich schreibe das EVENT-Feld nicht in die history DB - redundante Info. datenbank minimierung....
2) ich setze beim Datenbank-schreiben generische defaults für UNITs, für temperatur, humidity, pressure, wind usw.
    Unter anderm auch weil ich nach wie vor Probleme mit der richtigen Darstellung (trotz UTF-8) vom ° (Grad Zeichen) in der DB bzw. mySQLAdmin habe.....
   z.b: if($reading eq 'temperature')  { $unit= "C"; }

[Andy Fuchs]

On 10.12.2012, at 18:30, Erwin <emens...@gmail.com> wrote:

m wesentlichen: 
1) ich schreibe das EVENT-Feld nicht in die history DB - redundante Info. datenbank minimierung....

Hi Erwin,

Das ist natürlich etwas unglücklich, denn wenn ich jetzt ein Update gemacht hätte, dann wären meine existierenden Clients futsch... Kannst Du das nicht mit einem Flag machen? Mich stört die Größe der Datenbank nicht.

2) ich setze beim Datenbank-schreiben generische defaults für UNITs, für temperatur, humidity, pressure, wind usw.
    Unter anderm auch weil ich nach wie vor Probleme mit der richtigen Darstellung (trotz UTF-8) vom ° (Grad Zeichen) in der DB bzw. mySQLAdmin habe.....
   z.b: if($reading eq 'temperature')  { $unit= "C"; }

Hm... diese Art der 'Problemlösung' finde ich auch nicht sehr elegant. Wäre es nicht vernünftiger, das Datenbank-Schema zu korrigieren? Ich hänge hier auf diversen SQLites, die das Problem nicht haben, sofern die Sourcen als UTF-8 eingecheckt sind (was ja bei fhem gewünschter Standard ist, wenn ich mich richtig erinnere).

Ausserdem hat das natürlich zur Folge, dass der Client doch wieder Heuristiken anstellen muss, anstatt die Unit einfach anzuhängen.

Auf gut deutsch heisst das, dass ich eigentlich gegen solche Diversifizierungen bin, um damit ganz andere Probleme zu kaschieren.

Gruß

andy

[tobias.faust]

Hi Andy,
die Info war nur für mich. War neugierig.
Die Punkte 1 und 2 schlagen sich nicht auf das Modul für die Allgemeinheit nieder.....
Übrigens, ich check das Modul jetzt in den Mainstream ein

[Andy Fuchs]

Hi Tobias,

Uff... Gut & danke für die Info - ich habe schon von meinem eigenen Branch geträumt :)

Andy

--
 
 

[Erwin]

Hi Andy,
sorry für die Verwirrung, war nur die Antwort auf die Frage von Tobias, was ich anders mache, und hat nichts mit dem modul im contrib / mainstream zu tun.
zu Pkt. 2...: Ich hab schon relativ viel probiert, das mit dem Grad zeichen richtig hinzubekommen, das dblog Modul ist UTF-8 (zeigt auch Grad richtig an), das mysql unit feld ist utf8_bin , auch utf8_gerneral_ci und utf8_unicode_ci hab ich probiert, es kommt immer unfug in der DB an.
Ich hab auch versucht $unit= x\{00B0}."C" zu kodieren, bringt's auch nicht...
Also wenn da jemand einen Tipp hätte..... (mySQL server version 5.1.36 ,phpMyAdminVersions: 3.3.5)

...Abgesehen davon: In Anbetracht der Varianten, wie z.b. temperatur dargestellt wird... (schau mal ins event feld und was das dblog modul alles anstellt, um daraus temperatur-wert und unit herauszufinden, find ich meinen Ansatz nicht so übel...
z.b. temperatur heisst immer temperatur und die unit ist grundsätzlich °C, falls wer andere units haben möchte, - kein Problem - code an EINER stelle anpassen....

l.g. erwin

[tobias.faust]

hmm, warum bekomme ich eine Fehlermeldung wenn ich jetzt das DbLogModul per "update" updaten möchte??

update 93_DbLog.pm

'93_DbLog.pm' not found.

[Markus Bloch]

Da die Files im Ordner "contrib" nicht via update Prozess verwaltet werden. Wenn du ein File aus dem contrib updaten willst, musst du es per Hand aus dem SVN laden (http://fhem.svn.sourceforge.net/viewvc/fhem/trunk/fhem/contrib/91_DbLog.pm).


Es sei denn jemand erklärt sich bereit das Modul zu betreuen (weiterentwickeln/bugfixing) und Support anzubieten, dann kann man es nach FHEM verschieben.

Viele Grüße
Markus

[tobias.faust]

ähem, es liegt im FHEM/93_DbLog.pm

[Markus Bloch]

sry, mein Fehler. :-/ 

Also bei mir ist die Datei via update installiert worden. Evtl. währe es ganz gut die Datei im contrib Ordner zu löschen.

Gruß

Markus

[tobias.faust]

eigentlich nicht, weil die nächsten VErsionen gibts erstmal nur im contrib. Erst wenn fertig gestetet ist will ich eine neue Version in den Meinstream schieben