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:
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
# $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
# $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
schon mal den RPC Server durchgestartet?
set <HMCCU> rpserver off
set <HMCCU> rpserver on
Wenn die CCU zwischenzeitlich mal neu gestartet wurde, reicht auch ein
set <iodev> rpcregister all
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)
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
Funktioniert das automatische Update nur bei einem Device nicht oder bei allen?
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 ?
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
wenn du mehrere CCUs hast, musst du sicherstellen, dass betroffene Device auch das richtige IODevice benutzt. Gilt auch für das RPC Device.
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
Nö, wenn der RPC Server dem falschen IO Device zugeordnet ist, hast Du genau diesen Effekt. get Update funktioniert, das automatische Update aber nicht.
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
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.
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
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
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:
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
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
Moin moin,
ich sehe gerade, daß nicht nur nach dem Namen gefiltert wird - so einfach ist es dann doch nicht ;)
HMCCU_FindClientDevices prüft das Device, nur die geforderten Werte für die Internals stimmen nicht alle...
Hier die Funktion, um ein paar Logausgaben erweitert (vergleiche mit Stand: $Id: 88_HMCCU.pm 18745 2019-02-26 17:33:23Z zap $)
sub HMCCU_FindClientDevices ($$$$)
{
my ($hash, $modexp, $namexp, $internal) = @_;
my @devlist = ();
my $name = $hash->{NAME};
Log3 $name, 2, ">>> HMCCU_FindClientDevices ";
Log3 $name, 2, ">>> +++ modexp: $modexp";
Log3 $name, 2, ">>> +++ namexp: $namexp";
Log3 $name, 2, ">>> +++ internal: $internal";
foreach my $d (keys %defs) {
my $ch = $defs{$d};
my $m = 1;
my $logmatch = ($ch->{NAME} eq 'HW_FL_Presence');
next if (!defined ($ch->{TYPE}) || !defined ($ch->{NAME}));
if ($logmatch) {
Log3 $name, 2, ">>> checking secific device" ;
Log3 $name, 2, ">>> - Name " . $ch->{NAME} ;
Log3 $name, 2, ">>> - type:" . $ch->{TYPE} ;
Log3 $name, 2, ">>> - iodev:" . $ch->{IODev} ;
}
next if (defined ($modexp) && $ch->{TYPE} !~ /$modexp/);
if ($logmatch) { Log3 $name, 2, ">>> +++ modexp ok"; }
next if (defined ($namexp) && $ch->{NAME} !~ /$namexp/);
if ($logmatch) { Log3 $name, 2, ">>> +++ name ok"; }
next if (defined ($hash) && exists ($ch->{IODev}) && $ch->{IODev} != $hash);
if ($logmatch) { Log3 $name, 2, ">>> +++ iodev ok"; }
if (defined ($internal)) {
foreach my $intspec (split (',', $internal)) {
my ($i, $v) = split ('=', $intspec);
if (defined ($v) && exists ($ch->{$i}) && $ch->{$i} !~ /$v/) {
$m = 0;
last;
}
}
}
if ($m == 1) {
Log3 $name, 2, ">>> ### adding device to devlist";
} else {
Log3 $name, 2, ">>> ### skipping device, internals do not match/exist: $internal";
}
push @devlist, $ch->{NAME} if ($m == 1);
}
Log3 $name, 2, "<<< HMCCU_FindClientDevices ";
return @devlist;
}
Hier die erweiterte Logausgabe:
2019.04.20 10:01:06.398 1: HMCCU: [HW_HMCCU2] All RPC servers running
2019.04.20 10:01:06.407 2: >>> HMCCU_FindClientDevices
2019.04.20 10:01:06.408 2: >>> +++ modexp: (HMCCUDEV|HMCCUCHN)
2019.04.20 10:01:06.408 2: >>> +++ namexp: .*
2019.04.20 10:01:06.408 2: >>> +++ internal: ccudevstate=active,ccuif=BidCos-RF
2019.04.20 10:01:06.410 2: >>> checking secific device
2019.04.20 10:01:06.410 2: >>> - Name HW_FL_Presence
2019.04.20 10:01:06.411 2: >>> - type:HMCCUDEV
2019.04.20 10:01:06.411 2: >>> - iodev:HASH(0x350fa38)
2019.04.20 10:01:06.412 2: >>> +++ modexp ok
2019.04.20 10:01:06.412 2: >>> +++ name ok
2019.04.20 10:01:06.413 2: >>> +++ iodev ok
2019.04.20 10:01:06.413 2: >>> ### skipping device, internals do not match/exist: ccudevstate=active,ccuif=BidCos-RF
2019.04.20 10:01:06.416 2: <<< HMCCU_FindClientDevices
2019.04.20 10:01:06.416 2: HMCCU: No client devices matching .*
2019.04.20 10:01:06.417 2: HMCCU: [HW_HMCCU2] Updated devices. Success=0 Failed=0
Allerdings hat das internal 'ccuif' des Client-Device den Wert HmIP-RF, deshalb wird "nichts gefunden".
Dabei haben sowohl das HMCCU-Device im Internal 'ccuif' als auch die RPC-Device im Internal 'rpcinterface' den Wert BidCos-RF, passend dazu läuft in der CCU2 die Funkhardware unter dem Gerätenamen 'HM-RCV-50 BidCoS-RF'.
Insofern scheint es, als komme der Wert BidCos-RF nur nicht im Internal des Client-Devices an.
An dieser Stelle die Prüfung zu übergehen, reicht auch nicht, der Unterschied wirkt sich offensichlich noch an mindestens einer anderen Stelle aus ...
TIA Chris
oops, double post gelöscht
Mach mal ein list von dem Device in FHEM
Ok, hier das Client-Device:
Internals:
DEF 000C17099A00AF
FUUID 5cba2915-f33f-1138-0dc1-ce40f2d989a4b23c
IODev HW_HMCCU2
NAME HW_FL_Presence
NR 338
STATE Initialized
TYPE HMCCUDEV
ccuaddr 000C17099A00AF
ccudevstate active
ccuif HmIP-RF
ccuname HW_FL_Presence
ccutype HmIP-SPI
channels 2
statevals devstate
READINGS:
2019-04-20 10:21:03 1.CURRENT_ILLUMINATION 0.0
2019-04-20 10:21:03 1.PRESENCE_DETECTION_ACTIVE on
2019-04-20 10:21:03 battery ok
2019-04-20 10:21:03 batteryLevel 2.7
2019-04-20 10:21:03 control on
2019-04-20 10:21:03 hmstate present
2019-04-20 10:21:03 illumination 416.8
2019-04-20 10:21:03 presence present
2019-04-22 02:01:10 state Initialized
hmccu:
devspec 000C17099A00AF
Attributes:
IODev HW_HMCCU2
ccureadingfilter (ILLUMINATION|PRESENCE|LOW_BAT|OPERATING_VOLTAGE)
ccureadingname 0.LOW_BAT:battery;0.OPERATING_VOLTAGE:batteryLevel;1.ILLUMINATION:illumination;1.PRESENCE_DETECTION_STATE:presence
controldatapoint 1.PRESENCE_DETECTION_ACTIVE
event-on-change-reading battery,batteryLevel,illumination,presence
eventMap /datapoint 1.RESET_PRESENCE 1:reset/datapoint 1.PRESENCE_DETECTION_ACTIVE 1:detection-on/datapoint 1.PRESENCE_DETECTION_ACTIVE 0:detection-off/
group Sensoren
hmstatevals SABOTAGE!(1|true):sabotage
icon message_presence
room - Innenlicht,Hardware
statedatapoint 1.PRESENCE_DETECTION_STATE
stripnumber 1
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
Thnx, Chris
Sieht alles korrekt aus. Einzige Idee wäre noch, im define statt der Adresse den Namen des Device anzugeben. Irgendwann war das mal ein Thema, insbesondere wenn die Adresse mit 0 beginnt.
Zitat von: zap am 23 April 2019, 13:42:24
Sieht alles korrekt aus.
Yup, aber
ccuif stimmt halt leider nicht.
Zitat von: zap am 23 April 2019, 13:42:24
Einzige Idee wäre noch, im define statt der Adresse den Namen des Device anzugeben. Irgendwann war das mal ein Thema, insbesondere wenn die Adresse mit 0 beginnt.
Nein, leider nicht, und mein "irgendwann mal" war ja Ende 2018 - da hat es ja noch mit der numerischen Adresse getan, da sollte es wohl eher an den Änderungen seitdem liegen. Ich habe HMCCU_GetCCUDeviceParam mit ein paar Log-Ausgaben gespickt, und einmal mit der numerischen Adresse und ein weiteres Mal mit dem Namen HW_FL_Presence als DEF im neu und manuell angelegten Client Device gestartet - es kommen identische Werte heraus:
2019.04.23 19:05:14.766 2: >>> returning ccuif: HmIP-RF
2019.04.23 19:05:14.766 2: >>> returning ccuadr: 000C17099A00AF
2019.04.23 19:05:14.767 2: >>> returning ccuname: HW_FL_Presence
2019.04.23 19:05:14.767 2: >>> returning ccutype: HmIP-SPI
2019.04.23 19:05:14.767 2: >>> returning channels: 2
Das
ccuif wird aus
$hash->{hmccu}{dev}{$devadd}{interface} gezogen, mir ist bei der schieren Menge sowohl des Codes als auch der Änderungen zwischen den beiden Versionen nur nicht klar, welcher Teil des Codes den Wert in den Hashtree setzt - da müsste dann doch etwas schief laufen? Welcher Teil wäre das?
Ich werde noch ein Duplikat des aktuellen SD-Mediums mit der alten Version der Module versehen und laufen lassen, und dann mal schauen, wie die Listings der drei beteiligten Devices im Vergleich aussehen.
Thnx, Chris
Was ist falsch am ccuif?
Zitat von: zap am 23 April 2019, 20:57:34
Was ist falsch am ccuif?
Hatte ich weiter oben geschrieben (20. April 2019, 10:40:08), das
HmIP-RF wurde von HMCCU_FindClientDevices nicht aktzeptiert, weil nach
BidCos-RF gesucht wurde; das meinte ich damit. Aber es hat sich herausgestellt, daß ich Ursache und Wirkung vertauscht habe - es konnte ja auch sein, das der Fehler drin lag, daß das
gesuchte Interface falsch ist, also der Parameter für HMCCU_FindClientDevices nicht stimmte.
Und so scheint es zu sein - es gibt neue Erkenntnisse. Zu allererst: es tut wieder. Die Ursache für die Besserung ist offensichtlich, daß ich die CCU2 komplett zurückgesetzt und dann noch einmal das physische Gerät angelernt habe. Damit hat sich etwas verändert, was zunächst unbemerkt blieb - nach der Neuanlage der fhem-Devices taucht im Listing der Client-Device jetzt ein Internal
firmware 1.0.0 auf, das fehlte bisher. Und HMCCU_FindClientDevices "findet" jetzt das Client-Device ohne Problene - somit wird also das ccuif
HmIP-RF gesucht.
Auf das Zurücksetzen der CCU2 bin ich übrigens gar nicht von selbst gekommen. Als ich fhem auf einer Kopie des Images mit dem alten Softwarestand starten wollte, mußte ich das physische Gerät neu an der CCU2 anlernen, weil dies nicht erreichbar war. Hierbei wurde vom CCU2-Web-Interface der Werksreset des Geräts durchgeführt - oder auch nicht - der Geräteeintrag blieb auf jeden Fall drin, konnte auch nicht mehr gelöscht werden und ein Neuanlernen ging nicht mehr. Da half nur Zurücksetzen der CCU2 auf Werkseinstellungen und komplett neu konfigurieren usw..
Beim Zurückschwenken auf das Image mit der aktuellen Version (also mit dem Problem) mußte ich das physische Gerät wiederum erneut anlernen, auch hier ging es nur mit Werksreset der CCU2. Dann habe ich nochmal die HMCCU* devices gelöscht und neu erzeugt, und seitdem läuft das Update des Client-Device sauber.
Damit ist das Problem erst einmal gelöst, darüber bin ich natürlich sehr froh, auch wenn ich die tieferliegende Ursache nur vermuten kann. Und das merkwürdige Verhalten der CCU2 ist leicht bedenklich - hoffentlich ist zukünftig nicht schon bei einem Batteriewechsel in einem physischen Gerät ein Zurücksetzen erforderlich.
Auf jeden Fall vielen Dank für Deine Hilfe, und für Deine Arbeit an den Modulen überhaupt, der Code ist ja schon heftig umfangreich! Und dann muß nur noch die CCU2 mitspielen! ;D
Thnx Chris
Der Code wird demnächst schrumpfen, wenn die Unterstützung für den internen RPC Server wegfällt.
Geräte neu anlernen nach Batteriewechsel hatte ich bisher noch nicht. HMIP Steckdosen sind bekannt dafür, dass man sie nach einem Firmware Update manchmal neu anlernen muss.
Zitat von: zap am 24 April 2019, 12:06:35
Geräte neu anlernen nach Batteriewechsel hatte ich bisher noch nicht. HMIP Steckdosen sind bekannt dafür, dass man sie nach einem Firmware Update manchmal neu anlernen muss.
HM Steckdosen brauchen hier immer ein neues Anlernen nach dem Batterietausch, aber das geht ja mit fhem, kein Poblem also in diesem Fall. Beim letzten Mal Batterietausch mit dem HMIP Präsenzmelder mußte ich dagegen neu anlernen, daher meine Befürchtung. Nun hat ja die CCU2 offensichtlich ein Problem gehabt, es mag damals also daran gelegen haben.
Aber ich habe es gerade noch einmal ausprobiert und die Batterien gezogen. Nach einer halben Stunde habe ich sie wieder zugesteckt und es tut alles ohne Anlernen - hoffentlich alles gut also beim nächsten Mal!