FHEM startet nicht mehr

[Tardar]

Sorry, ich habe angenommen, dass HMCCU in "attr global exclude_from_update" eingetragen wurde, und deswegen inkompatible Versionen der Dateien vorliegen. Nach pruefen von "konsolenausgabe.txt" stellt sich raus, dass vermutlich "nur" die Reihenfolge der Definitionen verdreht ist: zunaechst kommt HMCCUDEV (und vermutlich danach erst HMCCU).

Loesung #1: Reihenfolge in fhem.cfg wiederherstellen oder "define xx HMCCU" in der fhem.cfg vor dem ersten "define yy HMCCUDEV" eintragen.
Loesung #2: Maintainer benachrichtigen, damit man in HMCCUDEV sicherheitshalber "use 88_HMCCU;" eingebaut wird.

Lösung 1 hat bei mir geholfen
FHEM startet wieder und mein GIT ist auch aktualisiert - vielen lieben Dank
Ich werde den Thread noch an zap schicken, vielleicht kann er hier noch einen Fix liefern, dass der Fehler ggf. anders abgefangen werden kann

Danke nochmal für Eure Hilfsbereitschaft.
Wünsche Euch einen schönen Feiertag und ruhiges Wochenende.

VG
Tardar

[zap]

Der "Fehler" entsteht in 99% der Fälle dann, wenn man entweder die fhem.cfg manuell editiert oder das IODevice nach den anderen definiert (wobei ich mir da nicht mal sicher bin; ggf. stellt fhem die richtige Reihenfolge beim Speichern wieder her).

Ein use HMCCU in HMCCUDEV bringt nichts, da beim define von HMCCUDEV Informationen aus dem IO Device benötigt werden.
Ggf. könnte ich da allerdings etwas einbauen, damit das funktioniert.

Die beste Variante ist: IoDevice vor den anderen definieren und Finger weg von der fhem.cfg

[CoolTux]

Der "Fehler" entsteht in 99% der Fälle dann, wenn man entweder die fhem.cfg manuell editiert oder das IODevice nach den anderen definiert (wobei ich mir da nicht mal sicher bin; ggf. stellt fhem die richtige Reihenfolge beim Speichern wieder her).

Es ist quasi eine menschliche exception 

[Beta-User]

Ähm, kurze Zwischenbemerkung:

Da dieses Reihenfolgethema in der Vergangenheit (bei anderen Modulen) immer mal wieder kam, wäre es m.E. besser, das auch bei der HMCCU-Familie so zu lösen, dass es "unempfindlich" gegen das Problem wird (ging mit global:initialized oder einem InternalTimer, es gab dazu auch einen längeren Thread vor 2-3 Jahren).

Das Problem entsteht jedenfalls nicht nur durch manuelles Editieren (sowas darf man gerne "bestrafen"), sondern tendenziell häufiger durch Löschen/Neuanlagen des IO's (so war es jedenfalls in "meinen" MySensors-Fällen). (fhem.pl oder configDB verhindern das auch nicht). Ist zwar auch eine user-Aktion, aber m.E. keine, die man wirklich als "Fehler" bezeichnen darf.

Gruß, Beta-User