Mahlzeit!
Ich verwende eine Raspberrymatic auf einem RPi3 und habe 111 HmIP-Geräte gekoppelt. Von FHEM aus greife ich mit HMCCU (procrpc) auf die Raspberrymatic zu. Das funktioniert prinzipiell zuverlässig. Nach Firmware-Updates der Raspberrymatic laufe ich jedoch häufig in eine Situation, in der sich die CCU teilweise oder vollständig aufhängt.
Der Ablauf ist in etwa wie folgt:
- Firmware-Update der Raspberrymatic
- Nach dem Neustart fehlen sämtliche Messwerte/Status der Geräte in der Raspberrymatic, sie füllen sich sukzessive sobald die zugehörigen Geräte sie senden.
- shutdown restart von FHEM bzw. rpcserver off;rpcserver on
- Im FHEM-Log erscheint eine Vielzahl von Meldungen der Art 2019.03.26 22:44:14.756 1: CCURPC: [d_rpcHmIP_RF] CB2010000011000182 maximum queue size reached. Dropping event. sowie 2019.03.26 22:44:25.865 2: HMCCU: [hmccu2] HMScript failed. http://CCUHOSTNAME:8181/tclrega.exe: Select timeout/error:
- Die vorher einwandfrei reagierende CCU reagiert mit Verzögerungen >10s, eintreffende Events werden nicht mehr verarbeitet. In einigen Fällen reagiert sie garnicht mehr. Die CCU erholt sich auch nach längerem Warten nicht.
Letztendlich führt das nach Firmware-Updates oftmals dazu, dass ich längere Zeit damit verbringen muss, das System wieder irgendwie hinzubiegen. Gestern bin ich die im Log ersichtlichen Meldungen schrittweise angegangen:
- attr d_rpcHmIP_RF rpcQueueSize 1000 (d. h. verdoppelt) => Die Queue-Size-Meldungen verschwanden vollständig.
- attr hmccu2 ccuReqTimeout 15 => Es traten nur noch vereinzelt Timeouts auf.
Danach habe ich die Raspberrymatic neu gestartet, 15 Minuten gewartet und dann den FHEM neu verbunden (über rpcserver off;on).
Anscheinend feuert hmccu beim FHEM-Start eine stattliche Zahl an "get updates" auf eine Vielzahl (alle?) in FHEM definierten Devices ab. Meine These wäre nun, dass die CCU mit den zugehörigen Rückmeldungen schlichtweg überfordert ist.
Besteht die Möglichkeit, die "get updates" testweise auszubremsen? Ist das nonBlocking-Flag hier relevant?
Der Vollständigkeit halber ein Auszug meiner Konfiguration:
defmod hmccu2 HMCCU CCUHOSTNAME
attr hmccu2 DbLogInclude iface_.*,rpcstate,state
attr hmccu2 ccuReqTimeout 15
attr hmccu2 ccuaggregate name:battery,filter:name=.*,read:(LOWBAT|LOW_BAT),if:any=yes,else:no,prefix=battery_,coll:NAME
attr hmccu2 ccudef-substitute CONFIG_PENDING,DUTY_CYCLE,LOW_BAT,UNREACH,UPDATE_PENDING,MOTION,MOTION_DETECTION_ACTIVE,ERROR_OVERHEAT,FROST_PROTECTION,PARTY_MODE,SWITCH_POINT_OCCURED,SABOTAGE,SELF_CALIBRATION_RESULT,STICKY_UNREACH,BOOT,DEVICE_IN_BOOTLOADER,LOWBAT,ERROR_WIND_COMMUNICATION,ERROR_WIND_NORTH,TEMPERATURE_OUT_OF_RANGE,RAINING,RAIN_COUNTER_OVERFLOW,SUNSHINEDURATION_OVERFLOW,SUNSHINE_THRESHOLD_OVERRUN,WIND_THRESHOLD_OVERRUN,ALARMSTATE!false:0,true:1
attr hmccu2 ccuflags procrpc,nonBlocking,reconnect
attr hmccu2 event-on-change-reading .*
attr hmccu2 rpcinterfaces BidCos-RF,HmIP-RF
attr hmccu2 rpcport 2001,2010
attr hmccu2 rpcserver on
defmod d_rpcHmIP_RF HMCCURPCPROC CCUHOSTNAME HmIP-RF
attr d_rpcHmIP_RF event-on-change-reading .*
attr d_rpcHmIP_RF eventMap /rpcserver on:on/rpcserver off:off/
attr d_rpcHmIP_RF rpcEventTimeout 300
attr d_rpcHmIP_RF rpcQueueSize 1000
Patrick
Nach dem Neustart der CCU nicht den RPC Server neu starten sondern mit "set rpcregister all" die RPC Server neu registrieren. Das genügt. Geht auch automatisch mit den entsprechenden Einstellungen.
Wie Du richtig vermutest, wird nach dem Start der RPC Server ein Update auf alle Devices gemacht, um den aktuellen Zustand zu ermitteln. Das scheint bei einigen zu den genannten Problemen zu führen.
Bei mir funktioniert es komischerweise.
Ich werde das Update abschaltbar machen.
Hallo Patrick,
willkommen im Club!
Die Antwort von mir wird zwar dein Problem nicht lösen, aber Probleme sind leichter zu ertragen, wenn man nicht alleine damit ist :).
Auch ich und ein anderer User hat seit einigen Tagen ähnliche Probleme wie du.
Guck mal: https://forum.fhem.de/index.php/topic,98287.0.html (https://forum.fhem.de/index.php/topic,98287.0.html)
Auch wir haben schon alle möglichen logischen Tests gemacht und konnten uns das Verhalten nicht erklären. Irgendetwas muss zwischen FHEM (HMCCU) und der CCU3 passieren oder falsch laufen, weshalb die Probleme in der Art auftreten. Erst durch den Tipp von zap mit "set rpcregister all" konnte ich Fhem wieder, nach einigen Tagen Abstinenz, mit der CCU3 kommunizieren lassen. Bei mir trat der Fehler mit der CCU2 und der CCU3 auf. RaspberryMatic wollte ich ev. am Wochenende mal versuchen.
Hast du deine Konfig mit Backup - Restore auf RaspberryMatic übertragen oder hast du die 110 Geräte neu angelernt?
Wenn du meinst dein Problem ist das gleiche wie das unsere, sollten wir eventuell den og. Thread dafür verwenden um eine Lösung dafür zu bekommen.
Gruß Reinhard
Hi!
Zitat von: zap am 28 März 2019, 07:25:31
Nach dem Neustart der CCU nicht den RPC Server neu starten sondern mit "set rpcregister all" die RPC Server neu registrieren. Das genügt. Geht auch automatisch mit den entsprechenden Einstellungen.
Danke für den Tipp. Mit welchen Einstellungen geht das denn automatisch? reconnect habe ich gesetzt (s. o.).
Zitat von: zap am 28 März 2019, 07:25:31
Wie Du richtig vermutest, wird nach dem Start der RPC Server ein Update auf alle Devices gemacht, um den aktuellen Zustand zu ermitteln. Das scheint bei einigen zu den genannten Problemen zu führen.
Bei mir funktioniert es komischerweise.
Komisch. Mangels Existenz eines RaspberryPi4 kann ich das Problem zumindest nicht mit Hardware totwerfen :) Wie viele HmIP-Geräte hast Du angelernt? Hast Du auch nonBlocking gesetzt?
Zitat von: zap am 28 März 2019, 07:25:31
Ich werde das Update abschaltbar machen.
Oh ja bitte! Dann kann ich endlich das Carfentanyl wieder absetzen. Wenn das tatsächlich den gewünschten Erfolg bringt, wäre das Optimum ein konfigurierbar dosierbares Update. Aber ggf. kann man das auch außenrumbauen, ohne das Modul anzufassen. Hängt davon ab, wie viele Betroffene es tatsächlich gibt.
Patrick
Hallo Reinhard,
Zitat von: Rewe2000 am 28 März 2019, 17:47:26
willkommen im Club!
Die Antwort von mir wird zwar dein Problem nicht lösen, aber Probleme sind leichter zu ertragen, wenn man nicht alleine damit ist :).
Auch ich und ein anderer User hat seit einigen Tagen ähnliche Probleme wie du.
Ein Gesprächskreis könnte tatsächlich helfen, die Situation besser zu verarbeiten ;)
Zitat von: Rewe2000 am 28 März 2019, 17:47:26
Guck mal: https://forum.fhem.de/index.php/topic,98287.0.html (https://forum.fhem.de/index.php/topic,98287.0.html)
Tatsache.
Zitat von: Rewe2000 am 28 März 2019, 17:47:26
Auch wir haben schon alle möglichen logischen Tests gemacht und konnten uns das Verhalten nicht erklären.
Naja letztlich scheint die CCU aus irgendeinem Grund mit dem Breitseite der Updateanfragen überfordert zu sein. Wenn man sich das Web-GUI und vor allem die Reaktionszeiten ansieht, hat man glaube ich keine Zweifel an der Fragilität dieses informatischen Werks.
Interessant wäre aber, warum das Problem bei zap nicht auftritt. Ich wüsste ehrlich gesagt nicht, was ich an meinem Setup noch optimieren könnte. Raspberrymatic ohne Module, Anbindung per Kupfer etc.
Zitat von: Rewe2000 am 28 März 2019, 17:47:26
RaspberryMatic wollte ich ev. am Wochenende mal versuchen.
Das kannst Du Dir sparen, zumindest wenn es Dir um die Behebung des Problems geht...
Zitat von: Rewe2000 am 28 März 2019, 17:47:26
Hast du deine Konfig mit Backup - Restore auf RaspberryMatic übertragen oder hast du die 110 Geräte neu angelernt?
Ich hatte schon zu CCU2-Zeiten (mit wesentlich weniger Geräten) migriert und zwar mit dem Einspielen des Config-Backups. Lief einwandfrei bzw. so gut wie vorher. Irgendwo hatte ich danach aber eine Anleitung gefunden, wie man die Migration "richtig" macht.
Zitat von: Rewe2000 am 28 März 2019, 17:47:26
Wenn du meinst dein Problem ist das gleiche wie das unsere, sollten wir eventuell den og. Thread dafür verwenden um eine Lösung dafür zu bekommen.
Das Problem scheint tatsächlich das gleiche zu sein. Würde noch die Antwort von zap abwarten und mich dann an den anderen Thread dranhängen.
Patrick
Hallo Patrick,
wie du schon vermutet hattest, RapberryMatic löst unser Problem auch nicht.
Was mich nur wundert, weshalb tritt dieses Phänomen nur bei bisher 3 Usern auf?
Vor einigen Jahren hatte ich anscheinend als einziger mal astronomisch lange Antwortzeiten in Verbindung mit der CCU2, irgendwann nach einigen Wochen war das Problem wieder verschwunden ohne die Ursache gefunden zu haben.
Was ist bei uns so anders als bei zap und den anderen Usern, starten wir als einzige unseren Raspi und die CCU zur gleichen Zeit?
Mit dem Tipp von zap bekomme ich meine Systeme wenigstens wieder zum laufen, es ist nur unbefriedigend wenn wir den Fehler überhaupt nicht eingrenzen können. Dazu benötigt man gute Perl Kenntnisse um das HMCCU Modul zu verstehen oder auch die Programmierung der CCU, irgend etwas muss da passieren, was die Systeme so sehr stresst. Leider kann ich mangels Programmierkenntnissen nicht viel dazu beitragen, mit Logik alleine kommen wir da anscheinend nicht weiter, wir haben da schon ziemlich viel ausprobiert https://forum.fhem.de/index.php/topic,98287.msg922354.html#msg922354 (https://forum.fhem.de/index.php/topic,98287.msg922354.html#msg922354), https://forum.fhem.de/index.php/topic,98287.msg925082.html#msg925082 (https://forum.fhem.de/index.php/topic,98287.msg925082.html#msg925082).
Eventuell müssen wir eine Rufnummer schalten (diese könnte ja zap ins Wiki mit aufnehmen) , wo wir uns gegenseitig ausweinen können, wenn wir das Problem nicht eingrenzen können ;).
Gruß Reinhard
Gerade wieder folgende Aktion durchgeführt:
- RPC Server gestoppt
- CCU3 auf neueste Firmware aktualisiert, inkl. Neustart
- RPC Server gestartet inkl. globalem Update auf alle Geräte
Kein Absturz, kein Hänger. Lediglich ein paar GetValue Fehler im Log der CCU, ist aber normal.
Gestartet werden 4 RPC Server, aktualisiert werden 78 Geräte, virtuell, BidCos, HmIP und CUXD.
Gleiches Spiel auf einem Charly Set, allerdings nur mit einigen HmIP Geräten. Erst recht kein Hänger.
Habt Ihr beim IO Device oder einzelnen Geräten das Attribut ccuget auf State gesetzt?
Zitat von: zap am 02 April 2019, 17:48:46
Habt Ihr beim IO Device oder einzelnen Geräten das Attribut ccuget auf State gesetzt?
Nicht bewusst und habe auch gerade die fhem.cfg durchsucht.
Steht nirgends mit dabei.
Hallo zap,
auch bei mir Fehlanzeige, habe eben meine Fhem.cfg nach ccuget durchsucht, dieses Attribut verwende ich (bisher) nirgends.
Gruß Reinhard
Habe ccuget auch nicht gesetzt.
@all: Wie viele Geräte welcher Technologie habt Ihr?
Hintergrund der Frage: Ich habe 111 Geräte als Fast-HmIP-Monokultur (109 HmIP, 2 HM legacy).
@zap: Hast Du nonBlocking gesetzt?
Patrick
/edit: Zu ccuget: Habe das nicht konsequent beobachtet, aber bei meinem letzten Problem hatte die CCU definitiv keine Werte. Fällt dann der Default ccuget Value in der CCU auf State zurück?
Hallo,
ich habe folgende Geräte derzeit an der CCU3 (RaspberryMatic):
3 Stück HmIP-BSM
2 HmIP-eTRV
3 HmIP-eTRV-2
2 HmIP-FSM
2 HmIP-KRCA
1 Stück HmIP-PCBS
1 Stück HmiP-PSM
1 Stück HmIP-SMi
1 Stück HmiP-SMO-A
21 Stück HmIP-SWDO
11 Stück HmIP-SWSD
1 Stück HmIP-WRC6
5 Stück HmIP-WTH-2
1 Stück HM-Dis-EP-WM55
1 Stück HM-MOD-EM-8
1 Stück HM-Sen-RD-O
1 Stück HM-WDS100-C6-O-2
5 HmIP-Heizgruppen
3 Miniaturprogramme ohne Script
Nur Standard Direktverknüpfungen und ca. 5 Systemvariablen
Ich verwende die CCU3 nur zum einsammeln der Geräte, die Anzahl dürfte jedoch von der Menge absolut unproblematisch sein.
Eben konnte ich meine Systeme, nur durch set CCU2 rpcregister all wieder zum laufen bekommen, nach dem Update bricht immer das totale Chaos aus, wenn ich die RPC-Server neu starten muss. Dieses Mal hatte sich sogar meine CCU3 aufgehangen, obwohl ich diese überhaupt nicht neu gestartet hatte.
Ich hoffe nur bis zur Urlaubszeit haben wir die Probleme irgendwie im Griff, wenn da nach einem Gewitter der Strom ausfällt, geht absolut nichts mehr.
Gruß Reinhard
Ich habe aktuell am Charly (RaspberryMatic) folgende Geräte.
An der CCU3 hatte ich dasselbe Verhalten.
HMIP:
8x HMIP-PS
3x HmIP-BSL
1x HmIP-FSM
3x HMIP-WRC2
1x HmIP-FDT
2x HmIP-RC8
4x HMIP-PSM
10x HmIP-BSM
3x HmIP-BRC2
6x HmIP-SWD
HM:
2x HM-LC-Sw1PBU-FM
3x HM-LC-Dim1T-Pl-3
4x HM-Sec-SCo
1x HM-ES-PMSw1-Pl
Grüße,
Ban
Ich würde das Thema gern noch mal aufgreifen:
1. gibt es inzwischen eine Möglichkeit beim Restart des RPCServers das Update zu deaktivieren
2. Die Konfiguration des RPCServers in HMCCU hat sich ja etwas geändert, ist das Wiki dazu aktuell?
Grüße
Im I/O Device das Attribut ccuflags auf "noInitialUpdate" setzen. Das verhindert die Aktualisierung nach dem Start der RPC-Server.
Hallo zap,
vielen Dank :). Du bist ja immer zur Stelle.
Nur zur Info: procrpc und nonblocking setze ich immer noch, korrekt? Das wird erst mit 4.4 überflüssig?
ja