DbLog: Anpassungen für Feldwerte mit | oder §

Begonnen von Reinerlein, 23 April 2017, 22:55:49

Vorheriges Thema - Nächstes Thema

Reinerlein

Hallo Tobias,

ich hatte das Problem, dass meine Sonos-Readings nicht korrekt in der Datenbank gelandet sind.
Daraufhin habe ich mir den Code mal angeschaut, und festgestellt, dass die Feldwerte vor dem asynchronen Schreiben in die Datenbank in Strings verpackt werden, die dann mittels | (bzw. mehrere Datensätze mit §) getrennt werden.
Da ich | auch in meinen Readings verwende, war das das Problem :)

Ich habe mich mal kurz drangemacht, und das ganze umgeschrieben. Ich habe die Variante mit Dumper zur Array -> Stringkonvertierung und eval zur String -> Arraykonvertierung verwendet. Damit können in den Feldwerten beliebige Zeichen vorkommen...

Im Anhang mal ein Diff meiner Anpassungen. Vielleicht kannst du das ja einarbeiten, bzw. eine eigene Lösung einchecken...
Es kann natürlich auch sein, dass ich nicht alle Stellen erwischt habe, die ich hätte erwischen sollen :) Deshalb meine Bitte, dass du dir das mal anschaust...

Danke schon mal...

EDIT: Anhang entfernt.

Grüße
Reinerlein

DS_Starter

Hallo Reinerlein,

danke für den Changevorschlag.  :)
Momentan bin ich unterwegs und kann mir es nicht genau anschauen, aber das mache ich gerne wenn ich wieder Zeit dazu habe.
Aber in der Zwischenzeit kannst du gerne mal eine Testversion in dem Thread https://forum.fhem.de/index.php/topic,65860.msg571048.html#msg571048 zur Verfügung stellen und gemeinsam mit den Mitstreitern testen lassen. Außer dem logging sollten auch die Funktionen listCache, exportCAche, importCachefile funktionieren,

VG
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Reinerlein

Hallo Heiko,

ok, ich habe nochmal bzgl. der von dir geschriebenen Funktionen geschaut.
Bei importCache fehlte das dann noch.

Allerdings sind jetzt natürlich die Formate für listCache und export/importCache andere. Vorher war es ein String, der die Felder mit | getrennt enthielt, jetzt ist es eine Perl-Array-Repräsentation (also so, wie man es in einem Perl Quelltext sxhreiben würde).
Das ist also nicht Abwärtskompatibel!

Außerdem habe ich bei der Angabe von ValueFn festgestellt, dass man keine Felder auf leer setzen konnte. Auch das war bei mir ein Problem, da ich prinzipiell keine Auftrennung in Einheit oder so brauchte, habe ich also meine eigene Auftrennfunktion eingesetzt, und das Feld Unit auf leer gesetzt. Es hatte dann immer den vom Modul erkannten und vorgegebenen Wert erhalten :)
Außerdem habe ich Readings, die tatsächlich leer sind. Das kommt bei Multimedia-Devices, die z.B. Titel oder ähnliches anzeigen häufiger vor. Dort stand dann im Feld Reading auch immer die Modulvorgabe.

Das habe ich durch entfernen des if-Statements hinter den beiden Variablen $reading und $unit nach der Auswertung der valueFn für mich gelöst. Für die Allgemeinheit sollte das vielleicht Attributgesteuert sein, oder das alte Verhalten ist wirklich nicht sooo wichtig :)

Im Anhang also ein aktualisierter Diff für diese Anpassungen..

Danke schon mal...

Grüße
Reiner