10_CUL_HM v6098 verursacht MISSING ACK

[tagedieb]

Hallo zusammen
nach der FHEMWiederherstellung des o.g.Probleme kann ich keine Aktoren mehr anlernen
es erscheint auch kein Eintrag in der Log (vom Pairing Versuch)

vielleicht reicht für die Spezialisten ein Blick in die Datei, ob der Fehler soft-oder hardwareseitig ist und überhaupt mit diesem Update zusammenhängt
habe leider keinen anderen HMLAN zum probieren vorrätig

bin für jede Hilfe dankbar

Gruss tagedieb

[peterk_de]

@tagedieb War bei mir in der strittigen Version auch so - Pairing ging nicht. Habe ein Paar neue Geräte die Tage (Außenthermometer, RT-DN) Revert der CUL_HM.pm (siehe erstes Post in diesem Thread) löste das Problem. In der Version stürzt FHEM zwar beim Pairen mit folgender Ausgabe in der Konsole ab ...

Code Auswählen Erweitern


Use of uninitialized value $updt in concatenation (.) or string at ./FHEM/00_HMLAN.pm line 750.
Use of uninitialized value $updt in concatenation (.) or string at ./FHEM/00_HMLAN.pm line 752.
Can't use an undefined value as an ARRAY reference at ./FHEM/10_CUL_HM.pm line 766.
Can't use an undefined value as a symbol reference at FHEM/Blocking.pm line 130.
Can't use an undefined value as a symbol reference at FHEM/Blocking.pm line 130.
Can't use an undefined value as a symbol reference at FHEM/Blocking.pm line 130.
Can't use an undefined value as a symbol reference at FHEM/Blocking.pm line 130.


.. aber das Gerät ist, nachdem ich FHEM dann wieder neu gestartet habe, da:

Code Auswählen Erweitern


Internals:
   DEF        25FA26
   HMLANGW_MSGCNT 3
   HMLANGW_RAWMSG E25FA26,0000,04CE2F1A,FF,FFCD,01867025FA2600000000FE36
   HMLANGW_RSSI -51
   HMLANGW_TIME 2014-06-12 16:19:24
   IODev      HMLANGW
   LASTInputDev HMLANGW
   MSGCNT     3
   NAME       CUL_HM_HM_WDS10_TH_O_25FA26
   NR         696
   STATE      ???
   TYPE       CUL_HM
   lastMsg    No:01 - t:70 s:25FA26 d:000000 00FE36
   protLastRcv 2014-06-12 16:19:24
   rssi_at_HMLANGW avg:-43.66 min:-51 max:-40 lst:-51 cnt:3
   Readings:
     2014-06-12 16:19:23   CommandAccepted yes
   Helper:
     Io:
       newChn     +25FA26,00,01,00
       nextSend   1402582764.23331
       rxt        0
       p:
         25FA26
         00
         01
         00
     Mrssi:
       mNo        01
       Io:
         HMLANGW    -49
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rssi:
       At_hmlangw:
         avg        -43.6666666666667
         cnt        3
         lst        -51
         max        -40
         min        -51
Attributes:
   IODev      HMLANGW
   autoReadReg 4_reqStatus
   expert     2_full
   room       CUL_HM



Allerdings ungepairt. Wenn man jetzt nochmal pairt, und dann n getConfig macht, ist alles gut, ohne Absturz:

Code Auswählen Erweitern


Internals:
   DEF        25FA26
   HMLANGW_MSGCNT 20
   HMLANGW_RAWMSG E25FA26,0000,04D588F8,FF,FFD8,04867025FA26000000010933
   HMLANGW_RSSI -40
   HMLANGW_TIME 2014-06-12 16:27:10
   IODev      HMLANGW
   LASTInputDev HMLANGW
   MSGCNT     20
   NAME       CUL_HM_HM_WDS10_TH_O_25FA26
   NR         696
   STATE      T: 26.5 H: 51
   TYPE       CUL_HM
   lastMsg    No:04 - t:70 s:25FA26 d:000000 010933
   protCmdDel 6
   protLastRcv 2014-06-12 16:27:10
   protResnd  6 last_at:2014-06-12 16:25:53
   protResndFail 2 last_at:2014-06-12 16:25:58
   protSnd    12 last_at:2014-06-12 16:27:05
   protState  CMDs_done
   rssi_at_HMLANGW avg:-41.09 min:-51 max:-37 lst:-40 cnt:20
   CHANGETIME:
   Helper:
     Dblog:
       Activity:
         Dblog:
           TIME       1402583225.26631
           VALUE      alive
       D-firmware:
         Dblog:
           TIME       1402583225.26631
           VALUE      1.3
       D-serialnr:
         Dblog:
           TIME       1402583225.26631
           VALUE      LEQ0029731
       R-burstrx:
         Dblog:
           TIME       1402583192.52398
           VALUE      off
       R-paircentral:
         Dblog:
           TIME       1402583192.52398
           VALUE      0x34EF21
       T:
         Dblog:
           TIME       1402583230.85833
           VALUE      26.5 H
       Battery:
         Dblog:
           TIME       1402583230.85833
           VALUE      ok
       Humidity:
         Dblog:
           TIME       1402583230.85833
           VALUE      51
       State:
         Dblog:
           TIME       1402583158.87274
           VALUE      RESPONSE TIMEOUT:RegisterRead
       Temperature:
         Dblog:
           TIME       1402583230.85833
           VALUE      26.5
   Readings:
     2014-06-12 16:27:05   Activity        alive
     2014-06-12 16:26:32   CommandAccepted yes
     2014-06-12 16:27:05   D-firmware      1.3
     2014-06-12 16:27:05   D-serialNr      LEQ0029731
     2014-06-12 16:27:05   PairedTo        0x34EF21
     2014-06-12 16:26:32   R-burstRx       off
     2014-06-12 16:26:32   R-pairCentral   0x34EF21
     2014-06-12 16:27:05   RegL_00:          01:00 02:01 05:00 0A:34 0B:EF 0C:21 0F:00 00:00
     2014-06-12 16:27:10   battery         ok
     2014-06-12 16:27:10   humidity        51
     2014-06-12 16:27:10   state           T: 26.5 H: 51
     2014-06-12 16:27:10   temperature     26.5
   Helper:
     cSnd       0134EF2125FA260103
     mId        003D
     peerIDsRaw ,00000000
     rxType     132
     Io:
       newChn     +25FA26,00,01,00
       nextSend   1402583230.94533
       rxt        0
       p:
         25FA26
         00
         01
         00
     Mrssi:
       mNo        04
       Io:
         HMLANGW    -38
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rssi:
       At_hmlangw:
         avg        -41.1
         cnt        20
         lst        -40
         max        -37
         min        -51
     Shadowreg:
Attributes:
   IODev      HMLANGW
   actCycle   000:10
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_full
   firmware   1.3
   model      HM-WDS10-TH-O
   peerIDs    00000000,
   room       CUL_HM
   serialNr   LEQ0029731
   subType    THSensor



... nur mal so als temporärer Workaround. War sowohl bei 3 Thermostaten (FW 1.2) als auch bei dem Außenthermometer so.

[tagedieb]

Hallo peterk_de

dankechön für den Hinweis, hat prima geholfen

Gruss tagedieb

[tinyfhem]

Hatte bisher immer regelmaessig, im Abstand von ein oder zwei Wochen "update" getippt und dann "shutdown restart". Heute war es auch mal wieder soweit und prompt bin ich genau in die hier beschriebenen Probleme gelaufen. Von diesem thread wusste ich da noch nichts aber ich konnte mir selbst helfen, habe einfach das backup restored und alles war wieder gut.

Doch nun die Frage: Was ist eigentlich die richtige Vorgehensweise, wenn man nicht unbedingt immer das neueste haben will sondern immer nur von einem stabilen, konsistenten, und getesteten Stand auf den naechsten stabilen, konsistenten, und getesteten Stand hoch gehen moechte? Ich vermute mal, einfach "update" in die commandline des Web UI eintippen, ist definitiv der falsche Weg. Aber was stattdessen?

[marvin78]

Immer erst Nachmittags oder Abends updaten . Vorher hier rein schauen und die Beiträge querlesen (am besten die ungelesenen  Beiträge durchgehen). So mache ich es auf dem Produktivsystem.

[Ich79]

Immer erst Nachmittags oder Abends updaten . Vorher hier rein schauen und die Beiträge querlesen (am besten die ungelesenen  Beiträge durchgehen). So mache ich es auf dem Produktivsystem.

Sehe ich ähnlich, lieber nicht morgens updaten Bin auch drauf "reingefallen". Aber hey, auf der anderen Seite bin ich echt froh, dass Martin sich darum immer kümmert! Es ist ja schliesslich seine Freizeit. Schade, dass es im Moment leider nur den "Development" Zweig gibt und noch keinen Stable. Aber ich bin schon froh, dass es FHEM überhaupt gibt
VG,
Boris

[kossmann]

Jeder, der momentan Probleme mit Homematic-Devices (und in den letzten 2 Tagen ein FHEM-Update gemacht) hat, kann einfach Abhilfe schaffen, indem der die 10_CUL_HM.pm von hier herunterlädt und in seinem FHEM-Ordner die neue, kaputte Version durch diese ersetzt. Danach den FHEM-Neustart nicht vergessen.

Alle anderen seien gewarnt: Kein Update machen, bevor Martin den Fehler nicht behoben hat.

[betateilchen]

Doch nun die Frage: Was ist eigentlich die richtige Vorgehensweise, wenn man nicht unbedingt immer das neueste haben will

Drei Systeme:

• Entwicklungssystem - da wird gebastelt und da werden Updates zuerst eingespielt.
• Testsystem / QS-System - da wird alles, was im Entwicklungssystem entstanden ist und dort funktioniert, eingespielt und getestet.
• Produktivsystem - da wird alles, was im QS-System erfolgreich getestet wurde, eingespielt und in den Produktivbetrieb übernommen.

[peterk_de]

... meine Variante ist, da ich kein zusätzliches Testsystem habe, nur updaten wenn etwas nicht so funktioniert wie ich will, und ich danach noch mindestens 2 Stunden Freizeit zum Testen und Problembeheben habe Denn sowas wie einen Stable-Branch hat FHEM ja nicht. Wenn man bedenkt, wie oft Martin updatet und was für einen gigantischen Zoo an Geräten er hier alleine wuppt (kein anderes Open-Source-Automationstool hat diesen krassen Homematic-Support!), finde ich, dass dafür recht selten soetwas passiert - liegt aber nunmal in der Natur der Dinge, dass es vorkommt.

[chris1284]

Drei Systeme:

• Entwicklungssystem - da wird gebastelt und da werden Updates zuerst eingespielt.
• Testsystem / QS-System - da wird alles, was im Entwicklungssystem entstanden ist und dort funktioniert, eingespielt und getestet.
• Produktivsystem - da wird alles, was im QS-System erfolgreich getestet wurde, eingespielt und in den Produktivbetrieb übernommen.

sollte man nicht lieber den updatemechanismus von fhem überdenken? updates sollen etwas verbessern und nicht verschlechtern. gerade bei hm ist das in der zeit wo ich fhem betreibe das 3. oder 4. mal das nach einem update im bereich hm nichts mehr sauber läuft (auch bei anderen modulen aber hm trifft mich zum beispiel am meisten wenn nicht gerade hochsommer ist). bitte auch nicht falsch verstehen, martin leistet tolle arbeit und steckt offensichtlich sehr viel zeit hier rein. man kann/sollte den usern nicht 2-3 systeme zumuten um sicher zu sein (klar ist es recht einfach zurück zu springen wenn man weiss wie).

etwas in richtung stabel und nightly updates wären doch nicht schlecht oder? wenn die nighly-tester keine fehler melden nach x tagen gehts ins stable-update mir rein. per "globaler varibale" kann sich der user dann aussuchen ob er stabil oder aktuell sein will.

[marvin78]

Das wirst du nicht hinbekommen (zu wenig Tester mit allen möglichen Geräten -  da kann es für manche Entwicklungen ewig dauern, bis sie endlich im stable-Zweig sind). Ich denke auch nicht, dass man 2-3 Systeme braucht um sicher zu sein. Meine Methode mit dem Update am Nachmittag oder Abend, erst nachdem ich mich hier grob durchgelesen habe, ist schon recht sicher und ich hatte bspw. noch nie ein Problem mit einem nicht mehr funktionierenden System, weil ein Modul gesponnen hat.

FHEM ist kein Consumer-System. Das muss man wissen, wenn man sich darauf einlässt. Und unter dem Gesichtspunkt sollte man schon jeden User von FHEM zutrauen, das mit den Updates selbst ganz günstig zu entscheiden.

[chris1284]

Das wirst du nicht hinbekommen (zu wenig Tester mit allen möglichen Geräten -  da kann es für manche Entwicklungen ewig dauern, bis sie endlich im stable-Zweig sind). Ich denke auch nicht, dass man 2-3 Systeme braucht um sicher zu sein. zu entscheiden.

sehe ich für mich auch so, habe auch mehrere system (allein wenn mal hardware ausfällt)

FHEM ist kein Consumer-System. Das muss man wissen, wenn man sich darauf einlässt.

wie so viele andere opensource-projekte auch, das sollte nicht als "ausrede" angeführt werden.
ich finde nur der anspruch eines users an software darf es durchaus sein etwas stabiles zu bekommen und nicht bei jedem update bangen zu müssen (das wirkt sich auch positiv auf verbreitung und denke ich auch dann mehr support der entwickler durch zb spenden, ob nun sachen oder geld, aus).

Code Auswählen Erweitern


Das wirst du nicht hinbekommen (zu wenig Tester mit allen möglichen Geräten -  da kann es für manche Entwicklungen ewig dauern,
sollte man solche kaum genutzten module evtl. nur in contrib und entsprechendem hinweis verteilen

[marc2]

sollte man nicht lieber den updatemechanismus von fhem überdenken? updates sollen etwas verbessern und nicht verschlechtern.

Ihr nutzt den Entwicklungstrunk ! Es ist nicht den Entwicklern anzulasten, wenn Ihr meint diesen direkt produktiv einzusetzen zu müssen. Wenn man bedenkt, was gerade bei HM nahezu täglich an Erweiterungen eingebaut wird  (und hier kann man Martin gar nicht genug danken !!!!) ist es fast  unglaublich wie stabil die Entwicklungsversion läuft ! Wem das Risiko zu hoch ist, der muss halt mit dem offiziellen Stable Release vorlieb nehmen ! Wer jedoch immer am Puls der Zeit sein möchte, der muss damit leben, wenn sich mal ein Bug einschleicht und schlicht in der Lage sein, auf die alte Version zurückzurollen, oder bereits von betateilchen erwähnt - und das ist der Mindeststandard im realen IT Betrieb - sich eine E/K/P Landschaft gönnen ! That's it ! Das Forum ist nicht zuletzt dafür da, die Fehler aufzudecken, die sich ggf. eingeschlichen haben, damit die Entwickler sie fixen können ....

[betateilchen]

Es ist doch ohnehin niemand dazu gezwungen, täglich jedes verfügbare Update einzuspielen.

Und wem 30 Euro Hardwarekosten für ein zweites System, um Updates vor der Übernahme in die Produktivumgebung zu testen, zuviel Geld sind, sollte sich nicht beschweren, wenn er durch ein nicht funktionierendes Update seine Installation lahmlegt. Bei mir kommt schon lange kein Update mehr direkt in das Produktivsystem, nicht nur aus den Erfahrungen mit Homematic, sondern auch aus meiner Sicht als Entwickler und aus den Erfahrungen mit meinen eigenen Modulen. Der "reine" Nutzer, der keine eigenen Entwicklungsarbeiten leistet, braucht vermutlich keine drei Systeme, aber zwei sollten es schon sein, wenn man sein fhem so weit ausgebaut hat, dass man auf einen zuverlässigen Betrieb angewiesen ist.

Der Vorschlag, "wenig benötigte Module" nach contrib zu verlegen, bringt auch nicht viel weiter, denn contrib wird beim Update überhaupt nicht berücksichtigt - und das ist auch gut so.

[betateilchen]

Ich habe eben ausnahmsweise etwas getan, was ich sonst eigentlich nie mache:

Um zu verhindern, dass sich andere User durch ein Update auf die defekte 10_CUL_HM.pm ihr fhem lahmlegen, habe ich das Modul auf die vorherige Version 6096 zurückgesetzt, da nach drei Tagen noch keinerlei Reaktion seitens der Entwicklung kam. (Natürlich darf sich jeder irgendwann eine Auszeit nehmen.)