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:
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.
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:
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.
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.
Hallo zap!
Vielen Dank!
Hab jetzt bei mir das so gesetzt:
attr d_ccu ccuflags procrpc,reconnect
Übrigens fehlt mE in der commandref ein Zeilenumbruch:
reconnect - Automatically reconnect to CCU when events timeout occurred. Flags intrpc, extrpc and procrpc cannot be combined.
sollte wohl so sein:
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.