Moin,
Ich habe die tage mal mein dblogfile angesehen und es war mit knapp 3gb recht groß in knapp einem Jahr, fhem dadurch etwas träge (Plots).
Mir fiel auf das man für gezieltes loggen mit dblog im Gegensatz zu FileLog viel mehr Aufwand betreiben muss um dies zu konfigurieren.
(bei FileLog einfach autocreate aus und nicht mehr kümmern, bei zu loggenden devices einfach das File mit entsprechenden readings die zu loggen sind definieren)
Das fängt damit an das man DbLog nicht ohne regexp definieren kann. ohne regexp würde DbLog erst einmal nichts loggen, wäre aber bereit zur Nutzung. das wäre ein optimaler Ausgangspunkt.
In devices kann man nur mit DbLogExclude arbeiten, ein DbLogInclude wäre wünschenswert. Warum? Am Beispiel eines HM-CC-RT Clima-Channel oder Sysmon-Device ist das einfach erklärt.
Bei sysmon will ich nun cpu_temp, cpu0_freq und cpu1_freq loggen. ich muss also ein
attr Sysmon DbLogExclude cpu_bogomips,cpu_temp_avg,eth0,eth0_diff,eth0_ip,fhemuptime,fhemuptime_text,idletime,idletime_text,loadavg,perl_version,power_ac_stat,power_ac_text,power_battery_info,power_battery_stat,power_battery_text,power_usb_stat,power_usb_text,ram,root,stat_cpu,stat_cpu0,stat_cpu0_diff,stat_cpu0_percent,stat_cpu0_text,stat_cpu1,stat_cpu1_diff,stat_cpu1_percent,stat_cpu1_text,stat_cpu_diff,stat_cpu_percent,stat_cpu_text,swap,uptime,uptime_text,wlan0,wlan0_diff bei einem device mit 40 readings sehr umständlich
nehmen statt der einfachen Version wenn es einen DbLogInclude gäbe
attr Sysmon DbLogInclude cpu_temp, cpu_freq,cpu1_freq
oder device komplett
attr Sysmon DbLogInclude .*
mein aktueller Workaround:
dblog logged alles, neue devices bekommen autom. ein blog exclude verpasst.
-> evtl. auch eine Option: in dblog eine Art attr <dblog> autolog off / oder 0 was dazu führt das DbLogInclude .* autom. gesetzt wird.
Bestehenden devices habe ich DbLogExclude .* per attr .* DbLogEnclude .* und erstmal grob die wieder inkludiert die ich loggen will deleteattr TYPE=CUL_HM DbLogEnclude
nun wäre der schritt noch alle nicht gewünschten readings zu excluden.
Ein define dblog DbLog <conffile> .*:(temperature|valveposition|humidity).* wäre genau so umständlich wie das 3 Zeilen Exclude im Sysmon wenn man viele untersch. devices hat die man teilweise vollständig loggen will. mehrere regexp in der DEF gehen scheinbar auch nicht, so das man ggf, div. typen angeben kann + div. Namensgebungen
sowas wie define <> dblog file TYPE=CUL_HM, .*._HZ_Clima, az_.*.:temperature, bla:bla
Sinnvoller ist es meist, die gewünschten Readings in der DB-Log-Definition zu hinterlegen.
In den einzelnen Devices ist dann keine weiter Definition für DbLog erforderlich.
Sieht bei mir zB so aus
def DbLog DbLog dblog.conf .*(Katzenklappe.Sensor|Thermostat_Climate|Fenster(|.L|.M|.R)|_Pwr|Heizung(|.L|.R)_Clima|Luefter|Kuehlschrank|Spuelmaschine|Gas7[02]|Strom(70|72|.EDV)|Helligkeit|[Tt]emperatur|Temp|Wetter|Twilight|dunkel|Klingeltaster):(ValvePosition|window|consumption.*|controlMode|cooling|working|current|desired-temp|humidity|inside|kWh_[tl].*|level|measured-temp|power|temperature|total|twilight|time_[01]|ring).*
Hallo,
nachdem ich kürzlich auch auf dblog umgestellt habe bin ich auf diesen Thread gestoßen und dachte mir, den muss man doch nochmal hoch holen.
Ich wünsche mir eigentlich das selbe wie chris1284 und arbeite im Moment auch genau so: DBLog loggt alles und per und bei jedem einzelnen Device wird aber erst mal alles wieder per DBLogExclude ausgeschlossen. Bei Bedarf werden dann dort die RegEx(en) entsprechend angepasst, was aber bei einem Device mit vielen Readings, von denen man evtl. nur 2 oder 3 im Log braucht recht aufwändig sein kann. Außerdem ändern sich Readings ja auch gelegentlich mal. (Bspw. nach einem Update oder nach einem Peering)
Ich musste also relativ schnell feststellen, dass ein DBLogInclude die einfachere Methode sein könnte: Sprich standardmäßig wird nichts geloggt, außer dem was in DBLogInclude eingetragen ist.
Gruß Benni.
Moin,
ein dbloginculde hatte ich auch vor einiger Zeit mal vorgeschlagen. Mindestens genau so interessant wäre aber die Möglichkeit die Datenbank zu verdichten, soll heißen die Auflösung/Frequenz der Daten wird mit fortschreitender Zeit immer geringer. Vielleicht könnte sowas sogar ein Script übernehmen.
Grüße,
Markus
Das ist sicherlich interessant, wäre aber doch eigentlich eher Datenbankmanagement an sich und gehört damit m.E. nicht in das DBLog-Modul.
Gruß Benni.
Hallo,
ich habe das bei mir mal ausprobiert und bei mir ein Attribut DbLogInclude eingebaut, ebenso wie ein Attribut am DbLog-Device (DbLogSelectionMode), mit dem das Handling der device-spezifischen Attribute DbLogExclude und DbLogInclude festgelegt werden kann.
Ich bin jetzt (noch) nicht so der Perl-Programmierer, deshalb kann man das eventuell auch noch eleganter lösen, es hat aber bei mir in ersten Tests soweit sehr gut funktioniert.
Ein Patch zur aktuell im SVN vorhandenen Version von 93_DbLog.pm habe ich mal angehängt. Es enthält auch die entsprechend erweiterte Doku in beiden Sprachen.
Vielleicht kann es ja so, oder so ähnlich in DbLog integriert werden. 8)
Kurz zur Funktionsweise:Es gibt analog zu
DbLogExclude eine Attribut
DbLogInclude, das an alle devices propagiert wird.
Weiterhin gibt es, wie oben schon erwähnt ein neues Attribut
DbLogSelectionMode, dass festlegt, wie DbLogExclude und DbLogInclude behandelt werden sollen:
DbLogSelectionMode kann dabei folgende 3 Werte haben:
- Exclude: DbLog verhaelt sich wie bisher auch, alles was ueber die RegExp im DEF angegeben ist, wird geloggt, bis auf das, was ueber die RegExp in DbLogExclude ausgeschlossen wird. Das Attribut DbLogInclude wird in diesem Fall nicht beruecksichtigt
- Include: Es wird nur das geloggt, was ueber die RegExp im DEF angegenben wurde und sonst nichts, es sei denn es wird ueber die RegExp in DbLogInclude eingeschlossen.Das Attribut DbLogExclude wird in diesem Fall nicht beruecksichtigt.
- Exclude/Include: Funktioniert im Wesentlichen, wie "Exclude", nur das sowohl DbLogExclude, als auch DbLogInclude geprueft werden: Readings, die durch DbLogExclude zwar ausgeschlossen wurden, mit DbLogInclude aber wiederum eingeschlossen werden, werden somit dennoch geloggt.
Wird DbSelectionMode nicht angegeben, so wird
Exclude als Default angenommen, damit verhält sich DbLog ohne die Angabe des Attributes also genau so wie bisher (=abwärtskompatibel).
tobiasfaust ggf anschreiben ;) damkt er die,wirklich nützlichen, änderungen einpflegt
Hallo Chris,
danke für den Hinweis, ich habe ihm mal eine PM geschickt.
Mal sehen, was draus wird :)
Gruß Benni.
Ist im nächste Release mit drin. Danke!
Freut mich! 8)
Kannst du denn schon sagen, wann das in etwa sein wird?
Nachdem man ja nicht so genau weiß, wie lange es noch dauert, bis die Änderungen in die produktive Version integriert sein werden, veröffentliche ich hier auch mal noch das gesamte geänderte Modul (Basis war Version
6573 2014-09-19 17:08:11Z), damit evtl. gleich noch mehr Leute die Funktionalität testen können.
Zur Installation:
- Backup machen! (von FHEM und Datenbank in die geloggt wird)
- Das hier angehängte Modul im fhem-Verzeichnis unter FHEM/ ablegen (i.d.R. /opt/fhem/FHEM) und FHEM neu starten (shutdown restart).
- Modul-Doku lesen (in der Kommandozeile in FHEMWEB help DbLog eingeben.
!!! Unbedingt Beachten:
- Bei einem regulären update des Moduls wird das nach obiger Methode installierte natürlich wieder überschrieben.
- Eventuell wird die Implementierung vom eigentlichen Modul-Maintainer später nicht 1:1 übernommen, was dann zu Fehlfunktionen und erhöhtem Anpassungsaufwand nach einem regulären update führen kann.
Ich habe das Modul inzwischen übrigens in meiner produktiven FHEM-Installation laufen. 8)
Zitat von: Benni am 01 Mai 2015, 12:57:40
!!! Unbedingt Beachten:
- Bei einem regulären update des Moduls wird das nach obiger Methode installierte natürlich wieder überschrieben.
- Eventuell wird die Implementierung vom eigentlichen Modul-Maintainer später nicht 1:1 übernommen, was dann zu Fehlfunktionen und erhöhtem Anpassungsaufwand nach einem regulären update führen kann.
Um diese Probleme zu umgehen, kann man das (globale) Attribut
exclude_from_update (siehe commandref) benutzen ... muss dann natürlich irgendwann mal wieder entfernt werden, sobald die Änderungen offiziell sind und im regulären Update kommen.
Peter
Zitat von: ph1959de am 01 Mai 2015, 16:24:17
Um diese Probleme zu umgehen, kann man das (globale) Attribut exclude_from_update (siehe commandref) benutzen ... muss dann natürlich irgendwann mal wieder entfernt werden, sobald die Änderungen offiziell sind und im regulären Update kommen.
Tatsächlich habe ich das bei mir auch so gemacht 8) und mir den Hinweis darauf auch absichtlich gespart. Denn wie du geschrieben hast, ist das nur ein Umgehen, bzw. Verscheiben der Probleme und man muss zusätzlich noch beachten, bzw. im Hinterkopf behalten, dass man ein reguläres Update damit verhindert. ;)
Btw. ich weiß gar nicht, ob bei einem update check überhaupt auf ein solche vom Update ausgeschlossenen Files hingewiesen wird oder nicht ???Hab's gerade getestet: Auf solche Files wird dabei
nicht hingewiesen!
Hi,
testet mal bitte... hier sind mehrere Patches drin:
- SuppressUndef (http://forum.fhem.de/index.php/topic,36615.msg289041.html)
- Hinzufügen von Anfang und Ende-Werten beim Ploten in engen Grenzen (http://forum.fhem.de/index.php?topic=34006)
- 93_DbLog_DbLogInclude.diff
- 93_DbLog_dbReadings_using_DbLogType.diff
Nach OK, checke ich es ein...
Hallo Tobias,
es war bei DbLogInclude doch noch ein kleiner Fehler drin. :-[
Beim reinen "Include" - Modus und Komplettausschluß aller events im DEF (bspw. mit none:none als RegEx) ist die Anwendung nie in den Überprüfungszweig gelaufen. Ich habe das entsprechend in Zeile 525 so angepasst, dass bei Include grundsätzlich auch die restliche Überprüfung durchgeführt wird.
(Es ist übrigens tatsächlich sogar so, dass bei Include die Angabe der RegEx in DEF grundsätzlich ignoriert wird, und auch nur geloggt wird, was per DbLogInclude eingeschlossen wird -> Doku angepasst)
Außerdem waren in der Doku noch ein paar Formatierungen nicht ganz in Ordnung, die habe ich ebenfalls gleich noch angepasst.
Ich hänge hier einfach mal das komplette Modul (auf Basis deiner Testversion) mit den o.a. Änderungen hier an.
Gruß Benni.
Super, danke..... Altes MOdul aus meinem Post gelöscht...
Könnte man noch bei den FBDECT was ändern?
Wenn man Statistics verwendet, werden die Statistikwerte nicht richtig geloggt.
Hier läuft FBDECT mit einen Fritz!Powerline546E.
Ich habe bei mir es wie folgt angepasst gehabt:
# FBDECT
elsif (($type eq "FBDECT")) {
+ if ( $reading =~ m/(power|voltage|current|energy)/) {
if ( $value=~/([\.\d]+)\s([a-z])/i ) {
$value = $1;
$unit = $2;
}
+ }
}
Danke, habs probiert - FHEM läuft noch - paar kleine Meldungen sind noch im LOG:
2015.05.02 20:06:16 1: PERL WARNING: Use of uninitialized value in numeric lt (<) at (eval 4359) line 1.
2015.05.02 19:55:56 1: PERL WARNING: Use of uninitialized value in numeric eq (==) at ./FHEM/93_DbLog.pm line 1153.
2015.05.02 19:55:56 1: PERL WARNING: Use of uninitialized value $sqlspec{"day_before"} in concatenation (.) or string at ./FHEM/93_DbLog.pm line 948.
2015.05.02 19:55:56 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/93_DbLog.pm line 927.
Die eine Warnung (s.u.) finde ich auch insgesamt 3 mal in meinem log, seit ich heute Mittag die erste Testversion eingespielt habe. Kann es aber keinem Ereignis wirklich zuordnen:
2015.05.02 17:26:41 1: PERL WARNING: Use of uninitialized value in numeric eq (==) at ./FHEM/93_DbLog.pm line 1153.
Ich habe zum ang. Zeitpunkt nicht mal einen Log-Eintrag auf der DbLog-Datenbank, dem ich das zuordnen könnte.
@stromer-12: Sorry, nein... Das ist Aufgabe des FBDECT Moduls die DbLog_SplitFn (http://www.fhemwiki.de/wiki/DevelopmentModuleIntro#X_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
So....hab das jetzt auch mal testen können - sieht für mich soweit erstmal gut aus. :)
Die Änderungen welche meine Punkte betrafen funktionieren wie bisher jetzt auch und ich hatte sonst auch keine Fehler bekommen...
Viele Grüße
Michael
Jetzt endlich committed.
Hallo,
nach einem Update heute, stürzt mein fhem sobald ich eine Seite mit Plots anzeigen lasse nach einer ganzen Reihe von PERL Warnings einfach ab:
... sehr viele gleiche Warnings aus Zeile 1153
2015.05.18 14:09:25 1: PERL WARNING: Use of uninitialized value in numeric eq (==) at ./FHEM/93_DbLog.pm line 1153.
2015.05.18 14:09:25 3: stacktrace:
2015.05.18 14:09:25 3: main::__ANON__ called by ./FHEM/93_DbLog.pm (1153)
2015.05.18 14:09:25 3: main::DbLog_Get called by fhem.pl (3022)
2015.05.18 14:09:25 3: main::CallFn called by fhem.pl (1557)
2015.05.18 14:09:25 3: main::CommandGet called by fhem.pl (1032)
2015.05.18 14:09:25 3: main::AnalyzeCommand called by ./FHEM/01_FHEMWEB.pm (2017)
2015.05.18 14:09:25 3: main::FW_fC called by ./FHEM/98_logProxy.pm (820)
2015.05.18 14:09:25 3: main::logProxy_Get called by fhem.pl (3022)
2015.05.18 14:09:25 3: main::CallFn called by fhem.pl (1557)
2015.05.18 14:09:25 3: main::CommandGet called by fhem.pl (1032)
2015.05.18 14:09:25 3: main::AnalyzeCommand called by fhem.pl (905)
2015.05.18 14:09:25 3: main::AnalyzeCommandChain called by ./FHEM/01_FHEMWEB.pm (2020)
2015.05.18 14:09:25 3: main::FW_fC called by ./FHEM/98_SVG.pm (1115)
2015.05.18 14:09:25 3: main::SVG_getData called by ./FHEM/98_SVG.pm (1083)
2015.05.18 14:09:25 3: main::SVG_doShowLog called by ./FHEM/98_SVG.pm (959)
2015.05.18 14:09:25 3: main::SVG_showLog called by ./FHEM/01_FHEMWEB.pm (649)
2015.05.18 14:09:25 3: main::FW_answerCall called by ./FHEM/01_FHEMWEB.pm (424)
2015.05.18 14:09:25 3: main::FW_Read called by fhem.pl (3022)
2015.05.18 14:09:25 3: main::CallFn called by fhem.pl (643)
2015.05.18 14:09:25 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/93_DbLog.pm line 927.
2015.05.18 14:09:25 3: stacktrace:
2015.05.18 14:09:25 3: main::__ANON__ called by ./FHEM/93_DbLog.pm (927)
2015.05.18 14:09:25 3: main::DbLog_Get called by fhem.pl (3022)
2015.05.18 14:09:25 3: main::CallFn called by fhem.pl (1557)
2015.05.18 14:09:25 3: main::CommandGet called by fhem.pl (1032)
2015.05.18 14:09:25 3: main::AnalyzeCommand called by ./FHEM/01_FHEMWEB.pm (2017)
2015.05.18 14:09:25 3: main::FW_fC called by ./FHEM/98_logProxy.pm (820)
2015.05.18 14:09:25 3: main::logProxy_Get called by fhem.pl (3022)
2015.05.18 14:09:25 3: main::CallFn called by fhem.pl (1557)
2015.05.18 14:09:25 3: main::CommandGet called by fhem.pl (1032)
2015.05.18 14:09:25 3: main::AnalyzeCommand called by fhem.pl (905)
2015.05.18 14:09:25 3: main::AnalyzeCommandChain called by ./FHEM/01_FHEMWEB.pm (2020)
2015.05.18 14:09:25 3: main::FW_fC called by ./FHEM/98_SVG.pm (1115)
2015.05.18 14:09:25 3: main::SVG_getData called by ./FHEM/98_SVG.pm (1083)
2015.05.18 14:09:25 3: main::SVG_doShowLog called by ./FHEM/98_SVG.pm (959)
2015.05.18 14:09:25 3: main::SVG_showLog called by ./FHEM/01_FHEMWEB.pm (649)
2015.05.18 14:09:25 3: main::FW_answerCall called by ./FHEM/01_FHEMWEB.pm (424)
2015.05.18 14:09:25 3: main::FW_Read called by fhem.pl (3022)
2015.05.18 14:09:25 3: main::CallFn called by fhem.pl (643)
2015.05.18 14:09:25 1: PERL WARNING: Use of uninitialized value $sqlspec{"day_before"} in concatenation (.) or string at ./FHEM/93_DbLog.pm line 948.
2015.05.18 14:09:25 3: stacktrace:
2015.05.18 14:09:25 3: main::__ANON__ called by ./FHEM/93_DbLog.pm (948)
2015.05.18 14:09:25 3: main::DbLog_Get called by fhem.pl (3022)
2015.05.18 14:09:25 3: main::CallFn called by fhem.pl (1557)
2015.05.18 14:09:25 3: main::CommandGet called by fhem.pl (1032)
2015.05.18 14:09:25 3: main::AnalyzeCommand called by ./FHEM/01_FHEMWEB.pm (2017)
2015.05.18 14:09:25 3: main::FW_fC called by ./FHEM/98_logProxy.pm (820)
2015.05.18 14:09:25 3: main::logProxy_Get called by fhem.pl (3022)
2015.05.18 14:09:25 3: main::CallFn called by fhem.pl (1557)
2015.05.18 14:09:25 3: main::CommandGet called by fhem.pl (1032)
2015.05.18 14:09:25 3: main::AnalyzeCommand called by fhem.pl (905)
2015.05.18 14:09:25 3: main::AnalyzeCommandChain called by ./FHEM/01_FHEMWEB.pm (2020)
2015.05.18 14:09:25 3: main::FW_fC called by ./FHEM/98_SVG.pm (1115)
2015.05.18 14:09:25 3: main::SVG_getData called by ./FHEM/98_SVG.pm (1083)
2015.05.18 14:09:25 3: main::SVG_doShowLog called by ./FHEM/98_SVG.pm (959)
2015.05.18 14:09:25 3: main::SVG_showLog called by ./FHEM/01_FHEMWEB.pm (649)
2015.05.18 14:09:25 3: main::FW_answerCall called by ./FHEM/01_FHEMWEB.pm (424)
2015.05.18 14:09:25 3: main::FW_Read called by fhem.pl (3022)
2015.05.18 14:09:25 3: main::CallFn called by fhem.pl (643)
2015.05.18 14:09:25 1: PERL WARNING: Use of uninitialized value $sqlspec{"order_by_hour"} in concatenation (.) or string at ./FHEM/93_DbLog.pm line 978.
2015.05.18 14:09:25 3: stacktrace:
2015.05.18 14:09:25 3: main::__ANON__ called by ./FHEM/93_DbLog.pm (978)
2015.05.18 14:09:25 3: main::DbLog_Get called by fhem.pl (3022)
2015.05.18 14:09:25 3: main::CallFn called by fhem.pl (1557)
2015.05.18 14:09:25 3: main::CommandGet called by fhem.pl (1032)
2015.05.18 14:09:25 3: main::AnalyzeCommand called by ./FHEM/01_FHEMWEB.pm (2017)
2015.05.18 14:09:25 3: main::FW_fC called by ./FHEM/98_logProxy.pm (820)
2015.05.18 14:09:25 3: main::logProxy_Get called by fhem.pl (3022)
2015.05.18 14:09:25 3: main::CallFn called by fhem.pl (1557)
2015.05.18 14:09:25 3: main::CommandGet called by fhem.pl (1032)
2015.05.18 14:09:25 3: main::AnalyzeCommand called by fhem.pl (905)
2015.05.18 14:09:25 3: main::AnalyzeCommandChain called by ./FHEM/01_FHEMWEB.pm (2020)
2015.05.18 14:09:25 3: main::FW_fC called by ./FHEM/98_SVG.pm (1115)
2015.05.18 14:09:25 3: main::SVG_getData called by ./FHEM/98_SVG.pm (1083)
2015.05.18 14:09:25 3: main::SVG_doShowLog called by ./FHEM/98_SVG.pm (959)
2015.05.18 14:09:25 3: main::SVG_showLog called by ./FHEM/01_FHEMWEB.pm (649)
2015.05.18 14:09:25 3: main::FW_answerCall called by ./FHEM/01_FHEMWEB.pm (424)
2015.05.18 14:09:25 3: main::FW_Read called by fhem.pl (3022)
2015.05.18 14:09:25 3: main::CallFn called by fhem.pl (643)
2015.05.18 14:09:25 1: PERL WARNING: DBD::SQLite::db prepare failed: near "FROM": syntax error at ./FHEM/93_DbLog.pm line 988.
2015.05.18 14:09:25 3: stacktrace:
2015.05.18 14:09:25 3: main::__ANON__ called by ./FHEM/93_DbLog.pm (988)
2015.05.18 14:09:25 3: main::DbLog_Get called by fhem.pl (3022)
2015.05.18 14:09:25 3: main::CallFn called by fhem.pl (1557)
2015.05.18 14:09:25 3: main::CommandGet called by fhem.pl (1032)
2015.05.18 14:09:25 3: main::AnalyzeCommand called by ./FHEM/01_FHEMWEB.pm (2017)
2015.05.18 14:09:25 3: main::FW_fC called by ./FHEM/98_logProxy.pm (820)
2015.05.18 14:09:25 3: main::logProxy_Get called by fhem.pl (3022)
2015.05.18 14:09:25 3: main::CallFn called by fhem.pl (1557)
2015.05.18 14:09:25 3: main::CommandGet called by fhem.pl (1032)
2015.05.18 14:09:25 3: main::AnalyzeCommand called by fhem.pl (905)
2015.05.18 14:09:25 3: main::AnalyzeCommandChain called by ./FHEM/01_FHEMWEB.pm (2020)
2015.05.18 14:09:25 3: main::FW_fC called by ./FHEM/98_SVG.pm (1115)
2015.05.18 14:09:25 3: main::SVG_getData called by ./FHEM/98_SVG.pm (1083)
2015.05.18 14:09:25 3: main::SVG_doShowLog called by ./FHEM/98_SVG.pm (959)
2015.05.18 14:09:25 3: main::SVG_showLog called by ./FHEM/01_FHEMWEB.pm (649)
2015.05.18 14:09:25 3: main::FW_answerCall called by ./FHEM/01_FHEMWEB.pm (424)
2015.05.18 14:09:25 3: main::FW_Read called by fhem.pl (3022)
2015.05.18 14:09:25 3: main::CallFn called by fhem.pl (643)
Da ich annehme, dass der Absturz an den letzten Änderungen liegt, poste ich das Problem in diesem Thread. Falls gewünscht, kann ich natürlich auch einen neuen Thread aufmachen.
Nach Herstellen der letzten Version von DBLog r6573 läuft wieder alles ohne Probleme.
Falls ich durch weitere Infos zur Problemlösung beitragen kann, bin ich gerne dazu bereit.
Gruß,
Gero
Hab mich gestern auch Mal wieder ein bisschen mit DbLog gespielt. FHEM und MySQL.
Leider ist mir DbLog nach einem Restart von FHEM nach dem Schreiben von nur ein paar Werten "eingeschlafen", obwohl noch immer brav "DbLog connected" angezeigt wird. Ursache konnte ich nicht eingrenzen. Bei dem Versuch Plots anzulegen/-zeigen hängt sich FHEM komplett weg. Zumindest beim Schreiben konnte ich mit einem Patch aus irgendeinem Thread hier:
if ($hash->{DBMODEL} eq "MYSQL") {
eval {
$dbh->begin_work();
};
if($@) {
#Log 0,$@;
DbLog_Connect($hash);
$dbh->begin_work();
}
etwas verbessern. Allerdings "schläft" DBlog immer noch sporadisch ein, bleibt aber auf "connected". Ich komme damit aber wenigstens ohne Absturz auf die PlotSVG-Seite.
Zudem ist mir aufgefallen, dass beim Loggen eines vermeitlich innerhalb DbLog nicht definierten Devices des Moduls km200 die DB-Einträge im table "current" nicht überschrieben, sondern mit anderem Time-Stamp als neuer Datensatz angelegt werden. Muss man die rollierenden Einträge irgendwo explizit definieren?
das problem gab es doch schon einmal meine ich, hier war wenn ich mich erinnere plotfork das problem
Ich verwende sqlite und kein plotfork.
Zitat von: Tobias am 17 Mai 2015, 13:38:17
Jetzt endlich committed.
Hallo Tobias,
sehe ich das richtig, dass die Version, die jetzt über das Update kam, nicht die ist, die ich oben (http://forum.fhem.de/index.php/topic,30998.msg291196.html#msg291196) nochmals korrigiert hatte?
Gruß Benni.
Habe auch gerade gesehen das ich meine VErsion committet habe. Konnte aber eben deine VErsion nicht aktualisieren da due in den <ul> durcheinandergekommen bist und fehler enthalten. Da lehnt svn das commit ab. kannst du mal bitte nur den relevanten Patch hier posten? Ich glaube im Endeffekt war es nur eine Zeile für DBLogInclude die geändert werden musste...
Zitat von: Tobias am 19 Mai 2015, 08:14:20
Ich glaube im Endeffekt war es nur eine Zeile für DBLogInclude die geändert werden musste...
... und die Doku musste angepasst werden.
Ich werde mich heute Abend darum kümmern.
Gruß Benni.
[Hier stand Unsinn...]
[Notiz an mich: nicht im schlaftrunkenen Zustand Testdatenbanken anlegen] :)
Markus
Zitat von: Benni am 19 Mai 2015, 09:01:00
... und die Doku musste angepasst werden.
Ich werde mich heute Abend darum kümmern.
Gruß Benni.
Im Anhang der Patch.
Gruß Benni.
Ich habe mir gerade die aktuelle Version angesehen, um meinen fhem Absturz zu verstehen. Kann es sein, dass ihr die Änderungen nicht für sqlite nachgezogen habt?
Für sqlite fehlen meiner Meinung nach die Werte
$sqlspec{order_by_hour}
$sqlspec{max_value}
$sqlspec{day_before}
Dies führt zu vielen Warnings und abschließend zum Absturz von fhem, weil das SQL Statement ungültig ist.
Gruß,
Gero
hmm, ich habe leider kein SQLITE,
kannst du bitte mal schauen, welche Werte für SQLite korreekt sind??
Hier das Beispiel wie es für PostGreQL passt:
$sqlspec{order_by_hour} = "TO_CHAR(TIMESTAMP, 'YYYY-MM-DD HH24')";
$sqlspec{max_value} = "MAX(VALUE)";
$sqlspec{day_before} = "($sqlspec{from_timestamp} - INTERVAL '1 DAY')";
Schade, das in der ziemlich langen Testphase keiner sqlite getestet hat...
TO_CHAR gibt es bei sqlite nicht. Das Date & Time Handling unterscheidet sich etwas. Leider habe ich mich damit noch nie wirklich mit SQlite beschäftigt. An dieser Stelle, bin ich ausnahmsweise mal einfacher User.
Vielleicht findet sich jemand anderes, der die DbLog für SQlite wieder geradeziehen kann. Falls nicht, muß ich mich wohl etwas einarbeiten.
Gruß,
Gero
...ich versuchs mal rauszusuchen.
Bei dem TO_CHAR geht es eigentlich nur darum das Datum vorzuformatieren...ich seh mal ob ich was finde.
PostGreSQL hab ich auch soweit über Hilfeseiten zusammenbekommen...
...ich hab mal was rausgesucht und das angepasst.
Ich hoffe ich hab die korrekte Version im GIT-Repository gefunden (wurde vor 5 Tagen das letzte Mal geändert):
diese hier hab ich als Quelle verwendet (https://raw.githubusercontent.com/mhop/fhem-mirror/master/fhem/FHEM/93_DbLog.pm)
Ich hab das jetzt noch für Oracle und SQLite angepasst und auch den ELSE-Zweig da - wie vorher auch - einfach mit dem gesetzt was bei SQLite gesetzt wurde.
Probierts mal aus....
Patch häng ich hier an...
Viele Grüße
Michael
Danke. Ich werde es morgen testen.
Ich habe mich doch schon jetzt an den Rechner gesetzt. Auf den ersten Blick sieht alles gut aus.
Lediglich eine Warning müllt mir noch das Log zu.
PERL WARNING: Use of uninitialized value in numeric eq (==) at ./FHEM/93_DbLog.pm line 1162.
Daher habe ich nochmal eine aktualisierte Fassung von deinem Patch angehängt.
Gruß,
Gero
Hi, ich benutze die ungepatchte version, die mit dem Update ausgeliefert wird/wurde und bekomme da folgende Logmeldungen:
2015.05.24 20:53:55 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/93_DbLog.pm line 927.
2015.05.24 20:53:55 1: PERL WARNING: Use of uninitialized value $sqlspec{"day_before"} in concatenation (.) or string at ./FHEM/93_DbLog.pm line 948.
2015.05.24 20:53:55 1: PERL WARNING: Use of uninitialized value in numeric eq (==) at ./FHEM/93_DbLog.pm line 1153.
Wäre schön, wenn das noch behoben wird :-)
Hallo Tobias,
ich denke so langsam sollte man das hier mal wieder gerade ziehen, inzwischen haben wir eine offizielle Version, die an mehreren Stellen nicht ganz korrektr funktioniert und mehrere Patches für die teils unterschiedlichen Probleme.
Ein eher unbefriedigender Zustand ;)
Gruß Benni.
Hallo Tobias,
habe gerade gesehen, dass du inzwischen zwar die Änderungen bzgl. SQLITE in svn eingecheckt hast, allerdings fehlt jetzt immer noch der Patch bzgl. der Korrektur von DbLogInclude aus diesem Post (http://forum.fhem.de/index.php/topic,30998.msg296200.html#msg296200)
Soll ich dir nochmal einen Patch auf der aktuellen (svn) Version bauen?
Gruß Benni.
Schick nochmal einen aktuellen Stand rüber. Gebe mir Mühe es dieses Wochenende zu testen und einzuchecken
Gesendet von meinem ALCATEL ONE TOUCH 997D mit Tapatalk
Hallo Tobias,
kein Problem! :)
Im Anhang der patch basierend auf der letzten SVN-Version.
Gruß Benni.
erledigt... checkt es mal bitte ab morgen
Sieht gut aus für mich.
Danke! :)
Ich hab zur Zeit bei FHEM-Start sowas im Log:
given is experimental at ./FHEM/93_DbLog.pm line 1288, <$fh> line 40.
when is experimental at ./FHEM/93_DbLog.pm line 1290, <$fh> line 40.
when is experimental at ./FHEM/93_DbLog.pm line 1298, <$fh> line 40.
when is experimental at ./FHEM/93_DbLog.pm line 1308, <$fh> line 40.
when is experimental at ./FHEM/93_DbLog.pm line 1316, <$fh> line 40.
given is experimental at ./FHEM/93_DbLog.pm line 1321, <$fh> line 40.
when is experimental at ./FHEM/93_DbLog.pm line 1322, <$fh> line 40.
when is experimental at ./FHEM/93_DbLog.pm line 1323, <$fh> line 40.
when is experimental at ./FHEM/93_DbLog.pm line 1324, <$fh> line 40.
when is experimental at ./FHEM/93_DbLog.pm line 1337, <$fh> line 40.
Zitat von: Virsacer am 16 Juni 2015, 23:15:33
Ich hab zur Zeit bei FHEM-Start sowas im Log:
Das hat nichts mit den Dingen in diesem Thread zu tun und dürfte an der eingesetzten Perl-Version liegen.
Ist doch ein Wunsch, dass das verbessert wird ;)
Perlversion ist übrigens 5.20.2
DbLog schreibt nach ein paar Minuten nicht mehr in die DB
Hallo,
nach langem Suchen hier im Forum hoffe ich, dass ich mit diesem thread die richtige Stelle für meine Frage getroffen habe.
(Bitte sagt mir, wenn ich besser einen neuen thread aufmachen soll)
Ich möchte das Loggen auf DbLog umstellen und habe deshalb FHEM experimentell auf einem zweiten Pi eingerichtet, ein paar Sensoren umgehängt und DbLog initialisiert.
Das Phänomen: Nach dem Starten des Systems (z.B. kompletter Restart des Pi) werden Readings sauber in die DB geschrieben, nach ein paar Minuten aber nicht mehr.
Meine Umgebung:
Bare metal Installation: Raspberry Pi B+, Raspbian (neueste Version + apt-get update/upgrade) auf 4GB SD-Karte, Installation Enocean Pi Board, FHEM Installation + update (das letzte gestern), DbLog Install, MySQL DB auf all-inkl Server, Zugriff aus dem lokalen Netz mittels HeidiSQL-Client getestet, DbLog initialisiert (musste noch das DBI.pm und den mysql-client nachinstallieren), EnOcean Switch gedrückt, Readings tauchen in der DB auf. Bis nach ein paar Minuten...
Was habe ich schon probiert?
- Nach den plotfork-Hinweisen hier im Forum habe ich alle erstellten SVG Plots wieder gelöscht -> keine Änderung
- Verbose Level von DbLog auf 5 gesetzt: Nun werden die Readings im FHEM Log geloggt aber nach der Unterbrechung ist keine Fehlermeldung zu finden
- service fhem stop|start führt dazu, dass die Readings wieder in der DB landen; bis in ein paar Minuten (etwa zwischen 5 und 10)
- manchmal hilft ein "set myDbLog reopen", aber auch nicht immer. Dann ist ein fhem Neustart nötig
- STATE im DbLog ist dabei durchgängig auf "connected"
In die Filelogs werden die Readings übrigens auch nach dem DbLog "Ausstieg" fleißig weiter geschrieben. Deshalb gehe ich davon aus, dass es nicht an dem Zweig Sensoren, EnOceanPi-Board, Standard FHEM liegt.
Die Datenbank ist mittels HeidiSQL-Client (Windows) auch nach dem DbLog "Ausstieg" erreichbar. Da da auch andere produktive DBs drauf laufen schliesse ich die DB als Fehlerquelle auch aus.
Jetzt bin ich mit meinem Latein am Ende :( und hoffe auf Unterstützung von euch.
Was kann ich noch tun?
Besten Gruß.
Hallo photon2000,
schon mal versucht, plotfork zu deaktivieren?
http://fhem.de/commandref_DE.html#FHEMWEB (http://fhem.de/commandref_DE.html#FHEMWEB)
Btw.: Nur weil es auch DBLog betrifft, ist das hier thematisch nicht ganz der richtige Thread um sich anzuhängen.
Hallo Benni,
danke für die schnelle Antwort.
Das attr plotfork ist in WEB auf "0" gesetzt. Wenn ich die commandref richtig verstanden habe, müsste damit plotfork deaktiviert sein, oder?
-> Leider keine Änderung
Besten Gruß