von configDB wieder zurück auf TXT File

[Mitch]

Hallo Zusammen,

wie komme ich wieder von configDB zurück auf fhem.cfg?

Ich habe massive Probleme seit dem Umstellen und möchte wieder auf die TXT Variante gehen.

Vielen Dank!

[Hans Franz]

Hallo,
siehe http://forum.fhem.de/index.php/topic,27090.msg200328.html#msg200328
Gruß
Hans

[betateilchen]

mich würde eher interessieren, was das für "massive Probleme" sein sollen, die man mit der configDB haben kann...

[Mitch]

100% kann ich nicht sagen, ob es configDB ist oder doch DBLog. Habe beides gleichzeitig umgestellt.

Das größte Problem im Moment ist, dass fhem andauernd "stehe blebt", d.h. genauer, wenn ich mit top schaue, zeigt der Perl Prozess 100% CPU Last und nichts geht mehr.
Im Log gibt es keine Einträge, keine Fehler. Es ist auch nicht mit Schaltbefehlen oder notifys in Zusammenahng zu bringen.

Mit dem Log habe ich das Problem, dass er nur ab und zu schreibt und komischerweise über das Menü meist alte Daten anzeigt, über den direkten Link "manchmal" aktuelle, manchmal nicht.
Wenn ich die Datei direkt im Linux mit nano öffne, steht aber alles aktuell drinnen.

Was mich noch wundert, wenn die die Logdatei physikalisch komplett lösche, ruf er noch immer von iregndwo Daten ab, sprich wenn ich im Menü auf Log klicke, kommen allte Daten.
Diese können ja eigentlich nur aus der Datenbank kommen. Was komisch ist, weil ja der "Systemlog" nicht in der DB liegt, sondern als File auf der Platte.

Des weiteren habe ich folgenden Fehler beim Start vom fhem im Log:

Code Auswählen Erweitern

2014.12.13 21:39:48 3: [HCWK] invalid device, <FHT_Waschkeller> not found
2014.12.13 21:39:48 3: [HCKM] invalid device, <FHT_Hobbyraum> not found
2014.12.13 21:39:48 3: [HCPM] invalid device, <FHT_Wohnzimmer> not found
2014.12.13 21:39:48 3: [HCKF] invalid device, <FHT_KellerFlur> not found
2014.12.13 21:39:48 3: [HCH] invalid device, <FHT_Hobbyraum> not found
2014.12.13 21:39:48 3: [HCS] invalid device, <FHT_Schlafzimmer> not found
2014.12.13 21:39:48 3: [HCC] invalid device, <FHT_Carlotta> not found
2014.12.13 21:39:48 3: [HCL] invalid device, <FHT_Leoni> not found
2014.12.13 21:39:48 3: [HCFO] invalid device, <FHT_FlurOben> not found
2014.12.13 21:39:48 3: [HCFU] invalid device, <FHT_FlurUnten> not found
2014.12.13 21:39:48 3: [HCK] invalid device, <FHT_Klo> not found
2014.12.13 21:39:48 3: [HCO] invalid device, <FHT_Buero> not found
2014.12.13 21:39:48 3: [HCW] invalid device, <FHT_Wohnzimmer> not found
2014.12.13 21:39:48 3: [HCB] invalid device, <FHT_Bad> not found

Habe das hier schonmal geschrieben.
Ich vermute, die FHTs werden nach Heating_Control definiert. Das war aber früher nicht der fall und ich weiß nicht, ob und wie man die Reihenfolge in der DB ändern kann.

Dann habe ich noch Telnet Probleme.

Code Auswählen Erweitern

telnetPort: Can't open server port at 7072: Address already in use. Exiting.
Soetwas "ballert" mir das Logfile zu, bis ich fhem neu starte.
Ich habe den Port auch schon auf 7075 gelegt, gleiches Problem.

Was mich dabei auch sehr wundert, ich habe keine weitere Telnet Session von einem anderen Programm, noch den Port in Gebrauch.

Mehr fällt mir gerade nicht ein, halt doch, mit dem STATE File habe ich auch Probleme. Hier verhällt es sich ähnlich dem Log. Ich habe dann in der Datenbank die Tabelle für STATE komplett geleert und trotzdem hat fhem nach einem Neustart wieder die STATE drinnen.

Alles in allem sehr dubiose und mir nicht nachvollziehbaren Probleme.

Im Moment ist fhem nicht mehr zu gebrauchen und hängt mit Perl 100% Systemlast spätestetens nach 30 Minuten 

Eine kleine Vermutung habe ich noch abseits von fhem. Könnte die Festplatte in meinem Server solche Probleme verursachen?

Als OS benutze ich Ubutnu 14.04.1 LTS Server auf einem ATOM Nettop mit 8GB RAM und 500GB HD.

[betateilchen]

Was komisch ist, weil ja der "Systemlog" nicht in der DB liegt, sondern als File auf der Platte.

Logfiles liegen nie in der configDB.

Des weiteren habe ich folgenden Fehler beim Start vom fhem im Log:
...
Ich vermute, die FHTs werden nach Heating_Control definiert.
Das war aber früher nicht der fall und ich weiß nicht, ob und wie man die Reihenfolge in der DB ändern kann.

Es gibt keinen Grund, sich um die Reihenfolge zu kümmern. Die Konfiguration wird immer aus dem LAUFENDEN fhem geschrieben, und damit auch in der richtigen Reihenfolge. Ein funktionierendes fhem wird also immer funktionsfähig in die configDB geschrieben.

Dann habe ich noch Telnet Probleme.

Code Auswählen Erweitern

telnetPort: Can't open server port at 7072: Address already in use. Exiting.

Das hat weder was mit configDB noch mit DbLog zu tun, sondern ist mit 99,9% Sicherheit ein Problem, das in Deiner Betriebssystemumgebung zu suchen ist.

mit dem STATE File habe ich auch Probleme.

Das statefile geht Dich als Benutzer eigentlich überhaupt nichts an, das braucht ausschließlich fhem für seine interne Verwaltung.

Alles in allem erkenne ich in Deiner Auflistung kein Problem, dessen Ursache die configDB sein sollte. Ich tippe eher auf Unzulänglichkeiten in Deinem Betriebssystemumfeld, im Besonderen im Umgang mit SQL-Datenbanken. Aber dazu hast Du ja leider viel zu wenig geschrieben. Alles auf fhem zu schieben ist vermutlich einfacher...

[Mitch]

Die Datenbank ist mysql, welches ich nur für fhem installiert habe und nur für dieses benutze.
Die Tabellen wurden so wie im Commanref beschrieben angelegt.

In die DB logge ich nur die FHTs und drei Temp-Sensoren. Alle anderen devices haben das Attribut DBLogExclude .*

Ich will nicht aussschliessen, dass ich da ein Problem habe, nur läuft mein Server zu 100% ohne Probleme und vor der Umstellung auf die Datenbank hatte ich auch keine Probleme.

Komisch ist auch, dass das Heating_Control erst mit der db aufgekommen ist.



Was an Infos muss ich noch liefern, dass man mir helfen kann?

[Loredo]

Ich stelle auch gerade wieder auf Flatfiles um.
Hiermit bekommst du eine neue fhem.cfg:

Code Auswählen Erweitern


echo "configdb list;exit" | netcat localhost 7072|tail -n +3 > /opt/fhem/fhem.cfg



Edit: Allerdings gibt der Befehl "configdb list" die Geräte scheinbar nicht in der Reihenfolge wieder, wie sie FHEM eigentlich intern führen würde. Out of the Box funktioniert die fhem.cfg daher nicht. Du musst die Geräte noch in die richtige Reihenfolge manuell umsortieren (Global Attribute, FHEMWEB, IO Geräte, etc.). Etwas mühsam, aber man kann es hinbekommen.

[Doggiebert]

da bin ich mal gespannt, ob der Blumenstrauß an Problemen dann weg ist, würde mich aber wundern - stay tuned...

[Mitch]

Danke Loredo.

Aus Interesse, warum stellst Du wieder um?

[betateilchen]

Hiermit bekommst du eine neue fhem.cfg:

Warum macht Ihr Euch eigentlich das Leben so sinnlos schwer?

Code Auswählen Erweitern


attr global configfile fhem.cfg
save config
shutdown


Fertig.

Aber Achtung: in der Konfigurationsdatenbank befinden sich auch sämtliche Konfigurationsdateien anderer Module (z.B. RSS-layouts, DbLog-Verbindungsdateien, gplot-Dateien usw.) die auf diesem Weg nicht automatisch wieder verfügbar werden.

Bis jetzt habe ich immer noch keinen nachvollziehbaren Grund erkannt, warum man den Weg zurück gehen sollte. Ausser mangelndes technisches Verständnis auf seiten des Anwenders, wenn es um fhem generell geht (und nicht um die Frage, woher die Konfigurationsdaten kommen)

[Mitch]

Ja, man kann es immer auf den dummen Anwender schieben.... 

Ich habe seit Umstieg Probleme und um zu Testen, ob es wirklich an der db liegt, gehe ich zurück auf Filestruktur.
Wenn die Probleme weiterhin bestehen, dann kann ich auch sofort wieder zruück auf db.

Ich verstehe nicht, warum du so ein Problem damit hast.

[Loredo]

Danke Loredo.

Aus Interesse, warum stellst Du wieder um?

Für mich läuft es darauf hinaus, dass ich seit der Umstellung auch einige Fehler (oder zumindest hier und dort anderes Reaktionsverhalten, wie ich es gewohnt war) hatte, die ich mir nicht erklären konnte. Bei einem konkreten Fehler habe ich hier im Forum auch seitens des Entwicklers zu hören bekommen, ich würde ja was falsch machen. Das habe ich dann mal so hingenommen.
Letztendlich habe ich kein Vertrauen in configDB gewinnen können und ich habe keine Lust mir den Sourcecode durchzulesen, um mich selbst in die Lage zu versetzen mir selbst zu helfen. Letztendlich kann man bei Flatfiles besser selbst eingreifen (wenn man weiß was man tut). Das ist deutlich aufwändiger, wenn ich dafür die Datenbank manipulieren muss. Das "es funktioniert einfach und ich muss nicht drüber nachdenken" ist halt zu meiner Enttäuschung nicht so.


Daraus resultiert mein Bauchgefühl, dass ich mich lieber wieder in die Lage versetzen möchte, mir selbst helfen zu können, statt auf fremde Mithilfe angewiesen zu sein.




Gruß
Julian

[Loredo]

Warum macht Ihr Euch eigentlich das Leben so sinnlos schwer?

Code Auswählen Erweitern


attr global configfile fhem.cfg
save config
shutdown


Fertig.

Weil du uns diese Abkürzung bisher nicht verraten wolltest

[betateilchen]

Ja, man kann es immer auf den dummen Anwender schieben

Von "dummen" Anwendern habe ich ganz bewußt nirgends etwas geschrieben. Es hat nichts mit "dumm" zu tun, sondern schlichtweg mit Umdenken und mit der Bereitschaft, sich in "anderes" hineinzudenken. Ein "Lesen von Sourcecode" ist dazu überhaupt nicht notwendig und das erwarte ich als Entwickler auch überhaupt nicht vom Anwender.

Und der Weg über das Attribut configfile ist keine Abkürzung, die man irgendjemandem "verraten" müsste, sondern das Attribut gibt es schon seit Urzeiten und es ist in der commandref dokumentiert. Solange eine Vielzahl von Anwendern aber nicht bereit ist, zumindest mal eine Dokumentation zu lesen, wird sich an der Situation des sinn- und grundlosen rumjammernden Anwenders und seinen Schuldzuweisungen an Entwickler nichts ändern.

Dass einem Entwickler ob solcher Umstände irgendwann die Lust vergeht, zum 728. Mal die einfachsten Dinge zu erklären, ist hoffentlich auch nachvollziehbar.

[Mitch]

Mal zurück zum Thema 

Ich habe gestern dann angefangen, die Files aus der Datenbank zurück zu holen:
1. Export aller Files aus der configDB
2. attr global configfile fhem.cfg, save config, shutdown restart (fhem kam ohne Problem mit ein paar Warnungen hoch)
3. attr global configfile configDB, save config, shutdown restart (fhem kam ohne Probleme mit ein paar Warnungen hoch)

Nun war diese Nacht die erste seit Tagen (Wochen), wo fhem nicht abgestürzt ist.
Ob es so bleibt, kann ich noch nicht sagen.

Den Zusammenhang kann ich (asl Laie) nicht nachvollziehen.
Lag es daran, dass ich die Files aus der DB geholt habe?

Ich werde nun weiter auf configDB beleiben und sehen, wie stabil fhem nun läuft.