[Gelöst] HMCCUDEV device bekommt kein automatisches Update mehr

clang · 05 April 2019, 23:20:38

Hallo zap, hallo *,

seit einem Update von vor zwei Wochen (siehe auch https://forum.fhem.de/index.php/topic,99363.0.html) bekommt ein HMCCUDEV Device kein Update mehr (das ist das Gerät aus https://forum.fhem.de/index.php/topic,90649.0.html).

Hier die aktuelle Gerätedefinition, diese ist lt. meinen Sicherungen seit Monaten unverändert:

Code Auswählen

define HW_FL_Presence HMCCUDEV 000C17099A00AF
attr HW_FL_Presence IODev HW_HMCCU2
attr HW_FL_Presence ccureadingfilter (ILLUMINATION|PRESENCE|LOW_BAT|OPERATING_VOLTAGE)
attr HW_FL_Presence ccureadingname 0.LOW_BAT:battery;;0.OPERATING_VOLTAGE:batteryLevel;;1.ILLUMINATION:illumination;;1.PRESENCE_DETECTION_STATE:presence
attr HW_FL_Presence controldatapoint 1.PRESENCE_DETECTION_ACTIVE
attr HW_FL_Presence event-on-change-reading battery,batteryLevel,illumination,presence
attr HW_FL_Presence eventMap /datapoint 1.RESET_PRESENCE 1:reset/datapoint 1.PRESENCE_DETECTION_ACTIVE 1:detection-on/datapoint 1.PRESENCE_DETECTION_ACTIVE 0:detection-off/
attr HW_FL_Presence group Sensoren
attr HW_FL_Presence hmstatevals SABOTAGE!(1|true):sabotage
attr HW_FL_Presence icon message_presence
attr HW_FL_Presence room Hardware,Maint. Sensoren
attr HW_FL_Presence statedatapoint 1.PRESENCE_DETECTION_STATE
attr HW_FL_Presence stripnumber 1
attr HW_FL_Presence substitute LOW_BAT!(0|false):ok,(1|true):low;;PRESENCE_DETECTION_STATE!(0|false):absent,(1|true):present;;PRESENCE_DETECTION_ACTIVE!(0|false):off,(1|true):on

Die CCU2-Homematic-WebUI im Linux-Container erkennt Änderungen in der Präsenz und Helligkeit problemlos, das o.g. Gerät HW_FL_Presence verbleibt aber im Status Initialized. Ein get update aktualisert das device im fhem korrekt, nur automatisch kommt nichts an. In keinem Fall gibt es bezüglich dieses Geräts Fehlermeldungen, das Log enthält aus meiner Sicht nur die korrekten Startup-Meldungen von HMCCU, RPC & Co., da läuft alles offensichtlich ganz sauber hoch.

Die letzten Versionen der HMCCU-Moduldateien, die hier eingesetzt wurden und mit denen das Problem nicht bestand, waren

Code Auswählen

#  $Id: 88_HMCCU.pm 18134 2019-01-04 15:48:08Z zap $
#  Version 4.3.009
#  $Id: 88_HMCCUCHN.pm 18134 2019-01-04 15:48:08Z zap $
#  Version 4.3.005
#  $Id: 88_HMCCUDEV.pm 18134 2019-01-04 15:48:08Z zap $
#  Version 4.3.006
#  $Id: 88_HMCCURPCPROC.pm 18134 2019-01-04 15:48:08Z zap $
#  Version 1.4

die Versionen seitdem mit diesem Problem sind die folgenden

Code Auswählen

#  $Id: 88_HMCCU.pm 18745 2019-02-26 17:33:23Z zap $
#  Version 4.3.014
#  $Id: 88_HMCCUCHN.pm 18552 2019-02-10 11:52:28Z zap $
#  Version 4.3.006
#  $Id: 88_HMCCUDEV.pm 18552 2019-02-10 11:52:28Z zap $
#  Version 4.3.008
#  $Id: 88_HMCCURPCPROC.pm 18745 2019-02-26 17:33:23Z zap $
#  Version 1.7.001

Kann ich noch etwas für die Analyse tun?

TIA Chris

Wetterhexe · 06 April 2019, 13:39:35

schon mal den RPC Server durchgestartet?

set <HMCCU> rpserver off
set <HMCCU> rpserver on

zap · 06 April 2019, 15:24:08

Wenn die CCU zwischenzeitlich mal neu gestartet wurde, reicht auch ein

set <iodev> rpcregister all

clang · 06 April 2019, 17:47:27

Zitat von: Wetterhexe am 06 April 2019, 13:39:35
schon mal den RPC Server durchgestartet?

set <HMCCU> rpserver off
set <HMCCU> rpserver on

Na klar, schon mehrfach - da sah das log ebenso total ok aus - wie zigmal sowohl fhem als auch der ganze Raspi durchgestartet wurde (also auch die CCU2 Software, die auch darauf läuft)

clang · 06 April 2019, 17:56:08

Zitat von: zap am 06 April 2019, 15:24:08
Wenn die CCU zwischenzeitlich mal neu gestartet wurde, reicht auch ein

set <iodev> rpcregister all

Vielen Dank für den Hinweis. Ich habe das mal ausprobiert, weil ich das noch nicht kannte. Die zwei Zeilen, die dann im Log erscheinen, tauchten auch jeweils nach einem Neustart von fhem auf, alles ok damit also. Insofern ändert das wie erwartet nichts am Problem, nach wie vor kommt ohne ein get update keine Änderung an.

Die CCU2 läuft im lxc auf demselben Raspi, und wurde also mehrfach mit dem ganzen System durchgestartet, insofern sollte das ggf. jedesmal schon ausgereicht haben.

Thnx Chris

zap · 06 April 2019, 17:57:32

Funktioniert das automatische Update nur bei einem Device nicht oder bei allen?

clang · 08 April 2019, 20:46:12

Zitat von: zap am 06 April 2019, 17:57:32
Funktioniert das automatische Update nur bei einem Device nicht oder bei allen?

Nur bei einem nicht, aber leider ist es das einzige, welches über die CCU2 angebunden ist...

Eine Sache habe ich bislang im Log übersehen, da steht fast am Ende Success=0, müsste da nicht eine 1 stehen ? Zudem: woher kommt das Pattern .* welches angeblich auf kein Clientdevice passt ? Von mir kommt das nicht, beim devicelist create habe ich den Namen HW_FL_Presence explizit angegeben... oder hat es damit keine Bewandnis ?

Code Auswählen


2019.04.08 20:33:37.626 2: HMCCU: [HW_HMCCU2] Get RPC device for interface BidCos-RF
2019.04.08 20:33:37.643 2: HMCCURPCPROC: [d_rpc032011BidCos_RF] RPC server process started for interface BidCos-RF with PID=27044
2019.04.08 20:33:37.657 2: CCURPC: [d_rpc032011BidCos_RF] Initializing RPC server CB2001032008032011 for interface BidCos-RF
2019.04.08 20:33:37.694 1: HMCCURPCPROC: [d_rpc032011BidCos_RF] RPC server starting
2019.04.08 20:33:37.834 2: HMCCURPCPROC: [d_rpc032011BidCos_RF] Callback server CB2001032008032011 created. Listening on port 7411
2019.04.08 20:33:37.836 2: CCURPC: [d_rpc032011BidCos_RF] CB2001032008032011 accepting connections. PID=27044
2019.04.08 20:33:37.847 2: HMCCURPCPROC: [d_rpc032011BidCos_RF] RPC server CB2001032008032011 enters server loop
2019.04.08 20:33:37.848 2: HMCCURPCPROC: [d_rpc032011BidCos_RF] Registering callback http://172.16.32.8:7411/fh2001 of type A with ID CB2001032008032011 at http://172.16.32.11:2001
2019.04.08 20:33:37.955 1: HMCCURPCPROC: [d_rpc032011BidCos_RF] RPC server CB2001032008032011 running
2019.04.08 20:33:37.965 1: HMCCU: [HW_HMCCU2] All RPC servers running
2019.04.08 20:33:37.976 2: HMCCU: No client devices matching .*
2019.04.08 20:33:37.976 2: HMCCU: [HW_HMCCU2] Updated devices. Success=0 Failed=0
2019.04.08 20:33:37.995 1: HMCCURPCPROC: [d_rpc032011BidCos_RF] Scheduled CCU ping every 300 seconds
2019.04.08 20:33:38.060 2: CCURPC: [d_rpc032011BidCos_RF] CB2001032008032011 NewDevice received 52 device and channel specifications

Ein weiteres Aufblähen des Logs hat leider nichts weiter ergeben. Gibt es sonst noch Möglichkeiten, einen Hinweis auf die Fehlerursache zu bekommen?

TIA Chris

zap · 09 April 2019, 11:44:52

wenn du mehrere CCUs hast, musst du sicherstellen, dass betroffene Device auch das richtige IODevice benutzt. Gilt auch für das RPC Device.

clang · 12 April 2019, 09:26:17

Zitat von: zap am 09 April 2019, 11:44:52
wenn du mehrere CCUs hast, musst du sicherstellen, dass betroffene Device auch das richtige IODevice benutzt. Gilt auch für das RPC Device.

Stimmt na klar! Allerdings muß es wohl das richtige IO-Device sein, das manuell get update geht ja. Zudem hat es ja seit über einem Jahr mit dieser Konfiguration funktioniert - es tut nur nicht mehr nach dem SW-Update.

Thnx, Chris

zap · 12 April 2019, 11:32:27

Nö, wenn der RPC Server dem falschen IO Device zugeordnet ist, hast Du genau diesen Effekt. get Update funktioniert, das automatische Update aber nicht.

clang · 13 April 2019, 12:02:39

Zitat von: zap am 12 April 2019, 11:32:27
Nö, wenn der RPC Server dem falschen IO Device zugeordnet ist, hast Du genau diesen Effekt. get Update funktioniert, das automatische Update aber nicht.

Ah ok, der RPC-Server wird na klar nur für eine der beiden Richtungen gebraucht, und das get update ist gar nicht aussagekräftig. Ich habe das IODev dann sicherheitshalber auch mal gezielt geprüft, dies ist für das RCP- als auch für das Client-Device unverändert korrekt eingestellt.

Allerdings habe ich Deine Aussage nicht verstanden, daß ich das korrekte IODev sicherstellen muß. Sowohl RCP- als auch Client-Device sind durch fhem generiert worden, damit wird das IODev durch fhem festgelegt. Das IODev ist auch nicht etwa ungewollt durch das aktualisierte CUL_HM-Modul verändert worden, das wäre mir bereits beim Vergleich der aktuellen Gerätedefinition mit der Sicherung von vor acht Monaten aufgefallen.

Muß ich also wirklich selbst darauf achten bzw. gibt es Fälle, wo man das IODev manuell abändert oder das automatische Generieren durch fhem nicht sauber funktioniert?

Thnx Chris

zap · 13 April 2019, 15:07:51

Normalerweise ordnet HMCCU bei der Generierung der RPC Devices das IO Device automatisch und korrekt zu. Du kannst das aber natürlich manuell verändern, dann könnte es eben sein, dass das falsch ist.
Aber was soll das mit einem CUL_HM Update zu tun haben? Sind völlig verschiedene Welten.

clang · 15 April 2019, 01:19:34

Zitat von: zap am 13 April 2019, 15:07:51
Normalerweise ordnet HMCCU bei der Generierung der RPC Devices das IO Device automatisch und korrekt zu. Du kannst das aber natürlich manuell verändern, dann könnte es eben sein, dass das falsch ist.

Ah, jetzt ergibt es einen Sinn. Ok, das habe ich nicht gemacht, und das hatte ich zu Beginn auch so nicht geschrieben.

Zitat von: zap am 13 April 2019, 15:07:51
Aber was soll das mit einem CUL_HM Update zu tun haben? Sind völlig verschiedene Welten.

Ooops, sorry, da habe ich mich schlicht vertan. Ich habe zeitgleich ja noch das andere Problem, welches Du auch gelesen hattest (https://forum.fhem.de/index.php/topic,99363.0.html) und das ist ja ebenfalls erst seit dem letzten Update aufgetreten, die habe ich kurz durcheinander gebracht. Ich meinte in diesem Fall hier tatsächlich die Änderungen an HMCCU(CHN|DEV|RPC).

Gibt es noch Dinge, die ich tun kann, um bei der Analyse weiterhelfen würden?

thnx Chris

zap · 15 April 2019, 09:23:15

Da es nur um ein Device geht, würde ich folgendes machen:

- Device in FHEM löschen
- Device in der CCU ablernen und neu anlernen
- Für das IO Device einmal "get devicelist" ausführen
- Device in FHEM neu definieren

Der folgende Eintrag im Log zeigt, dass FHEM für Deine CCU2 überhaupt keine Devices findet:

2019.04.08 20:33:37.976 2: HMCCU: No client devices matching .*
2019.04.08 20:33:37.976 2: HMCCU: [HW_HMCCU2] Updated devices. Success=0 Failed=0

clang · 20 April 2019, 00:26:38

Hey zap,

Zitat von: zap am 15 April 2019, 09:23:15
Da es nur um ein Device geht, würde ich folgendes machen:

- Device in FHEM löschen
- Device in der CCU ablernen und neu anlernen
- Für das IO Device einmal "get devicelist" ausführen
- Device in FHEM neu definieren

Ok, bis auf das Neuanlernen des Geräts hatte ich das bereits gemacht - nun also inklusive Neuanlernen des Geräts!!

Zitat von: zap am 15 April 2019, 09:23:15
Der folgende Eintrag im Log zeigt, dass FHEM für Deine CCU2 überhaupt keine Devices findet:

2019.04.08 20:33:37.976 2: HMCCU: No client devices matching .*
2019.04.08 20:33:37.976 2: HMCCU: [HW_HMCCU2] Updated devices. Success=0 Failed=0

Nach den o.g. Schritten fehlten beim ersten fhem-Restart diese beiden Zeilen, aber seit dem zweiten Restart sind sie wieder da.
Wahrscheinlich war das auch beim letzten Mal so, als ich nur das Client-Device neu angelegt habe, nur habe ich das Startup-Log nicht sofort gezogen und diesen Unterschied nicht bemerkt.

Es ist echt merkwürdig, daß da auf das Suchmuster '.*' nichts zurückkommt. Gut, ich weiß nicht, auf welche Datenmenge das Suchmuster angewendet wird:
* auf die Namen aller Client-Devices in fhem - aber da gibt es ja mindestens ein Client-Device namens HW_FL_Presence
* auf die Namen aller Devices, die von der CCU2 geliefert werden - aber dort gibt es das namensgleiche device HW_FL_Presence ebenfalls

Hier die deviceinfo des passenden Device der CCU2:

Code Auswählen


CHN 000C17099A00AF:0 HW_FL_Presence:0
  DPT {b} HmIP-RF.000C17099A00AF:0.CONFIG_PENDING = false [RE]
  DPT {b} HmIP-RF.000C17099A00AF:0.DUTY_CYCLE = false [RE]
  DPT {n} HmIP-RF.000C17099A00AF:0.ERROR_CODE = 0 [RE]
  DPT {b} HmIP-RF.000C17099A00AF:0.LOW_BAT = false [RE]
  DPT {f} HmIP-RF.000C17099A00AF:0.OPERATING_VOLTAGE = 2.700000 [RE]
  DPT {n} HmIP-RF.000C17099A00AF:0.RSSI_DEVICE = 181 [RE]
  DPT {n} HmIP-RF.000C17099A00AF:0.RSSI_PEER = 179 [RE]
  DPT {b} HmIP-RF.000C17099A00AF:0.SABOTAGE = false [RE]
  DPT {b} HmIP-RF.000C17099A00AF:0.UNREACH = false [RE]
  DPT {b} HmIP-RF.000C17099A00AF:0.UPDATE_PENDING = false [RE]
CHN 000C17099A00AF:1 HW_FL_Presence:1
  DPT {f} HmIP-RF.000C17099A00AF:1.CURRENT_ILLUMINATION = 0.000000 [RE]
  DPT {f} HmIP-RF.000C17099A00AF:1.ILLUMINATION = 350.100000 [RE]
  DPT {b} HmIP-RF.000C17099A00AF:1.PRESENCE_DETECTION_ACTIVE = true [RWE]
  DPT {b} HmIP-RF.000C17099A00AF:1.PRESENCE_DETECTION_STATE = false [RE]
  DPT {b} HmIP-RF.000C17099A00AF:1.RESET_PRESENCE =  [W]

Dann noch ein Schuß ins Blaue: Theoretisch gäbe es noch die Möglichkeit, daß überhaupt keine Namen in der Prüfroutine ankommen, deshalb die Prüfung per regexp gar nicht durchgeführt und dennoch diese Fehlermeldung ausgegeben wird - die dann aber, wenn auch nicht total falsch, aber zumindest irreführend ist.

An dem eigentlichen Problem hat sich letztendlich nichts geändert - automatisch kommt da leider noch nichts bezgl. Statusänderungen des Präsenzmelders in fhem an.

Hier noch das komplette aktuelle Startup-Log

Code Auswählen


2019.04.19 23:27:10.901 1: Including fhem.cfg
2019.04.19 23:27:17.463 1: HMCCU: [HW_HMCCU2] Initialized version 4.3.014
2019.04.19 23:27:17.463 1: HMCCU: [HW_HMCCU2] HMCCU: Initializing device
2019.04.19 23:27:17.524 1: HMCCU: [HW_HMCCU2] HMCCU: Read 2 devices with 53 channels from CCU 172.16.32.11
2019.04.19 23:27:17.525 1: HMCCU: [HW_HMCCU2] HMCCU: Read 3 interfaces from CCU 172.16.32.11
2019.04.19 23:27:17.525 1: HMCCU: [HW_HMCCU2] HMCCU: Read 0 programs from CCU 172.16.32.11
2019.04.19 23:27:17.525 1: HMCCU: [HW_HMCCU2] HMCCU: Read 0 virtual groups from CCU 172.16.32.11
2019.04.19 23:27:17.623 1: HMCCURPCPROC: [d_rpc032011BidCos_RF] Initialized version 1.7.001 for interface BidCos-RF with I/O device HW_HMCCU2
2019.04.19 23:27:17.885 1: Including ./log/fhem.save
2019.04.19 23:27:23.600 0: HMCCU: Start of RPC server after FHEM initialization in 12 seconds
2019.04.19 23:27:23.778 1: usb create starting
2019.04.19 23:27:24.156 1: PERL WARNING: can't getattr: Input/output error at FHEM/DevIo.pm line 422.
2019.04.19 23:27:24.156 1: ZWDongle: Can't open /dev/serial1: Input/output error
2019.04.19 23:27:24.220 1: CUL: Can't open /dev/ttyS0: Input/output error
2019.04.19 23:27:24.242 1: usb create end
2019.04.19 23:27:24.243 0: Featurelevel: 5.9
2019.04.19 23:27:24.243 0: Server started with 328 defined entities (fhem.pl:19006/2019-03-23 perl:5.024001 os:linux user:fhem pid:15240)
2019.04.19 23:27:25.149 1: FHEMWEB SSL/HTTPS error:  SSL accept attempt failed error:1408F09C:SSL routines:ssl3_get_record:http request (peer: 172.16.32.8)
2019.04.19 23:27:35.602 2: HMCCU: [HW_HMCCU2] Get RPC device for interface BidCos-RF
2019.04.19 23:27:35.618 2: HMCCURPCPROC: [d_rpc032011BidCos_RF] RPC server process started for interface BidCos-RF with PID=15283
2019.04.19 23:27:35.632 2: CCURPC: [d_rpc032011BidCos_RF] Initializing RPC server CB2001032008032011 for interface BidCos-RF
2019.04.19 23:27:35.669 1: HMCCURPCPROC: [d_rpc032011BidCos_RF] RPC server starting
2019.04.19 23:27:35.801 2: HMCCURPCPROC: [d_rpc032011BidCos_RF] Callback server CB2001032008032011 created. Listening on port 7411
2019.04.19 23:27:35.802 2: CCURPC: [d_rpc032011BidCos_RF] CB2001032008032011 accepting connections. PID=15283
2019.04.19 23:27:35.812 2: HMCCURPCPROC: [d_rpc032011BidCos_RF] RPC server CB2001032008032011 enters server loop
2019.04.19 23:27:35.814 2: HMCCURPCPROC: [d_rpc032011BidCos_RF] Registering callback http://172.16.32.8:7411/fh2001 of type A with ID CB2001032008032011 at http://172.16.32.11:2001
2019.04.19 23:27:35.919 1: HMCCURPCPROC: [d_rpc032011BidCos_RF] RPC server CB2001032008032011 running
2019.04.19 23:27:35.928 1: HMCCU: [HW_HMCCU2] All RPC servers running
2019.04.19 23:27:35.939 2: HMCCU: No client devices matching .*
2019.04.19 23:27:35.939 2: HMCCU: [HW_HMCCU2] Updated devices. Success=0 Failed=0
2019.04.19 23:27:35.958 1: HMCCURPCPROC: [d_rpc032011BidCos_RF] Scheduled CCU ping every 300 seconds
2019.04.19 23:27:36.028 2: CCURPC: [d_rpc032011BidCos_RF] CB2001032008032011 NewDevice received 52 device and channel specifications

Thnx, der ratlose Chris