SVG Fehlermeldung nach Umstellung auf DbLog

[fhem-me]

Habe nun von FileLog auf DbLog umgestellt.
Dabei musste ich feststellen das ich Fehler bei der Darstellung der Plots bei meinen ZWAVE Werten erhalte.

Code Auswählen Erweitern

PERL WARNING: Argument "140 Lux" isn't numeric in sprintf at ./FHEM/98_SVG.pm line 1946.
Im Dump der Datenbank fand ich dann

Code Auswählen Erweitern

INSERT INTO "history" VALUES('2015-04-03 13:43:27','Sensor','ZWAVE','luminance: 140 Lux','luminance','140 Lux','');
Eigentlich sollte Lux in der letzten Spalte stehen. Nun hatte ich erst meinen Import der FileLog ins DbLog in Verdacht. Aber nachdem ich das alles korrigiert hatte kam weiter die PERL WARNING
Im 93_DbLog.pm bin ich dann fündig geworden - hier wird für Module wie ZWAVE die Einheit nicht korrekt aufgespalten.
Hier mein Patch mit dem DbLog korrekt die Einheit nach numerischen Werten extrahiert:

Code Auswählen Erweitern


161,164d160
<   # extract unit - must be a suffix to number
<   } elsif (@parts == 1 && $parts[0] =~ /^(.*\d) (\D+)$/) {
<     $value = $1;
<     $unit  = $2;


[Tobias]

Sorry,  nein... Das ist Aufgabe des ZWAVE Moduls die DbLog_SplitFn zu implementieren. Hat im DBLog nichts mehr zu suchen. Die aktuellen Einträge im DBLogModul fliegen mittelfristig auch alle raus und werden in die spezifischen Module verlagert

[fhem-me]

nun gut - hätte zwar erwartet das ZWave Events nicht anders aussehen als die Standard Events, aber wenn es sein muss anbei mein Patch mit DbLog_splitFn
[basiert auf $Id: 10_ZWave.pm 8552 2015-05-09 11:01:02Z rudolfkoenig $]

***update***
musste beim Rückbau der DbLog feststellen das ich auch bei FHEM2FHEM im Probleme laufe.
Sehe daher doch bei DbLog Handlungsbedarf.

[losh]

Sorry, dass ich den wieder ausgrabe, aber wie ist denn hier der Stand? Der patch scheint das svn wohl nie erreicht zu haben, da ich das gleiche Problem habe und ich in der 10_ZWave.pm keine "DbLog_SplitFn" finde (oder bin ich blind?)

[losh]

Ich formuliere meine Frage mal anders: was passiert bei einem Fhem-Update mit meiner modifizierten 10_ZWave.pm?

[krikan]

http://www.fhem.de/commandref.html#update: wird überschrieben*, wenn 10_ZWave.pm nicht im Attribut exclude_from_update steht.
Würde die Aufnahme in exclude_from_update aber genau überlegen -> Support grds. nur für aktuelles Fhem (10_ZWave.pm)

Mir erschließt sich nicht, wieso für Dblog jetzt jedes Modul eine Extra-Funktion haben sollte: Ist das nicht eine Aufgabe von Dblog sich das passend zu machen?


* besser: verschoben in das entsprechenden restoreDir-Verzeichnis

[losh]

Danke für deine Anwort, krikan.
Bitte entschuldige meine Unwissenheit. Mein Wissen beschränkt sich auf das, was ich diesem Forum entnehme und so wie ich das verstanden habe, müssen sollen modulspezifische Anpassungen in den jeweiligen Modulen implementiert werden.

Konkrete Frage: wie würdest du persönlich dieses Problem sauber lösen?

[krikan]

Brauchst Dich nicht entschuldigen.

so wie ich das verstanden habe, müssen sollen modulspezifische Anpassungen in den jeweiligen Modulen implementiert werden.

Lese ich auch so. Verstehe ich aber in diesem Fall nicht und müssten die Developer Tobias und rudolfkoenig untereinander regeln.

Konkrete Frage: wie würdest du persönlich dieses Problem sauber lösen?

Keine Ahnung, da ich aus diversen Gründen persönlich kein Dblog nutze. Grds. vermeide ich eigene Anpassung an Modulen bzw. liefere das als Patchvorschlag, so dass es ggfs. ins offizielle SVN kommt.

[Tobias]

Hi,

Ist das nicht eine Aufgabe von Dblog sich das passend zu machen?

DbLog kann nicht für alle 100 Module Konvertierungroutinen einbauen. Wenn der Modulentwickler was ändert müsste das dann immer im DBLog Modul nachgezogen werden.
Der spezifische Modulentwickler ist allein für verantwortlich eine saubere Aufschlüsselung von ReadingName, Value, Unit bereitzustellen

[krikan]

Hallo Tobias!

Der spezifische Modulentwickler ist allein für verantwortlich eine saubere Aufschlüsselung von ReadingName, Value, Unit bereitzustellen

Ok, da halte ich mich raus; sind Eure Entscheidungen und ist für mich zu sehr in den Internas  .

Für @losh heißt das:
Um DBLog mit ZWave sinnvoll nutzen zu können, muss losh Rudi einen Patch für die ZWave-Module einreichen.

Tobias, hattest Du Edit im obigen Beitrag von fhem-me mit dem (zurückgezogenen) Patch für ZWave gesehen, der auch bei DBlog Handlungsbedarf sah?

Gruß, Christian

[losh]

Danke für eure Antworten! Gibt es hier irgendwelche Konventionen für das Einreichen von Patches?

Gesendet von meinem SM-G900F mit Tapatalk

[krikan]

Schau mal: http://www.fhemwiki.de/wiki/How_to_write_a_patch

[losh]

Danke! Bin dann mal raus hier.

Gesendet von meinem SM-G900F mit Tapatalk

[fhem-me]

Ich will doch noch einmal höflich nachfragen:

DbLog kann nicht für alle 100 Module Konvertierungroutinen einbauen. Wenn der Modulentwickler was ändert müsste das dann immer im DBLog Modul nachgezogen werden.
Der spezifische Modulentwickler ist allein für verantwortlich eine saubere Aufschlüsselung von ReadingName, Value, Unit bereitzustellen

Bei ZWave sehe ich das ein - das ist für mich vollkommen OK.
Jedoch hat FHEM2FHEM keine Chance hier einzugreifen.
Braucht nach dieser Logik jedes Modul demnach auch ein FHEM2FHEM_SplitFn?