[Gelöst] HMCCU verliert Verbindung zu CCU nach Router Neustart/Reboot

[loescher]

Hi!

Ich habe heute folgendes Problem festgestellt:
Meine FritzBox (FB) hat nach einem Stromausfall neu gestartet.
FHEM und CCU2 liefen weiter, da sie an einer USV hängen.
Aber FHEM hat ab diesem Zeitpunkt überhaupt keine Daten von der CCU2 (via HMCCU) bekommen.
Erst ein Neustart der CCU und Neustart der HMCCU rpcserver hat geholfen.

Kennt ihr das Problem? (Ist m.E. ein CCU Problem, da alle anderen Geräte im LAN normal weiterfunktionieren.)
Gibt es dafür eine Lösung? (Ich kann die FB leider nicht an die USV hängen)
Oder kann ich im FHEM wenigstens erkennen, dass mit der CCU nicht mehr kommuniziert wird?

Da ein list meines ccu Geräts sehr lang ist, hier mal nur Teile:

Code Auswählen Erweitern


Internals:
   CCUNum     1
   Clients    :HMCCUDEV:HMCCUCHN:HMCCURPC:HMCCURPCPROC:
   DEF        192.168.178.33
   FUUID      5c586976-f33f-a2be-f7c2-5a53ef69261b448e
   NAME       d_ccu
   NOTIFYDEV  global,TYPE=(HMCCU|HMCCUDEV|HMCCUCHN)
   NR         20
   NTFY_ORDER 50-d_ccu
   RPCState   running
   STATE      running/OK
   TYPE       HMCCU
   ccuaddr    BidCoS-RF
   ccuchannels 106
   ccudevices 15
   ccuif      BidCos-RF
   ccuinterfaces VirtualDevices,HmIP-RF,BidCos-RF
   ccuip      192.168.178.33
   ccuname    HM-RCV-50 BidCoS-RF
   ccustate   active
   ccutype    CCU2/3
   host       192.168.178.33
   version    4.3.010
   READINGS:
     2019-03-26 17:29:57   count_channels  106
     2019-03-26 17:29:57   count_devices   15
     2019-03-26 17:29:57   count_groups    0
     2019-03-26 17:29:57   count_interfaces 3
     2019-03-26 17:29:57   count_programs  2
     2019-03-22 10:02:40   rpcstate        running
     2019-03-22 10:02:50   state           OK
   hmccu:
     defInterface BidCos-RF
     defPort    2001
     evtime     0
     evtimeout  0
     rpccount   0
     rpcports   2001,2010,9292
     updatetime 1553617796
     adr:
...
     ccu:
       chncount   106
       delay      180
       delayed    0
       devcount   15
       gcount     0
       ifcount    3
       prgcount   2
       timeout    1
...
     ifports:
       2001       BidCos-RF
       2010       HmIP-RF
       9292       VirtualDevices
     interfaces:
       BidCos-RF:
         device     d_rpcBidCos_RF
         flags      forceASCII
         host       192.168.178.33
         manager    null
         port       2001
         prot       http
         state      inactive
         type       A
         url        http://192.168.178.33:2001
       HmIP-RF:
         device     d_rpcHmIP_RF
         flags      _
         host       192.168.178.33
         manager    null
         port       2010
         prot       http
         state      inactive
         type       A
         url        http://192.168.178.33:2010
...
     rpc:
Attributes:
   ccudef-readingname ^(.+\.)?LOW_?BAT$:battery;^(.+\.)?UNREACH$:activity
   ccudef-substitute LOWBAT,LOW_BAT!(0|false):ok,(1|true):low;UNREACH!(0|false):alive,(1|true):dead
   ccuflags   procrpc
   rpcinterfaces BidCos-RF,HmIP-RF,VirtualDevices
   rpcport    2001,2010,9292
   rpcserver  on
   stateFormat rpcstate/state


Im Forum konnte ich nur Threads finden zum Thema Startreihenfolge FHEM und CCU, aber die laufen bei mir ja beide dauerhaft.

Bin um jeden Hinweis oder Idee dankbar!

LG,
Stephan.

[loescher]

Ich bin offensichtlich der Einzige mit diesem Problem. 
Daher habe ich mir ein DOIF gebaut, das als Grundlage für eine Erkennung dieses Fehlers dienen kann:

Code Auswählen Erweitern


defmod Aktuelle_CCU_Readings DOIF ([:00])\
(setreading $SELF dev_namen [@:"":state:((ReadingsAge($name,"state",0)<3600)&&($TYPE=~/^HMCCU/)),"keine"],\
setreading $SELF anzahl [#:"":state:((ReadingsAge($name,"state",0)<3600)&&($TYPE=~/^HMCCU/)),0])
attr Aktuelle_CCU_Readings state [$SELF:anzahl]
attr Aktuelle_CCU_Readings do always
attr Aktuelle_CCU_Readings comment Jede volle Stunde wird gezählt, wieviele Homematic Geräte einen Status haben, der nicht älter ist als eine Stunde. Sollte hier Null stehen, dann ist wahrscheinlich die CCU oder die Verbindung dorthin ausgefallen.


Evtl. hilft es ja jemandem...

LG,
Stephan.

[zap]

Die FB ist der Router und der DNS Server in Deinem Netz, von daher isr es nicht verwunderlich, dass FHEM und/oder CCU die Verbindung zueinander verlieren. Die CCU hört mit dem Senden von Events auf, wenn der Partner für eine gewisse Zeit nicht erreichbar war. Dann muss sich der RPC Server in FHEM neu bei der CCU registrieren.

Das kann man mit folgendem Befehl erreichen:

set <iodev> rpcregister all

Ist aber normalerweise überflüssig, da HMCCU den Ausfall erkennen und die Registrierung automatisch durchführen kann. Dazu muss im IO Device im Attribut ccuflags das Flag reconnect gesetzt werden (glaube das heißt so, s. Doku).

Außerdem gibt es ein Event in FHEM, wenn für eine definierbare Zeit keine Updates von der CcU kamen. Auch das kann man in einem Notify nutzen.

Ein Neustart von FHEM oder CCU ist jedenfalls nicht erforderlich.

[loescher]

Hallo zap!

Vielen Dank!
Hab jetzt bei mir das so gesetzt:

Code Auswählen Erweitern

attr d_ccu ccuflags procrpc,reconnect

Übrigens fehlt mE in der commandref ein Zeilenumbruch:

Code Auswählen Erweitern


reconnect - Automatically reconnect to CCU when events timeout occurred. Flags intrpc, extrpc and procrpc cannot be combined.

sollte wohl so sein:

Code Auswählen Erweitern


reconnect - Automatically reconnect to CCU when events timeout occurred.
Flags intrpc, extrpc and procrpc cannot be combined.

Beim Überfliegen hatte ich dadurch wahrgenommen, dass man procrpc nicht mit reconnect kombinieren kann. Hätte ich es nur genauer gelesen.

LG,
Stephan.