93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)

Begonnen von JoeALLb, 27 Januar 2017, 22:16:19

Vorheriges Thema - Nächstes Thema

JoeALLb

#30
Hi,
Zitat von: Garry Hayne am 31 Januar 2017, 13:09:21
hast du das am laufendem DbLog gemacht? Bei mir funkioniert es nicht.
Was genau funktioniert nicht? Das
attr DbLog colEvent 0?
oder das Löschen der bisherigen alten Einträge in der Tabelle zum herausfinden, wieviel Speicherplatz dadurch frei wird?

attr DbLog colEvent 0? klappt bei mir problemlos!

Die (Test-)Datenbank habe ich mit dem Trick bereinigt, den ich schon angegeben habe zum Konvertieren der
Datenbank nach Aria.

Edit: Habe die Anleitung in diesem Thread unter #1 nochmal vereinfacht angehängt.
(siehe https://forum.fhem.de/index.php/topic,65860.msg571050.html#msg571050)
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

ghayne

Zitat von: JoeALLb am 31 Januar 2017, 13:22:31
Hi,Was genau funktioniert nicht? Das
attr DbLog colEvent 0?
oder das Löschen der bisherigen alten Einträge in der Tabelle zum herausfinden, wieviel Speicherplatz dadurch frei wird?

attr DbLog colEvent 0? klappt bei mir problemlos!

Die (Test-)Datenbank habe ich mit dem Trick bereinigt, den ich schon angegeben habe zum Konvertieren der
Datenbank nach Aria. Siehe die ersten Punkte unter https://forum.fhem.de/index.php/topic,62998.msg568302.html#msg568302 (also anlegen einer neuen DB, umbenennen, bearbeiten, zurück umbenennen und zInhalte wieder zusammenführen)...

Hi,
dann muss ich history doch nachbearbeiten, ich dachte die EVENT werte werden einfach nicht geschrieben nachdem ich colEvent auf 0 gesetzt habe!

Regards, Garry

JoeALLb

Hinweis: Habe die Anleitung in diesem Thread unter #1 nochmal vereinfacht angehängt.
(siehe https://forum.fhem.de/index.php/topic,65860.msg571050.html#msg571050)


Wenn Du
attr DbLog colEvent 0
setzt, werden ab jetzt die neuen Logs ohne diese Spalte geschrieben.
Die bisherigen Datensätze, die schon in der Datenbank sind, werden dadurch natürlich nicht gelöscht!

Dazu müsstest Du etwas wie
update history set event='';
ausführen! Aber Achtung, die Daten sind dadurch gelöscht, und dieser Vorgang wird eine weile benötigen!
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

ghayne

Zitat von: JoeALLb am 31 Januar 2017, 13:36:42
Hinweis: Habe die Anleitung in diesem Thread unter #1 nochmal vereinfacht angehängt.
(siehe https://forum.fhem.de/index.php/topic,65860.msg571050.html#msg571050)


Wenn Du
attr DbLog colEvent 0
setzt, werden ab jetzt die neuen Logs ohne diese Spalte geschrieben.
Die bisherigen Datensätze, die schon in der Datenbank sind, werden dadurch natürlich nicht gelöscht!

Dazu müsstest Du etwas wie
update history set event='';
ausführen! Aber Achtung, die Daten sind dadurch gelöscht, und dieser Vorgang wird eine weile benötigen!

Leider wird EVENT immer noch geschrieben, selbst nach dem ich history geleert habe!

Garry

JoeALLb

Hallo Garry, versuch mal bitte ein
set <DEVICE> reopen oder sogar
einen Neustart von FHEM.
Hast Du die aktuelle Version von heute im Einsatz, ich habe nur diese getestet (2.11.1) aus dem
normalen FHEM-Update (oder von hier https://svn.fhem.de/trac/export/13289/trunk/fhem/FHEM/93_DbLog.pm)?

Ich habe diese getestet und bei mir hats wunderbar funktioniert.
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

DS_Starter

Hi Garry, Joe,

Sorry, habe nicht daran gedacht dass Harry ja SQLite hat. Die Beschneidung der Feldlänge haben wir bisher ja nur für Nicht-Sqlite implementiert weil SQLite DB das ja nicht benötigt für die ursprünglich gedachte Verwendung.
Könnte man natürlich leicht für alle DB's machen.

Was meint ihr ?

Grüße,
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

ghayne

Zitat von: DS_Starter am 31 Januar 2017, 14:37:31
Hi Garry, Joe,

Sorry, habe nicht daran gedacht dass Harry ja SQLite hat. Die Beschneidung der Feldlänge haben wir bisher ja nur für Nicht-Sqlite implementiert weil SQLite DB das ja nicht benötigt für die ursprünglich gedachte Verwendung.
Könnte man natürlich leicht für alle DB's machen.

Was meint ihr ?

Grüße,
Heiko

Ich werde mich freuen :)

Garry

JoeALLb

Hallo Heiko,

Zitat von: DS_Starter am 31 Januar 2017, 14:37:31
Sorry, habe nicht daran gedacht dass Harry ja SQLite hat. Die Beschneidung der Feldlänge haben wir bisher ja nur für Nicht-Sqlite implementiert weil SQLite DB das ja nicht benötigt für die ursprünglich gedachte Verwendung.
Könnte man natürlich leicht für alle DB's machen.

das hatte ich auch nicht mehr am Schirm!!
Natürlich ist es schöner, wenn die Funktionalität für alle Datenbanken gilt.
Dies liese sich hier ja relativ einfach umsetzen und bräuchte lediglich für das Setzen der Standardwerte ein anderes Vorgehen.


FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

JoeALLb

#38
Wunsch:
Was noch schön wäre ist eine Attribut, ähnlich wie bei Readingsgroups, mit dem ich Werte vor dem Einfügen in die Datenbank abändern kann.
Bei den Readingsgroups heißt eines dieser Attribute zB "valueFormat", welches ich nutzen kann um die Anzeigewerte komplett abändern.
Andere Module haben solche Funktionen auch, zB splitFn, pidActorCallBeforeSetting in PID20, ...

Abtuell nutze ich eine stored Procedure in MySQL, um gewisse Werte, die DbLog nicht korrekt einträgt,
umzuschreiben:
Beispiel:

if
  (New.TYPE='CUL_EM'  and New.READING='total') then Set New.value = CAST(New.value AS DECIMAL(8,4));
ELSEIF
  (New.TYPE='CUL_EM'  and New.READING='power') then Set New.value = CAST(New.value AS DECIMAL(8,4));
ELSEIF
  (New.TYPE='OWTHERM'  and New.READING='data') then Set New.value =digits(New.value);
ELSEIF
  (New.event ='yowsup:who') then Set New.value = digits(New.value);
END IF


Da für FHEM eine Stored procedure zu komplex sein dürfte und diese nicht datenbankübergreifend kompatibel ist,
wäre es schön, dafür einfach Perl nutzen zu können!
Auch wenn DbLog irgendwann keine Schwierigkeiten mehr mit Units hat, sehe ich dann immernoch ein Anwendungsgebiet
für diese Funktion. Man könnte damit beispielsweise bestimmte Readings runden, werte wie "set Heizung Eco"
umwandeln in "set Heizung 17°", etc.

Beispiel für Möglichkeiten mi valueFormat:
{
   if( $READING eq "humidity" && $VALUE  =~ /^hu/ ) {    $VALUE = "%";  }
   elsif( $VALUE  ==  1 ) {    $VALUE = "&nbsp;"}
   elsif( $VALUE  eq "state" ) {    $VALUE = " "}
   elsif( $VALUE  eq "positionCombi" ) {    $VALUE = " "} 
}


Diese könnte zB "insertFormat" heißen.
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

DS_Starter

#39
Hallo Garry, @all,

mit der angehängten Version 2.11.2 gelten die Feldlängenbegrenzungen mit den Attributen colEvent, colReading und colValue auch für SQLite Datenbanken. Es wird nun auch bei SQLite mit colEvent=0 das Feld EVENT nicht gefüllt.

HINWEIS:
Um die Kompatibilität mit dem bisherigen Verhalten keine Feldlängenbegrenzung bei SQLite vorzunehmen zu erhalten, gelten die Feldlängenbegrenzungen bei SQLite erst dann wenn eines der oben genannten Attribute gesetzt wird. Dann gelten aber ALLE im Internal COLUMNS angezeigten Feldlängen.
Unter Umständen sind sie dann anzupassen.

Garry, probiers mal bei dir aus. Denke es passt so...  :)

Grüße
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

DeeSPe

Hab mir mal die Importfunktion angesehen.
Irgendwie ist die nicht so ganz wie ich mir das vorstellen würde (IMHO). ???
Das FileLogConvert Modul habe ich nun komplett non-blocking gemacht. Meint Ihr wir könnten den Import so ähnlich (etwas benutzerfreundlicher) integrieren?
Möchte jetzt nicht behaupten dass mein Modul "Das Gelbe vom Ei" ist, aber ich denke zumindest etwas benutzerfreundlicher.
Oder man lässt das Modul wirklich separat zu DbLog. Schadet erstens der Übersicht nicht und man kann die Konvertierungsfunktionen mit dem FileLogConvert Device nach der Migration entsorgen, die braucht man dann wohl eh nie wieder... ;)

Gruß
Dan
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

DS_Starter

Morgen Dan,

ZitatHab mir mal die Importfunktion angesehen.
Irgendwie ist die nicht so ganz wie ich mir das vorstellen würde

Das war auch nur ein Beispiel um in die Funktionsweise reinzukommen. Klar dass die Convert-Funktion andere Anforderungen hat.
Aber prima dass du dein Modul hast umstellen können  :)

Ich muß es auch mal ausprobieren um ein Gefühl für das Handling zu bekommen. Schön wäre wohl schon eine Integration in DbLog. Aber das können wir jederzeit noch machen und muß ja nicht gleich sein. Wie du schon sagst kann man es ja auch separat super nutzen.

Grüße
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

ghayne

Zitat von: DS_Starter am 31 Januar 2017, 19:44:29
Hallo Garry, @all,

mit der angehängten Version 2.11.2 gelten die Feldlängenbegrenzungen mit den Attributen colEvent, colReading und colValue auch für SQLite Datenbanken. Es wird nun auch bei SQLite mit colEvent=0 das Feld EVENT nicht gefüllt.

HINWEIS:
Um die Kompatibilität mit dem bisherigen Verhalten keine Feldlängenbegrenzung bei SQLite vorzunehmen zu erhalten, gelten die Feldlängenbegrenzungen bei SQLite erst dann wenn eines der oben genannten Attribute gesetzt wird. Dann gelten aber ALLE im Internal COLUMNS angezeigten Feldlängen.
Unter Umständen sind sie dann anzupassen.

Garry, probiers mal bei dir aus. Denke es passt so...  :)

Grüße
Heiko

Heiko,

werde ich Heute probieren.
Ich habe am Stromkasten von eine Rasperry Pi 1 zum Zero gewechselt und habe Probleme mit timing irgendwie (Ich habe dazu ein neue thread geoeffnet).

Regards, Garry

DS_Starter

Hi Dan,

ZitatMeint Ihr wir könnten den Import so ähnlich (etwas benutzerfreundlicher) integrieren?

Hab mal einen Blick drauf geworfen. Also ich denke das kriegen wir bestimmt so nutzerfeundlich integriert. Ich habe erst am WE wieder mehr Zeit.
Dann schau eich es mir mal genauer an wie das zu machen wäre .
Ich bin ein echter Fan von Rudis Blocking.pm und mache viel damit. Ist einen feine Sache...

Schönen Abend und bis später mal ...
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

DeeSPe

Zitat von: DS_Starter am 01 Februar 2017, 18:54:05
Hi Dan,

Hab mal einen Blick drauf geworfen. Also ich denke das kriegen wir bestimmt so nutzerfeundlich integriert. Ich habe erst am WE wieder mehr Zeit.
Dann schau eich es mir mal genauer an wie das zu machen wäre .
Ich bin ein echter Fan von Rudis Blocking.pm und mache viel damit. Ist einen feine Sache...

Schönen Abend und bis später mal ...
Heiko

Wie so ziemlich alles in FHEM ist auch BlockingCall toll, wenn man erst mal begriffen hat wie es funktioniert und wie man es einsetzt.
Jetzt wo ich weiß wie es geht, werden sich sicherlich zukünftig weitere Anwendungsbereiche ergeben...

Gruß
Dan
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe