hallo tobias,
die aktuelle dblog version funktioniert zumindest bei mir mit sqlite nicht mehr. die letzte version ist noch ok.
ZitatDBD::SQLite::st bind_columns failed: bind_columns called with 2 values but 4 are needed at /usr/local/FHEM/share/fhem/FHEM/93_DbLog.pm line 791.
DBD::SQLite::st bind_columns failed: bind_columns called with 2 values but 4 are needed at /usr/local/FHEM/share/fhem/FHEM/93_DbLog.pm line 791.
DBD::SQLite::st bind_columns failed: bind_columns called with 2 values but 4 are needed at /usr/local/FHEM/share/fhem/FHEM/93_DbLog.pm line 791.
DBD::SQLite::st bind_columns failed: bind_columns called with 2 values but 4 are needed at /usr/local/FHEM/share/fhem/FHEM/93_DbLog.pm line 791.
DBD::SQLite::st bind_columns failed: bind_columns called with 2 values but 4 are needed at /usr/local/FHEM/share/fhem/FHEM/93_DbLog.pm line 791.
DBD::SQLite::st bind_columns failed: bind_columns called with 2 values but 4 are needed at /usr/local/FHEM/share/fhem/FHEM/93_DbLog.pm line 791.
DBD::SQLite::st bind_columns failed: bind_columns called with 2 values but 4 are needed at /usr/local/FHEM/share/fhem/FHEM/93_DbLog.pm line 791.
DBD::SQLite::st bind_columns failed: bind_columns called with 2 values but 4 are needed at /usr/local/FHEM/share/fhem/FHEM/93_DbLog.pm line 791.
gruss
andre
Ähnliches Problem hatte ich gestern auch schon (http://forum.fhem.de/index.php/topic,19011.msg129993.html#msg129993) festgestellt, als nach dem DbLog-Update plötzlich alle SVG-Plots leer blieben. Auch bei mir läuft DbLog mit sqlite3
Ich denke, der Hund liegt hier begraben (Zeilen 655-676):
my $inf = lc(shift @a);
my $outf = lc(shift @a);
...
} elsif(uc($outf) eq "webchart") {
# redirect the get request to the chartQuery function
return chartQuery($hash, @_);
}
Da wird ein per uc($outf) in GROSSBUCHSTABEN umgewandelter String gegen einen String in kleinbuchstaben geprüft. Da dies niemals ein TRUE ergeben kann, wird die Weiterleitung nach chartQuery() niemals stattfinden.
Meiner Meinung nach sollte es in dem elsif heißen
} elsif(lc($outf) eq "webchart") {
Testen kann ich das allerdings erst heute abend, hier habe ich aktuell kein fhem mit aktiviertem DbLog.
Das von andre beschriebene Datenbankproblem hat allerdings eine andere Ursache weiter hinten im Modul.
an der stelle weiter hinten ist mir beim überfliegen nur aufgefallen das in der alten version irgendetwas mit ALL verglichen wird und in der neuen case sensitiv mit '=~ m/(all|array)/'. ich vermute hier fehlt ein i ?
gruss
andre
Ja das ist vermutlich die eine Hälfte der Ursache.
Die andere ist, dass in Folge dieses Fehlers das bind_columns meiner Meinung nach (und auch laut Fehlermeldung) falsch aufgerufen wird. Im Normalfall sollte diese Stelle wahrscheinlich gar nicht erreicht werden und ist deshalb noch nicht auffällig geworden 8)
ich bin gerade dabei...
Ursache liegt in $inf.... und das dieser Parameter bei den SVG´s mit "current" übergeben wird.
Aber "current" ist ein Schlüsselwort das die Datenabfrage auf die Current-Tabelle geht...
habs aber gleich...
Bitte testet mal bitte diese version. Dann checke ich sie heute abend ein.
Zitat von: Tobias am 28 Januar 2014, 14:46:00
Bitte testet mal bitte diese version. Dann checke ich sie heute abend ein.
Teste ich gerne, aber frühestens 19 Uhr heute abend.
Scheint erstmal zu funktionieren, die Plots an sich sind wieder da.
2014.01.28 18:53:01 3: Defining SVG with :CURRENT is depricated. Please define SVG-Plots with :HISTORY instead of :CURRENT. (define <mySVG> SVG <DbLogDev>:<gplotfile>:HISTORY)
Die Meldung sehe ich zum ersten Mal - hast Du das in der aktuellen Version eingebaut oder kommt das aus 98_SVG?
das kommt von mir...
Sorry für die Unanehmlichkeit... soviel getestet, aber auf die Plots hab ich nicht geschaut...
Ist eingecheckt...
Zitat von: Tobias am 28 Januar 2014, 19:17:12das kommt von mir...
Du solltest vielleicht Rudi einen Hinweis geben, damit er das mit dem :CURRENT ggf. in der commandref zu 98_SVG vermerkt.
Zitat von: betateilchen am 28 Januar 2014, 18:55:27Defining SVG with :CURRENT is depricated.
Hinweis: es heißt deprecated und hat nix mit deprimierend zu tun ;)
Hallo Tobias,
kannst Du Dir das mal bitte noch anschauen:
rollback ineffective with AutoCommit enabled at ./FHEM/93_DbLog.pm line 387.
Die Meldung kommt bei mir ab und zu auf der Konsole an.
Zitat von: betateilchen am 28 Januar 2014, 19:48:23
Hinweis: es heißt deprecated und hat nix mit deprimierend zu tun ;)
Hatte ich gestern schon geändert als ich dein Post gelesen habe... *g*
Bzgl der Rollback-Meldung: Ist es in der aktuellen Version auch noch? Mach mal bitte ein update.
Arbeitest du mit asyncronem OWServer?
Mit OW arbeite ich gar nicht.
Ob die rollback-Meldung mit der aktuellen Version noch kommt, kann ich erst heute abend prüfen.
...hab auch noch eine "unschöne" Fehlermeldung bekommen (mit der aktuellen version) ..... nach dem Batteriewechsel am FHT80b:
Argument "synctime: 16" isn't numeric in multiplication (*) at /opt/fhem/FHEM/93_DbLog.pm line 228.
Zitat von: roedert am 29 Januar 2014, 12:21:01
...hab auch noch eine "unschöne" Fehlermeldung bekommen (mit der aktuellen version) ..... nach dem Batteriewechsel am FHT80b:
Argument "synctime: 16" isn't numeric in multiplication (*) at /opt/fhem/FHEM/93_DbLog.pm line 228.
Kommt definitiv nicht vom Update... war vorher auch schon... ev müsste man ab Zeile 225 etwas anpassen. Da ich aber keine FHT´s besitze bin ich auf Zulieferung von Patches angewiesen...
elsif($value eq "synctime") {
$reading= "actuator-synctime";
undef $value;
}
Dazu muss man gar keine FHT haben ;)
Argument "synctime: 16"
Du testest aber auf
elsif($value eq "synctime") {
anstatt auf
elsif($value eq "synctime:") {
und landest deshalb im letzten else, wo probiert wird, $value als numerischen Wert zu interpretieren, was fehlschlagen muss, da der Textteil noch enthalten ist.
Das Loggen von FHT80b in der jetzigen Form in DbLog kann ohnehin nicht immer korrekt funktionieren, denn Du schreibst immer "actuator-<reading>" als readingname. Wenn aber an einer FHT80b mehr als ein Actuator (maximal 8) angemeldet sind, werden die mit actuator1..actuator8 bezeichnet. Entsprechend müsstest Du dann auch die Readings so benennen. Es gibt sowohl "actuator" als auch "actuatorN".
ich habe dieses CodeBlock von Boris Neubert übernommen. Ich kann das nicht testen... Schickt mir nen Patch...
Du wirst doch einen fehlenden Doppelpunkt auch ohne DIFF-Datei hinbekommen? 8)
Moin Tobias,
bei der letzten aktualisierung von DbLog hat sich in Zeile 709 ein Sonderzeichen eingeschlichen
$readings[$i][1] = "%" if(length($readings[$i][1])==0); #falls Reading nicht gef\FCllt setze Joker
und in Zeile 1704 nocheinmal
Damit erh\E4lt man alle aktuellen Readings "temperature" von allen in der DB geloggten Devices.
zumindest meutert mich gedit an, wenn ich DbLog öffnen will.
Gruß Joachim
Edith:
Oder habe ich mit codepage UTF-8 den falschen Zeichensatz?
Hallo Tobias,
ich hab mal noch eine Grundsatzfrage: Die Tabelle current wird wohl gar nicht benutzt? Bei mir (sqlite3) ist die jedenfalls immer leer. Nicht dass ich da etwas vermissen würde, aber irgendwas muss sich irgendjemand ja mal dabei gedacht haben, oder?
Viele Grüße
Udo
Also bei mir (mysql) ist in current jeweils der letze Wert eines jeden Readings.
Hallo,
ich habe heute auch mal meine Definitionen der Plots "aufgeräumt" nachdem ich mal wieder in das Logfile geschaut habe und das
ZitatDefining DbLog SVG-Plots with :CURRENT is deprecated. Please define DbLog SVG-Plots with :HISTORY instead of :CURRENT. (define <mySVG> SVG <DbLogDev>:<gplotfile>:HISTORY)
gefunden habe.
Ich habe ja kein Problem mit der Meldung aber ich wollt nur mal my2cents beitragen ;D
Grüße
Zitat von: betateilchen am 02 Februar 2014, 19:46:15
Hallo Tobias,
ich hab mal noch eine Grundsatzfrage: Die Tabelle current wird wohl gar nicht benutzt? Bei mir (sqlite3) ist die jedenfalls immer leer. Nicht dass ich da etwas vermissen würde, aber irgendwas muss sich irgendjemand ja mal dabei gedacht haben, oder?
Viele Grüße
Udo
liegt an deiner Einstellung im DbLog. Steht bestimmt auf "History" ;)
Puschel: Die Meldung soll dir sagen das die SVG´s umdefiniert werden soltzen...
Zitat von: Tobias am 02 Februar 2014, 21:28:22liegt an deiner Einstellung im DbLog. Steht bestimmt auf "History"
Hau mich nicht, ich hab gestern VOR meinem Posting lange erfolglos gesucht, um eine Antwort zu finden. Wo soll ich denn da irgendwo etwas einstellen können?
Moin betateilchen,
Es gibt ein nicht dokumentiertes attr, mit dem man zw. current und/oder history unterscheiden kann, wenn es nicht gesetzt ist, wird immer current/history gesetzt.
nur dann wird current mit dem letzten Wert gefüttert (beim Starten wird der Wert eingetragen, danache wird in dieser Tabelle der Wert nur noch upgedatet), und wenn ich das richtig nachvollzogen habe, flüchtig im RAM gespeichert.
Der Sinn hat sich mir auch noch nicht ganz erschlossen, aber ich versuche gerade mir das für einen Umbau von DbLog zu nutze zu machen.
Gruß Joachim
komisch... ohne das Attribut "DbLogType" wird immer in Current und History geloggt. Das ist Default.
Mit diesem Attr. kannst du einstellen ob du nur aktuelle Werte (current) oder nur historische (history) oder beides (Current/History) (->default) haben willst.
Seit neuestem benutze ich auch die CurrentTabelle im Modul Text2Speech um Statistiken über die Nutzung der MP3 Files zu sammeln. Wird später noch benutzt um nicht verwendete Files automatisiert löschen zu können.
Zitat von: Joachim am 03 Februar 2014, 10:29:57
Der Sinn hat sich mir auch noch nicht ganz erschlossen, aber ich versuche gerade mir das für einen Umbau von DbLog zu nutze zu machen.
Versteh ich nicht...
Die letzten Änderungen am DbLog (Nutzung von Wildcards) sind alles Vorarbeiten um per fhemweb Daten aus der Db zu bekommen, aber auch um noch etwas später Daten löschen zu können.
Moin Tobias,
Das bezieht sich auf diesen Tread:
http://forum.fhem.de/index.php/topic,17468.15.html
Zitatauf jeden fall hört sich das ganz gut an...
Macht doch einen Patch, dann checke ich das ins contrib ein zum breiten testen. Bitte diese Funktionalität per Attr steuern.
Auf meiner TODO-Liste steht die Idee mit der Aggregation und dem daraus resultierenden Löschen... Meine Postgresql-DB ist zZ. 2GB groß
Ich bin mit dem Umbau fast fertig, und habe ersteinmal das undokumentierte attr current dafür genutzt, da ich dafür keine andere Verwendung gesehen habe.
Das ganze muß noch ein paar Tage getestet werden, und dann stelle ich es zur Verfügung.
Gruß Joachim
wieviele verschiedene DbLog-Module sind eigentlich aktuell im Umlauf?
Nach meinem Kenntnissstand genau eins, welches mit dem update ausgeliefert wird.
Gruß Joachim
Zitat von: Joachim am 03 Februar 2014, 10:47:15
Ich bin mit dem Umbau fast fertig, und habe ersteinmal das undokumentierte attr current dafür genutzt, da ich dafür keine andere Verwendung gesehen habe.
Eigentlich dokumentiere ich immer schön alles wenn ich neue Attr einführe ... muss ich wohl vergessen haben :(
Auf jedenfall kann man damit steuern ob man nur aktuell und/oder historische Werte benötigt
ich werde mich heute abend mal auf die Suche machen.
Wie gesagt - ich brauch die current eigentlich gar nicht, mir war nur gestern bei der Systemwartung aufgefallen, dass da nix drinsteht.
Moin betateilchen,
in current steht nur ein Wert drin, und zwar der aktuelle, und der wird auch nicht auf einem "Datenspeicher", sondern nur im RAM abgelegt.
http://forum.fhem.de/index.php/topic,11391.msg66479/topicseen.html#msg66479
ZitatHi,
I'm using SQLite with the DbLog module on my RPi. On a small embedded device like this minimizing writes to reduce wear on flash storage and save IO bandwidth is important. So I have created the attached simple patch to 93_DbLog.pm that
- Moves the 'current' table to memory and modifies a few internal parameters in SQLite to minimize flash wear.
- Makes easier to setup DbLog with SQLite. Database tables are created automatically when the database is opened.
Gruß Joachim
weil die current tabelle nicht persistent ist ist sie auch nur aus dem prozess abfragbar der die angelegt hat.
wenn du mit von hand drauf schaust ist sie immer leer.
gruss
andre
*TILT*
dann sollte aber mal jemand schleunigst die Doku anpassen.
?
ZitatThe database contains two tables: current and history. The latter contains all events whereas the former only contains the last event for any given reading and device.
deswegen
Naja, ich sage mal zweideutig,
denn wenn FHEM nicht läuft, dann gibt es auch keinen letzten Stand, sondern nur historische.
Gruß Joachim
Für mich ist das nicht zweideutig. Da steht nix von "wenn fhem läuft" denn die Datenbank und ihre Inhalte haben mit fhem an sich nix zu tun. Und wenn in der Doku steht, dass in der Tabelle "current" der letzte Wert steht, dann gehe ich davon aus, dass der da auch drinsteht, wenn fhem NICHT läuft. Denn davon, dass der Wert wieder verschwindet, steht auch nirgends was.
Naja, jetzt weist Du es ja.
Gruß Joachim