HMScript failed. http://192.168.1.32:8181/tclrega.exe: Select timeout/error:

[Dirk070]

Also ich habe routing im Einsatz, aber ich kann mittlerweile mein FHEM wieder starten wie ich will. ob es benutzt wird kann ich aber nicht sagen, aber zumindet aktviert ist es bei 2 PSM Aktoren.

Verrückt, jetzt wollte ich das gerade nochmal testen und die CCU beobachten, da läuft alles ganz normal. Also einfach FHEM restart ohne Probleme, das einzige was ich gestern an HMCCU I/O DEV geändert habe war das ccuflag nonblocking und reconnect gesetzt und beim CCU RPC HmIP-RF das ccuflag auf expert gesetzt, sonst habe ich zu gestern nichts geändert.

Und beim HMCCU I/O DEV hatte ich das attr rpcinterval auf 2 stehen, warum weiß ich nicht mehr, aber ich habe das attribute komplett gelöscht, default ist wohl 5.

Also "nur" durch:

• ccuflag nonblocking und reconnect
• ccuflag auf expert
• attr rpcinterval gelöscht

[doman75]

Korrekt

[Rewe2000]

Hallo,

Mal ein Gedanke: kann es am Routing der IP-Aktoren liegen?

auch ich verwende Routing über eine HmIP-PSM Schaltsteckdose, meine aber nicht, dass dies die Ursache hierfür sein kann.
Das Routing ist, wenn ich mich korrekt erinnere, grundsätzlich bei der Einrichtung von neuen Geräten aktiv und muss bewusst vom Anwender abgeschaltet werden. Ich vermute nicht, dass jeder User mit Fhem dieses Routing gezielt abschaltet.

Nachtrag:
Habe das komplette Routing in meiner RaspberryMatic nun stillgelegt, nach Neustart der CCU3 nun auch Fhem neu gestartet, das Problem besteht nach wie vor.
Jemand anders, kann sich somit diesen Versuch sparen.

@zap:
Die einzige Lösung wird sein, das Update abschaltbar zu machen (ggf. pro RPC-Server getrennt). Hast du noch Hoffnung das Update mit Pausen zu verlangsamen?
Bei mir hat ja der Versuch https://forum.fhem.de/index.php/topic,98287.msg930558.html#msg930558 nicht geklappt.
Wenn wir da noch etwas in der Richtung testen sollen, melde dich bitte, ggf. war der Ansatz ja auch nicht optimal, wie wir das versucht haben.

Gruß Reinhard

[zap]

Also "nur" durch:

• ccuflag nonblocking und reconnect
• ccuflag auf expert
• attr rpcinterval gelöscht

reconnect zu setzen macht Sinn, da sich der RPC Server dann automatisch neu bei der CCU registriert.

nonBlocking wird von dem initialen Geräteupdate (noch) nicht benutzt. Und wenn, dann hätte es keinen Einfluss auf die Stabilität der CCU, nur auf die von FHEM.

[Dirk070]

Nonblocking und reconnect habe ich auch gesetzt.
Ob das beim Neustart von FHEM/CCU "heilende" Wirkung hat, konnte ich noch nicht testen.

Unabhängig von Neustarts, sondern im täglichen Betrieb:
Einzelne Timeouts sehe ich immer mal wieder, immer nur bei den IP-Aktoren.
Ich denke, das dies durch das Routing geschieht. Das Routing in den Aktoren ("Routing aktiv") ist zwar per default eingeschaltet, beim Steckdosen-Aktor muss man die Funktion "Gerät dient als Router" jedoch explizit einschalten.
Da das Routing erst greift, wenn die Zentrale den Aktor nicht direkt erreicht, dauert die Kommunikation offenbar länger und FHEM meldet den Timeout, obwohl der Aktor schlussendlich reagiert.

Ich habe ccuReqTimeout mal auf 6 gesetzt....

[zap]

Bei der direkten Ansteuerung der Geräte hilft sowohl nonblocking als auch die Erhöhung des Request Timeouts. Das mit dem Routing ist wirklich ein interessanter Punkt. Allerdigs dürfte das Abschalten des Routings das Problem evtl. verschlimmern, da die Geräte dann tatsächlich  nicht erreichbar sind.

[Ban]

Hallo zusammen,

zur Sicherheit, falls jemand den Thread "HMCCU: Version 4.3 verfügbar" nicht verfolgt.
Zap hat ein Update bzgl. des Updates der Geräte beim fhem Start veröffentlicht.

https://forum.fhem.de/index.php/topic,91033.msg938922.html#msg938922

Grüße,
Ban

[Dirk070]

Danke für den Hinweis!! 

[Rewe2000]

Hallo,

auch von meiner Seite vielen Dank für den Tipp, werde es heute noch installieren.

Gruß Reinhard

[Rewe2000]

Hallo,

leider ist bei mir der Test nicht sehr erfolgreich verlaufen, ich habe fast den Eindruck die RPC-Server können nur dann fehlerfrei mit ccuflags auf noInitialUpdate gestartet werden, wenn die CCU3 (mit RasperryMatic) schon länger gelaufen ist. Starte ich die CCU3 und kurz danach Fhem, so stürzt Fhem bei mir sogar ab.
Mehr dazu weiter unten.

HMCCU habe ich wie folgt definiert (RAW-Definition):

Code Auswählen Erweitern

defmod CCU2 HMCCU 192.168.1.32 waitforccu=120
attr CCU2 DbLogExclude .*
attr CCU2 ccuReqTimeout 8
attr CCU2 ccuaggregate name:HmIP_battery_,filter:group=HmIP-Device,read:(Batterie),if:any=leer,else:ok,prefix=HmIP_battery_,coll:alias;;\
name:HM_battery_,filter:group=HM-Device,read:(Batterie),if:any=leer,else:ok,prefix=HM_battery_,coll:alias;;\
name:DutyCycle_,filter:group=HmIP-Device,read:(0.DUTY_CYCLE),if:any=(1|true),else:(0|false),prefix=DutyCycle_,coll:alias\
name:Unerreichbar_,filter:group=HmIP-Device,read:(0.UNREACH),if:any=(1|true),else:(0|false),prefix=Unerreichbar_,coll:alias
attr CCU2 ccuflags procrpc,nonBlocking
attr CCU2 cmdIcon on:general_an off:general_aus
attr CCU2 eventMap /rpcserver on:on/rpcserver off:off/
attr CCU2 group Hardware
attr CCU2 icon hm_ccu
attr CCU2 room Homematic
attr CCU2 rpcinterfaces BidCos-RF,HmIP-RF,VirtualDevices
attr CCU2 rpcport 2001,2010,9292
attr CCU2 rpcqueue /tmp/ccuqueue
attr CCU2 rpcserver on
attr CCU2 stateFormat rpcstate/state
attr CCU2 verbose 2

setstate CCU2 running/OK
setstate CCU2 2019-05-14 18:30:00 DutyCycle_count 54
setstate CCU2 2019-05-14 18:30:00 DutyCycle_list no match
setstate CCU2 2019-05-14 18:30:00 DutyCycle_match 0
setstate CCU2 2019-05-14 18:30:00 DutyCycle_state (0|false)
setstate CCU2 2019-05-14 18:30:00 HM_battery_count 4
setstate CCU2 2019-05-14 18:30:00 HM_battery_list no match
setstate CCU2 2019-05-14 18:30:00 HM_battery_match 0
setstate CCU2 2019-05-14 18:30:00 HM_battery_state ok
setstate CCU2 2019-05-14 18:30:00 HmIP_battery_count 54
setstate CCU2 2019-05-14 18:30:00 HmIP_battery_list no match
setstate CCU2 2019-05-14 18:30:00 HmIP_battery_match 0
setstate CCU2 2019-05-14 18:30:00 HmIP_battery_state ok
setstate CCU2 2019-05-14 18:43:50 Status_Watchdog 0
setstate CCU2 2019-05-14 18:30:00 Unerreichbar_count 54
setstate CCU2 2019-05-14 18:30:00 Unerreichbar_list HM_EG_FK1_Wohnzimmer,HM_EG_FK1_Dusche,HM_OG_FK2_Schlafzimmer,HM_OG_FK1_BueroReinhard,HM_EG_TKE1_Wohnzimmer,HM_OG_FK1_Schlafzimmer,HM_OG_FK1_Bad
setstate CCU2 2019-05-14 18:30:00 Unerreichbar_match 7
setstate CCU2 2019-05-14 18:30:00 Unerreichbar_state (1|true)
setstate CCU2 2019-05-14 18:26:45 count_channels 380
setstate CCU2 2019-05-14 18:26:45 count_devices 65
setstate CCU2 2019-05-14 18:26:45 count_groups 5
setstate CCU2 2019-05-14 18:26:45 count_interfaces 3
setstate CCU2 2019-05-14 18:26:45 count_programs 11
setstate CCU2 2019-05-14 18:41:51 iface_addr_1 PEQ1947473
setstate CCU2 2019-05-14 18:41:51 iface_addr_2 3014F711A0001F58A9A71F51
setstate CCU2 2019-05-14 18:41:51 iface_conn_1 1
setstate CCU2 2019-05-14 18:41:51 iface_conn_2 1
setstate CCU2 2019-05-14 18:41:51 iface_ducy_1 5
setstate CCU2 2019-05-14 18:41:51 iface_ducy_2 5
setstate CCU2 2019-05-14 18:41:51 iface_type_1 CCU2
setstate CCU2 2019-05-14 18:41:51 iface_type_2 HMIP_CCU2
setstate CCU2 2019-05-14 18:27:15 rpcstate running
setstate CCU2 2019-05-14 18:36:50 state OK

HMCCURPCPROC - HmIP-RF wie folgt (RAW-Definition):

Code Auswählen Erweitern

defmod d_rpc001032HmIP_RF HMCCURPCPROC http://192.168.1.32 HmIP-RF
attr d_rpc001032HmIP_RF DbLogExclude .*
attr d_rpc001032HmIP_RF alias CCU RPC HmIP-RF
attr d_rpc001032HmIP_RF ccuflags noInitialUpdate
attr d_rpc001032HmIP_RF eventMap /rpcserver on:on/rpcserver off:off/
attr d_rpc001032HmIP_RF icon hm_ccu
attr d_rpc001032HmIP_RF room Homematic
attr d_rpc001032HmIP_RF stateFormat rpcstate/state
attr d_rpc001032HmIP_RF verbose 2

setstate d_rpc001032HmIP_RF running/OK
setstate d_rpc001032HmIP_RF 2019-05-14 18:27:05 rpcstate running
setstate d_rpc001032HmIP_RF 2019-05-14 18:37:02 state OK


Ich denke das sollte grundsätzlich so passen.

Meine Tests im einzelnen:

1. Neustart nur Fhem
Die CCU3 war über einen Tag in Betrieb, Fhem wurde, nach stoppen der RPC-Server, mit shutdown restart neu gestartet.
Der Start klappte bei mir genau so, wie @Ban ihn beschrieben hatte, Fhem kam sauber hoch, ohne Fehler im Log, auch die CCU3 zeigte keinerlei Abweichungen.

2. Neustart CCU3 und Fhem
Beim zweiten Test habe ich die CCU3 und Fhem gestoppt, als erstes die CCU3 gestartet und während des Hochlaufs der CCU3 habe ich Fhem gestartet. Früher startete Fhem mit Fehlern bei der HMCCU und den RPC-Servern, nach ca. 5 Minuten konnte ein shutdown restart ausgeführt werden und Fhem lief danach wieder absolut stabil.

Beim heutigen und den gleichen gestrigen Versuch, startet Fhem, nach ca. 2 Minuten hängt es sich auf und stürzt mit der Fehlermeldung

Code Auswählen Erweitern

2019.05.14 17:58:11 4: HMCCU: [CCU2] Build URL =
Can't locate object method "simple_request" via package "RPC::XML::Client::new: Missing location argument" (perhaps you forgot to load "RPC::XML::Client::new: Missing location argument"?) at ./FHEM/88_HMCCU.pm line 7668.
ab.

Nach einem sudo reboot oder sudo /etc/init.d/fhem status startet danach Fhem wieder, die CCU3 ist jedoch stark "beschäftigt" und es kommen viele Servicemeldungen (unreach-fehler). Nach einem erneuten Neustart der CCU3 und set CCU2 rpcregister all läuft alles wieder stabil.
Wenn Interesse besteht, ich habe mir das Log mit Verbose 5 und stacktrace bei auftreten des Absturzes aufgehoben.

Zumindest ist jetzt wieder ein shutdown restart möglich, nachdem die CCU3 länger gelaufen ist, bisher war ja nicht einmal dies möglich.

Danke @zap für deine Mühe mit dem Patch, leider hat dieser nur einen Teilerfolg erzielt.
Bin gespannt wie die Tests bei meinen "Leidensgenossen" verlaufen sind.

Gruß Reinhard

[zap]

Und wenn du bei allen RPC Devices no initial update setzt?

[Rewe2000]

Hallo zap,

Und wenn du bei allen RPC Devices no initial update setzt?

hab ich eben probiert, klappt auch nicht!
Auch das IP-Routing ist an allen Geräten abgeschaltet.

Auch das "normale" shutdown restart (bei laufender CCU3) funktioniert nicht mehr.
Die CCU3 mit RaspberryMatic bringt > 25 Kommunikationsstörungen und musste neu gestartet werden.
Aber Fhem stürzt zumindest nicht mehr ab 

Wenn ich mein Fehlerlog als Laie so interpretiere, denke ich fast, es werden bei mir noch immer alle Geräte, trotz noInitialUpdate bei allen RPC-Servern, beim Start noch abgefragt.
Eben nochmal flag noInitialUpdate bei allen RPC-Servern geprüft und erneut shutdown restart ausgeführt, das Ergenis ändert sich jedoch nicht.

Ich häng nochmal mein LOG mit an, eventuell fällt ja jemanden noch etwas auf.

Code Auswählen Erweitern

2019.05.15 18:27:21 0: HMCCU: Start of RPC server after FHEM initialization in 12 seconds
2019.05.15 18:27:21 3: Opening WAGO device 192.168.1.30:502
2019.05.15 18:27:21 3: WAGO device opened
2019.05.15 18:27:21 1: usb create starting
2019.05.15 18:27:22 3: Probing ZWDongle device /dev/serial1
2019.05.15 18:27:22 3: Probing CUL device /dev/ttyS0
2019.05.15 18:27:22 1: usb create end
2019.05.15 18:27:22 0: Featurelevel: 5.9
2019.05.15 18:27:22 0: Server started with 392 defined entities (fhem.pl:19381/2019-05-13 perl:5.024001 os:linux user:fhem pid:13337)
2019.05.15 18:27:23 1: Perfmon: possible freeze starting at 18:27:08, delay is 15.225
2019.05.15 18:27:23 3: telnetForBlockingFn_1557937643: port 33025 opened
2019.05.15 18:27:23 2: ModbusTCPServer_Parse: except (code 2)
2019.05.15 18:27:33 2: HMCCU: [CCU2] Get RPC device for interface BidCos-RF
2019.05.15 18:27:33 2: HMCCU: [CCU2] Get RPC device for interface HmIP-RF
2019.05.15 18:27:33 2: HMCCU: [CCU2] Get RPC device for interface VirtualDevices
2019.05.15 18:27:33 2: HMCCURPCPROC: [d_rpc001032BidCos_RF] RPC server process started for interface BidCos-RF with PID=13367
2019.05.15 18:27:33 2: CCURPC: [d_rpc001032BidCos_RF] Initializing RPC server CB2001001033001032 for interface BidCos-RF
2019.05.15 18:27:33 1: HMCCURPCPROC: [d_rpc001032BidCos_RF] RPC server starting
2019.05.15 18:27:33 2: HMCCURPCPROC: [d_rpc001032HmIP_RF] RPC server process started for interface HmIP-RF with PID=13368
2019.05.15 18:27:33 2: CCURPC: [d_rpc001032HmIP_RF] Initializing RPC server CB2010001033001032 for interface HmIP-RF
2019.05.15 18:27:33 1: HMCCURPCPROC: [d_rpc001032HmIP_RF] RPC server starting
2019.05.15 18:27:33 2: HMCCURPCPROC: [d_rpc001032VirtualDevices] RPC server process started for interface VirtualDevices with PID=13369
2019.05.15 18:27:33 2: CCURPC: [d_rpc001032VirtualDevices] Initializing RPC server CB9292001033001032 for interface VirtualDevices
2019.05.15 18:27:33 1: HMCCURPCPROC: [d_rpc001032VirtualDevices] RPC server starting
2019.05.15 18:27:33 2: HMCCURPCPROC: [d_rpc001032BidCos_RF] Callback server CB2001001033001032 created. Listening on port 7411
2019.05.15 18:27:33 2: CCURPC: [d_rpc001032BidCos_RF] CB2001001033001032 accepting connections. PID=13367
2019.05.15 18:27:33 2: HMCCURPCPROC: [d_rpc001032BidCos_RF] RPC server CB2001001033001032 enters server loop
2019.05.15 18:27:33 2: HMCCURPCPROC: [d_rpc001032BidCos_RF] Registering callback http://192.168.1.33:7411/fh2001 of type A with ID CB2001001033001032 at http://192.168.1.32:2001
2019.05.15 18:27:33 2: HMCCURPCPROC: [d_rpc001032HmIP_RF] Callback server CB2010001033001032 created. Listening on port 7420
2019.05.15 18:27:33 2: CCURPC: [d_rpc001032HmIP_RF] CB2010001033001032 accepting connections. PID=13368
2019.05.15 18:27:33 2: HMCCURPCPROC: [d_rpc001032VirtualDevices] Callback server CB9292001033001032 created. Listening on port 14702
2019.05.15 18:27:33 2: CCURPC: [d_rpc001032VirtualDevices] CB9292001033001032 accepting connections. PID=13369
2019.05.15 18:27:34 1: HMCCURPCPROC: [d_rpc001032BidCos_RF] RPC server CB2001001033001032 running
2019.05.15 18:27:34 1: HMCCURPCPROC: [d_rpc001032BidCos_RF] Scheduled CCU ping every 300 seconds
2019.05.15 18:27:34 2: HMCCURPCPROC: [d_rpc001032VirtualDevices] RPC server CB9292001033001032 enters server loop
2019.05.15 18:27:34 2: HMCCURPCPROC: [d_rpc001032VirtualDevices] Registering callback http://192.168.1.33:14702/fh9292 of type A with ID CB9292001033001032 at http://192.168.1.32:9292/groups
2019.05.15 18:27:34 2: CCURPC: [d_rpc001032BidCos_RF] CB2001001033001032 NewDevice received 79 device and channel specifications
2019.05.15 18:27:34 2: CCURPC: [d_rpc001032VirtualDevices] CB9292001033001032 NewDevice received 35 device and channel specifications
2019.05.15 18:27:44 1: HMCCURPCPROC: [d_rpc001032VirtualDevices] RPC server CB9292001033001032 running
2019.05.15 18:27:44 2: HMCCURPCPROC: [d_rpc001032HmIP_RF] RPC server CB2010001033001032 enters server loop
2019.05.15 18:27:44 2: HMCCURPCPROC: [d_rpc001032HmIP_RF] Registering callback http://192.168.1.33:7420/fh2010 of type A with ID CB2010001033001032 at http://192.168.1.32:2010
2019.05.15 18:27:44 1: HMCCURPCPROC: [d_rpc001032HmIP_RF] RPC server CB2010001033001032 running
2019.05.15 18:27:44 1: HMCCU: [CCU2] All RPC servers running
2019.05.15 18:27:45 2: CCURPC: [d_rpc001032HmIP_RF] CB2010001033001032 NewDevice received 331 device and channel specifications
2019.05.15 18:27:54 2: HMCCU: [CCU2] HMScript failed. http://192.168.1.32:8181/tclrega.exe: Select timeout/error:
2019.05.15 18:27:54 2: HMCCU: Update of device 000A55699D54CA failed
2019.05.15 18:28:02 2: HMCCU: [CCU2] HMScript failed. http://192.168.1.32:8181/tclrega.exe: Select timeout/error:
2019.05.15 18:28:02 2: HMCCU: Update of device 000A5709916E0D failed
2019.05.15 18:28:10 2: HMCCU: [CCU2] HMScript failed. http://192.168.1.32:8181/tclrega.exe: Select timeout/error:
2019.05.15 18:28:10 2: HMCCU: Update of device 00045709AABA11 failed
2019.05.15 18:28:23 2: HMCCU: [CCU2] HMScript failed. http://192.168.1.32:8181/tclrega.exe: Select timeout/error:
2019.05.15 18:28:23 2: HMCCU: Update of device 000BD569A36E45 failed
2019.05.15 18:28:31 2: HMCCU: [CCU2] HMScript failed. http://192.168.1.32:8181/tclrega.exe: Select timeout/error:
2019.05.15 18:28:31 2: HMCCU: Update of device 000A97099C2095 failed
2019.05.15 18:28:40 2: HMCCU: [CCU2] HMScript failed. http://192.168.1.32:8181/tclrega.exe: Select timeout/error:
2019.05.15 18:28:57 2: HMCCU: [CCU2] HMScript failed. http://192.168.1.32:8181/tclrega.exe: Select timeout/error:
2019.05.15 18:28:57 2: HMCCU: Update of device 000393C994CDFB failed
2019.05.15 18:29:05 2: HMCCU: [CCU2] HMScript failed. http://192.168.1.32:8181/tclrega.exe: Select timeout/error:
2019.05.15 18:29:05 2: HMCCU: Update of device 0000D569A4A8C0 failed
2019.05.15 18:29:26 2: HMCCU: [CCU2] HMScript failed. http://192.168.1.32:8181/tclrega.exe: Select timeout/error:
2019.05.15 18:29:26 2: HMCCU: Update of device 000915699D38CB failed
2019.05.15 18:29:48 2: HMCCU: [CCU2] HMScript failed. http://192.168.1.32:8181/tclrega.exe: Select timeout/error:
2019.05.15 18:29:48 2: HMCCU: Update of device 000855699C41DE failed
2019.05.15 18:30:04 2: HMCCU: [CCU2] HMScript failed. http://192.168.1.32:8181/tclrega.exe: Select timeout/error:
2019.05.15 18:30:04 2: HMCCU: Update of device 0000D569A4AA0C failed
2019.05.15 18:30:12 2: HMCCU: [CCU2] HMScript failed. http://192.168.1.32:8181/tclrega.exe: Select timeout/error:
2019.05.15 18:30:12 2: HMCCU: Update of device 000855699C40D9 failed
2019.05.15 18:30:21 2: HMCCU: [CCU2] HMScript failed. http://192.168.1.32:8181/tclrega.exe: Select timeout/error:
2019.05.15 18:30:21 2: HMCCU: Update of device 000A9709A0D2C2 failed
2019.05.15 18:30:29 2: HMCCU: [CCU2] HMScript failed. http://192.168.1.32:8181/tclrega.exe: Select timeout/error:
2019.05.15 18:30:37 2: HMCCU: [CCU2] HMScript failed. http://192.168.1.32:8181/tclrega.exe: Select timeout/error:
2019.05.15 18:30:37 2: HMCCU: Update of device 0000D3C995FED6 failed
2019.05.15 18:30:51 2: HMCCU: [CCU2] HMScript failed. http://192.168.1.32:8181/tclrega.exe: Select timeout/error:
2019.05.15 18:30:51 2: HMCCU: Update of device 000A55699D6F4F failed
2019.05.15 18:30:59 2: HMCCU: [CCU2] HMScript failed. http://192.168.1.32:8181/tclrega.exe: Select timeout/error:
2019.05.15 18:30:59 2: HMCCU: Update of device 000B5569A27E19 failed
2019.05.15 18:31:29 2: HMCCU: [CCU2] HMScript failed. http://192.168.1.32:8181/tclrega.exe: Select timeout/error:
2019.05.15 18:31:29 2: HMCCU: Update of device 000895699E78A7 failed
2019.05.15 18:31:40 2: HMCCU: [CCU2] HMScript failed. http://192.168.1.32:8181/tclrega.exe: Select timeout/error:
2019.05.15 18:31:40 2: HMCCU: Update of device 000855699C41D7 failed
2019.05.15 18:31:48 2: HMCCU: [CCU2] HMScript failed. http://192.168.1.32:8181/tclrega.exe: Select timeout/error:
2019.05.15 18:31:48 2: HMCCU: Update of device 0000D569A4A8DE failed
2019.05.15 18:31:57 2: HMCCU: [CCU2] HMScript failed. http://192.168.1.32:8181/tclrega.exe: Select timeout/error:
2019.05.15 18:31:57 2: HMCCU: Update of device 0000D569A4AA67 failed
2019.05.15 18:32:19 2: HMCCU: [CCU2] HMScript failed. http://192.168.1.32:8181/tclrega.exe: Select timeout/error:
2019.05.15 18:32:19 2: HMCCU: Update of device 000895699E78CF failed
2019.05.15 18:32:19 1: PERL WARNING: Use of uninitialized value $filter in concatenation (.) or string at ./FHEM/88_HMCCU.pm line 2665.
2019.05.15 18:32:19 2: HMCCU: [CCU2] Updated devices for interface filter . Success=43 Failed=22
2019.05.15 18:32:19 1: Perfmon: possible freeze starting at 18:27:35, delay is 284.799
2019.05.15 18:32:19 3: ModbusTCPServer_Timeout, request: SimpleWrite [42 DC 00 00 00 06] 00 01 42 DC 00 08
2019.05.15 18:32:20 2: Systemhinweis - Folgende Geäte sind nicht erreichbar: HM_OG_FKE1_Garderobe,HM_EG_FK1_Wohnzimmer,HM_EG_TKE1_Wohnzimmer !
2019.05.15 18:32:21 3: ModbusTCPServer_Parse: got frame for previous request:  [42 DC 00 00 00 04] 00 01 01 00
2019.05.15 18:32:21 1: Perfmon: possible freeze starting at 18:32:20, delay is 1.672
2019.05.15 18:32:21 1: 192.168.1.30:502 disconnected, waiting to reappear (WAGO)
2019.05.15 18:32:22 2: AttrTemplates: got 87 entries
2019.05.15 18:32:23 1: Perfmon: possible freeze starting at 18:32:22, delay is 1.322
2019.05.15 18:32:24 1: 192.168.1.30:502 reappeared (WAGO)
2019.05.15 18:32:26 2: ModbusTCPServer_Parse: except (code 2)
2019.05.15 18:34:13 2: HMCCURPCPROC: [d_rpc001032BidCos_RF] Registering callback http://192.168.1.33:7411/fh2001 of type A with ID CB2001001033001032 at http://192.168.1.32:2001
2019.05.15 18:34:14 2: HMCCURPCPROC: [d_rpc001032HmIP_RF] Registering callback http://192.168.1.33:7420/fh2010 of type A with ID CB2010001033001032 at http://192.168.1.32:2010
2019.05.15 18:34:14 2: HMCCURPCPROC: [d_rpc001032VirtualDevices] Registering callback http://192.168.1.33:14702/fh9292 of type A with ID CB9292001033001032 at http://192.168.1.32:9292/groups
2019.05.15 18:34:14 2: CCURPC: [d_rpc001032BidCos_RF] CB2001001033001032 NewDevice received 79 device and channel specifications
2019.05.15 18:34:14 2: CCURPC: [d_rpc001032VirtualDevices] CB9292001033001032 NewDevice received 35 device and channel specifications
2019.05.15 18:34:15 2: CCURPC: [d_rpc001032HmIP_RF] CB2010001033001032 NewDevice received 331 device and channel specifications
2019.05.15 18:34:24 1: Perfmon: possible freeze starting at 18:34:14, delay is 10.122

Beim stoppen der RPC-Server ist mir eben die Meldung im Log aufgefallen, Fehler in Fhem hatte ich aber keine bemerkt.

Code Auswählen Erweitern

2019.05.15 20:07:46 2: CCURPC: [d_rpc001032HmIP_RF] Number of I/O errors = 91

Gruß Reinhard

[zap]

ok, da ist noch ein Fehler drin. Wenn bei allen RPC Devices noInitialUpdate gesetzt ist, werden statt keine alle Devices aktualisiert.
Bis ich das gefixt habe, setze das Flag überall außer z.B. für das Interface VirtualDevices.

[Rewe2000]

Hallo zap.

danke für die Info, ich dachte schon ich mache da irgend etwas falsch.
Ich warte lieber bis du die berichtigte Version einstellst, mittlerweile können wir uns ja helfen.

Mich wundert nur ein wenig, dass die Rückmeldungen von einigen anderen Usern positiv ausfielen. Eigentlich sollten doch alle HMCCU.. Versionen beim letzten Update gleich gewesen sein.

Gruß Reinhard

[zap]

Vermutlich hat es bei den anderen genügt, für HmIP noInitialUpdate zu setzen.