[BUG] heutiges Update 10_CUL_HM.pm

[octek0815]

Wie wäre es wenn wir hier in diesem Thread beim Thema beliben, und das ist und beleibt vorrangig ein Bug in der 10_CUL_HM.pm.
Andere Probleme wie "falsch eingestellte Backups" oder "gar kein Backup" oder "wie konfiguriere ich FHEM überhaupt" sollten doch lieber in einem neuen oder anderen Thread diskutiert werden.

[marvin78]

Zumal diese Fragen alle vor einem Problem geklärt sein sollten.


Für alle, die das nicht geklärt haben, gibt es aber natürlich auch schon genug dazu in der Dokum, hier im Forum und im Wiki.

[Tedious]

Ich fasse mal zusammen, denn sollte alles gesagt sein, und nicht jeder macht sich ja die Mühe mehr als die letzten 2 Beiträge im Thread zu lesen

Variante 1:

/opt/fhem/restoreDir/DATUM - hier findet sich in aller Regel die jeweils letzte Datei die ersetzt wurde. Also von hier aus in /FHEM kopieren. Läuft wieder

Variante 2:

Bei gesetztem attr global backup_before_update 1 in der fhem.cfg liegen im Backup-Vereichnis gepackte Dateien mit den letzten Änderungen. Auch hieraus kann man die "alte" datei extrahieren und nach /FHEM kopieren. Auch dann läuft wieder alles.

Timestamp der Datei ist erstmal wumpe - ob die nun aus dem Juli oder von vorgestern ist - zumindest läuft erst mal wieder alles.

Wer mit der shell nicht klarkommt - sudo apt-get install mc. Das geht auch mit dem Midnight Commander, mehr dazu hier: https://wiki.ubuntuusers.de/Midnight_Commander/

EDIT: kleine Anmerkung: man sollte IMHO das Backup einfach IMMER mitlaufen lassen. Ich sichere immer das letzte stabile Archiv eines Monats auf einen anderen Rechner bzw. NAS. Alle anderen Backups fliegen in die Tonne. Man kann so zumindest jederzeit auf einen stabilen Stand zurück, selbst wenn der Massenspeicher des FHEM-Rechners in die Knie geht läuft eine Neuinstallation in wenigen Minuten wieder wie vor dem Crash.

[betateilchen]

Man könnte auch einfach in Zeile 7835 der fehlerhaften Moduldatei das dort enthaltene Wort "defined" löschen, damit alles funktioniert.
Dann braucht man überhaupt nicht mit Rumkopieren, Attributen und Backupstrategien rumkaspern.
Und das funktioniert sogar dann, wenn man den FHEM-eigenen Mechanismus zum Update überhaupt nicht verwendet.

[eisman]

hi,
damit stellt sich doch die frage, ist es behoben oder nicht,
an Modul-Dateien sollte man wohl weniger etwas ändern.
mir würde sowas nicht gefallen und
vielleicht sollte man ein extra bereich für solche Fehler machen, dann gibt es auch
keine 20 verschiedene bereiche. wo der Fehler und die Lösungen gepostet werden.
gruss

[marvin78]

etwas ändern.
mir würde sowas nicht gefallen und
vielleicht sollte man ein extra bereich für solche Fehler machen, dann gibt es auch
keine 20 verschiedene bereiche. wo der Fehler und die Lösungen gepostet werden.

Darauf würde ich nicht wetten.

[Tedious]

Man könnte auch einfach in Zeile 7835 der fehlerhaften Moduldatei das dort enthaltene Wort "defined" löschen, damit alles funktioniert.
Dann braucht man überhaupt nicht mit Rumkopieren, Attributen und Backupstrategien rumkaspern.
Und das funktioniert sogar dann, wenn man den FHEM-eigenen Mechanismus zum Update überhaupt nicht verwendet.

Nix für ungut, aber ich denke mal bei kritischer Betrachtung der Probleme die schon beim Thema Update auftauchen mag der eine oder andere beim Thema Editor ggf überfordert sein. Und, dem angelehnt - es wird immer wieder drauf rumgeritten bloß nicht in der fhem.cfg händisch zu arbeiten, das steht ja fast unter Todesstrafe Wer das überblickt macht das trotzdem ab und an... der editiert auch in der pm herum. Aber einerseits zu fordern bei der cfg die finger vom Editor zu lassen und auf der anderen Seite denn in der .pm rumzuknuffeln ist ein schwieriger Spagat.

IMHO ist es denn zielführender auf die funktionale Version zurück zu gehen und auf einen fix zu warten - die lief eh bei 99% der User problemlos.  Der Maintainer kennt sich nun mal am besten mit dem Code und den Änderungen aus, und nicht selten zieht eine manuelle Änderung andere Probleme hinter sich her. Just my 2 cents ;; 

[CoolTux]

hi,
damit stellt sich doch die frage, ist es behoben oder nicht,
an Modul-Dateien sollte man wohl weniger etwas ändern.
mir würde sowas nicht gefallen und
vielleicht sollte man ein extra bereich für solche Fehler machen, dann gibt es auch
keine 20 verschiedene bereiche. wo der Fehler und die Lösungen gepostet werden.
gruss

Schau doch einfach ins SVN dort siehst Du ob seit auftauchen des Fehlers das Modul neu eingecheckt wurde.
Am Modul etwas ändern ist ok, so lange man weiß was man tut.

[betateilchen]

an Modul-Dateien sollte man wohl weniger etwas ändern.

Wer sagt das? Die Lizenz, unter der die Moduldateien von FHEM stehen, erlaubt und fördert sowas ganz grundsätzlich.

Ausserdem wird eine mögliche Lösung ja von perl selbst schon in der Fehlermeldung selbst vorgeschlagen...

[betateilchen]

Um nochmal auf den eigentlich Bug zurückzukommen... es handelt sich schlichtweg um ein versionsabhängiges perl-Verhalten.
In der perl Dokumentation steht:

Use of defined on aggregates (hashes and arrays) is no longer supported.

Also gibt es gar keine andere Lösung, als die Prüfung per defined() in der genannten Modulzeile zu entfernen.

Und vermutlich tritt das Problem bei martin aufgrund einer älteren perl Version in seiner Entwicklungsumgebung gar nicht auf, sonst hätte er das Modul vermutlich so nicht eingecheckt. Und vermutlich hat er deshalb auch diesen Thread hier noch gar nicht entdeckt...

[eisman]

Wer sagt das? Die Lizenz, unter der die Moduldateien von FHEM stehen, erlaubt und fördert sowas ganz grundsätzlich.

hi, du hast da schon recht,

der Rest ist oben schon gesagt, ist halt Internet Problem (ja,nein und vielleicht)
und natürlich kann man in SVN schauen. (Hilft aber nicht jeden)
Oder man schreibt nicht cfg edit=> NEIN include => NEIN und dann mach es selber.

gruss

[raiderxxl]

Mahlzeit,

kann man den Martin den irgendwie anstupsen?

Grüßle

Pascal

[marvin78]

Versuch's doch mal

[Pfriemler]

Andere Probleme wie "falsch eingestellte Backups" oder "gar kein Backup" oder "wie konfiguriere ich FHEM überhaupt" sollten doch lieber in einem neuen oder anderen Thread diskutiert werden.

Stimmt. Aber wer ist der Maintainer von "global"?
Die commandref kennt weder restoreDir noch backup_before_update noch exclude_from_update. Das kann doch keine Absicht sein.

Martin übersieht den Thread garantiert nicht. Aber man darf gern eine PM schicken. Aber nicht alle auf einmal.
Dann reagiert er schneller. Hat jemand schon?

[marvin78]

Natürlich kennt die Commandref diese Attribute. Man findet sie unter update. Ist der Searchbutton in deinem Browser kaputt? Und wer maintainer von update ist, ist klar. Wofür man den in dem Zusammenhang braucht oder wissen muss, wer das ist, ist mir nicht klar.