Pairing an VCCU

plie80 · 13 November 2024, 23:24:49

Guten Abend,

ich hab eine Ergänzung bzw. Frage zum Thema Pairing von HM-CC-RT-DN bzw. HM-TC-IT-WM-W-EU an einer VCCU, die mittels mehrerer HMUARTLGWs angebunden ist.

Ich hab mir die Wiki Einträge zum Thema Pairing und auch zum Thema Probmele mit Version 1.5 ausführlich durchgelesen.

Der Pairingvorgang sieht bei mir allerdings immer - egal ob version 1.4 oder 1.5 so aus.

1) Start des Pairings an der VCCU
2) Start des Pairings am RT bzw. WT
3) hmPair terminiert mit hmId, model, aber sieht die S/N nicht
4) Im Log erscheint folgender Eintrag:

2024.11.13 09:18:47 3: HMUARTLGW_xxxxxx: Unknown code A1A0184007ACB090000001400AD554551313031323331355803FFFF::-59:HMUARTLGW_xxxxxx, help me!

5) Ich starte den Pairing Vorgang an der VCCU erneut, nachdem ich auf dem halb angelernten Devices clear msgEvents ausgeführt habe.
6) Ich starte den Pairing Vorgang am RT bzw. WT neu, ohne Batterien raus, ohne Reset.
7) Pairing ist nachvollziehbar erfolgreich. Diesmal ist auch die S/N mit übermittelt worden.

Ich frage mich, ob das Pairing im ersten Anlauf an der Nachricht 4) scheitert. Vielleicht kann sich jemand mit etwas mehr Erfahrung mit dem BidCos Protokoll der Nachricht einmal annehmen?

Danke Euch
Peter

frank · 14 November 2024, 09:56:22

moin

Code Auswählen

2024.11.13 09:18:47 3: HMUARTLGW_xxxxxx: Unknown code A1A0184007ACB090000001400AD554551313031323331355803FFFF::-59:HMUARTLGW_xxxxxx, help me!

das ist die anlernmessage des rt, die beim knöpfchen drücken gesendet wird.

gleichzeitig startet der rt den "countdown".
wenn dieser nicht innerhalb kurzer zeit abbricht, bekommt der rt keine antwort auf diese message. also einfach nach ende des countdown nochmal aufs knöpfchen drücken.

plie80 · 14 November 2024, 10:40:42

Hallo Frank,

danke für die Antwort. Aber warum wird die mit "help me!" geloggt?

Ich hatte die Vermutung, dass diese nicht richtig interpretiert wird und deswegen das Pairing im ersten Versuch fehlschlägt. Das ist reproduzierbar so, wie ich oben geschrieben hatte.

Danke
Peter

frank · 14 November 2024, 10:53:49

Zitat von: plie80 am 14 November 2024, 10:40:42Aber warum wird die mit "help me!" geloggt?

gute frage.

zeig mal ein list deiner vccu.
aber höchstens aes keys unkenntlich machen.

plie80 · 16 November 2024, 22:11:47

Hallo Frank,

List findest Du im Anhang. Wie gesagt, es ist so eindeutig reproduzierbar, dass es sich vielleicht fixen und damit ein Teil der Anlernproblematik verbessern lässt.

Bezüglich VCCU Setup habe ich auch noch ein paar andere Fixes, die ich auch noch submitten werde, wenn sie ausführlich getestet sind. Geht größtenteils um die Auswahl des geeignetsten IODevs. Leider reagiert der Maintainer wohl aktuell nicht mehr. Ich habs vor vielen Wochen mal mit einem kleinen Patch zum Export eines Readings probiert.

Bezüglich Anlernen schlägt beim ersten Mal fehl. Das ist unabhängig von der Anzahl der IODevs. Das passiert auch im ganz kleinen Rahmen.

Im Logfile schlagen sich die Anlernversuche so wieder:

1. Versuch:

2024.11.16 19:26:05 3: CUL_HM set HM_VCCU hmPairForSec 30
2024.11.16 19:26:09 2: autocreate: define HM_7C5AEA CUL_HM 7C5AEA
2024.11.16 19:26:09 3: CUL_HM pair: HM_7C5AEA thermostat, model HM-TC-IT-WM-W-EU serialNr
2024.11.16 19:26:09 3: HMUARTLGW_45BA6F: Unknown code A1A0184007C5AEA0000001400AD554551323230343034365803FFFF::-73:HMUARTLGW_45BA6F, help me!

2. Versuch:

2024.11.16 19:26:15 3: CUL_HM set HM_7C5AEA clear msgEvents
2024.11.16 19:26:15 3: CUL_HM set HM_VCCU hmPairForSec 30
2024.11.16 19:26:20 3: CUL_HM pair: HM_7C5AEA thermostat, model HM-TC-IT-WM-W-EU serialNr UEQ2204046
2024.11.16 19:26:20 3: CUL_HM_assignIO HM_7C5AEA IODev HMUARTLGW_45BA6F rssi -71
2024.11.16 19:26:27 3: CUL_HM set HM_7C5AEA getConfig noArg

Das AC auf dem Thermostat sehe ich erst beim 2. Versuch.

Die CUL_HM_assignIO Log Meldung gibt es im offizieleln FHEM Code noch nicht. Das ist ein Teil eines der Patches, dass das IODev mit der besten rssi auswählt, das ist im offiziellen Code nämlich aktuell leider total kaputt.

Dass die Meldung erst im 2. Versuch auftaucht, bedeutet vermutlich, dass FHEM erst im 2. Versuch Daten Richtung Thermostat sendet.

Danke
Peter

plie80 · 22 November 2024, 13:26:44

Ich habe noch als Ergänung: Wenn das Device in FHEM angelegt ist, klappt, auch nach einem Reset der RT, das Pairing im ersten Anlauf. Das macht den Eindruck, das in FHEM irgendeine Datenstruktur noch nicht angelegt ist, in dem Moment, wo die Message mit dem "Help Me!" auftaucht. Wenn niemand mehr eine spontane Idee dazu hat, dann versuche ich mich mal selbst dran.

frank · 23 November 2024, 12:07:52

ich konnte das verhalten reproduzieren und bekomme auch eine help message, obwohl sie kurz zuvor noch richtig verarbeitet wurde.

Code Auswählen

2024.11.17 12:34:12.166 4: CUL_Parse: cul868 A 1A 13 8400 2060F0 000000 2100394B4551303034313030365800FFFF1B -60.5
2024.11.17 12:34:12.172 5: cul868: dispatch A1A1384002060F00000002100394B4551303034313030365800FFFF::-60.5:cul868
2024.11.17 12:34:12.235 2: autocreate: define HM_2060F0 CUL_HM 2060F0
2024.11.17 12:34:12.287 2: autocreate: define FileLog_HM_2060F0 FileLog %L/HM_2060F0-%Y.log HM_2060F0
2024-11-17 12:34:12.512 Global global UNDEFINED HM_2060F0 CUL_HM 2060F0
2024-11-17 12:34:12.512 Global global DEFINED HM_2060F0
2024-11-17 12:34:12.512 Global global DEFINED FileLog_HM_2060F0
2024-11-17 12:34:12.872 Global global DEFINED HM_2060F0_Weather
2024-11-17 12:34:13.177 Global global DEFINED HM_2060F0_Climate
2024-11-17 12:34:13.480 Global global DEFINED HM_2060F0_WindowRec
2024.11.17 12:34:13.565 3: cul868: Unknown code A1A1384002060F00000002100394B4551303034313030365800FFFF::-60.5:cul868, help me!
2024.11.17 12:34:13.584 0: HMLAN_Parse: hmlan1 R:E2060F0   stat:0000 t:470B1C46 d:FF r:FFCC     m:13 8400 2060F0 000000 2100394B4551303034313030365800FFFF
2024.11.17 12:34:13.909 0: HMUARTLGW hmuart1 recv: 01 05 00 00 40 msg: 13 84 00 2060F0 000000 2100394B4551303034313030365800FFFF

das anlegen der entities beim pairing ist fehlerhaft/unvollständig.
ein fhem restart wird es dann wohl richten.

zb hat das attr IOgrp keine wirkung. es wird einfach ein anderes io genutzt. erst durch nochmaliges setzen des attributes wird es wirksam.

attr actioncycle wurde auch nicht gesetzt.

meine channel haben ausserdem falsche attribute

2x pairen ist aber überflüssig.
die pairing cmds kommen beim ersten pairing auf den stack, aber werden nicht gesendet.
die cmds werden aber bei der zweiten anlernmessage korrekt gesendet, allerdings vom falschen io.
also einfach nochmal das knöpfchen drücken.

plie80 · 24 November 2024, 15:51:05

Hallo Frank,

danke Dir für das Update.
Bezüglich der Nutzung des falschen IO Device, hilft evtl. einer der Bugs, die noch in ioAssign existieren.
Irgendwann ist vermutlich mal die Groß-/Kleinschreibung bei IOGrp geändert worden. Deswegen funktioniert die Auswahl des besten Device (nach RSSI) upstream aktuell nicht. Vielleicht hat das beim Pairing auch eine Auswirkung noch an anderer Stelle. Ich schaue mir den Code dahingehend auch nochmal an und werde die Patches, die ich jetzt seit längerem im Testing habe, mal im Forum posten. Das Pairing Problem lösen sie aber leider nicht.

Hast Du eine Idee, wo man wegen der fehlenden Entities andocken könnte? Am Thermostat nochmal drücken ist schön und gut, aber es wäre ja wünschenswert, wenn es schon beim ersten Mal sauber klappt.

frank · 29 November 2024, 10:45:41

moin,

hier erst einmal ein fix für die seriennummer und für die korrekte funktion des prefered io.

CUL_HM_Parse:
1. prefered io fix

Code Auswählen

          if (   defined($mh{myRSSI})
              && $mh{myRSSI} ne ''
              && $mh{myRSSI} >= -50) { #noansi: on good rssi set prefered, too
            $attr{$sname}{IOgrp} .= ':'.$mh{ioName};
#            my @a = ();#frank:
            my @a = ($mh{ioName});#frank:set also the helper key
            $mh{devH}->{helper}{io}{prefIO} = \@a;
          }

CUL_HM_parseCommon:
2. serialnumber fix:

Code Auswählen

    if ( $hmPair ){# pairing is active
      my $regser = ReadingsVal($mhp->{devN},"D-serialNr",AttrVal($mhp->{devN},'serialNr',''));
      if (!$hmPser || $hmPser eq $regser){
        CUL_HM_infoUpdtDevData($mhp->{devN}, $mhp->{devH}, $mhp->{p}, 1)
                  if (!$modules{CUL_HM}{helper}{hmManualOper});
        $regser = ReadingsVal($mhp->{devN},"D-serialNr",AttrVal($mhp->{devN},'serialNr',''));#frank: now we have the data

3. prefered io fix

Code Auswählen

          if($ioOwn){
            $attr{$mhp->{devN}}{IOgrp} = "$ioOwn:$ioHash->{NAME}";
            my @a = ($ioHash->{NAME});#frank:set also the helper key
            $devHlpr->{io}{prefIO} = \@a;#frank:set also the helper key
          }

ZitatHast Du eine Idee, wo man wegen der fehlenden Entities andocken könnte? Am Thermostat nochmal drücken ist schön und gut, aber es wäre ja wünschenswert, wenn es schon beim ersten Mal sauber klappt.

es fehlen keine entities, sondern die erlaubten attribute der entities sind teilweise falsch.
=> falsches internal ".AttrList"

wenn man nur einmal das knöpfchen drückt, werden die pairing cmds aktuell, je nach fähigkeit des gerätes, gesendet. bei meinem thermostat über wakeup, also sobald es das nächste mal aufwacht. sollte auch beim rt so sein. es wird sogar 3 mal versucht.
das ist natürlich die falsche strategie, weil es darauf nicht reagiert, da es noch nicht gepairt ist.
keine ahnung, warum das extra so eingebaut ist.

die auswahl des io beim pairen sieht aktuell so aus:
es gewinnt das io, dessen empfangene anlernmessage als erstes verarbeitet wird.
und dieses io wird als prefered io im attribut gesetzt.
diese strategie ist bei deinen über 60 ios wahrscheinlich ein glücksspiel.

gruss frank

plie80 · 29 November 2024, 12:16:10

Vielen Dank für deine Bemühungen, ich werde das schnellstmöglich überprüfen und Feedback geben.

Zitat von: frank am 29 November 2024, 10:45:41die auswahl des io beim pairen sieht aktuell so aus:
es gewinnt das io, dessen empfangene anlernmessage als erstes verarbeitet wird.
und dieses io wird als prefered io im attribut gesetzt.
diese strategie ist bei deinen über 60 ios wahrscheinlich ein glücksspiel.

Das feste Setzen eines IOs bei guter RSSI habe ich ehrlich gesagt komplett entfernt, da es in dem Fall, dass man ein Device irgendwo anlernt und dann inrgendwoanders hinträgt genau das falsche tut. Der aktuelle Algorithmus kommt aus der Situation auch nicht mehr heraus, solange das fest eingestellte IO noch online ist (ob es noch funkfähig ist, ist noch eine andere Sache).

Mit den 3 Patches hier on-top läuft die Auswahl des richtigen IOs eigentlich ziemlich gut. Ich hänge die Dir mal an, damit Du eine Idee davon bekommst:

Code Auswählen

diff --git a/10_CUL_HM.pm b/10_CUL_HM.pm
index 8e91a1e..eb69477 100644
--- a/10_CUL_HM.pm
+++ b/10_CUL_HM.pm
@@ -11004,25 +11004,25 @@ sub CUL_HM_assignIO($){ #check and assign IO, returns 1 if IO changed
  
  if ($hh->{io}{vccu}){# second option - any IO from the
    my $iom;
+    my @IOList = split(/,/, AttrVal($hh->{io}{vccu},"IOList",""));
    ($iom) = grep {CUL_HM_operIObyIOName($_)} @{$hh->{io}{prefIO}}  if(!$iom && @{$hh->{io}{prefIO}});
    ($iom) = grep {$_ eq 'none'}              @{$hh->{io}{prefIO}}  if(!$iom && @{$hh->{io}{prefIO}});
    return 0 if $iom && $iom eq 'none';
    if(!$iom){
-      my @ioccu = grep{CUL_HM_operIObyIOName($_)} @{$defs{$hh->{io}{vccu}}{helper}{io}{ioList}};
+      my @ioccu = grep{CUL_HM_operIObyIOName($_)} @IOList;
      ($iom) =    ((sort {@{$hh->{mRssi}{io}{$b}}[0] <=>    # This is the best choice
                            @{$hh->{mRssi}{io}{$a}}[0] } 
                          (grep { defined @{$hh->{mRssi}{io}{$_}}[0]} @ioccu))
                          ,(grep {!defined @{$hh->{mRssi}{io}{$_}}[0]} @ioccu))      if(@ioccu);
-    } 
-    ($iom) = grep{defined $defs{$_}} @{$hh->{io}{prefIO}}                          if(!$iom && @{$hh->{io}{prefIO}});
-    ($iom) = grep{defined $defs{$_}} @{$defs{$hh->{io}{vccu}}{helper}{io}{ioList}}  if(!$iom && @{$defs{$hh->{io}{vccu}}{helper}{io}{ioList}});
+    }
+    ($iom) = grep{defined $defs{$_}} @{$hh->{io}{prefIO}}  if(!$iom && @{$hh->{io}{prefIO}});
+    ($iom) = grep{defined $defs{$_}} @IOList              if(!$iom && @IOList);
    return 0 if ($iom && $iom eq 'none');
    $newIODevH  = $defs{$iom} if($iom);
  }
-  
-  
+
  if (!defined $newIODevH) {# not assigned thru CCU - try normal
-    my $dIo = AttrVal($hash->{NAME},"IODev",""); 
+    my $dIo = AttrVal($hash->{NAME},"IODev","");
    if (CUL_HM_operIObyIOName($dIo)) {
      ; # assign according to reading/attribut
    }
@@ -11056,6 +11056,7 @@ sub CUL_HM_assignIO($){ #check and assign IO, returns 1 if IO changed
          && $hash->{helper}{io}{flgs} & 0x02) { $hash->{helper}{io}{sendWu} = 1;    } #noansi: for CUL
      else                                    { delete($hash->{helper}{io}{sendWu}); }
    }
+    Log3($hash, 3, "CUL_HM_assignIO $hash->{NAME} IODev $newIODevH->{NAME} rssi ".@{$hh->{mRssi}{io}{$newIODevH->{NAME}}}[0]);
    $result = 1;
  }
  else{

Hier oben war wohl das Problem, dass sich die Schreibweise irgendwann mal von ioList zu IOList geändert hat. Seitdem funktionierte das Auswählen des besten IOs nicht mehr.

Code Auswählen

diff --git a/10_CUL_HM.pm b/10_CUL_HM.pm
index 8420b5c..c5e7afd 100644
--- a/10_CUL_HM.pm
+++ b/10_CUL_HM.pm
@@ -1820,13 +1820,13 @@ sub CUL_HM_Parse($$) {#########################################################
        if ($ioOwn) {
          $attr{$sname}{IOgrp} = $ioOwn;
          $mh{devH}->{helper}{io}{vccu} = $ioOwn;
-          if (  defined($mh{myRSSI})
-              && $mh{myRSSI} ne ''
-              && $mh{myRSSI} >= -50) { #noansi: on good rssi set prefered, too
-            $attr{$sname}{IOgrp} .= ':'.$mh{ioName};
-            my @a = ();
-            $mh{devH}->{helper}{io}{prefIO} = \@a;
-          }
+        #if (  defined($mh{myRSSI})
+        #    && $mh{myRSSI} ne ''
+        #    && $mh{myRSSI} >= -50) { #noansi: on good rssi set prefered, too
+        #  $attr{$sname}{IOgrp} .= ':'.$mh{ioName};
+        #  my @a = ();
+        #  $mh{devH}->{helper}{io}{prefIO} = \@a;
+        #}
        }
      }
      else{

Code Auswählen

diff --git a/10_CUL_HM.pm b/10_CUL_HM.pm
index c5e7afd..f07e631 100644
--- a/10_CUL_HM.pm
+++ b/10_CUL_HM.pm
@@ -10968,7 +10968,8 @@ sub CUL_HM_operIObyIOName($){ # noansi: in ioname, return iohash if IO is operat
  return if (  !defined($iohash)
              || defined InternalVal($_[0],'XmitOpen',undef) && InternalVal($_[0],'XmitOpen',0) == 0 # HMLAN/HMUSB/TSCUL
              || ReadingsVal($_[0],'state','disconnected') eq 'disconnected'                        # CUL
-            || IsDummy($_[0])
+            || ReadingsVal($_[0],'loadLvl','') eq 'suspended'                                      # HMUARTLGW
+            || IsDummy($_[0])
              || IsDisabled($_[0])                                                                                                
            );
  return $iohash;

Beim letzten Patch wäre zu überlegen, das I/O schon kurz vor Überlast nicht mehr zu verwenden.

plie80 · 30 November 2024, 17:25:22

eh voila:

Code Auswählen

diff --git a/10_CUL_HM.pm b/10_CUL_HM.pm
index 3a855c2..b936309 100644
--- a/10_CUL_HM.pm
+++ b/10_CUL_HM.pm
@@ -4040,6 +4040,7 @@ sub CUL_HM_parseCommon(@){#####################################################
         delete $mhp->{devH}{READINGS}{"RegL_00."};
         delete $mhp->{devH}{READINGS}{".RegL_00."};
         push @evtEt,[$defs{$ioOwn},1,"hmPair:name:$mhp->{devN} SN:".$regser." model:$attr{$mhp->{devN}}{model}"];
+        $mhp->{md} = $attr{$mhp->{devN}}{model}; #plie80: $mhp->{md} has already been set in CUL_HM_parse before the device data was actually parsed from $mhp->{p}.
         if (!$modules{CUL_HM}{helper}{hmManualOper}){
           if($ioOwn){
             $attr{$mhp->{devN}}{IOgrp} = "$ioOwn:$ioHash->{NAME}";