Hallo betateilchen,
danke für das Modul.
Ich hatte ja damals mit Deinem Beaglebone schon die ersten Gehversuche mit configDB gemacht,
bin aber dann wieder zurück zur fhem.cfg.
Da ich schon seit einer Ewigkeit keine Änderung mehr manuell in der fhem.cfg durchgeführt habe wollte ich wieder den Schritt wagen auf configDB umzusteigen.
1. Grund war, dass ich für das kopieren von DEVICE von einem System auf das andere den configDB list Befehle sehr schick finde.
Anschließend das Ergebnis in die Putty Sesion einfügen.
2. Ich selbst sehr viel mit sqlite arbeite und deshalb die Lösung sehr interessant finde.
Nun zu meinen Themen:
Thema 1:
Mir ist aufgefallen, dass das speichern viel länger benötigt wie bei fhem.cfg und "wa" für ein paar Sekunden auf 88 geht.
Deshalb die Frage ist es beabsichtigt, das die Tabellen automatisch keinen Index bekommen?
Thema 2:
Da ich System für System vom Rasp umziehen möchte dachte ich mir es gibt die Funktion configDB list auch mit TYPE=FS20 etc.
Was denkst Du, ist es ein großer Aufwand die Listfunktion um die Funktion "configDB list TYPE=FS20 zu erweitern?
Gruß und Danke
Hannes
Zitat von: AHA1805 am 17 Februar 2015, 06:42:38
Deshalb die Frage ist es beabsichtigt, das die Tabellen automatisch keinen Index bekommen?
Da ja generell nicht permanent in der Datenbank gelesen/geschrieben wird, war ein Index bisher nicht notwendig.
Zitat von: AHA1805 am 17 Februar 2015, 06:42:38
Was denkst Du, ist es ein großer Aufwand die Listfunktion um die Funktion "configDB list TYPE=FS20 zu erweitern?
Geht doch jetzt schon:
configdb search FS20
Hallo zusammen,
ich hatte auch schon gelegentlich das "Problem", dass bei einem configdb info im Webfrontend das ganze zu lange dauert und keine Seite mehr zurückgeliefert wird. Das war für mich bisher immer die Erinnerung, mal wieder mit configb reorg die alten Versionen rauszuschmeißen (sollte ich mal was älteres Brauchen, habe ich ja auch noch meine Backups)
Könnte man da eventuell auch mit einem Index noch was beschleunigen?
Falls ja, wie wäre dieser einzurichten? (configDB läuft bei mir mit sqlite)
um die configDB geschmeidig zu halten, gibt es jetzt bereits zwei Möglichkeiten:
- ein nächtliches at, das ein configdb reorg ausführt.
- das configDB attribut "maxversions" mit dem man eine maximale Anzahl von Konfigurationsversionen festlegen kann. Steht bei mir in Entwicklungssystemen auf 10, in Produktivsystemen auf 3 und diese Werte haben sich in der Praxis Wert bewährt.
Ich sträube mich gegen einen Index, weil das die Einrichtung wieder unnötig verkompliziert. Manche Leute sind ja jetzt schon damit überfordert, eine mitgelieferte (!!!) betriebsbereite Datenbankdatei einfach nur zu kopieren und zu verwenden.
Damit kann ich gut leben!
Werde mich wohl für 2. entscheiden :)
Zitat von: betateilchen am 17 Februar 2015, 08:16:33
Da ja generell nicht permanent in der Datenbank gelesen/geschrieben wird, war ein Index bisher nicht notwendig.
Geht doch jetzt schon:
configdb search FS20
Hallo Udo
danke für die schnelle Antwort.
1. Okay verstehe ich, dann werde ich mir einfach selber einen Index anlegen, da ich gerne viele Versionsstände in der DB behalten möchte
Bis jetzt verwalte ich alle Stände der fhem.cfg, da es sich schon oft bewährt hat, bei auffallenden Problemen diese über das systematische zurück gehen auf ältere Version einzugrenzen.
2. Leider ist das nicht das Ergebnis, welche ich haben wollte.
Um alle Daten eines TYPE z. B. FS20 kopieren zu können sollten alle Attribute aller FS20 DEVICE gelistet werden, auch die welche kein FS20 enthalten.
Schöne grüße
Hannes
Gesendet von Tapatalk
Dein Anwendungsfall ist mir nach wie vor unklar.
Das fhem-eigene devspecarray() arbeitet grundsätzlich mit geladenen/definierten devices im Speicher Deines laufenden fhem, unabhängig davon, ob man mit fhem.cfg oder configDB arbeitet.
Hallo Udo,
fange für die schnelle Antwort.
Bisher habe ich mir die Daten aus der fhem.cfg kopiert und per einfügen in eine telnet Session in einen anderem System (2. RASP) kopiert.
Die funktioniert "copyTo TYPE=FS20 192.168.18.29:7072 gibt es ja bisher nicht.
Jetzt habe ich gelesen das es bei ConfigDB die coole Funktion" ConfigDB list Device Version " gibt.
Hier werden analog fhem.cfg das DEF mit allen attr gelistet.
Diese kann ich jetzt einfach über die zwischenAblage in eine telnet Session einfügen.
Wenn ich schon bei" Wünsch dir was" bin hätte ich auch noch gern einen Zeitstempel für jede Version :-)
Schöne grüße
Hannes
Gesendet von Tapatalk
Zitat von: AHA1805 am 17 Februar 2015, 16:41:59
Wenn ich schon bei" Wünsch dir was" bin hätte ich auch noch gern einen Zeitstempel für jede Version :-)
Auch Du solltest meine Gutmütigkeit bitte nicht überstrapazieren...
Mach mal ein "configdb info" - da steht bei jeder Version ein Zeitstempel dabei.
Ver 0 saved: Sun Feb 8 20:49:45 2015 def: 9 attr: 34
Ver 1 saved: Sun Feb 8 13:55:31 2015 def: 9 attr: 35
Ver 2 saved: Sun Feb 8 12:38:36 2015 def: 9 attr: 35
Ver 3 saved: Sun Feb 8 12:28:09 2015 def: 9 attr: 35
Ver 4 saved: Sun Feb 8 12:26:11 2015 def: 9 attr: 35
Ver 5 saved: Sun Feb 8 12:23:04 2015 def: 9 attr: 34
Ver 6 saved: Sat Feb 7 23:13:05 2015 def: 9 attr: 32
Ver 7 saved: Sat Feb 7 23:11:49 2015 def: 9 attr: 31
Ver 8 saved: Sat Feb 7 21:52:29 2015 def: 8 attr: 31
Ver 9 saved: Sat Feb 7 21:25:11 2015 def: 8 attr: 29
Das TYPE=FS20 werde ich nicht einbauen.
Hallo Udo
sorry heute ist irgendwie nicht der richtige Tag...
Das mit den Version Zeitstempel habe ich übersehen, Asche über mich.
Ich hätte es halt schön gefunden wenn der list Befehl ähnlich wie der fhem list Befehl funktionieren würde.
Ein Versuch war es Wert.
Heute ist Faschingsdienstag,
nimm die ganzen Diskussionen nicht sooooooooo ernst.
Wünsch dir noch einen schönen närrischen Tag
Hannes
Gesendet von Tapatalk
Der nächste, der mich heute auf der Straße, im ICE, in der S-Bahn oder sonst irgendwo mit "Helau", "Alaaf" oder sonstigem Schwachsinn überschüttet, stirbt eines nicht natürlichen Todes...
Upps
Duck und weg
Gesendet von Tapatalk
Hi FHEM Freunde!
Falls jemand beim Migrieren der fhem.cfg in die configDB diese Meldung bekommt:
DBD::mysql::st execute failed: Data too long for column 'DEVICE' at row 1 at configDB.pm line 650.
Dann sollte dies die Lösung sein: (hat bei mir zumindest das Problem gelöst)
Auslöser sind Devicenamen länger 32 Zeichen
mySQL
ALTER TABLE fhemconfig MODIFY device char(255);
Hoffe es hilft jemandem
Gruß
der Merlin
Das Thema haben wir schon mehrfach hier im Forum diskutiert.
Hast Du mal getestet, ob Deine überlangen device-Namen dann auch noch mit DbLog funktionieren?
Zitat von: betateilchen am 19 Mai 2015, 21:32:26
Das Thema haben wir schon mehrfach hier im Forum diskutiert.
Hast Du mal getestet, ob Deine überlangen device-Namen dann auch noch mit DbLog funktionieren?
Echt, wurde schon mehrfach diskutiert?
Habe ich leider dann übersehen.
Nein, ich habe das noch nicht mit dblog geprüft.
Ich habe mir gerade mal eine Testinstanz aufgesetzt und nutze dort erstmal das configDB Modul das ich schon ganz fein finde.
Sollte es mit langen Namen im dblog nicht funktionieren, würde ich configDB bzw. logdb an der Stelle als "buggy" bezeichnen und Dich bitten mehr als 32 Zeichen zuzulassen. ;)
Gruß
der Merlin
EDIT:
@Udo,
ich nehme mal an Du sprichst das wegen dem "db_create_mysql.sql" Script an?
Ich habe das mal eben für mich wiefolgt angepasst:
Zitat
CREATE TABLE `fhemdb`.`history` (TIMESTAMP TIMESTAMP, DEVICE varchar(255), TYPE varchar(32), EVENT varchar(512), READING varchar(255), VALUE varchar(255), UNIT varchar(32));
CREATE TABLE `fhemdb`.`current` (TIMESTAMP TIMESTAMP, DEVICE varchar(255), TYPE varchar(32), EVENT varchar(512), READING varchar(255), VALUE varchar(255), UNIT varchar(32));
CREATE INDEX Search_Idx ON `fhemdb`.`history` (DEVICE, READING, TIMESTAMP);
Ist das so okay?