Hallo,
nachdem sich meine SSD am Raspberry 3 aufgelöst hat, habe ich das System komplett neu aufgesetzt mit Raspberry Buster und den neuesten fhem Version.
Da auf dem alten System alles in eine SQL Datenbank geschrieben wurde, möchte ich das auch bei dem neuen Sytem machen, da ich unter anderem fast alle fhem Dateien sichern konnte.
Aber beim Anlegen der Tabellen in der Datenbank tritt ein Fehler auf.
Vorgegangen bin ich nach dieser Anleitung: https://wiki.fhem.de/wiki/DbLog
Sobald ich den SQL Befehl:
CREATE TABLE `current` (`TIMESTAMP` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,`DEVICE` varchar(64) DEFAULT NULL,`TYPE` varchar(64) DEFAULT NULL, `EVENT` varchar(512) DEFAULT NULL, `READING` varchar(64) DEFAULT NULL, `VALUE` varchar(255) DEFAULT NULL, `UNIT` varchar(32) DEFAULT NULL);
eingebe, ehalte ich den Fehler: Error: near "ON": syntax error
Die history Tabelle betrifft das nicht, die ja quasi identisch ist.
Vielen Dank im Voraus.
_fhemuser_
Funktioniert das ON UPDATE überhaupt in SQLite? M.E. Geht das nur mit Trigger. Ich wüsste auch nicht, was das ON UPDATE für einen Sinn macht. Imho wird die Tabelle doch nur fortlaufend mit INSERT geschrieben.
Gesendet von iPhone mit Tapatalk
Hi _fhemuser_,
Schau mal besser in die Commandref, da ist ein link zum SVN, da sind die aktuellen Scripte enthalten.
https://svn.fhem.de/trac/browser/trunk/fhem/contrib/dblog
Gruß Otto
Nimm die Befehle, die in /opt/fhem/contrib/dblog/db_create_sqlite.sql sind
Oder einfach:
sudo sqlite3 /opt/fhem/fhem.db < /opt/fhem/contrib/dblog/db_create_sqlite.sql
Vielen Dank für die vielen schnellen Antworten.
Die Lösung von amenomade war die schnellste und einfachste.
Es funktioniert jetzt wieder wie gewohnt.
Dann wäre es doch vielleicht sinnvoll im Wiki im Abschnitt SQLite nur den EintragCREATE TABLE current (TIMESTAMP TIMESTAMP, DEVICE varchar(64), TYPE varchar(64), EVENT varchar(512), READING varchar(64), VALUE varchar(128), UNIT varchar(32)); einzutragen.
Nein, der stimmt so nicht. Beim INSERT würde keine automatische Timestamp erstellt. Entsprechend ließen sich die Readings nicht mehr zeitlich zuordnen.
Gesendet von iPhone mit Tapatalk
Beim INSERT von was, wie, wann, wo?
Mit einem INSERT Kommando wird ein Datensatz in die Tabelle geschrieben. FHEM liefert dabei soweit ich weiß keine Timestamp mit. Daher muss das setzen der Timestamp von der Datenbank selbst übernommen werden. Das stellt man über das DEFAULT Attribut der Timestamp Spalte bei der Erstellung der Tabelle ein.
Im weiter oben verlinkten Skript ist es richtig. Im Codebeispiel des OP fehlt das DEFAULT Attribut.
Gesendet von iPhone mit Tapatalk
Wie muss den dann die CREATE Anweisung aussehen?
Wie die, im oben verlinkten Skript. So schwer kann das doch nicht sein [emoji51]
Edit: ich sehe grad, das der DEFAULT nur in der Historie Tabelle gesetzt wird. Imho ist der Befehl für die current auch im Skript nicht richtig.
CREATE TABLE history (TIMESTAMP TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, DEVICE varchar(64), TYPE varchar(64), EVENT varchar(512), READING varchar(64), VALUE varchar(128), UNIT varchar(32));
Gesendet von iPhone mit Tapatalk
Hallo zusammen,
muss mal kurz einhaken...
ZitatFHEM liefert dabei soweit ich weiß keine Timestamp mit. Daher muss das setzen der Timestamp von der Datenbank selbst übernommen werden. Das stellt man über das DEFAULT Attribut der Timestamp Spalte bei der Erstellung der Tabelle ein.
Das ist nicht richtig. FHEM bringt den Timestamp mit, entweder den Timestamp von CHANGETIME des Events wenn vorhanden, ansonsten den aktuellen Timestamp.
LG,
Heiko
Dann wäre das DEFAULT in der History aber auch nicht nötig. Warum setzt man es da?
Das DEFAULT kommt nur zum Einsatz, wenn beim INSERT der Wert nicht, oder als NULL übergeben wird
Gesendet von iPhone mit Tapatalk
ZitatDann wäre das DEFAULT in der History aber auch nicht nötig. Warum setzt man es da?
Stimmt, wäre auch nicht nötig.
DbLog gibt es schon seit mehr als 10 Jahren und hat bestimmt eine bewegte Geschichte hinter sich. Vielleicht wurde der Timestamp früher nicht geliefert, ich kann es nicht sagen. Ich betreue das Modul erst rund 3 Jahre seit ca. Ende 2016.
Aber da es nicht stört, muss man das Erstellungsscript auch nicht ändern.
LG,
Heiko
Zitat von: DS_Starter am 19 Januar 2020, 18:26:34
muss man das Erstellungsscript auch nicht ändern.
Hallo Heiko,
müssen wir das Wiki ändern? Da steht ja ein völlig anderes Script. Im Wiki besser bloß link zum Contrib?
Gruß Otto
Hallo Otto,
jetzt wo du es fragst ... ich habe mir das zitierte Wiki noch garnicht komplett angeschaut. :(
Ein Link zum contrib bzw. den dort hinterlegten Skripten wäre m.M. das Beste weil die sich im Zuge von Weiterentwicklungen durchaus mal ändern können.
Schönen Wochenstart !
Grüße,
Heiko
Oder einfach folgendes ausführen lassen:
sudo sqlite3 /opt/fhem/fhem.db < /opt/fhem/contrib/dblog/db_create_sqlite.sql
Hi amenomade,
da besteht nur das Problem, dass die lokalen Skripte im opt/fhem/contrib/ ja nicht upgedated werden. Nur die im SVN contrib sind quasi die "echten".
LG,
Heiko
Naja ich könnte mein SVN Update Script für diesen Teil anpassen und so im Wiki verankern.
1. Also SVN -> contrib Ordner die SQL Scripts updaten
2. Dann den Befehl von amenomade ausführen :)
Morgen Otto ... jo, gute Idee ... :)
Warum aber sollte das Script als "root" ausgeführt werden?
also eigentlich ist das "sudo" unnötig ...
Zitat von: Wernieman am 20 Januar 2020, 08:52:40
Warum aber sollte das Script als "root" ausgeführt werden?
also eigentlich ist das "sudo" unnötig ...
Gute Frage. sudo habe ich nur vom Befehl
sudo sqlite3 /opt/fhem/fhem.db übernommen
Auch da ist das sudo unnötig.
Warum wird eigentlich immer zu schnell zu root gewechselt?
Zitat von: Wernieman am 20 Januar 2020, 19:10:38
Auch da ist das sudo unnötig.
Warum wird eigentlich immer zu schnell zu root gewechselt?
Weil es mit root IMMER funktioniert... zumindest am Anfang.
Aber ich gebe zu, wenn es nicht nötig ist, musste man es vermeiden
Weil es mit root IMMER funktioniert... zumindest am Anfang.
Und danach nicht mehr, weil alles root gehört ....