Autor Thema: 93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)  (Gelesen 8137 mal)

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1005
Antw:93_DbLog - Überlegungen zur weiteren Optimierung
« Antwort #30 am: 31 Januar 2017, 13:22:31 »
Hi,
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)
« Letzte Änderung: 31 Januar 2017, 13:34:26 von JoeALLb »
FHEM-Server auf IntelAtom+Debian (12 Watt),
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

Offline Garry Hayne

  • New Member
  • *
  • Beiträge: 39
Antw:93_DbLog - Überlegungen zur weiteren Optimierung
« Antwort #31 am: 31 Januar 2017, 13:32:35 »
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
Verschiedener Raspberry Pi's im Einsatz. Wohne wieder in meine Heimat Wales nach 32 Jahre in Deutschland. Spricht fliessend SQL, Deutsch, Englisch.

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1005
Antw:93_DbLog - Überlegungen zur weiteren Optimierung
« Antwort #32 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 0setzt, 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 (12 Watt),
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

Offline Garry Hayne

  • New Member
  • *
  • Beiträge: 39
Antw:93_DbLog - Überlegungen zur weiteren Optimierung
« Antwort #33 am: 31 Januar 2017, 14:17:11 »
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 0setzt, 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
Verschiedener Raspberry Pi's im Einsatz. Wohne wieder in meine Heimat Wales nach 32 Jahre in Deutschland. Spricht fliessend SQL, Deutsch, Englisch.

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1005
Antw:93_DbLog - Überlegungen zur weiteren Optimierung
« Antwort #34 am: 31 Januar 2017, 14:35:22 »
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 (12 Watt),
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

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1210
Antw:93_DbLog - Überlegungen zur weiteren Optimierung
« Antwort #35 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
ESXi 6.5 auf NUC6i5SYH mit FHEM Gastsystemen auf Debian 8 64 Bit  (Jessie) & Synology iSCSI-LUNs,
DbLog/DbRep mit MariaDB auf Synology,
Homematic, IT, FS20, Cams in Synology Surveillance Station (SSCAM), CUL 433, CUL 868, HM-CFG-LAN

Offline Garry Hayne

  • New Member
  • *
  • Beiträge: 39
Antw:93_DbLog - Überlegungen zur weiteren Optimierung
« Antwort #36 am: 31 Januar 2017, 14:40:27 »
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
Verschiedener Raspberry Pi's im Einsatz. Wohne wieder in meine Heimat Wales nach 32 Jahre in Deutschland. Spricht fliessend SQL, Deutsch, Englisch.

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1005
Antw:93_DbLog - Überlegungen zur weiteren Optimierung
« Antwort #37 am: 31 Januar 2017, 14:43:01 »
Hallo Heiko,

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 (12 Watt),
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

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1005
Antw:93_DbLog - Überlegungen zur weiteren Optimierung
« Antwort #38 am: 31 Januar 2017, 17:00:21 »
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.
« Letzte Änderung: 31 Januar 2017, 17:04:02 von JoeALLb »
FHEM-Server auf IntelAtom+Debian (12 Watt),
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

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1210
Antw:93_DbLog - Überlegungen zur weiteren Optimierung
« Antwort #39 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
« Letzte Änderung: 31 Januar 2017, 19:48:05 von DS_Starter »
ESXi 6.5 auf NUC6i5SYH mit FHEM Gastsystemen auf Debian 8 64 Bit  (Jessie) & Synology iSCSI-LUNs,
DbLog/DbRep mit MariaDB auf Synology,
Homematic, IT, FS20, Cams in Synology Surveillance Station (SSCAM), CUL 433, CUL 868, HM-CFG-LAN

Offline DeeSPe

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2659
  • Das könnte EINE mögliche Lösung sein...
Antw:93_DbLog - Überlegungen zur weiteren Optimierung
« Antwort #40 am: 01 Februar 2017, 04:30:43 »
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
FHEM 5.8, Brix, Debian Jessie, ZME_UZB1
HM-CFG-LAN, HM-MOD-UART-WIFI, HUE, HarmonyHub, JeeLink, CO20
Hyperion auf RPi Zero W, Sonos, viel Z-Wave und HM
alles per HomeKit steuerbar
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1210
Antw:93_DbLog - Überlegungen zur weiteren Optimierung
« Antwort #41 am: 01 Februar 2017, 08:26:46 »
Morgen Dan,

Zitat
Hab 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 6.5 auf NUC6i5SYH mit FHEM Gastsystemen auf Debian 8 64 Bit  (Jessie) & Synology iSCSI-LUNs,
DbLog/DbRep mit MariaDB auf Synology,
Homematic, IT, FS20, Cams in Synology Surveillance Station (SSCAM), CUL 433, CUL 868, HM-CFG-LAN

Offline Garry Hayne

  • New Member
  • *
  • Beiträge: 39
Antw:93_DbLog - Überlegungen zur weiteren Optimierung
« Antwort #42 am: 01 Februar 2017, 11:25:25 »
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
Verschiedener Raspberry Pi's im Einsatz. Wohne wieder in meine Heimat Wales nach 32 Jahre in Deutschland. Spricht fliessend SQL, Deutsch, Englisch.

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1210
Antw:93_DbLog - Überlegungen zur weiteren Optimierung
« Antwort #43 am: 01 Februar 2017, 18:54:05 »
Hi Dan,

Zitat
Meint 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 6.5 auf NUC6i5SYH mit FHEM Gastsystemen auf Debian 8 64 Bit  (Jessie) & Synology iSCSI-LUNs,
DbLog/DbRep mit MariaDB auf Synology,
Homematic, IT, FS20, Cams in Synology Surveillance Station (SSCAM), CUL 433, CUL 868, HM-CFG-LAN

Offline DeeSPe

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2659
  • Das könnte EINE mögliche Lösung sein...
Antw:93_DbLog - Überlegungen zur weiteren Optimierung
« Antwort #44 am: 02 Februar 2017, 10:52:31 »
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
FHEM 5.8, Brix, Debian Jessie, ZME_UZB1
HM-CFG-LAN, HM-MOD-UART-WIFI, HUE, HarmonyHub, JeeLink, CO20
Hyperion auf RPi Zero W, Sonos, viel Z-Wave und HM
alles per HomeKit steuerbar
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert

 

decade-submarginal