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

[clang]

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 $)

Code Auswählen Erweitern


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:

Code Auswählen Erweitern


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

[clang]

oops, double post gelöscht

[zap]

Mach mal ein list von dem Device in FHEM

[clang]

Ok, hier das Client-Device:

Code Auswählen Erweitern


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

[zap]

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.

[clang]

Sieht alles korrekt aus.

Yup, aber ccuif stimmt halt leider nicht.

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:

Code Auswählen Erweitern


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

[zap]

Was ist falsch am ccuif?

[clang]

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! 

Thnx Chris

[zap]

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.

[clang]

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!