Inbetriebnahme CCU2

Depechem · 29 Oktober 2018, 18:48:35

Zitat von: zap am 29 Oktober 2018, 18:33:26
Mit dem Attribut rpcEventTimeout legst du die Zeit in Sekunden fest, nach der der Event getriggert wird, wenn dazwischen kein Update von der CCU kommt.

Der getriggerte Event lautet

No events from interface ... for xx seconds

muss ich das attr im "d_rpcHmIP_RF" Modul oder in der "HMCCU" vornehmen?

und welches "verbose" Level muss ich einstellen um diesen Event im Log nach dem ausschalten der CCU3 zu loggen?

Depechem · 29 Oktober 2018, 18:57:14

Also ich habe im Modul "HmIP-RF" "rpcEventTimeout 20" gesetzt
und "verbose 3"

Danach Raspimatic heruntergefahren

nun finde ich einen Eintrag im fhem.log

Code Auswählen

HMCCURPCPROC: [d_rpcHmIP_RF] Received no events from interface CB2010002200 for 20 seconds

Damit kann ich jetzt einen notify setzen das die Verbindung zwischen CCU3 und FHEM verloren gegangen ist!?
Gleichzeitig könnte man doch ein

Code Auswählen

set d_ccu rpcserver on somit müsste sobald die CCU wieder online ist die Verbindung wieder aufgebaut werden.
Oder ist dies eher Kontraproduktiv?

wie viele Sekunden würdes du den Timeout festlegen?

Viele Grüße Thomas

zap · 29 Oktober 2018, 21:43:25

Genau, darauf kann ein notify reagieren. Es geht aber einfacher. Setze ccuflags im jeweiligen RPC device auf reconnect, dann versucht sich FHEM automatisch neu bei der CCu zu registrieren, sobalsd der event timeout auftritt

Depechem · 30 Oktober 2018, 11:52:52

Hallöle,
Seit heut morgen bringt mir FHEM im Log minütlich immer die Nachricht das er die CCU nicht finden kann.

Code Auswählen

HMCCURPCPROC: [d_rpcHmIP_RF] Received no events from interface CB2010002200 for 60 seconds

Also genau der Log den ich fürs notify nutzen sollte.
Wenn ich einen Schaltvorgang von einem HMiP Gerät vornehme wird dieser in FHEM auch abgebildet. Also kann es ja nicht daran liegen das keine Verbindung zw. CCU und FHEM besteht?

Gesendet von iPhone mit Tapatalk

zap · 30 Oktober 2018, 16:16:53

Diese Meldung bedeutet nicht, dass keine Verbindung mehr zur CCU besteht. Sie besagt einfach nur, dass von der CCU in den letzten 60 Sekunden kein Update für ein HmIP Gerät gekommen ist.

Wenn du nur wenige Geräte hast und diese nicht sonderlich geschwätzig sind, kann das durchaus vorkommen.

Du musst dich auch von dem Gedanken lösen, dass HMCCU eine ständige Verbindung zur CCU hat. HMCCU baut nur in folgenden Fällen eine temporäre Verbindung zur CCU auf:

- Beim Start von FHEM, um die Geräte der CCU abzufragen
- Beim Starten und Stoppen der RPC Server für die Event Registrierung
- Bei der Ausführung von Befehlen oder Programmen

Im laufenden Betrieb ist es v.a. die CCU, die sich bei FHEM meldet, sofern Updates für Geräte vorliegen. Und genau auf diese Updates achtet HMCCU und triggert ein Event, wenn sie für die definierte Zeit ausbleiben.

Die RPC Schnittstelle der CCU bietet einen Ping Request an. Dieser erzwingt eine Antwort der CCU per Pong Event. Theoretisch könnte man das für einen regelmäßigen Keepalive Test nutzen. Leider kommt aber die Rega der CCU damit nicht klar und produziert endlose Fehlermeldungen im Log der CCU. Wenn EQ3 das mal fixed, werde ich das in HMCCU einbauen.

Depechem · 21 Dezember 2018, 21:28:17

Ich muss nochmal nachfragen.

- FHEM läuft
- CCU3 wird neu gestartet

Nachdem die CCU wieder läuft kann man die Aktoren wieder über FHEM schalten, aber sie werden in FHEM nicht ausgewetet(also der Status ändert sich nicht) sozusagen wird bekommt FHEM es auch nicht mit wenn außerhalb von FHEM Aktoren geschalten werden.

Erst duch einen Neustart des "rpcserver" läuft wieder alles. Meine attr im Anhang. Laut meinen attr müsste doch FHEM allein mitbekommen das die CCU nicht mehr angebunden ist und des Server neu starten oder!?

In: d_ccu

Code Auswählen

attr d_ccu ccuGetVars 360
attr d_ccu ccuaggregate name:battery,filter:name=^HM_.*,read:battery,if:any=low,else:ok,prefix:battery_,coll:comment!Batterien OK;;name:voltage,filter:type=(HM-CC-RT-DN|HM-TC-IT-WM-W-EU),read:BATTERY_STATE,if:le=2.2,else:0,prefix:voltage_,coll:comment!Batteriespannung OK;;name:lock,filter:name=^HM_TF.*,read:state,if:any=open,else:closed,prefix:lock_,coll:comment!Alle Fenster/Türen geschlossen;;name:lockroof,filter:group=Dachfenster,read:state,if:any=open,else:closed,prefix:lockroof_,coll:comment!Alle Dachfenster geschlossen;;name:lockwin,filter:name=^HM_TF.*!Haustuer$,read:state,if:any=open,else:closed,prefix:lockwin_,coll:comment!Alle Fenster/Türen geschlossen;;name:hummax,filter:name=^HM_KL.*,read:HUMIDITY,if:ge=60,else:0,prefix:hummax_,coll:alias!Luftfeuchte OK;;name:unreach,filter:name=^HM_.*,read:activity,if:any=dead,else:alive,prefix:unreach_,coll:comment!Alle Devices erreichbar
attr d_ccu ccudef-readingfilter ^(LOW_?BAT|UNREACH)$
attr d_ccu ccudef-readingname ^(.+\.)?LOW_?BAT$:battery;; ^(.+\.)?UNREACH$:activity
attr d_ccu ccudef-substitute AES_KEY!(0|false):off,(1|true):on;;LOWBAT,LOW_BAT!(0|false):ok,(1|true):low;;UNREACH!(0|false):alive,(1|true):dead;;MOTION!(0|false):noMotion,(1|true):motion;;DIRECTION!0:stop,1:up,2:down,3:undefined;;WORKING!0:false,1:true;;INHIBIT!(0|false):unlocked,(1|true):locked
attr d_ccu ccuflags procrpc
attr d_ccu cmdIcon on:general_an off:general_aus
attr d_ccu event-on-change-reading .*
attr d_ccu eventMap /rpcserver on:on/rpcserver off:off/
attr d_ccu room CCU3
attr d_ccu rpcevtimeout 600
attr d_ccu rpcinterfaces BidCos-RF,HmIP-RF
attr d_ccu rpcport 2001,2010
attr d_ccu rpcserver on
attr d_ccu stateFormat rpcstate/state

In: d_rpcHmIP_RF

Code Auswählen

attr d_rpcHmIP_RF alias CCU RPC HmIP-RF
attr d_rpcHmIP_RF ccuflags reconnect
attr d_rpcHmIP_RF eventMap /rpcserver on:on/rpcserver off:off/
attr d_rpcHmIP_RF room CCU3
attr d_rpcHmIP_RF rpcEventTimeout 60
attr d_rpcHmIP_RF stateFormat rpcstate/state
attr d_rpcHmIP_RF verbose 2

Liebe Grüße
Thomas

zap · 22 Dezember 2018, 08:30:05

Ein Neustart der RPC Server ist nicht notwendig. Die müssen sich nur neu bei der CCU registrieren. Momentan geht das nur, indem du in den HMCCURPCPROC Devices ccuflags auf reconnect setzt.

Bin aber gerade dabei, das zu vereinfachen

Depechem · 22 Dezember 2018, 11:49:45

Zitat von: zap am 22 Dezember 2018, 08:30:05
Ein Neustart der RPC Server ist nicht notwendig. Die müssen sich nur neu bei der CCU registrieren. Momentan geht das nur, indem du in den HMCCURPCPROC Devices ccuflags auf reconnect setzt.

Bin aber gerade dabei, das zu vereinfachen

Habe ich ja, sie meinen attr weiter oben.
Das funktioniert aber nicht?!
Oder fehlt da noch was?

zap · 22 Dezember 2018, 13:23:00

Ok, wer lesen kann ...

Eigentlich müsstest Du 2 HMCCURPCPROC Devices haben. Bei beiden muss ccuflags gesetzt sein (BidCos ist immer da, weil das die Standard Schnittstelle der CCU ist).

Außerdem müssten im Logfile 60 irgendwann nach dem CCU Neustart (bei dir vermutlich nach 60 Sekunden) Timeout Meldungen erscheinen mit entsprechenden Reconnect Ankündigungen. Sind solche Meldungen vorhanden?

Depechem · 22 Dezember 2018, 16:37:20

Zitat von: zap am 22 Dezember 2018, 13:23:00
Eigentlich müsstest Du 2 HMCCURPCPROC Devices haben. Bei beiden muss ccuflags gesetzt sein (BidCos ist immer da, weil das die Standard Schnittstelle der CCU ist

Ist bei beiden Devices aktiv

Zitat von: zap am 22 Dezember 2018, 13:23:00
Außerdem müssten im Logfile 60 irgendwann nach dem CCU Neustart (bei dir vermutlich nach 60 Sekunden) Timeout Meldungen erscheinen mit entsprechenden Reconnect Ankündigungen. Sind solche Meldungen vorhanden?

Code Auswählen

2018.12.22 16:28:55.915 2: HMCCURPCPROC: [d_rpcHmIP_RF] Received no events from interface CB2010002200 for 60 seconds
2018.12.22 16:28:55.916 2: HMCCURPCPROC: [d_rpcHmIP_RF] Reconnecting to CCU interface HmIP-RF
2018.12.22 16:28:55.918 2: HMCCURPCPROC: [d_rpcHmIP_RF] Registering callback http://192.168.2.200:7420/fh2010 of type A with ID CB2010002200 at http://192.168.2.199:2010
2018.12.22 16:28:56.077 2: CCURPC: [d_rpcHmIP_RF] CB2010002200 NewDevice received 10 device and channel specifications
2018.12.22 16:29:56.192 2: HMCCURPCPROC: [d_rpcHmIP_RF] Received no events from interface CB2010002200 for 60 seconds
2018.12.22 16:29:56.192 2: HMCCURPCPROC: [d_rpcHmIP_RF] Reconnecting to CCU interface HmIP-RF
2018.12.22 16:29:56.195 2: HMCCURPCPROC: [d_rpcHmIP_RF] Registering callback http://192.168.2.200:7420/fh2010 of type A with ID CB2010002200 at http://192.168.2.199:2010
2018.1

zap · 22 Dezember 2018, 18:19:54

Grundsätzlich scheint der Reconnect ja ausgeführt zu werden ("Registering callback ..."). Seltsam nur, dass bei Dir trotzdem keine Readings in FHEM aktualisiert werden. Zumal beim Neu-Registrieren anscheinend keine Fehlermeldung kommt.

Depechem · 22 Dezember 2018, 21:03:36

Zitat von: zap am 22 Dezember 2018, 18:19:54
Grundsätzlich scheint der Reconnect ja ausgeführt zu werden ("Registering callback ..."). Seltsam nur, dass bei Dir trotzdem keine Readings in FHEM aktualisiert werden. Zumal beim Neu-Registrieren anscheinend keine Fehlermeldung kommt.

Genau, wie könnte ich das weiter eingrenzen?

zap · 23 Dezember 2018, 10:46:28

Nach der ersten Neuregistrierung kommt zumindest einmal eine NewDevice Meldung. Die Kommunikation funktioniert also. Ich nehme an, es liegt am kurzen Timeout von 60 Sekunden und den wenigen Devices (10). Die schicken einfach innerhalb von 60 Sekunden keine Events, was zum erneuten Reconnect führt.

In der nächsten Version wird das per RPC Ping gelöst, der dafür sorgt, dass regelmäßig Events geschickt werden. Bis dahin könntest Du den Timeout erhöhen, vielleicht auf 180 oder 240.