Rätselhaftes Überschreiben der fhem.cfg

[Prof. Dr. Peter Henning]

Guten Morgen,

zusammen mit Daniel (ext23) stehe ich vor einem Rätsel.

Ich bin inzwischen seit mehr als einem Jahr dabei, ein neues OWX-Backend zu bauen, das sowohl synchron, als auch asynchron laufen kann. Hat sich als schwierig herausgestellt, weil das Timing des 1-Wire Bus zeitkritisch ist - aber läuft inzwischen einigermaßen rund.

Dabei werden dieselben Frontendmodule wie bisher verwendet (na ja, ein paar minimale Anpassungen gibt es schon).

Nun schreibt aber ext23, dass bereits der einfache Ersatz des alten 00_OWX.pm durch das neue 00_OWX.pm dazu führt, dass bei ihm die gesamte Konfigurationsdatei zerschossen wird. Das kann m.E. nur passieren, wenn ein "Save" ausgelöst wird, bevor die Datei komplett eingelesen wurde - aber, um Himmels Willen, wodurch denn ?

Es gibt nur einen strukturellen Unterschied: Das in der Distribution befindliche 00_OWX.pm erwartet Hilfsmodule OWX_SER.pm etc. während das "neue" Hilfsmodule 11_OWX_SER.pm etc. erwartet.

Ich habe jedenfalls die derzeit noch etwas Alpha-mäßige Version des Backends auf allen meinen Systemen im Einsatz, und kein solches Problem, wenn ich eine neue Version aufspiele.

Ärger gab es nur einmal: Bei der Umstellung von 5.7 auf 5.8 hat es beim ersten Start meine config.db zerschossen. Ich weiß aber bis heute nicht, warum - das kam danach niemals wieder vor, war auch schnell behoben.

Ich werde sehen, ob ich ext23 bewegen kann, seine Probleme hier genauer zu schildern.

Die aktuellen Alpha-Versionen hänge ich hier an - aber bitte Vorsicht, nicht einfach irgendwie installieren. Ich möchte nicht, dass jemand sich damit ein Problem einhandelt. Aber vielleicht gibt es ja irgendeinen dummen Fehler, den man durch eine Code-Inspektion finden kann.

LG

pah

[zap]

Irgendein Modul könnte ja während dem Start von FHEM den Save auslösen, oder?

[CoolTux]

Es muss nicht mal ein Modul sein. Es kann auch eine eigene Anwender Sub oder ein Notify sein.

[zap]

Den Status von FHEM (Initialized oder nicht) könnte man aber in CommandSave() abfragen und entsprechend das Speichern verweigern, sofern der Start von FHEM noch nicht abgeschlossen ist. Momentan wird das nicht gemacht, habe gerade in fhem.pl mal nachgeschaut.

[rudolfkoenig]

Stimmt, man koennte aber auch vieles sonst pruefen, was unpausibel ist.
Wie schafft man waehrend des Startens ein save auszufuehren?

[Thorsten Pferdekaemper]

Wie schafft man waehrend des Startens ein save auszufuehren?

Ein Modul schreiben, das im Define CommandSave aufruft?
...oder man schreibt das save direkt in die fhem.cfg rein.
Ich gebe zu, dass das beides ziemlich dämlich wäre, aber möglich. Oder?
(Ich sage damit nicht, dass pah oder ext23 so etwas tun. Ich wollte nur Rudis Frage beantworten.)
Gruß,
   Thorsten

[rudolfkoenig]

Ok, ich korrigiere, ich wollte einen halbwegs sinnvollen Grund fuer save in fhem.cfg haben.
Man kann schliesslich auch "rm -rf /" ins fhem.cfg reinschreiben, ich fuehle mich trotzdem nicht genoetigt, dagegen was zu unternehmen.

[Prof. Dr. Peter Henning]

Hm, Daniel schreibt, dass es sich nicht um ein Save handeln könne.

Hier sein O-Ton (hat hier keine Schreibrechte):

Es geht nicht um ein "Save". Hier wird kein Save ausgeführt, das muss man wenn dann manuell machen! Noch mal kurz zur Problem Beschreibung:
Vorher:
FHEM läuft, keine Änderungen im pending (Also kein rotes Fragezeichen neben "Save config")

Jetzt tausche ich die 00_OWX aus und starte FHEM neu (shutdown restart oder service fhem restart, egal)

Nachher:
FHEM läuft, aber ich sehe jetzt das rote Fragezeichen, schaue ich dort rein sehe ich die maximal anzuzeigender Änderungen (10 oder so). Da ist aber ALLES drin, also wenn ich jetzt save drücke, wird die gesamte config neu geschrieben. Das habe ich einmal gemacht, danach lief aber einiges nicht. Vermutlich macht er nicht alles richtig.
Mache ich aber bevor ich ein save mache ein "rereadcfg" ist alles OK, das Fragezeichen ist auch weg. Aber nur bis zum nächsten Neustart!

Vielleicht hilft die Beschreibung etwas besser. Also es wird hier kein automatisches Save ausgelöst, das ist falsch.

Ich verstehe aber jetzt noch weniger, als vorher, was hier abläuft.

LG

pah

P.S.: So trottelig, dass ich während der Initialisierung des Moduls ein Save ausführe, bin ich nun doch noch nicht.

LG

pah

[Thorsten Pferdekaemper]

P.S.: So trottelig, dass ich während der Initialisierung des Moduls ein Save ausführe, bin ich nun doch noch nicht.

Deshalb habe ich je extra das hier geschrieben:

(Ich sage damit nicht, dass pah oder ext23 so etwas tun. Ich wollte nur Rudis Frage beantworten.)

Jetzt zu der Problembeschreibung:
Das sieht eher so aus, dass FHEM die fhem.cfg komplett liest, aber dann am Ende der Meinung ist, dass das alles nicht in der fhem.cfg steht. Woher weiß eigentlich FHEM beim Starten, dass die ganzen defines etc. aus der fhem.cfg kommen und nicht danach vom Benutzer eingegeben warden? Vielleicht geht bei diesem Mechanismus was schief.

Gruß,
   Thorsten

[rudolfkoenig]

FHEM läuft, aber ich sehe jetzt das rote Fragezeichen, schaue ich dort rein sehe ich die maximal anzuzeigender Änderungen (10 oder so). Da ist aber ALLES drin, also wenn ich jetzt save drücke, wird die gesamte config neu geschrieben.

Das rote Fragezeichen gibt @structChangeHist aus. Dieser wird von jedem attr/define/modify/delete/deleteattr/rename gefuellt, aber nur wenn $init_done nicht wahr ist. Evtl. wird $init_done von jemandem zu frueh auf 1 gesetzt. Sollte aber trotzdem nicht direkt fuers kaputtschreiben der fhem.cfg verantwortlich sein, hoechstens auf einem mir noch unbekannten indirekten Weg.

Ich sehe gerade, dass 70_SCIVT.pm, 70_SISPM.pm und 70_TellStick.pm temporaer init_done auf 1 setzen, statt den letzten Parameter von InternalTimer auf 0. Sollte aber keine Auswirkungen haben.

[justme1968]

@rudi: $waitIfInitNotDone=1 im InternalTimer funktioniert sowieso nicht. zumindest nicht so wie man es erwarten würde. das warten ist blockierend und in fhem ändert sich nichts. die drei module oben könnten also ihre routine auch direkt aufrufen. oder ein perl sleep verwenden.

zumindest 70_SCIVT.pm setz readings und triggert events bevor fhem richtig läuft. da $init_done temporär umgebogen wird kann ich mir schon szenarien vorstellen bei denen dann etwas schief geht. aber ich glaube eher nicht das es im zusammenhang dieses threads relevant ist.

ich denke waitIfInitNotDone sollte entfernt/ignoriert werden und das umbiegen von init_done verboten.

zu dem konkreten problem hier: ein stacktrace aus CommandSave müsste helfen zu identifizieren ob es wirklich an einem save liegt.

[CoolTux]

@rudi: $waitIfInitNotDone=1 im InternalTimer funktioniert sowieso nicht. zumindest nicht so wie man es erwarten würde. das warten ist blockierend und in fhem ändert sich nichts.

Kann ich bestättigen. Ich hatte eine 1 als zweiten InternalTimer Wert in meinem PLAYBULB Modul im Define Teil und da ich 8 Devices hatte hat sich das starten von FHEM ewig hingezogen.

[Prof. Dr. Peter Henning]

Hier noch eine weitere Beschreibung von ext23:

Hinter dem Fragezeichen sieht man ja alle Änderungen die im "pending" sind, also alles was in den config files geändert wird "wenn" man save drückt. Dort werden aber nur maximal 10 Sachen angezeigt. Die Liste ist in Wirklichkeit aber länger also dort steht dann alles drin was ich als define auf dem System habe. Drücke ich dann save, schreibt der alle config files neu. Ich habe das nur ein mal gemacht, dann wurden aber alle 1-Wire Geräte irgendwie neu angelegt mit neuen namen etc. Habe ich in die config files geschaut fehlten viele Einträge. Ich habe dann nur noch die Kommentare gesehen. Eventuell sind die Änderungen auch in die Hauptkonfiguration (fhem.cfg) gerutscht, das weiß ich nicht. Ich habe mir das nicht so genau angeschaut.

Aus meiner Sicht ist diese Beschreibung immer noch nicht zielführend. Aber es kristallisiert sich ein Verdacht heraus, um dessen Bestätigung ich Daneil jetzt gebeten habe:

2. Kann es sein, dass die Defines der ganzen 1-Wire-Geräte in untergeordneten cfg-Dateien liegen ? Und dass die 1-Wire Geräteerkennung so früh los läuft, dass diese Geräte einfach mit den Default-Namen in der Haupt-Konfiguration neu angelegt werden, weil sie schon auf dem Bus gefunden wurden, bevor die (alten) Defines gelesen wurden ?

LG

pah

[CoolTux]

Das wäre endlich mal eine wirklich plausible Begründung. Auf die Antwort bin ich mega gespannt. pah bitte sei so nett und gib uns das Ergebnis dann hier bekannt. Danke

[CoolTux]

Code Auswählen Erweitern

Ich glaube ich kann Deine Frage beantworten. Unsicher zwar aber

[quote]
Eine Frage, ich habe die Config Files alle nach Räumen aufgeteilt und mit
include eingebunden. Das funktioniert auch ganz gut wenn man bei einiges
Sachen die Reihenfolge beachtet. Ich stelle nur immer wieder fest, dass
meine 3 AT Jobs immer wieder in die Hauptconfig wandern nachdem neue Geräte
durch autocreate hinzugefügt würden.

Ist das noch ein kleiner Fehler oder irgendwie bedingt durch den Aufbau?

Und dann hätte ich ja noch einen kleinen CR anzumelden ;-) Es wäre ganz
praktisch wenn die mit include eingebundenen Config Files auch über die
Webseite editierbar wären.

Viele Grüße
Daniel


Unsicher daher, weil diese Aussage aus dem Jahr 2012 stammt.