[gefixed] Heutiges CUL_HM update defekt

[Jamo]

Hallo,
nach heutigen update funktioniert meine gesamte Homematic konfiguration nicht mehr.
Alle 'channels' aller Devices, ausser 'channel_01' sind verschwunden.

Ausserdem bekomme ich folgende Fehlermeldung für alle Homematic devices:

Code Auswählen Erweitern

unknown attribute .mId

Das dürfte das gleiche Problem wie beim Vorredner sein. https://forum.fhem.de/index.php/topic,95405.0.html
Wenn man das alte CUL_HM wieder zurückspielt, und ein get config macht, bekommt mann immer ein "RESPONSE TIMEOUT:RegisterRead".

[tomster]

Super. Jetzt hab ich dummerweise gerade vor 30 Minuten ein Update gemacht. Alle CUL_HM wie von Dir beschrieben. *GRRR*

[LuckyDay]

wer heute ein update gemacht hat,

sollte da /opt/fhem/restoreDir/update/2019-01-06

auch die "alte" vor update" fhem.cfg liegen haben 

[Jamo]

Update:
Es ist wohl so, das man nach dem Update von heute morgen alle Geräte komplett neu anlernen muss. Das update an sich ist in Ordnung.

Weil ich jetzt sowieso alles neu anlernen musste, habe ich probehalber die neuen 00_HMLAN.pm und 10_CUL_HM.pm (also das update von heute morgen) doch nochmal eingespielt,
und nach dem neu anlernen sind alle Channels wieder da. Aber alle user attribute der Channels sind natürlich weg, etc.

backup einspielen und fertig

[marvin78]

Das ist natürlich quatsch. Bitte darüber informieren, was Anlernen (pairen) bedeutet. Und ein restore sollte gehen. Backup einspielen auch.

[Jamo]

Korrekt, Backup einspielen hat geholfen.

[yersinia]

Ich kann mich kaum beklagen. FHEM war zwar nach dem Update (und shutdown restart) tot (fhem start scheiterte wegen fehlender zugriffsberechtigungen auf das aktuelle log file); manuelles Neustarten via Console hilf auch nicht. Fix Raspi neu gestartet und dann brauchte FHEM etwas zum Starten aber dann ging es. Und nun läuft es.
Probleme mit den HM Devices kann ich nicht bestätigen. Pairing blieb bestehen, via VCCU konnte auch HM Devices schalten, auslesen (getconfig) etc.; Kanäle sind auch vorhanden. Also bis auf das verschlucken beim Neustart läufts.

Ich hab nur einige Warnings im Log:

2019.01.06 16:16:30 1: PERL WARNING: Use of uninitialized value in split at ./FHEM/10_CUL_HM.pm line 8539.
2019.01.06 16:16:30 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/10_CUL_HM.pm line 6591.
2019.01.06 16:16:30 1: PERL WARNING: Use of uninitialized value in split at ./FHEM/10_CUL_HM.pm line 6595.
2019.01.06 16:16:32 1: PERL WARNING: Use of uninitialized value $cmdS in concatenation (.) or string at ./FHEM/10_CUL_HM.pm line 4118.

[sensorle]

Hallo,

Bei mir tritt besagtes Verhalten auch auf.
Alternativ zum Backup hat bei mir funktioniert bei allen Geräten mit

Code Auswählen Erweitern

attr HM_Name modelForce GeräteBezeichnung
die Gerätebezeichnung neu zu setzen. Dadurch wird automatisch auch das Attribut "model" gesetzt. Ist natürlich Aufwand...
Das Attribut modelForce kann danach wieder gelöscht werden.

Gruß,
Jürgen.

[Hollo]

Ich frage einfach mal blöd nach dem aktuellen Stand, bevor noch mehr User Probleme haben und es dann wieder zig neue Threads gibt...

- Was ist die Ursache?   (nur die Cul_HM?)
- Wird das fehlerhafte Modul weiterhin per Update verteilt?
- Was muss nach einem Restart gemacht werden?
- Was kann vor einem Restart gemacht werden?

Derzeitiger Kenntnisstand (bitte korrigieren):
- einfachster Weg ist das Einspielen der 10_CUL_HM.pm + 00_HMLAN.pm + fhem.cfg aus dem Restore-Ordner

[breti]

Tja, mich hat's auch erwischt... "RESPONSE TIMEOUT:RegisterRead" überall... mir ist auch noch nicht ganz klar, was zu tun ist...

[Frank_Huber]

Hat mal einer den Maintainer angeschrieben?

Gesendet von meinem Doogee S60 mit Tapatalk

[marvin78]

Tja, mich hat's auch erwischt... "RESPONSE TIMEOUT:RegisterRead" überall... mir ist auch noch nicht ganz klar, was zu tun ist...

Restore oder Backup einspielen. Grundlagen, mit denen man sich vor dem Produktiveinsatz einer solchen Software beschäftigen MUSS.

[Hollo]

Hat mal einer den Maintainer angeschrieben?

Hab ihn per "Moderator informieren" auf diesen Thread hingewiesen, da der Moderator zufällig auch Maintainer der besagten Module ist.   

[Udomatic]

Alternativ zum Backup hat bei mir funktioniert bei allen Geräten mit

Code Auswählen Erweitern

attr HM_Name modelForce GeräteBezeichnung
die Gerätebezeichnung neu zu setzen. Dadurch wird automatisch auch das Attribut "model" gesetzt. Ist natürlich Aufwand...

Mich hat es auch erwischt. Der Subtype bei den Devices wird gelöscht. Mit Modelforce wird es wieder gesetzt.
Muss man Modelforce löschen oder kann es auch als Attribut gesetzt bleiben?

Gruß Udo

[det.]

irgendwie wird die Liste unter allr global exclude_from_update immer länger... Dabei findet jeder Entwickler mit Sicherheit 3-4 User mit unterschiedlichen Settings, welche gern bereit sind, die Module vor der Veröffentlichung auf Nebenwirkugen zu testen. Gibt es hier inzwischen Neuigkeiten, die ich überlesen habe?
attr HM_Name modelForce GeräteBezeichnung half leider bei meinem virtuellen doorcontakt nicht weiter