[cul_hm] falsche io zuweisungen nach fhem restart

[Beta-User]

Hmm, m.E. gute Vorschläge, wobei ich das noch etwas radikaler angehen würde:

Code Auswählen Erweitern

sub CUL_HM_operIObyIOHash($){ # noansi: in iohash, return iohash if IO is operational, else undef
  return if (!defined($_[0]));
  return CUL_HM_operIObyIOName($_[0]->{NAME}); #Beta-User: use shortcut to get simimar behaviour...
}
sub CUL_HM_operIObyIOName($){ # noansi: in ioname, return iohash if IO is operational, else undef
  return if (!$_[0]);
  my $iohash = $defs{$_[0]};
  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])
             || IsDisabled($_[0])
            );
  return $iohash;
}
Ob man das mit XmitOpen so braucht, sei mal dahingestellt, vermutlich hatte der "falsche" Default-Wert den Zweck, die CUL-TYPE Geräte auf billige Art rauszufiltern (regex ist vergleichsweise teuer, daher der obige Vorschlag, der auch etwas "generischer" ist, falls es wider Erwarten neue Geräte/IO-TYPE gäbe...)



Habe gestern noch meine VIRTUALs alle auf CUL-TYPE IOs als preferred umgezogen, das war soweit erkennbar auch "Neustartfest". Vorher war ein Teil beim HMUARTLGW gehangen, der Rest beim CUL, nichts beim Maple

[frank]

hallo beta-user,

mit folgendem anfang meiner CUL_HM_assignIO(), ist preferedIO/none nun wirksam, so dass keine weiteren io mehr gewählt werden. 

das verhalten meines test aktors (fhem device) ist ziehmlich perfekt.
commstate zeigt eine zeitlang pending, dann cmds_done_errors und im state dann sogar IOerr, wodurch das nächste automatische hminfo update das device in die HMinfoTools tabelle pusht.

Code Auswählen Erweitern

sub CUL_HM_assignIO($){ #check and assign IO, returns 1 if IO changed
  # assign IO device
  # only called after init_done
  # prio:
  # 0) no change if transmission is active
  # 1) with vccu check preferred list   as long as operational
  # 2) with vccu check remaining IOs    as long as operational sort by rssi
  # 3) with vccu first preferred        if assinged - unconditional
  # 4) with vccu first any              if defined - unconditional

  # 5) no vccu -> attr IODev            as long as defined (obey user decission)
  # 6) current IO                       as long as defined
  # 7) any IO with client "CUL_HM"      as long as operational
  # 8) any IO with client "CUL_HM"      unconditional
  # no option -

  my $hash = shift;
 
  my $oldIODevH = $hash->{IODev};
  my $hh = $hash->{helper};
  my $iom;
  Log(1,"----- assignio-Test0 ----- => n:$hash->{NAME} ioOld:".(defined($oldIODevH->{NAME})?$oldIODevH->{NAME}:"---")." ioNew:".(defined($iom)?$iom:"---"));

  return 0 if (   (   defined($hh->{prt}{sProc})
                    && $hh->{prt}{sProc} == 1           #don't change while send in process
                    && $oldIODevH                 )     #with an operational IO
                || defined($hh->{aesCommRq})            #don't change while CUL aesCommReq in progress
                || $modules{CUL_HM}{helper}{updateStep} #don't change while a fwupdate is in progress, only IO for update is in 100kbit/s speed
                );
  my $newIODevH;
  Log(1,"----- assignio-Test1 ----- => n:$hash->{NAME} ioOld:".(defined($oldIODevH->{NAME})?$oldIODevH->{NAME}:"---")." ioNew:".(defined($iom)?$iom:"---"));
 
  if ($hh->{io}{vccu}){# second option - any IO from the
    #my $iom;
    ($iom) = grep {CUL_HM_operIObyIOName($_)} @{$hh->{io}{prefIO}}                  if(!$iom && @{$hh->{io}{prefIO}});
    Log(1,"----- assignio-Test2 ----- => n:$hash->{NAME} ioOld:".(defined($oldIODevH->{NAME})?$oldIODevH->{NAME}:"---")." ioNew:".(defined($iom)?$iom:"---"));
    ($iom) = grep {$_ eq 'none'} @{$hh->{io}{prefIO}}                               if(!$iom && @{$hh->{io}{prefIO}});
    Log(1,"----- assignio-Test3 ----- => n:$hash->{NAME} ioOld:".(defined($oldIODevH->{NAME})?$oldIODevH->{NAME}:"---")." ioNew:".(defined($iom)?$iom:"---"));
    return 0 if $iom && $iom eq 'none'; #########
    if(!$iom){
      Log(1,"----- assignio-Test4 ----- => n:$hash->{NAME} ioOld:".(defined($oldIODevH->{NAME})?$oldIODevH->{NAME}:"---")." ioNew:".(defined($iom)?$iom:"---"));
      my @ioccu = grep{CUL_HM_operIObyIOName($_)} @{$defs{$hh->{io}{vccu}}{helper}{io}{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);
      Log(1,"----- assignio-Test5 ----- => n:$hash->{NAME} ioOld:".(defined($oldIODevH->{NAME})?$oldIODevH->{NAME}:"---")." ioNew:".(defined($iom)?$iom:"---"));
    }
    ($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}});
    return 0 if $iom && $iom eq 'none'; #########
    $newIODevH  = $defs{$iom} if($iom);
  }
  Log(1,"----- assignio-Test6 ----- => n:$hash->{NAME} ioOld:".(defined($oldIODevH->{NAME})?$oldIODevH->{NAME}:"---")." ioNew:".(defined($iom)?$iom:"---"));


Code Auswählen Erweitern

2021.10.13 14:46:50.942 3 : CUL_HM set SwitchUP02 on noArg
2021.10.13 14:46:50.994 1 : ----- assignio-Test0 ----- => n:SwitchUP02 ioOld:hmlan1 ioNew:---
2021.10.13 14:46:50.995 1 : ----- assignio-Test1 ----- => n:SwitchUP02 ioOld:hmlan1 ioNew:---
2021.10.13 14:46:50.996 1 : ----- assignio-Test2 ----- => n:SwitchUP02 ioOld:hmlan1 ioNew:hmlan1
2021.10.13 14:46:50.997 1 : ----- assignio-Test3 ----- => n:SwitchUP02 ioOld:hmlan1 ioNew:hmlan1
2021.10.13 14:46:50.998 1 : ----- assignio-Test6 ----- => n:SwitchUP02 ioOld:hmlan1 ioNew:hmlan1
2021.10.13 14:46:51.001 0 : HMLAN_Send:  hmlan1 S:S79B0EFF3 stat:  00 t:00000000 d:01 r:79B0EFF3 m:C9 A011 1ACE1F 285A44 0201C80000
2021.10.13 14:46:51.050 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 27 msg: C9 A0 11 1ACE1F 285A44 0201C80000
2021.10.13 14:46:51.191 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 38 msg: C9 80 02 285A44 1ACE1F 0101C80046
2021.10.13 14:46:51.224 0 : HMLAN_Parse: hmlan1 R:R79B0EFF3 stat:0001 t:129D5091 d:FF r:FFBE     m:C9 8002 285A44 1ACE1F 0101C80046
2021.10.13 14:47:05.616 3 : CUL_HM set SwitchUP02 off noArg
2021.10.13 14:47:05.667 1 : ----- assignio-Test0 ----- => n:SwitchUP02 ioOld:hmlan1 ioNew:---
2021.10.13 14:47:05.668 1 : ----- assignio-Test1 ----- => n:SwitchUP02 ioOld:hmlan1 ioNew:---
2021.10.13 14:47:05.668 1 : ----- assignio-Test2 ----- => n:SwitchUP02 ioOld:hmlan1 ioNew:hmlan1
2021.10.13 14:47:05.669 1 : ----- assignio-Test3 ----- => n:SwitchUP02 ioOld:hmlan1 ioNew:hmlan1
2021.10.13 14:47:05.670 1 : ----- assignio-Test6 ----- => n:SwitchUP02 ioOld:hmlan1 ioNew:hmlan1
2021.10.13 14:47:05.672 0 : HMLAN_Send:  hmlan1 S:S79B12943 stat:  00 t:00000000 d:01 r:79B12943 m:CA A011 1ACE1F 285A44 0201000000
2021.10.13 14:47:05.706 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 27 msg: CA A0 11 1ACE1F 285A44 0201000000
2021.10.13 14:47:05.840 0 : HMLAN_Parse: hmlan1 R:R79B12943 stat:0001 t:129D89E2 d:FF r:FFC4     m:CA 8002 285A44 1ACE1F 0101000046
2021.10.13 14:47:05.914 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 38 msg: CA 80 02 285A44 1ACE1F 0101000046
2021.10.13 14:47:15.225 1 : HMLAN_Parse: hmlan1 new condition disconnected
2021.10.13 14:47:27.147 3 : CUL_HM set SwitchUP02 on noArg
2021.10.13 14:47:27.199 1 : ----- assignio-Test0 ----- => n:SwitchUP02 ioOld:hmlan1 ioNew:---
2021.10.13 14:47:27.201 1 : ----- assignio-Test1 ----- => n:SwitchUP02 ioOld:hmlan1 ioNew:---
2021.10.13 14:47:27.201 1 : ----- assignio-Test2 ----- => n:SwitchUP02 ioOld:hmlan1 ioNew:---
2021.10.13 14:47:27.202 1 : ----- assignio-Test3 ----- => n:SwitchUP02 ioOld:hmlan1 ioNew:none

zuerst set on/off mit funktionierem io (hmlan1), danach set hmlan close mit anschliessendem set on.
=> keine messages werden gesendet.

[Beta-User]

...klingt gut, auch wenn ich mir das im Detail noch in Ruhe ansehen müßte...

Wie wäre denn der Vorschlag zum weiteren Vorgehen? Wir machen wieder eine Art "rolling release candidate" fertig und hoffen zum einen auf Tester und warten zum anderen auf Martin (und noansi), wann er/sie Zeit findet/n, sich das anzusehen?

Eigentlich wäre dein "offene Punkte"-Thread dafür prädestiniert, es kann aber auch wieder einen neuen Thread geben.

Da ich 0 Überblick habe (und das meiste auch nicht verstehe ): die Liste ist aktuell, oder? Vielleicht solltest du so oder so nochmal einen push machen, wenn alles dann halbwegs up to date ist (du scheinst die Liste ja im Lichte des aktuellen svn-updates nochmal durchgegangen zu sein).

[frank]

meine liste ist noch in arbeit und bekommt abschliessend einen push. hab noch nicht alles getestet.

deine oktober patches wurden ja komplett übernommen, oder? der thread könnte ja zu, damit martin nicht durcheinander kommt. dafür einen neuen mit neuen patches und im alten einen link zum neuen.

zur zeit habe ich die patches von hier plus den patch von dort: https://forum.fhem.de/index.php/topic,121650.msg1179090.html#msg1179090.

[Beta-User]

Soweit ich das beurteilen kann, hat Martin so ziemlich alles übernommen, teilweise aber nicht 1:1. Akribisch gegengecheckt habe ich aber nicht.

Danach sind unsere Stände jedenfalls derzeit praktisch gleich und wir könnten dann ggf. auch einfach diesen hier zum "patch-Thread Oktober II" erklären. Den anderen würde ich dann ggf. dazu nutzen, den aktuellen kundzutun und dann erst schließen. Wichtig wäre mAn. nur, dass wir das so machen, dass Martin weiß, wo er denn den jeweils letzten (funktionierenden) Stand findet.

[frank]

bis antwort #24 hier hatte martin die änderungen ebenfalls schon eingearbeitet.

diesen thread zum "allgemeinen" patch-thread zu machen finde ich nicht gut. sonst kommen hier lauter "ich kann mein device auch nicht pairen" posts. 

[Beta-User]

sonst kommen hier lauter "ich kann mein device auch nicht pairen" posts. 

ymmd!

(Es ist doch ganz egal, ob man einen neuen macht oder nicht, diese Art Rückmeldung wird es immer geben, sobald was als "Sammelthread" angesehen wird...)

bis antwort #24 hier hatte martin die änderungen ebenfalls schon eingearbeitet.

Das ist ein gutes Argument dagegen, schon gut...

Werde dann bei Gelegenheit alles in der bekannten Form zusammenpacken und "gerne vorab testen" rufen ...

[Beta-User]

Hier mal der hoffentlich korrekt konsolidierte Stand - läuft erst kurz, aber unauffällig.

Ohne das näher analysiert zu haben, scheinen aber - trotz anderer Priorisierung in der VCCU - relativ wenige Geräte den HMUART verwenden zu wollen. Meine Installation ist aber einfacher, und "none" brauche ich auch nicht.

[frank]

moin beta-user,
deine datei läuft bei mir und enthält wohl auch alles, prima.


ein altes thema ist immer noch aktuell: bei der suche nach ios werden hmlan/hmusb weiterhin an 3 stellen nicht gefunden!



1. zeilen 1008 und 10895 finden jeweils nur cul und hmuart.
scheinbar hat noch niemand mit hmlan/hmusb und ohne vccu die neue cul_hm getestet.

getestet in der fhem eingabezeile mit:

Code Auswählen Erweitern

{join(",",devspec2array('Clients=.*:CUL_HM:.*'))}

angelehnt an martins code habe ich nun zeile 1008 geändert zu:

Code Auswählen Erweitern

        my @IOnames = grep {InternalVal($_,"Clients",
                            defined $modules{InternalVal($_,"TYPE","")}{Clients}
                            ? $modules{InternalVal($_,"TYPE","")}{Clients}
                            : "") =~ m /:CUL_HM:/} keys %defs;

und zeile 10895 zu:

Code Auswählen Erweitern

      my @IOs = grep {InternalVal($_,"Clients",
                      defined $modules{InternalVal($_,"TYPE","")}{Clients}
                      ? $modules{InternalVal($_,"TYPE","")}{Clients}
                      : "") =~ m /:CUL_HM:/} keys %defs;




2. ebenso um zeile 7273 findet auch der cmd "set vccu assignIO über grep{$defs{$_}{Clients} =~ m/:CUL_HM:/} keys %defs)} kein hmlan/hmusb. assignIO hat vermutlich noch nie jemand benutzt, denn

- es erzeugt "millonen" warnings und findet nur cul und hmuart

Code Auswählen Erweitern

2021.10.15 09:49:53.961 1 : PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/10_CUL_HM.pm line 7373.
2021.10.15 09:49:53.961 1 : stacktrace:
2021.10.15 09:49:53.962 1 :     main::__ANON__                      called by ./FHEM/10_CUL_HM.pm (7373)
2021.10.15 09:49:53.962 1 :     main::CUL_HM_Set                    called by fhem.pl (3889)
2021.10.15 09:49:53.963 1 :     main::CallFn                        called by fhem.pl (1938)
2021.10.15 09:49:53.964 1 :     main::DoSet                         called by fhem.pl (1970)
2021.10.15 09:49:53.964 1 :     main::CommandSet                    called by fhem.pl (1265)
2021.10.15 09:49:53.965 1 :     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2773)
2021.10.15 09:49:53.965 1 :     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (1006)
2021.10.15 09:49:53.966 1 :     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (598)
2021.10.15 09:49:53.967 1 :     main::FW_Read                       called by fhem.pl (3894)
2021.10.15 09:49:53.967 1 :     main::CallFn                        called by fhem.pl (773)
das könnte man lösen durch:

Code Auswählen Erweitern

grep{defined($defs{$_}{Clients}) && $defs{$_}{Clients} =~ m/:CUL_HM:/} keys %defs
gefunden wird dadurch natürlich weiterhin kein hmlan.

- es erzeugt zudem ein warning wegen falschem match operator

Code Auswählen Erweitern

2021.10.15 09:49:53.952 1 : PERL WARNING: Argument "set" isn't numeric in numeric ne (!=) at ./FHEM/10_CUL_HM.pm line 7371.
2021.10.15 09:49:53.953 1 : stacktrace:
2021.10.15 09:49:53.954 1 :     main::__ANON__                      called by ./FHEM/10_CUL_HM.pm (7371)
2021.10.15 09:49:53.954 1 :     main::CUL_HM_Set                    called by fhem.pl (3889)
2021.10.15 09:49:53.955 1 :     main::CallFn                        called by fhem.pl (1938)
2021.10.15 09:49:53.956 1 :     main::DoSet                         called by fhem.pl (1970)
2021.10.15 09:49:53.956 1 :     main::CommandSet                    called by fhem.pl (1265)
2021.10.15 09:49:53.957 1 :     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2773)
2021.10.15 09:49:53.957 1 :     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (1006)
2021.10.15 09:49:53.958 1 :     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (598)
2021.10.15 09:49:53.959 1 :     main::FW_Read                       called by fhem.pl (3894)
2021.10.15 09:49:53.959 1 :     main::CallFn                        called by fhem.pl (773)

- ausserdem muss die logik des if negiert sein, damit die gefundenen io auch genutzt werden können.
- eine info in der commandref wäre sicherlich auch ganz nützlich


durch die folgenden änderungen der 2 return befehle kann ich das cmd nun fehlerfrei nutzen:

Code Auswählen Erweitern

    return "$io not suitable for CUL_HM" if(!scalar(grep{$_ eq $io}
                                                    grep {InternalVal($_,"Clients",
                                                          defined $modules{InternalVal($_,"TYPE","")}{Clients}
                                                          ? $modules{InternalVal($_,"TYPE","")}{Clients}
                                                          :"") =~ m /:CUL_HM:/} keys %defs));




-----------------------------

Ohne das näher analysiert zu haben, scheinen aber - trotz anderer Priorisierung in der VCCU - relativ wenige Geräte den HMUART verwenden zu wollen. Meine Installation ist aber einfacher, und "none" brauche ich auch nicht.

das liegt an einer mischung aus

ein paar "zufällige" abhängigkeiten:
- hardware/anbindung aller vorhandenen io
- reihenfolge der definitionen in fhem.cfg
- reihenfolge der io in "attr vccu IOList"
- zeitpunkt, wann ein io definiert ist
- zeitpunkt, wann ein io operabel ist
- zeitpunkt, wann ein io den ersten rssi ermittelt hat
- zeitpunkt, wann fhem die erste msg an ein device sendet (zb automatische statusrequest)

zu aller letzt ist entscheidend, wann man dann zb mit "get vccu listDevices" nach fhem restart die io verteilung anschaut.

bei mir ist der cul bereits vor dem ersten define der vccu operabel.
als nächstes ist der hmlan operabel, zur zeit vor dem ersten automatischen statusrequest
der hmuart braucht am längsten.

[Beta-User]

Wow, klingt einleuchtend. Hab's mal auf die Schnelle eingearbeitet und auch commandref+Logik zu assignIO entsprechend meinem Verständnis geändert.
Ist nur kurz im Testsystem angetestet, und die fraglichen Stellen sind auch nicht die, die ich im Hauptsystem nutze. Von daher kann ein kritischer Blick vorab nicht schaden, weil mir dann auch mind. noch eine andere Kleinigkeit nebenbei aufgefallen ist.

[frank]

warum hast du 'none' wieder ausgebaut?

[Beta-User]

Ups, vermutlich die falsche Basisversion erwischt... Sorry, update EDIT: ist im Anhang.

https://forum.fhem.de/index.php/topic,120856.msg1179854.html#msg1179854 muss ich mir erst ansehen, dann baue ich die Teile ggf. auch gleich in HMinfo ein.

EDIT: Patches - auch zu HMinfo - sind jetzt konsolidiert in https://forum.fhem.de/index.php/topic,123436.0.html zu finden.