[gefixed] Heutiges CUL_HM update defekt

[curt]

Vielleicht mal noch mal getConfig und "Anlernknöpfchen" drücken...

Danke erstens für den Hinweis und zweitens für das Mut-machen. Nach einer nächtlichen Turnstunde habe ich nun Muskelkater, aber so ganz langsam pendeln die sich wieder ein.

Falls noch was sein sollte, würde ich mich melden.

Danke sehr!

[rico5588]

Moin,
heute Früh wieder mal ein Update gemacht...

Code Auswählen Erweitern

configfile: VCCU: unknown attribute .mId. Type 'attr VCCU ?' for a detailed list.
Und noch 20 weitere...
Habe diese Woche schon 3 mal nach einem Fehlerhaften Update ein Backup wiedereingespielt.
Bei den ersten malen waren ganzen Geräte verschwunden oder auch nur einzelene Kanäle.
Soll das ernst gemeint sein, das ich mich vor jedem Update hier ins Forum bemühe um zu sehen ob jemand einen Fehler gemacht und ein anderer dies unschön bemerkt hat.
Kann so nicht euer ernst sein!!!

Nur so als Idee.
Wie wäre es mit einem Info Device über Aktuelle Hinweiße von der "FHEM-Zentrale" an FHEM.
Soll heisen, bei solchen Problemen bekommt man vor einem Update einen Hinweiß - "Update  Fehlerhaft, wenn möglich abwarten"

MFG Rico

PS: Backup wieder einspielen oder abwarten?

[martinp876]

Ich fasse es noch einmal so zusammen
- technisch
   # aktuell wird die Struktur der Entites aus dem Attribut "model" abgeleitet. Um mit Bugs von eQ3 umgehen zu können muss man das überschreiben können. "model" wird (leider) auch von anderen Modulen genutzt weshalb ich es nicht ändern kann. Somit wird das Attribut ".mId" eingeführt und automatisch befüllt. Das klappt vollautomatisch - allerdings nur bei einem reboot => "shutdown reboot".
  # Mein Fehler war anzunehmen, dass bei einem "Update" ein auch ein Reboot durchgeführt wird.
  # CUL_HM/HMInfo ändert NIE ohne Kommandos Register/peering/pairings. So lange man das nicht anstößt wird das System ohne Zentrale weiterlaufen (ein Grund warum ich möglichst viele Funktionen ohne Zentrale realisiere -> Ausfallsicherheit)
  # wenn man kein Save macht dürfen auch keinen neuen Attribute (".mId") gespeichert werden und nach einem Reboot sollten diese nicht mehr vorhanden sein. Macht man ein Save ist das Attribut gespeichert - logisch.

- ein Kanal Devices
  # Wie im Einsteigerdoc beschrieben wird ( im Gegensatz zu einer Sauberen Installation) Kanal und Device nicht getrennt. Das ist eine Vereinfachung (vielleicht). Der Anwender hat aber immer die Option, Kanal 01 anzulegen oder zu löschen um diesen Device und Kanal zu trennen oder zu kombinieren. Hierbei werden die Attribute und Readings nicht übernommen (wie auch). Readings werden sich automatisch wieder einstellen (getConfig, Statusmeldungen,...) und die Attribute (welche nicht Systembedingt sind) liegen beim Anwender.
  => wenn beim Update Device und Kanal getrennt wurden kannst du den Kanal 01 einfach löschen
  => dass der Kanat abgetrennt wurde sollte typisch nicht passieren - ich versuche das einmal zu simulieren

- Ablauf
  # da nach dem Update kein Reboot durchgeführt wurde kam es zu den Problemen. Ein "shutdown reboot" hätte das Problem beheben müssen - und ich habe Meldungen, dass dies bei manchen so funktioniert hat. Wäre also ganz einfach... aber ich verstehe natürlich die Frustration.
  # sollte ein Update automatisch NACH den update ein Save machen hat man natürlich ein"altes". Macht man nun den "update" auf die alte (jetzt aktuelle) Version macht es Sinn, das vom ersten Update gesicherte fhem.cfg einzukopieren.
  => ein Einspielen des alten Standes sollte kein Problem sein wenn man
    + einen neuen Update macht
    + das fhem.cfg for dem ersten Update rein-kopiert
    + einen shutdown restart macht
    + maximale Fehlermeldungen könnten Readings sein, welche nicht mehr passen. Diese würde ich inorieren.


- Nächster Update
  # da ich mich leider nicht auf den restart verlassen kann muss ich wohl doch hässliche Abfragen einbauen. In jedem Fall werden die neuen Funktionen erst aktiv, wenn man einen reboot macht. Geht nicht anders.

[DoubleD]

Hallo Martin.

Danke das du dich so einsetzt!

Ich kann Dir in meinem Fall versichern das ich 100%tig ein shutdown/reboot durchgeführt habe.
Direkt danach wurde mir schon angezeigt das Kanäle gelöscht wurden und ab diesen Zeitpunkt ging auch kein HM Aktor mehr. Siehe mein vorheriger Beitrag.

Danke & Gruß
Daniel

[oldscout]

Hallo, ich schliesse mich den Vorrednern an....heute nachmittag geupdatet, es geht bei meinen Rollos kein down,stop, level, pct mehr .....

Bitte anschauen.

Danke.

[Hollo]

Nein. Alles wieder in Ordnung.

Aufgrund der massiven Probleme bei verschiedenen Usern, verbunden mit deren unterschiedlichen Kenntnissen & Fertigkeiten, finde ich derartige Beiträge absolut nicht sinnvoll.

Auch wenn ich selbst bisher nicht betroffen bin, da ich glücklicherweise vor dem Update im Forum geguckt habe, finde ich die Vorgehensweise Mist.
Habe den ganzen Thread verfolgt und mehrfach gelesen...
der aktuelle Stand ist mir trotzdem nicht klar; anderen geht es vermutlich ähnlich.

Das ist keine Kritik am Modul-Maintainer; jeder verdient sein Geld im Job und das hier ist Hobby.
Aber bei den Usern ist es doch vergleichbar; wenn plötzlich nix mehr geht und die Zeit fehlt, kommt Hektik auf; auch mit Backup.

IMHO fehlt FHEM da ein Krisenmanagement, um weitere User zu schützen, und den Modulmaintainern etwas Zeit zu verschaffen!

Beispiel bei mehreren Problemmeldungen...
- 1 angepinnter Beitrag mit Infos
- besser noch ein roter Hinweistext mit Link dazu (wie bei neuen Release)
= man findet das vielleicht ohne die blöde Sufu und es kommen nicht drölfzig neue Threads

- Modul-Update wird nicht mehr ausgeliefert
- ältere Version wird wieder ausgeliefert
- Extra-Thread mit neuer Version und Beta-Testern (siehe aktuell 59_Weather)
- toll wäre natürlich ein Hinweis im Update-Check

Das ist nur so eine Idee, aber es guckt nicht jeder vor'm Update ins Forum.
Und es wird bei anderen Meldungen/Fragen auch gern "gemäkelt", ob denn erstmal alles auf dem aktuellsten Stand ist.

Sorry, das musste jetzt erstmal raus.   

[Udomatic]

- ein Kanal Devices
  # Wie im Einsteigerdoc beschrieben wird ( im Gegensatz zu einer Sauberen Installation) Kanal und Device nicht getrennt. Das ist eine Vereinfachung (vielleicht). Der Anwender hat aber immer die Option, Kanal 01 anzulegen oder zu löschen um diesen Device und Kanal zu trennen oder zu kombinieren. Hierbei werden die Attribute und Readings nicht übernommen (wie auch). Readings werden sich automatisch wieder einstellen (getConfig, Statusmeldungen,...) und die Attribute (welche nicht Systembedingt sind) liegen beim Anwender.
  => wenn beim Update Device und Kanal getrennt wurden kannst du den Kanal 01 einfach löschen
  => dass der Kanat abgetrennt wurde sollte typisch nicht passieren - ich versuche das einmal zu simulieren

Danke für die ausführliche Erklärung. Wie von dir beschrieben konnte ich Kanal 01 bei den betreffenden Fenster Kontakten löschen und wieder zu einem Device zusammen führen.

[eisman]

Aufgrund der massiven Probleme bei verschiedenen Usern, verbunden mit deren unterschiedlichen Kenntnissen & Fertigkeiten, finde ich derartige Beiträge absolut nicht sinnvoll.

Auch wenn ich selbst bisher nicht betroffen bin, da ich glücklicherweise vor dem Update im Forum geguckt habe, finde ich die Vorgehensweise Mist.
Habe den ganzen Thread verfolgt und mehrfach gelesen...
der aktuelle Stand ist mir trotzdem nicht klar; anderen geht es vermutlich ähnlich.

Das ist keine Kritik am Modul-Maintainer; jeder verdient sein Geld im Job und das hier ist Hobby.
Aber bei den Usern ist es doch vergleichbar; wenn plötzlich nix mehr geht und die Zeit fehlt, kommt Hektik auf; auch mit Backup.

IMHO fehlt FHEM da ein Krisenmanagement, um weitere User zu schützen, und den Modulmaintainern etwas Zeit zu verschaffen!

Beispiel bei mehreren Problemmeldungen...
- 1 angepinnter Beitrag mit Infos
- besser noch ein roter Hinweistext mit Link dazu (wie bei neuen Release)
= man findet das vielleicht ohne die blöde Sufu und es kommen nicht drölfzig neue Threads

- Modul-Update wird nicht mehr ausgeliefert
- ältere Version wird wieder ausgeliefert
- Extra-Thread mit neuer Version und Beta-Testern (siehe aktuell 59_Weather)
- toll wäre natürlich ein Hinweis im Update-Check

Das ist nur so eine Idee, aber es guckt nicht jeder vor'm Update ins Forum.
Und es wird bei anderen Meldungen/Fragen auch gern "gemäkelt", ob denn erstmal alles auf dem aktuellsten Stand ist.

Sorry, das musste jetzt erstmal raus.   

hi das hatte ich schon vor vielen monden vorgeschlagen, wurde aber abgelehnt,
damals war es gefühlte 50 Threads, jetzt wenigstens nur 1 ner, also schon mal eine Verbesserung.
muss aber auch sagen, ich habe bei mir, durch die Meldungen noch kein update gemacht.
(nur Systeme mit HM) die anderen laufen gut.

gruss

[JWRu]

Ich würde diese Initiative unterstützen.
Wenn ich nicht zufällig den Thread gelesen hätte, stände ich wahrscheinlich auch vor einem Problem, da ich regelmäßig FHEM-Updates mache.

[curt]

  # Mein Fehler war anzunehmen, dass bei einem "Update" ein auch ein Reboot durchgeführt wird.

  # wenn man kein Save macht dürfen auch keinen neuen Attribute (".mId") gespeichert werden und nach einem Reboot sollten diese nicht mehr vorhanden sein. Macht man ein Save ist das Attribut gespeichert - logisch.

Du gehst im Moment von falschen Annahmen aus.

1) Ich mache GRUNDSÄTZLICH reboot nach update.
2) Danach (Home-Seite von FHEM im Browser, MOTD) waren diese Fehlermeldungen da - ich machte KEIN save.

Ich sehe im Moment die Gefahr, dass Du den/die Fehler beim Nutzer suchst. Das dürfte in diesem Fall zu einfach sein.

Hoffe geholfen zu haben.

[octek0815]

Sorry, für die misslungene Änderung. Ich hatte etliche updated reboots und restarts erfolgreiche getest.
Sorry, dass ich erst jetzt antworte : tagsüber muss ich Bröttchen verdienen.

Die alten Versionen sind wieder eingecheckt. Ein weiteres Update sollte funktionieren.
Betroffen sind 10_CUL_HM.pm und HMConfig.pm

Zu den Devices: Man muss nichts neu Pairen, peeren, oder Register setzen. FHEM /CUL_HM setzt ohne User Kommando NIE diese Einstellungen.

Zu den Configs: Wenn man ein Save macht bleiben alle Einstellungen erhalten. Readings konnten sich verändern.
Es würde also reichen, 10_CUL_HM.pm und HMConfig.pm wieder einzuspielen.


Nun würde mich noch interessieren, wer sinnvoll beschreiben kann, was bei ihm passiert ist. Ich habe auch Rachmelder und Teamleads - die sind sauber upgedated worden mit der neuen SW.
Die Änderungen werden kommen - und wenn ich die Probleme kenne, kann ich diese korrigieren und testen.

bspw: Das Attribut ".mId" ist in der neuen Version gültig, neu  und ganz normal eingeführt. Es kann nicht zu Fehlermeldungen führen. Ist das der Fall brauche ich Details.

Hallo Martin,

ich hatte direkt am 06.01 das Update gemacht und keine Probleme nach dem Reboot gehabt.
Zwischendurch seit dem 06.01. ebenfalls mehrere Neustarts. Keine Problem.
Heute Morgen war mein FHEM irgendwie abgestürzt, also nichts bei gedacht und ein Neustart gemacht und anschließend hatte ich die hier im Thread beschriebenen Probleme.

Grüße
Oliver

[awel]

Hallo,
folgender Fehler mit dem heutigen Update:
Ich nutze einen Außen-Universalsensor nach https://wiki.fhem.de/wiki/Universalsensor zur Helligkeits- und Temperaturmessung.

Der Sensor stand auf activity dead, zusätzlich wurde ein unbekanntes Gerät HM_E10B08 angelegt, das keine sinnvoll verwertbaren Informationen lieferte

Bin jetzt zurück auf eine Uralt-Version

Achim

[Omega]

Weiterentwicklungen sollen und müssen auch sein. Vielleicht sollte man aber mal das Update-Konzept überprüfen. Bei vielen Entwicklungen gibt es z.B. die Möglichkeit, beim Update zwischen ,,stable" und ,,development" wählen zu können.
Beispiel: bei Homematic würde ich immer auf stable zurückgreifen wollen, bei MQtt(2) aktuell auf development.

Das wäre auf jeden Fall besser als einzelne Module per exclude vom Update auszuschließen. Wer von den Anwendern weiß denn schon konkret, welche Module z.B. zu Homematic gehören. Bei dem aktuellen Problem hieß es ja auch zuerst, die Module 10_CUL_HM.pm und 00_HMLAN.pm wären die Verursacher.  Mittlerweile wissen wir von Martin, dass es die Module 10_CUL_HM.pm und HMConfig.pm waren. Wer also nur die ersteren Module zurückgespielt hat, fuhr ein inkonsistentes System - mit welchen Auswirkungen auch immer.

Bei einem "update check" sehe ich zwar, welche Module seit meinem letzten Update geändert wurden. Es hilft mir aber nicht wirklich. Wenn unter anderem HMConfig.pm beteiligt war, müsste es doch auch in meinem restoreDir vom 06.01. vorhanden sein. Da ist es aber nicht.

LG
Holger

[awel]

Moin,
hab gerade ein Update -natürlich mit reboot- in der Hoffnung gemacht, dass wirklich die alte Version wieder eingespielt wurde.

Mist! Das war überhaupt nichts!
Heute werden beim Start zwei neue Geräte angelegt und der Universalsensor, der über Jahre perfekt funktioniert hat, ist dead!
Ich werde eine alte Version wieder einspielen und CUL_HM vom update ausschließen.

Achim

Hier die Listings der Geräte:

HM_590026

Code Auswählen Erweitern

Internals:
   CFGFN     
   CUL_0_MSGCNT 10
   CUL_0_RAWMSG A118B3400590026680000C2100872776636A7::-58.5:CUL_0
   CUL_0_RSSI -58.5
   CUL_0_TIME 2019-01-13 10:17:05
   DEF        590026
   IODev      CUL_0
   LASTInputDev CUL_0
   MSGCNT     10
   NAME       HM_590026
   NOTIFYDEV  global
   NR         282
   STATE      ???
   TYPE       CUL_HM
   lastMsg    No:8B - t:00 s:590026 d:680000 C2100872776636A7
   protLastRcv 2019-01-13 10:16:14
   protRcv    1 last_at:2019-01-13 10:16:14
   protRcvB   1 last_at:2019-01-13 10:16:14
   rssi_at_CUL_0 cnt:10 min:-58.5 max:-58.5 avg:-58.5 lst:-58.5
   .attraggr:
   .attrminint:
   READINGS:
     2019-01-13 10:16:14   .D-devInfo      -
     2019-01-13 10:16:14   .D-stc          -
     2019-01-13 10:16:14   .protLastRcv    2019-01-13 10:16:14
     2019-01-13 10:16:14   D-firmware      12.2
     2019-01-13 10:16:14   D-serialNr      rwf6�
   helper:
     HM_CMDNR   178
     mId       
     supp_Pair_Rep 1
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +590026,00,00,00
       nextSend   1547371025.65997
       prefIO     
       rxt        0
       vccu       
       p:
         590026
         00
         00
         00
     mRssi:
       mNo        8B
       io:
         CUL_0:
           -52.5
           -52.5
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
     rssi:
       at_CUL_0:
         avg        -58.5
         cnt        10
         lst        -58.5
         max        -58.5
         min        -58.5
     tmpl:
Attributes:
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   12.2
   model      unknown
   room       CUL_HM
   serialNr   rwf6�
   subType    und
HM_C21008

Code Auswählen Erweitern

Internals:
   CFGFN     
   CUL_0_MSGCNT 28
   CUL_0_RAWMSG A12700000C2100872715937A2705FB003FA10ED::-101.5:CUL_0
   CUL_0_RSSI -101.5
   CUL_0_TIME 2019-01-13 10:20:17
   DEF        C21008
   IODev      CUL_0
   LASTInputDev CUL_0
   MSGCNT     28
   NAME       HM_C21008
   NOTIFYDEV  global
   NR         280
   STATE      ???
   TYPE       CUL_HM
   lastMsg    No:70 - t:00 s:C21008 d:727159 37A2705FB003FA10ED
   protLastRcv 2019-01-13 10:16:14
   protRcv    1 last_at:2019-01-13 10:16:14
   rssi_at_CUL_0 cnt:28 min:-101.5 max:-101.5 avg:-101.5 lst:-101.5
   .attraggr:
   .attrminint:
   READINGS:
     2019-01-13 10:16:14   .D-devInfo      -
     2019-01-13 10:16:14   .D-stc          -
     2019-01-13 10:16:14   .protLastRcv    2019-01-13 10:16:14
     2019-01-13 10:16:14   D-firmware      3.7
     2019-01-13 10:16:14   D-serialNr      _���
   helper:
     HM_CMDNR   151
     mId       
     supp_Pair_Rep 1
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +C21008,00,00,00
       nextSend   1547371217.65453
       prefIO     
       rxt        0
       vccu       
       p:
         C21008
         00
         00
         00
     mRssi:
       mNo        70
       io:
         CUL_0:
           -99.5
           -99.5
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
     rssi:
       at_CUL_0:
         avg        -101.5
         cnt        28
         lst        -101.5
         max        -101.5
         min        -101.5
     tmpl:
Attributes:
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   3.7
   model      unknown
   room       CUL_HM
   serialNr   _���
   subType   

[oldscout]

Hallo,
ich habe mein SQL-Backup und FHEM-Backup vom 31.12.18 vorgekramt, geht wieder....
Ja ist ärgerlich solch Fehler....aber was solls.... Habe meiner Frau damit den Unabhängigkeitstest von FHEM (bei zb Stromausfall) bewiesen.... die Hütte war zumindest bei diesem Ausfall noch warm...

Es zeigt wieder, dass Backups unverzichtbar sind.... und auch diese mal getestet werden müssen/sollen.
So, schönes Rest WE!!!