von configDB wieder zurück auf TXT File

[betateilchen]

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.

[Mitch]

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)

[Klaus Rubik]

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

[Mitch]

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)

[betateilchen]

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.

[Mitch]

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?

[betateilchen]

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.

[Mitch]

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.

[forum-merlin]

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

[betateilchen]

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:

Code Auswählen Erweitern


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)

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.

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.

[JoeALLb]

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...

[Klaus Rubik]

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

[marvin78]

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.

[JoeALLb]

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!

[Mitch]

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.