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!
Hallo,
siehe http://forum.fhem.de/index.php/topic,27090.msg200328.html#msg200328 (http://forum.fhem.de/index.php/topic,27090.msg200328.html#msg200328)
Gruß
Hans
mich würde eher interessieren, was das für "massive Probleme" sein sollen, die man mit der configDB haben kann...
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:
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.
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.
Zitat von: Mitch am 17 Dezember 2014, 15:04:07
Was komisch ist, weil ja der "Systemlog" nicht in der DB liegt, sondern als File auf der Platte.
Logfiles liegen nie in der configDB.
Zitat von: Mitch am 17 Dezember 2014, 15:04:07
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.
Zitat von: Mitch am 17 Dezember 2014, 15:04:07
Dann habe ich noch Telnet Probleme.
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.
Zitat von: Mitch am 17 Dezember 2014, 15:04:07
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...
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?
Ich stelle auch gerade wieder auf Flatfiles um.
Hiermit bekommst du eine neue fhem.cfg:
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.
da bin ich mal gespannt, ob der Blumenstrauß an Problemen dann weg ist, würde mich aber wundern - stay tuned...
Danke Loredo.
Aus Interesse, warum stellst Du wieder um?
Zitat von: Loredo am 18 Dezember 2014, 09:10:05
Hiermit bekommst du eine neue fhem.cfg:
Warum macht Ihr Euch eigentlich das Leben so sinnlos schwer?
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)
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.
Zitat von: Mitch am 18 Dezember 2014, 10:18:43
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
Zitat von: betateilchen am 18 Dezember 2014, 10:38:43
Warum macht Ihr Euch eigentlich das Leben so sinnlos schwer?
attr global configfile fhem.cfg
save config
shutdown
Fertig.
Weil du uns diese Abkürzung bisher nicht verraten wolltest ;)
Zitat von: Mitch am 18 Dezember 2014, 10:46:05
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.
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.
Den Sinn des dritten Schrittes kann ich beim besten Willen nicht nachvollziehen.
Und von "shutdown restart" nach einem save config war auch nirgends die Rede, ich habe ganz bewußt nur ein "shutdown" oben in die Anleitung geschrieben.
Und wo soll der Sinn eines NUR shutdown sein?
ich habe alle nötigen Files aus der DB geholt und damit ist auch ein shutdown restart ohne Probleme möglich (hat ja auch funktioniert)
Zitat von: betateilchen am 19 Dezember 2014, 10:49:12
Den Sinn des dritten Schrittes kann ich beim besten Willen nicht nachvollziehen.
Ich würde mal sagen "raus aus den Kartoffeln, rein in die Kartoffeln". Ich würde den 3. Schritt als erneuten Versuch in die ConfigDB sehen :)
Richtig, und so habe ich es ja geschrieben:
1. Alles Files aus der DB holen
2. starten mit FLAT File (fhem.cfg)
3. zurück zur DB (starten mit configDB)
Zitat von: Mitch am 19 Dezember 2014, 11:17:40
Und wo soll der Sinn eines NUR shutdown sein?
Wieder mal fehlendes fhem Grundverständnis. Ich erklärs dir (auch wenn es vermutlich wegen Deiner ewigen Besserwisserei ein hoffnungsloses Unterfangen sein wird)...
- Das Attribut "configfile" wird bei einem save config NICHT mit gesichert - weder in die fhem.cfg noch in die configDB.
- Das Attribut "configfile" wird beim Starten von fhem immer automatisch bestimmt, je nachdem, ob fhem mit fhem.cfg oder configDB gestartet wird
- Ein "shutdown restart" startet fhem immer wieder exakt so, wie es ursprünglich gestartet wurde.
Das hat folgende Auswirkungen:
Ein "shutdown restart" nach der beschriebenen manuellen Änderung des Attribut "configfile" wird Dein fhem immer wieder mit der configDB starten und nicht mit fhem.cfg.
Das "nur shutdown" habe ich in die Anleitung geschrieben, damit das fhem kontrolliert beendet wird, nachdem die manuelle Änderung durchgeführt wurde, um Probleme durch die dadurch entstehende Inkonsistenz zu vermeiden. Danach hat man dann die Möglichkeit, zu entscheiden, wie man fhem danach wieder neu starten möchte.
Du hast also sowohl in Schritt 2 als auch in Schritt 3 Dein fhem immer mit der configDB gestartet. Deshalb macht Schritt 3 für mich keinen Sinn.
Vielen Dank für deine Erklärung.
Den ersten Absatz übergehe ich, da ich sehr gerne dazu lerne und mir etwas erklären lasse
Das fhem das Attribut configfile immer automatisch bestimmt war mir nicht bewusst.
Aber es wirft bei mir eine weitere/zusätzliche Frage auf:
Mein Ubuntu Server benutz upstart. In der fhem.conf hatte ich den Startbefehl auf "perl fhem.pl fhem.cfg" geändert, bevor ich ein "shutdown restart" gemacht wird.
Wird nun die conf Datei dabei benuzt?
Wenn ja, dann wurde ja trotz "shutdown restart" mit fhem.cfg gestartet.
Oder wird bei einem "shutdown restart" nicht die upstart conf benutzt?
Zitat von: Mitch am 19 Dezember 2014, 13:26:49
da ich sehr gerne dazu lerne und mir etwas erklären lasse
Nein. Genau das tust Du nicht. Du hast bisher
jede vorgeschlagene Vorgehensweise/Anleitung verändert, Dich danach gewundert, dass etwas Vorgeschlagenes bei Dir nicht funktioniert und trotzdem felsenfest behauptet, alles "genau so gemacht" zu haben wie vorgeschlagen.
Und Deine "Startfrage" habe ich in meinem letzten Beitrag schon ausführlichst beantwortet.
Einfach dort nochmal mit Sinn und Verstand nachlesen.
Over & Out.
Und du hast meine Frage "was passiert genau bei einem shutdown restart" nicht beantwortet.
Aber gut, passt soweit, ich komme damit klar und aus der DB raus, um zu testen.
Zitat von: Loredo am 18 Dezember 2014, 13:38:02
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
Das kann ich absolut zu 100% nachvollziehen!
Ich stehe gerade davor zu entscheiden wie ich FHEM künftig betreiben will.
Ich habe mit configDB getestet, und meine PRD Umgebung lief/läuft auf einem Pi mit fhem.cfg.
Jetzt ziehe ich FHEM vom Pi auf meinen Server um, und dort muss ich überlegen was ich haben will.
Ich arbeite täglich sehr viel mit Datenbanken und das ist für mich jedenfalls kein Hindernis configDB auch zu benutzen.
Ich denke jedoch ich werde allein schon wegen der Supportfrage hier im Forum lieber auf der fhem.cfg bleiben.
Oft kommt die Frage... "Wie schaut deine fhem.cfg" aus.
Viele Beschreibungen im Netz wie jemand was gebastelt hat sind auf Basis der fhem.cfg
Man kann auch ganz einfach jemandem eine BeispielConfig aus der fhem.cfg bereitstellen.
Und so gibt es viele Gründe mehr!
Trotzdem Danke an "betateilchen" dass Du configDB gebaut hast.
@betateilchen
Einen Tipp aber am Rande! Wenn Du Dein "Produkt" an den Anwender bringen willst, bzw. im Mark platzieren willst, dann leiste freundlichen Kundensupport, und zeige Geduld und Verständnis.
Wenn immer wieder die gleichen Fragen kommen überdenke deine Doku. Stell dir die Frage was ein DAU braucht um Dein "Produkt" gut zu finden.
Ist wirklich alles so einfach, oder ist es nur für DICH so einfach? Kann das ein 10jähriges Kind? Mein 2 jähriger Neffe kann der Oma schon auf dem iPhone die Bilder vom letzten Spielplatzbesuch zeigen.
Ist Dein Produkt auch so intuitiv?
BR
Holger
Zitat von: forum-merlin am 03 Juni 2015, 20:05:16
Ich denke jedoch ich werde allein schon wegen der Supportfrage hier im Forum lieber auf der fhem.cfg bleiben.
Oft kommt die Frage... "Wie schaut deine fhem.cfg" aus.
Viele Beschreibungen im Netz wie jemand was gebastelt hat sind auf Basis der fhem.cfg
Man kann auch ganz einfach jemandem eine BeispielConfig aus der fhem.cfg bereitstellen.
Das kann man mit der configDB auch. Beispiel: "configdb list sw4_1" liefert:
search result for device: sw4_1 in version: 0
--------------------------------------------------------------------------------
define sw4_1 CUL_HM 3840DE01
attr sw4_1 userattr structexclude sw4 sw4_map
attr sw4_1 devStateIcon on:10px-kreis-rot off:1px-spacer set.*:1px-spacer
attr sw4_1 group Steckdosen
attr sw4_1 model HM-LC-SW4-DR
attr sw4_1 peerIDs 00000000,
attr sw4_1 room 12 Arbeitszimmer
attr sw4_1 sw4 az_sw4
attr sw4_1 webCmd on:off
(Und das funktioniert sogar für verschiedene Versionen der gleichen Definition, damit man beispielsweise vergleichen kann, was man geändert hat)
Zitat von: forum-merlin am 03 Juni 2015, 20:05:16
Wenn immer wieder die gleichen Fragen kommen überdenke deine Doku. Stell dir die Frage was ein DAU braucht
Er braucht die Fähigkeit, lesen zu können und er sollte nicht anfangen, immer wieder mit "vorher" zu vergleichen.
Zitat von: forum-merlin am 03 Juni 2015, 20:05:16
Mein 2 jähriger Neffe kann der Oma schon auf dem iPhone die Bilder vom letzten Spielplatzbesuch zeigen.
Ist Dein Produkt auch so intuitiv?
Ja. Man braucht sich nach der Umstellung überhaupt nicht darum kümmern. Die meisten hier im Forum beschriebenen "Probleme" mit der configDB resultieren daraus, dass die Anwender sich nicht an das "nicht kümmern müssen" halten.
Mein Hauptgrund für ein zurück zur fhem.cfg wäre, dass ich das besser mit VIM vom Handy aus korrigieren kann.
Ich hatte unlängst ein USB-Device falsch definiert und fhem wollte nicht mehr starten, es verblieb in einer "Warteschleife".
Bis ich dieses Device aus der configDB am Handy gelöscht hatte, verging relativ viel zeit. mit fhem.cfg ist das leichter.
Vermutlich gibt es dazu aber auch einen einfachen SQL-Befehl dafür?!? ein FHEM-Befehl konnte ja nicht ausgeführt werden...
Hallo,
ich habedas Problem mit hängern in FHEM auchlange Zeit gehabt und SQL Prozess mit 100% in TOP. Das Problem ist weg, seitdem ich DBlog abgeklemmt habe. Scheint ein Problem mit DBlogging und mySQL zu sein. CONFIGDB istdefinitiv nicht das Problem.
Just my 2 cents :)
Das würde ich an deiner Stelle mal analysieren. DBLog macht solche Probleme nicht generell. Es kann sein, dass du zu viel Logst oder andere Probleme bestehen.
Zitat von: Klaus Rubik am 09 Dezember 2015, 11:03:50
Hallo,
ich habedas Problem mit hängern in FHEM auchlange Zeit gehabt und SQL Prozess mit 100% in TOP. Das Problem ist weg, seitdem ich DBlog abgeklemmt habe. Scheint ein Problem mit DBlogging und mySQL zu sein. CONFIGDB istdefinitiv nicht das Problem.
Just my 2 cents :)
Ich habe keine Probleme damit und liebe Dblog! Habs sogar auf dem Rpi mit mysql am laufen.... Nie 100% ausgelastet!
Also ich kann nur so viel sagen, seit ich wieder auf cfg FIle bin, habe ich keine Probleme mehr.
dblog benutze ich nach wie vor für meine Heizung.
Zur Laufzeit von fhem verursacht die configDB keine Last, da aus der Datenbank nur beim fhem-Start gelesen und die Datenbank dann wieder geschlossen wird.
Zitat von: betateilchen am 18 Dezember 2014, 10:38:43
attr global configfile fhem.cfg
save config
shutdown
Das funktionierte gerade eben nicht! die Datei fhem.cfg wurde nicht erstellt! Weder im Filesystem noch in der DB
ist sie vorhanden. ich habe sogar sämtliche Verzeichnisse danach durchscht, ohne erfolg!
Unter "Edit files" sieht man die Datei, wenn ich da jedoch draufklicke, bekomme ich eine Fehlermeldung, dass sie nicht angezeigt werden kann...
Lt. commandref hat sich hier jedoch in der zwischenzeit nichts geändert?!? Gibt es eine neue Version dieses befehls?
"save config" schreibt die Konfiguration in die Datei config
Vielen Dank! so funktionierts natürlich!