Hi Leute,
nach dem letzten Update von heute bekomme ich im Log folgende Fehler:
2019.09.29 16:16:16 1: FHEM::Meta::__GetUpdatedata: ERROR: Invalid datetime range in FHEM/controls_yeelight.txt:
UPD 2017-31-07_17:17:42 49939 FHEM/32_YeeLight.pm
2019.09.29 16:16:16 1: FHEM::Meta::__GetUpdatedata: ERROR: Invalid datetime range in FHEM/controls_yeelight.txt:
UPD 2017-31-07_17:17:33 6167 FHEM/32_YeeLightBridge.pm
Undefined subroutine &main::HMCCU_FindIODevice called at ./FHEM/88_HMCCUDEV.pm line 125.
2019.09.29 16:15:55 1: PERL WARNING: Use of uninitialized value $model in string eq at ./FHEM/32_YeeLight.pm line 172.
Auf Grund dieser vermute ich, dass mein FHEM nur kurz den service anstartet, aber dann direkt mit einem:
Sep 29 16:21:04 FHEM systemd[1]: Starting FHEM Home Automation...
Sep 29 16:21:04 FHEM fhem[2713]: Starting fhem...
Sep 29 16:21:04 FHEM systemd[1]: Started FHEM Home Automation.
Sep 29 16:21:13 FHEM systemd[1]: fhem.service: Main process exited, code=exited, status=255/n/a
Sep 29 16:21:13 FHEM fhem[2720]: Stopping fhem...
Sep 29 16:21:13 FHEM systemd[1]: fhem.service: Control process exited, code=exited status=1
Sep 29 16:21:13 FHEM systemd[1]: fhem.service: Unit entered failed state.
Sep 29 16:21:13 FHEM systemd[1]: fhem.service: Failed with result 'exit-code'.
zum Absturz bringt :(
Hat jemand von Euch vielleicht eine Idee ? ;)
Vielen Dank und einen schönen Restsonntag
Tardar
Ich wuerde FHEM aus der Konsole mit "perl fhem.pl -d fhem.cfg" starten, und wenn ich mit der Ausgabe nichts anfangen kann, dann diese hier anhaengen.
Anbei die Ausgabe im error.log
Vielen Dank fürs helfen :)
PS: Die IP Adressen hab ich mal etwas verfremdet.
Was passiert nach "Loading ./FHEM/88_HMCCUDEV.pm"?
Haengt es oder kriegt man den Prompt der Konsole?
Beides ist merkwuerdig, und entweder ist die Festplatte kaputt, oder YeeLight beendet FHEM.
Ich wuerde als naechstes FHEM aus der Konsole mit strace starten:strace -o /tmp/xy -f perl fhem.pl -d fhem.cfgund die strace Ausgabe (/tmp/xy) analysieren, oder hier hochladen.
Wenn ich fhem als Service starte, bricht der Start ab und fhem scheint erneut zu versuchen, den service zu starten.
Die xy hab ich hier mal angefügt.
Danke dir
Du hast mir beim vorherigen Beitrag was unterschlagen, in der Konsole muss was mit:
ZitatUndefined subroutine &main::HMCC...
stehen. Oder du hast perl nicht in der Konsole gestartet.
Wenn du strace mit
strace -s 1024 -o /tmp/xy -f perl fhem.pl -d fhem.cfgstartest, dann kann ich Dir auch die komplette Zeile verraten :)
In der Konsole steht das ;) - hab dir die Datei vom Start geschickt - benötigst du die Konsolenausgabe auch noch ? :)
Hier ist sie:
Und hier die gerade generierte Datei :)
VG
Die relevante Zeile ist:
ZitatUndefined subroutine &main::HMCCU_FindIODevice called at ./FHEM/88_HMCCUDEV.pm line 125.
Ich gehe davon aus, dass deine Version von 88_HMCCUDEV.pm nicht zu 88_HMCCU.pm passt.
=> Generell ist es problematisch einzelne Module zu updaten, weil die Entwickler so eine Kombination nicht testen.
Hm
was denkst du wäre jetzt der richtige Schritt für die Lösung des Problems ?
Der Rückschritt auf ältere Versionen der Module kann man zwar machen, bringen aber ja nur temporär eine Veränderung.
Kann ich dieses Thema im Bereich / beim Modul Entwickler angeben für eine Analyse und fix der Module ?
Danke, einen schönen Abend und beste Grüße
Tardar
Du könntest ein komplettes Update machen statt nur, vermutlich, einzelne Module.
Ich update immer mit updatel all :o
Natürlich nur, wenn ein update check Änderungen findet.
Von daher versteh ich den Fehler nur bedingt :D
Dann solltest Du das Problem einmal im entsprechenden Modulthread posten.
Mich wundert allerdings das Du der einzige bist und die Module doch recht beliebt sind.
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.
Zitat von: rudolfkoenig am 01 Oktober 2019, 21:44:45
Loesung #2: Maintainer benachrichtigen, damit man in HMCCUDEV sicherheitshalber "use 88_HMCCU;" eingebaut wird.
Hallo Rudi,
Wäre ein
main::LoadModule('HMCCU');Gleichwertig?
Grüße
Ich gehe davon aus, dass ja, man sollte es aber vor dem Einchecken pruefen. :)
Zitat von: rudolfkoenig am 01 Oktober 2019, 21:44:45
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
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
Zitat von: zap am 03 Oktober 2019, 08:32:45
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 :)
Ä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