HM-MOD-UART disconnected, waiting to reappear (myHmUART)

[Otto123]

Also wenn FHEM an der Stelle nicht blockiert und Du alle 3-4 min einen disconnect bekommst, dann muss ein anderer Prozess die serielle Schnittstelle mit diesem Zeitraster stören.

Da musst Du jetzt irgendwie die Prozesse auf dem Pi monitoren - weiß jetzt auf die Schnelle auch nicht richtig wie. Bei drei Minuten kannst Du Dich hinsetzen und mit top schauen welcher Prozess da eventuell hochschnellt.

[Pfriemler]

Da die disconnects bei mir zu einem ständigen Begleiter geworden sind, habe ich mal meine Logs des letzten Monats durchsucht und dabei eine interessante Beobachtung gemacht:

Code Auswählen Erweitern


2020.02.03 09:01:33 3: CUL_HM set AlarmanlageEntschaerfenButton press # das ist ein Kanal eines HM-Mod-Re-8, der auf eine andere FB "drückt"
2020.02.03 09:01:37 1: Alarmanlage ist jetzt Aus # kommt als Rückmeldung über einen HM-Mod-SEN-8bit
...
2020.02.03 09:01:44 1: HMUARTLGW HMUART unexpected info about Co_CPU_BL received (module crashed?), reopening
2020.02.03 09:01:44 3: HMUART device closed
2020.02.03 09:01:44 3: Setting HMUART serial parameters to 115200,8,N,1
2020.02.03 09:01:44 1: /dev/ttyAMA0 reappeared (HMUART)

Dieser Effekt kommt bei mir mit einer unglaublichen Präzision genau einmal am Tag, wobei ich zunächst an die konstant 7-8 s Verzögerung nach dem SEN-8bit-Telegramm dachte - stattdessen aber ist die Konstante der an das Re-8 gesendete (Burst-)Schaltbefehl, der zwischen 11 und 20 Sekunden davor liegt.

Was die Sache echt mystisch macht: Diese Befehle erfolgen über den Tag verteilt zu sehr unterschiedlichen Zeiten mehrmals, aber der "Zusammenbruch" erfolgt tatsächlich in 95% der Fälle zwischen 6 und 10 Uhr (wo der erste Schaltvorgang dieser Art kommt). Es ist auch nicht immer genau der Kanal des Re-8, manchmal wird ein anderer geschaltet und hat den gleichen Effekt.

Und es wird noch mystischer: Wenn es an einem Tag nicht das HMUART am seriellen Port des Raspi ist, erwischt es stattdessen das per WLAN angebundene Modul. Fast so, als hätte die VCCU an diesem Tag beschlossen das andere IO als Sender zu verwenden, was es daraufhin in den Orkus reißt.

Bei sowas macht es mir keinen Spaß, den Dingern näher auf den Grund zu gehen ...

[Udomatic]

Hallo,

ich kämpfe leider immer noch mit dem disconnect Fehler meines Funkmoduls, was sich scheinbar nicht lösen lässt.
Aus diesem überlege ich jetzt entweder das Thema Homematic auf einen eigenen Raspberry auszulagern.

Im Moment tendiere ich zu Raspberrymatic und dem einbinden über HMCCU
Alternativ ein zweite FHEM Instanz mit CUL_HM. Geht das überhaupt und wenn ja, wie bekomme ich dann die HM Geräte in meine primäre Instanz?

Gibt es hierzu Empfehlungen?

Gruß
Udo

[Otto123]

Naja Du musst wissen HMCCU und CUL_HM sind komplett anders. Du musst also alles was damit im Zusammenhang steht anfassen.

Warum lagerst Du nicht bloß mal das Funkmodul auf einen zweiten Pi aus? Das geht doch relativ easy.

[Udomatic]

Warum lagerst Du nicht bloß mal das Funkmodul auf einen zweiten Pi aus? Das geht doch relativ easy.

Hi Otto,

was meinst du genau mit auslagern?

[Otto123]

so

Also
1. VCCU machen
2. IOList setzen
3. Remote Pi per ser2net einbinden
4. In die IOList eintragen
5. alten lokale Def pausieren: attr DUMMY

[Udomatic]

so

Also
1. VCCU machen
2. IOList setzen
3. Remote Pi per ser2net einbinden
4. In die IOList eintragen
5. alten lokale Def pausieren: attr DUMMY

Danke für die Anleitung. Habe soweit alles eingerichtet. Mir wird aber gesagt, dass der Port bereits in Nutzung ist

Code Auswählen Erweitern

Internals:
   CFGFN     
   CMDS       
   CUL868_MSGCNT 2
   CUL868_TIME 2020-02-12 20:28:27
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS:FS20V: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   DEF        192.168.178.56:4000 0000
   DeviceName 192.168.178.56:4000
   FHTID      0000
   FUUID      5e44519f-f33f-45fc-ec9f-944598ee6d848e2c
   NAME       CUL868
   NEXT_OPEN  1581535767
   NR         524
   PARTIAL   
   RAWMSG     Port already in use
   STATE      disconnected
   TYPE       CUL
   initString X21
   .attraggr:
   .attreocr:
     .*
   .attrminint:
   .clientArray:
     SOMFY
   MatchList:
     0:FS20V    ^81..(04|0c)..0101a001......00[89a-f]...
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04......a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2020-02-12 20:28:27   state           disconnected
Attributes:
   event-on-change-reading .*
   room       Devices

Bin dieser Beschreibung gefolgt und nutze Port 4000

https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_für_Raspberry_Pi#Originaler_Einsatzzweck_im_Raspberry

In der VCCU sieht es jetzt so aus:

Code Auswählen Erweitern

Internals:
   .triggerUsed 1
   DEF        6A60EA
   FUUID      5e30b2cb-f33f-45fc-5543-1e9060fbfc6fdf59
   IODev     
   NAME       VCCU
   NOTIFYDEV  global
   NR         456
   NTFY_ORDER 50-VCCU
   STATE      myHmUART:UAS,CUL868:opened
   TYPE       CUL_HM
   assignedIOs CUL868,myHmUART
   chanNo     01
   .attraggr:
   .attrminint:
   READINGS:
     2020-02-12 20:43:32   IOopen          0
     2020-01-28 23:19:05   RegL_00.       
     2020-02-12 20:43:32   state           myHmUART:UAS,CUL868:opened
     2020-02-01 12:52:33   unknown_424242  received
     2020-02-01 12:02:08   unknown_683EBD  received
     2020-02-01 18:37:13   unknown_683ECF  received
     2020-02-01 12:01:23   unknown_683EE1  received
     2020-02-12 19:05:26   unknown_683EE2  received
   helper:
     HM_CMDNR   82
     mId        FFF0
     peerFriend peerSD,peerSens,peerAct
     peerOpt    -:virtual
     regLst     0
     rxType     1
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       prefIO     
       vccu       VCCUHM
       ioList:
         CUL868
     mRssi:
       mNo       
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       vrt        1
     tmpl:
Attributes:
   .mId       FFF0
   IODev      CUL868
   IOList     CUL868
   IOgrp      VCCUHM
   expert     2_raw
   model      CCU-FHEM
   room       CUL_HM
   subType    virtual
   webCmd     virtual:update

Bisher bekommen aktualisieren die HM Geräte nicht Ihre Register bzw. reagieren.
Woran kann es liegen?

Muss ich das Attribut IODev jedes Homematic Gerätes auch anpassen?Dort steht noch überall der deaktivierte myHMUART drinne

[Otto123]

Wieso jetzt CUL868  ? Ich denke wir reden vom HMUART Modul? Wo steht in der Anleitung was vom CUL?

Mit dem attr IOgrp VCCUHM bin ich auch durch den Wind? Woher nimmst Du das?

[Udomatic]

Wieso jetzt CUL868  ? Ich denke wir reden vom HMUART Modul? Wo steht in der Anleitung was vom CUL?

Nachdem ich ser2net auf dem zweiten Raspberry installiert habe, habe ich in FHEM folgendes gemacht:

define CUL868 CUL 192.168.178.56:4000 0000
CUL868 ist also nur der Name des IO Device

War das falsch?

[Udomatic]

Wieso jetzt CUL868  ? Ich denke wir reden vom HMUART Modul? Wo steht in der Anleitung was vom CUL?

Mit dem attr IOgrp VCCUHM bin ich auch durch den Wind? Woher nimmst Du das?

Hmm, stimmt, das müsste ja nur VCCU heißen, also der Name der VCCU. Hab ich ma geändert

[Otto123]

Ja - wo steht das
In dem Artikel dessen Link Du mir auch bestätigt hast, steht drin:

Code Auswählen Erweitern

define WLAN_HmUART HMUARTLGW uart://<IP-Adresse>:<Portnummer>

Also von mir aus:

Code Auswählen Erweitern

define rpi_HmUART HMUARTLGW uart://192.168.178.56:4000

Wie kommst Du nur auf CUL ?

Hattest Du jetzt eigentlich zwei HMUART Module?

[Udomatic]

Ja - wo steht das
In dem Artikel dessen Link Du mir auch bestätigt hast, steht drin:

Code Auswählen Erweitern

define WLAN_HmUART HMUARTLGW uart://<IP-Adresse>:<Portnummer>

Also von mir aus:

Code Auswählen Erweitern

define rpi_HmUART HMUARTLGW uart://192.168.178.56:4000

Wie kommst Du nur auf CUL ?

Hattest Du jetzt eigentlich zwei HMUART Module?

Verstanden, habe ich angelegt. Hier das List

Code Auswählen Erweitern

Internals:
   CFGFN     
   CNT        1
   Clients    :CUL_HM:
   DEF        uart://192.168.178.56:4000
   DevIoJustClosed 1
   DevState   1
   DevType    UART
   DeviceName 192.168.178.56:4000
   FUUID      5e445e31-f33f-45fc-8527-f0a23145f5698913
   LastOpen   1581539053.93827
   NAME       LAN_HmUART
   NOTIFYDEV  global
   NR         603
   NTFY_ORDER 50-LAN_HmUART
   STATE      disconnected
   TYPE       HMUARTLGW
   XmitOpen   0
   model      HM-MOD-UART
   .attraggr:
   .attreocr:
     .*
   .attrminint:
   Helper:
     AckPending:
       1:
         cmd        00
         dst        0
         frame      FD00030001009E03
         time       1581539054.97845
     LastSendLen:
       3
     Log:
       IDs:
   MatchList:
     1:CUL_HM   ^A......................
   READINGS:
     2020-02-12 21:21:05   D-type          HM-MOD-UART
     2020-02-12 21:24:14   cond            init
     2020-02-12 21:21:05   loadLvl         suspended
     2020-02-12 21:24:13   state           disconnected
Attributes:
   event-on-change-reading .*
   room       CUL_HM

Derzeit wechselt der Status von init zu disconnected. Das zweite HMUARt Modul habe ich gemäß deiner Kurzanleitung mit dem Attribut DUMMY deaktiviert

Im Log steht jetzt:

Code Auswählen Erweitern

2020.02.12 21:27:20 1: HMUARTLGW LAN_HmUART did not respond for the 1. time, resending
2020.02.12 21:27:21 1: 192.168.178.56:4000 reappeared (LAN_HmUART)
2020.02.12 21:27:21 1: 192.168.178.56:4000 disconnected, waiting to reappear (LAN_HmUART)

hmid braucht das Gerät jetzt auch wieder nehme ich an?

[Otto123]

Da stimmt was nicht. Der andere Pi muss natürlich genauso vorbereitet werden bez. UART Schnittstelle usw. Und es darf dort NICHTS auf  die UART und das Modul zugreifen! Kein FHEM mit einer Definition für das HMUART Modul!

Was sagt auf dem anderen

Code Auswählen Erweitern

systemctl status ser2net

[Udomatic]

Da stimmt was nicht. Der andere Pi muss natürlich genauso vorbereitet werden bez. UART Schnittstelle usw. Und es darf dort NICHTS auf  die UART und das Modul zugreifen! Kein FHEM mit einer Definition für das HMUART Modul!

Was sagt auf dem anderen

Code Auswählen Erweitern

systemctl status ser2net

Da hast du recht. List sieht jetzt so aus

Code Auswählen Erweitern

Internals:
   AssignedPeerCnt 12
   CFGFN     
   CNT        99
   Clients    :CUL_HM:
   DEF        uart://192.168.178.56:4000
   DEVCNT     76
   DevState   99
   DevType    UART
   DeviceName 192.168.178.56:4000
   FD         4
   FUUID      5e445e31-f33f-45fc-8527-f0a23145f5698913
   LastOpen   1581540048.00393
   NAME       LAN_HmUART
   NOTIFYDEV  global
   NR         603
   NTFY_ORDER 50-LAN_HmUART
   PARTIAL   
   RAWMSG     050000367F861063AB740000000A98C70C0540
   RSSI       -54
   STATE      opened
   TYPE       HMUARTLGW
   XmitOpen   1
   model      HM-MOD-UART
   msgLoadCurrent 33
   msgLoadHistory 33/-/-/-/-/-/-/-/-/-/-/-
   msgLoadHistoryAbs 33/0/-/-/-/-/-/-/-/-/-/-/-
   owner      424242
   owner_CCU  VCCU
   .attraggr:
   .attreocr:
     .*
   .attrminint:
   .clientArray:
     CUL_HM
   Helper:
     CreditTimer 23
     FW         66561
     Initialized 1
     SendCnt    34
     AckPending:
     LastSendLen:
       3
       3
     Log:
       IDs:
     PendingCMD:
     RoundTrip:
       Delay      0.00465106964111328
     loadLvl:
       lastHistory 1581540350.55961
   MatchList:
     1:CUL_HM   ^A......................
   Peers:
     56257F     +56257F,00,00,00
     628D91     +628D91,00,00,00
     6359A7     +6359A7,00,00,00
     64CBA3     +64CBA3,00,00,00
     654DB7     +654DB7,00,00,00
     6644DC     +6644DC,00,00,00
     6738DA     +6738DA,00,00,00
     674082     +674082,00,00,00
     6740B4     +6740B4,00,00,00
     674137     +674137,00,00,00
     6C483E     +6C483E,00,00,00
     6CD39F     +6CD39F,00,00,00
   READINGS:
     2020-02-12 21:40:50   D-HMIdAssigned  424242
     2020-02-12 21:40:50   D-HMIdOriginal  6BD774
     2020-02-12 21:40:50   D-firmware      1.4.1
     2020-02-12 21:40:50   D-serialNr      PEQ2214443
     2020-02-12 21:21:05   D-type          HM-MOD-UART
     2020-02-12 21:40:50   cond            ok
     2020-02-12 21:46:01   load            33
     2020-02-12 21:40:50   loadLvl         low
     2020-02-12 21:40:48   state           opened
   helper:
Attributes:
   event-on-change-reading .*
   hmId       424242
   room       CUL_HM

Und von der VCCU so:

Code Auswählen Erweitern

Internals:
   .triggerUsed 1
   DEF        424242
   FUUID      5e30b2cb-f33f-45fc-5543-1e9060fbfc6fdf59
   IODev     
   NAME       VCCU
   NOTIFYDEV  global
   NR         456
   NTFY_ORDER 50-VCCU
   STATE      LAN_HmUART:ok
   TYPE       CUL_HM
   assignedIOs LAN_HmUART
   chanNo     01
   .attraggr:
   .attrminint:
   READINGS:
     2020-02-12 21:40:50   IOopen          1
     2020-01-28 23:19:05   RegL_00.       
     2020-02-12 21:40:50   state           LAN_HmUART:ok
     2020-02-01 12:52:33   unknown_424242  received
     2020-02-01 12:02:08   unknown_683EBD  received
     2020-02-01 18:37:13   unknown_683ECF  received
     2020-02-01 12:01:23   unknown_683EE1  received
     2020-02-12 19:05:26   unknown_683EE2  received
   helper:
     HM_CMDNR   22
     mId        FFF0
     peerFriend peerSD,peerSens,peerAct
     peerOpt    -:virtual
     regLst     0
     rxType     1
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       prefIO     
       vccu       VCCU
       ioList:
         LAN_HmUART
     mRssi:
       mNo       
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       vrt        1
     tmpl:
Attributes:
   .mId       FFF0
   IODev      LAN_HmUART
   IOList     LAN_HmUART
   IOgrp      VCCU
   expert     2_raw
   model      CCU-FHEM
   room       CUL_HM
   subType    virtual
   webCmd     virtual:update

Die hmid des HMUART muss doch in die DEF der VCCU. Das ist korrekt oder?

Log spuckt gerade folgendes aus:

Code Auswählen Erweitern

2020.02.12 21:57:26 0: HMUARTLGW LAN_HmUART: Can't send ACK not originating from my hmId (firmware bug), please use a VCCU virtual device!
2020.02.12 21:58:01 1: [Freezemon] myFreezemon: possible freeze starting at 21:58:00, delay is 1.516 possibly caused by: tmr-SONOSPLAYER_SimulateCurrentTrackPosition(Sonos_Wohnzimmer_Beam)

[Otto123]

Das sieht auf die Schnelle gut aus.

Das mit der hmId ist korrekt. Du kannst ruhig das momentan deaktivierte myHmUART auch der VCCU zuordnen.

Du hast bei allen Geräten IOgrp gesetzt? Siehe Wiki VCCU, Befehlszeile:

Code Auswählen Erweitern

attr TYPE=CUL_HM:FILTER=DEF=[0-9a-fA-F]{6}:FILTER=DEF!=[0]{6} IOgrp VCCU