disabled Device "dblog" verschwindet beim Restart

[JoeALLb]

Ich habe 2 Devices "DBLOG", eines mit Mysql als Backend, eines mit SQLITE.

Das MySQL habe ich deaktiviert, da die DB derzeit nicht erreichbar ist.
Wenn ich FHEM nun neu starte, steht im Log, dass MySQL nicht erreicht werden kann.

Erwarten würde ich mir:
* Dass das Device nicht versucht, die DB anzusteuern, da es disabled ist
* Dass ich das disablede Device in FHEM sehen  um es ggf. zu löschen oder zu prüfen, ob es tatsächlich deaktiviert ist.
* Dass das Device beim klick auf save nicht still aus der fhem.cfg entfernt wird. Dies hängt jedoch bestimmt mit dem oberen Punkt zusammen.

Wird hier das Attribut disabled=1 zu spät angewendet?

[betateilchen]

Das Attribut kann logischerweise erst gesetzt und angewendet werden, wenn das Device exisitiert.

Beim Starten von fhem ist der Ablauf also folgender:

ZUERST wird das festgelegte define für das Logdevice ausgeführt und versucht, das device anzulegen,
DANACH wird das eben kreierte Logdevice disabled.

[JoeALLb]

Danke für die Antwort,
das dachte ich mir fast so. Aber was passiert, wenn das Device ein Attribut benötigt, um überhaupt erst erzeugt zu werden?
So wie in meinem Fall.... ? Sollte es nicht einen Moment warten, bis alle Attribute gesetzt wurden?

Ich finde es unschön und Fehleranfällig, wenn Devices bei einem Restart verschwinden, nur weil der MySQL-Server gerade nicht verfügbar ist.
Gerade ein LogDevice sollte nicht so einfach verschwinden.

[betateilchen]

Aber was passiert, wenn das Device ein Attribut benötigt, um überhaupt erst erzeugt zu werden?

Eine solche Abhängigkeit sollte auf keinen Fall in einem Modul programmiert werden.
Du kannst ein disabled ausschließlich auf ein vorhandenes Device setzen und damit die Verwendung des Device ein- und ausschalten.
Das Device kann aber in Deinem Fall gar nicht angelegt werden, weil sein Lebenszweck (eine MySQL Datenbank anzusprechen) nicht erfüllt werden kann.

Für das, was Du tun möchtest, ist das Attribut einfach ein Denkfehler - dafür ist es nicht vorgesehen.
Kommentiere die entsprechenden Zeilen für das Logdevice in der fhem.cfg einfach aus, solange die MySQL Verbindung nicht existiert.

[rudolfkoenig]

Ich sehe das Problem im Modul: nur weil das benoetigte Geraet/Dienst/etc beim FHEM-Start nicht erreichbar ist, sollte die Definition doch nicht fuer immer aus fhem.cfg verschwinden. Ich kann auch ein CUL definieren, ohne dass es angeschlossen ist, 00_CUL.pm prueft alle 5-Sekunden, ob es eingesteckt ist, und wenn ja, wird es geoeffnet und initialisiert.

disabled war dazu gedacht, die Funktion nicht auszuloesen, in diesem Fall also keine Daten zu speichern.

[JoeALLb]

Danke Rudi, sehe das genau so! Es kann ja immer mal passieren, dass ein MySQL-Dienst kurz nicht antwortet! Das ist kein Denkfehler, sondern eine nicht erreichte Verfügbarkeit von 100%.

Ich habe es deswegen kurzzeitig disabled, da ich die Fehlermeldungen, die während der DB-Umstellung sonst in FHEM erschienen wären, nicht sehen wollte.

[betateilchen]

Ich sehe das Problem im Modul: nur weil das benoetigte Geraet/Dienst/etc beim FHEM-Start nicht erreichbar ist, sollte die Definition doch nicht fuer immer aus fhem.cfg verschwinden.

Dann muss man aber ca. 99% aller Module erstmal umschreiben - ich denke, CUL ist da die einzige (mir bekannte) rühmliche Ausnahme.

Und verschwinden tut die Definition aus der fhem.cfg ja erst beim nächsten Abspeichern - und dafür ist nicht das Modul verantwortlich, sondern fhem.pl

[justme1968]

es ist sehr unglücklich das dblog einfach weg ist wenn es keine verbindung zur db bekommt.

andererseits hat ein modul zur zeit keine einfache möglichkeit etwas auf die konsole auszugeben und einen fehler zu signalisieren und trotzdem weiter zu laufen. wenn define etwas zurückgibt das dann angezeigt wird wird das device nicht angelegt...

[betateilchen]

andererseits hat ein modul zur zeit keine einfache möglichkeit etwas auf die konsole auszugeben und einen fehler zu signalisieren und trotzdem weiter zu laufen.

Wieso nicht? Es kann z.B. in der DefFn einen Fehler loggen und versuchen, den Verbindungsaufbau zur Datenbank regelmäßig zu wiederholen.

[rudolfkoenig]

Dann muss man aber ca. 99% aller Module erstmal umschreiben

Ich schaetze es auf hoechstens 20%. Alle, die DevIo_OpenDev verwenden, haben das Problem nicht (22 Module), und alle logischen Module (FS20/CUL_HM/etc) bzw. Helper wie at/notify/etc auch nicht. Allerdings gebe ich zu, dass FileLog das auch falsch macht.

andererseits hat ein modul zur zeit keine einfache möglichkeit etwas auf die konsole auszugeben und einen fehler zu signalisieren und trotzdem weiter zu laufen.

Bin der Ansicht von betateilchen: Man kann mit Log was ausgeben, Status auf disconnected setzen, und immer wieder probieren. Ist aber auch doof bei meinem typischen FileLog Fehler, wenn ich die beiden Parameter vertausche.

[justme1968]

wenn ich ein define in telnet tippe möchte ich in diesem fall direkt und sofort eine fehlermeldung sehen.

ich weiß das ich ins log schauen kann. das ist aber nicht intuitiv und nicht was man erwarten würde. jedenfalls nicht bei interaktiver benutzung.

das modul sollte also bei interaktiven define mit einem fehler abbrechen und beim define aus dem config file ins log schreiben.

[rudolfkoenig]

Daran habe ich auch schon gedacht. Aber:
- dann kann man nichts definieren, was nicht sofort funktioniert.
- Im DefineFn fehlt es an Info, ob man aus fhem.cfg oder FHEMWEB aufgerufen wurde. Dazu muesste CommandDefine das $cl an DefineFn weiterreichen.

[JoeALLb]

- dann kann man nichts definieren, was nicht sofort funktioniert.

Das könnte man mit einem "-force" dennoch erlauben.

[justme1968]

alles bevor $init_done true kann nicht interaktiv sein.

vermutlich muss man sich noch was für rereadcfg überegen. oder endlich verbieten

[justme1968]

ansonsten wäre auch eine unterscheidung on ein set per web oder per telnet aufgerufen wurde sehr hilfreich. dann kann man im web ein set per maus bedienen ohne aus der detail ansicht rauszufliegen und wenn man es interaktiv eingibt die rückgabe lesen. in der LightScene versuche ich das mit einem workaround der fast immer geht aber unschön ist.