[cul_hm] falsche io zuweisungen nach fhem restart

[frank]

zusätzlich passt die io präparation beim hmlan nicht zur liste listDevices der ccu. beim start behält er die prep von vor dem start, im internal iodev steht der cul bis zur ersten msg.

mit deiner nightly version scheint das problem behoben zu sein, da hmlan und hmuart nun wieder nach restart komplett präpariert werden. zumindestens zeigt es fhem.log.

getconfig auf 2 thermostate mit cul/hmlan liefen wie gewohnt sauber durch.

noch keine negativen auffälligkeiten. 
ich denke, die version sollte dancatt probieren.

[Beta-User]

  ... denn sie wissen nicht, was sie tun...

OK, der Reihe nach: Ich habe versucht zu verstehen, was da in dem IODev-Handling-Thread diskutiert wurde, und muss zugeben, dass da sehr viel drinsteht, von dem ich 0 (in Worten: NULL) Plan habe, und mir war auch nicht mehr klar, wie da teils die Gemütslage war... Na ja, Schwamm drüber, dann versuchen wir uns mal ans Aufräumen zu machen, denn das "Coding" ist ja teils wild.

Der Haupt-Trick scheint gewesen zu sein, die NotifyFn-Prio zu erhöhen, das geht in die Richtung der Anforderung von Martin, eine gesonderte "Preparation-done"-Fn haben zu wollen, das ganze verbunden damit, erst zu senden (aus den VIRTUALs), wenn timer abgearbeitet werden. Puh, scheinbar Glück gehabt (und die dankenswerterweise erfolgten Rückmeldungen der diversen freiwilligen und unfreiwilligen Tester wohl zutreffend interpretiert)...

Was ggf. noch eine Test wert wäre, wäre tatsächlich (das ungeliebte) Reading auszuwerten (ab #235):

Code Auswählen Erweitern

    for (@hmdev){
      $defs{$_}->{helper}{io}{restoredIO} = ReadingsVal($_,'IODev',undef) if ReadingsVal($_,'IODev',undef); #Beta-User: try to keep startup info somewhere
      if ( defined $attr{$_}{IODev} ) {


Vielleicht magst du das noch testen, es könnte aber sein, dass das "falsch" ist, wenn/weil AssignIoPort() über die Attributauswertung (vorher schon) "nachgesetzt" hatte und wir daher zu spät kommen.

Ansonsten wäre die Frage, wie dancatt die Info bekommt, und wer den Code-Mist dann wieder aufräumt....

[frank]

immer langsam.

vorhin habe ich nur davon gesprochen, dass die präparation der eq3 io (hmlan/hmuart) jetzt vermutlich von anfang an synchron ist mit dem internal IODev.

das bedeutet aber noch lange nicht, dass die aktuelle zuordung (internal IODev) der io dem entspricht, was unter IOgrp/prefered eingestellt ist. jetzt werden dem hmlan beim initialisieren sämtliche devices zunächst "entzogen" ("I:-", unassigned), da bis zu diesem zeitpunkt dem hmlan scheinbar kein einziges device zugeordnet wurde.
zu diesem zeitpunkt vermute ich bei allen devices den cul im internal IODev.

Code Auswählen Erweitern

2021.10.08 12:26:47.230 1: CUL_HM start inital cleanup
2021.10.08 12:26:52.183 1: CUL_HM finished initial cleanup
2021.10.08 12:26:52.266 3: HMinfo hminfo get:loadConfig :
2021.10.08 12:26:52.853 3: HMinfo hminfo get:configCheck :
2021.10.08 12:26:54.459 3: Opening SqueezeBoxServer device 192.168.1.10:9090
2021.10.08 12:26:57.464 1: SqueezeBoxServer: Can't connect to 192.168.1.10:9090: Connection timed out
2021.10.08 12:26:57.540 3: SB_SERVER_Notify(SqueezeBoxServer): DISCONNECTED - STATE: disconnected power: ?
2021.10.08 12:26:57.560 0: HMCCU: Start of RPC server after FHEM initialization in 12 seconds
2021.10.08 12:26:57.578 0: HMLAN_Send:  hmlan1 I:Y01,00,
2021.10.08 12:26:57.579 0: HMLAN_Send:  hmlan1 I:Y02,00,
2021.10.08 12:26:57.580 0: HMLAN_Send:  hmlan1 I:Y03,00,
2021.10.08 12:26:57.581 3: Opening hmuart1 device /dev/ttyAMA0
2021.10.08 12:26:57.583 3: Setting hmuart1 serial parameters to 115200,8,N,1
2021.10.08 12:26:57.587 3: hmuart1 device opened
2021.10.08 12:26:57.741 3: cul433 IT_set: IT09 on
2021.10.08 12:26:58.494 0: Featurelevel: 6
2021.10.08 12:26:58.495 0: Server started with 524 defined entities (fhem.pl:24776/2021-07-19 perl:5.028001 os:linux user:fhem pid:12019)
2021.10.08 12:26:59.185 0: HMLAN_Send:  hmlan1 I:-1F64D8
2021.10.08 12:26:59.187 0: HMLAN_Send:  hmlan1 I:-1C1BE3
2021.10.08 12:26:59.188 0: HMLAN_Send:  hmlan1 I:-52C4DF
2021.10.08 12:26:59.190 0: HMLAN_Send:  hmlan1 I:-52BB90
2021.10.08 12:26:59.192 0: HMLAN_Send:  hmlan1 I:-52BB9D
2021.10.08 12:26:59.193 0: HMLAN_Send:  hmlan1 I:-24AF1D
2021.10.08 12:26:59.195 0: HMLAN_Send:  hmlan1 I:-266EA5
2021.10.08 12:26:59.197 0: HMLAN_Send:  hmlan1 I:-25E38E
2021.10.08 12:26:59.198 0: HMLAN_Send:  hmlan1 I:-1A164B
2021.10.08 12:26:59.200 0: HMLAN_Send:  hmlan1 I:-3913D3
2021.10.08 12:26:59.202 0: HMLAN_Send:  hmlan1 I:-285A54
2021.10.08 12:26:59.203 0: HMLAN_Send:  hmlan1 I:-285A44
2021.10.08 12:26:59.205 0: HMLAN_Send:  hmlan1 I:-206278
2021.10.08 12:26:59.206 0: HMLAN_Send:  hmlan1 I:-1936FF
2021.10.08 12:26:59.208 0: HMLAN_Send:  hmlan1 I:-206487
2021.10.08 12:26:59.210 0: HMLAN_Send:  hmlan1 I:-2064CB
2021.10.08 12:26:59.212 0: HMLAN_Send:  hmlan1 I:-206219
2021.10.08 12:26:59.213 0: HMLAN_Send:  hmlan1 I:-1D252E
2021.10.08 12:26:59.215 0: HMLAN_Send:  hmlan1 I:-20DFE1
2021.10.08 12:26:59.217 0: HMLAN_Send:  hmlan1 I:-1DFDA5
2021.10.08 12:26:59.219 0: HMLAN_Send:  hmlan1 I:-1BF81B
2021.10.08 12:26:59.220 0: HMLAN_Send:  hmlan1 I:-1DE620
2021.10.08 12:26:59.222 0: HMLAN_Send:  hmlan1 I:-1DF7C6
2021.10.08 12:26:59.224 0: HMLAN_Send:  hmlan1 I:-1C4E25
2021.10.08 12:26:59.225 0: HMLAN_Send:  hmlan1 I:-1F91AA
2021.10.08 12:26:59.227 0: HMLAN_Send:  hmlan1 I:-193A9A
2021.10.08 12:26:59.229 0: HMLAN_Send:  hmlan1 I:-1BFC52
2021.10.08 12:26:59.230 0: HMLAN_Send:  hmlan1 I:-1DFC2F
2021.10.08 12:26:59.232 0: HMLAN_Send:  hmlan1 I:-1CE9F5
2021.10.08 12:26:59.234 0: HMLAN_Send:  hmlan1 I:-6869B6


die explizit gewünschte zuordnung gemäss attr IOgrp/prefered wird weiterhin erst durch messages an die devices nach und nach quasi zufällig hergestellt, ggf nie.

Code Auswählen Erweitern

2021.10.08 12:27:00.970 3: CUL_HM set Thermostat.OZ_Climate statusRequest noArg
2021.10.08 12:27:00.973 0: HMLAN_Send:  hmlan1 I:+20DFE1,02,00,00

[Beta-User]

...die Frage ist vermutlich doof (oder ketzerisch), aber was ist schädlich daran, wenn die Zuordnung erst beim ersten Senden gemacht wird?

Mal abgesehen von einem gewissen wear-out des EEPROM (falls das IO keinen volatilen Speicher für sowas hat) zur Speicherung/dem Löschen dieser Infos macht es für das Empfangen erst mal keinen Unterschied, wer diese Art Info an ParseFn weitergibt. Das hilft ggf. sogar erst mal um festzustellen, wie die aktuelle sendetechnische Landschaft so aussieht (RSSI-Werte sammeln und auswerten). Allenfalls für das Versenden von rechtzeitigen Acks könnte das ein Problem darstellen, wobei das dann auch nur (jeweils einmalig) eine etwas längere Empfangsbereitschaft (Batteriekapazität) der empfangenden Geräte bedeutet, oder?
Ansonsten ist es doch ausreichend, wenn die Landschaft erst nach und nach wieder (dynamisch) aufgebaut wird.

Oder gibt es prinzipielle Probleme bei der Auswahl nach den Prio-Listen (Device/VCCU)?

(Sorry, ich bin eigentlich nicht tief genug in dieser ganzen Materie drin).

[frank]

genau, IOgrp legt nur das io zum senden fest.

...die Frage ist vermutlich doof (oder ketzerisch), aber was ist schädlich daran, wenn die Zuordnung erst beim ersten Senden gemacht wird?

was ist eigentlich schädlich daran, immer sofort das richtige zu tun?
vor allem wenn man direkt angegeben hat, was das richtige ist.

du rennst doch sicherlich auch nicht immer zunächst gegen die tür und machst dann erst im nächsten versuch die tür vorher auf. 

[Beta-User]

Hmm, weiß nicht recht, na jedenfalls:

wenn ich das Log richtig deute, ist das Problem, dass HMLAN eigentlich irgendwie weiß, welche Devices bei ihm gemeldet waren. Ich unterstelle, dass die I-Geräte nur ein Teil sind und genau die erst mal abgemeldet sind. Man könnte also genausogut erst mal checken, ob die Tür schon offen ist (also die Devices am HMLAN gemeldet sind), und ob das erwünscht ist (also das zu prefIO paßt). Ich unterstelle mal, dass der Mechanismus prinzipiell derselbe ist wie die verbliebene Abfrage bei TSCUL. Soweit korrekt?
Falls du auch einen TSCUL hast: Dazu steht ja nichts im Log. Es wäre daher naheliegend, die Anfrage beim HMLAN dann zumindest testweise auch da noch reinzuknödeln? Wenn ich das richtig im Kopf habe, wird da ja für TSCUL auch nur ein restoredIO-Eintrag erzeugt. Werde mich aber vermutlich nicht vor Anfang kommender Woche damit befassen können und kann auch nichts testen - vielleicht magst du das angehen...?

[frank]

- klar kennt der hmlan "seine" assignten devices, so lange fhem sie nicht àndert.
- die "I:-" einträge behandelt alle existierenden, realen devices. das hast du gerade eingebaut. vorher wurde nichts getan.
das hat wohl dazu geführt, dass mindestens einmal bei hmlan und hmuart jeweils das selbe device assignt war. alle 3min wurde das device autonom angefunkt.
- auslesen ist scheinbar nicht möglich/bekannt?
- eigene listen im hash sind nach restart leer.
- ich habe nur einen cul kein tscul. der wird gar nicht präpariert, das ist auch wunderbar so.

als attr IODev noch existierte, hat es scheinbar dafür gesorgt, dass dieser eintrag nach restart auch sicher gesetzt wurde.

[Beta-User]

Die IODev-Reading-Auswertung atttest du nicht testweise eingebaut, oder?

[frank]

nein, noch nicht.

[frank]

ich beobachte nun erst mal martins neue versionen.
das verhalten ist besser, wieder anders, mal schauen.

[frank]

erste erfahrungen:

1. attr IOgrp option none
kann man nun setzen und hash wird immer entsprechend gefüllt.
ausschluss von io weiterhin nicht möglich. siehe oben.

2. zuweisung der io nach restart
reale devices erhalten nun regelmässig nach IOgrp/prefered ein io zugewiesen. (eventuell wegen iodev reading?)

bei virtuellen devices scheint es einen unterschied zu geben. sieht mehr nach regelmässigem zufall aus.

[Beta-User]

ich beobachte nun erst mal martins neue versionen.
das verhalten ist besser, wieder anders, mal schauen.

Nur zur Sicherheit: Im Moment gehe ich mal davon aus, dass du dich meldest, wenn noch Bedarf für weitere Lösungsfindung besteht.

ad:

erste erfahrungen:

1. attr IOgrp option none
kann man nun setzen und hash wird immer entsprechend gefüllt.
ausschluss von io weiterhin nicht möglich. siehe oben.

Ich gehe nach dem Code davon aus, dass nach der neuen Logik immer ein IO festgelegt werden muss. Sonst müßte man konsequenter Weise dsa Device dann auch auf dummy o. disabled setzen. Problem bleibt dann aber, dass die Doku nicht zum Verhalten paßt.

2. zuweisung der io nach restart
reale devices erhalten nun regelmässig nach IOgrp/prefered ein io zugewiesen. (eventuell wegen iodev reading?)

Vermute auch: wg. des Readings. Das ist die interne Funktionalität von AssignIO.

bei virtuellen devices scheint es einen unterschied zu geben. sieht mehr nach regelmässigem zufall aus.

Soweit bin ich noch nicht, aber in dem Zusammenhang eine Rückfrage: Ich habe eine ganze Reihe virtueller Devices/Kanäle und zwei CUL-TYPE IO und einen HMUARTLGW. Irgendwo war zu lesen, dass VIRTUALs und HMUARTLGW nicht so gut zusammenpassen. Ergo scheint die Empfehlung daher zu sein, die VIRTUALS den beiden CUL-TYPE als IO zuzuweisen (je nachdem, wer näher dran ist).
Zumindest in https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU fehlt dazu jedoch bisher ein Hinweis - da habe ich aber grade diverse Änderungen betr. IODev-Löschung eingefügt (wäre nett, wenn noch ein Wissender drübersehen würde). Falls zutreffend: Besser aufgehoben wäre es wohl in https://wiki.fhem.de/wiki/HomeMatic#Besondere_Entities, denn bei der VCCU geht es ja eigentlich eher um die Steuerung der Kommunikation zu echter Hardware (?).

PS: Ist eigentlich noch was offen von deiner langen Liste?

[frank]

Ich gehe nach dem Code davon aus, dass nach der neuen Logik immer ein IO festgelegt werden muss. Sonst müßte man konsequenter Weise dsa Device dann auch auf dummy o. disabled setzen. Problem bleibt dann aber, dass die Doku nicht zum Verhalten paßt.

ein io soll ja auch weiterhin zugeordnet bleiben, aber keins, das durch IOgrp/none ausgeschlossen wurde.
wenn zb nur eins erlaubt ist, muss man gar nicht erst versuchen, ein anderes zu finden. ist das io nicht operabel, wird eben nichts gesendet. das ist ja schliesslich auch der sinn. darum gibt es ja "none" => kein weiteres io, ausser den prefererd io.
stell dir vor, du hast ein einzelnes device am ende deiner ranch, das nur mit einem io kommunizieren kann, welches in unmittelbarer nähe positioniert ist. es ist doch dann völlig sinnlos ios zum senden an das device zu nötigen, die vielleicht 1km entfernt sind. im ungünstigsten fall geht das "sinnlose" io dadurch in overload und legt somit das restliche system lahm.

Vermute auch: wg. des Readings. Das ist die interne Funktionalität von AssignIO.

einige test haben das bereits wiederlegt.
egal was vorher war, nach restart bekomme ich immer die selbe zuordnung.
reale devices gemäss IOgrp, virtuelle devices nach "geheimer" regel.

Ich habe eine ganze Reihe virtueller Devices/Kanäle und zwei CUL-TYPE IO und einen HMUARTLGW. Irgendwo war zu lesen, dass VIRTUALs und HMUARTLGW nicht so gut zusammenpassen. Ergo scheint die Empfehlung daher zu sein, die VIRTUALS den beiden CUL-TYPE als IO zuzuweisen (je nachdem, wer näher dran ist).

ein problem taucht dann auf, wenn ein device eine msg an ein virtuelles device (mit eigener hmid) sendet, die den hmuart nötigt zu antworten. der hmuart kann nicht im namen dieser hmid (autonome) ACKs senden, weswegen dann im log folgender hinweis erscheint.

Code Auswählen Erweitern

2021.05.23 09:45:39.114 0: HMUARTLGW hmuart1: Can't send ACK not originating from my hmId (firmware bug), please use a VCCU virtual device!
das problem existiert also nur in bestimmten situationen und die auswirkungen sind sicherlich vom jeweiligen device abhängig. bei der kombi vd/vtc immer dann, wenn der vd konfiguriert wurde. da keine ACKs an den vd gesendet werden, wiederholt er dann sein anliegen permanent, wodurch unnötiger traffic entsteht, was wiederum auf die batterielebensdauer auswirkungen hat.

[Beta-User]

ein io soll ja auch weiterhin zugeordnet bleiben, aber keins, das durch IOgrp/none ausgeschlossen wurde.

Also ist das in der commandref beschriebene Verhalten das erwünschte.
Die IO-Zuweisung bei vccu ist nach meinem Verständnis in dem if-Pfad ab ~#10867 zu verorten. Da könnte uU. ein "jetzt geht es nicht" am Ende helfen? Dazu gleich noch testweise die Auswertung des Readings im darauffolgenden Zweig:

Code Auswählen Erweitern


    $newIODevH  = $defs{$iom} if($iom);
    return 0 if $iom && $iom eq 'none';
  }
 
 
  if (!defined $newIODevH) {# not assigned thru CCU - try normal
    my $dIo = AttrVal($hash->{NAME},"IODev",ReadingsVal($hash->{NAME},'IODev',''));
(mir ist schon klar, was damit grundsätzlich bezweckt wird, und danke für die Erläuterung. Das macht klar, dass das Entfallen des features wohl auch keine Absicht ist.

einige test haben das bereits wiederlegt.

Mir war nicht klar, dass sich das bereits auf die neue Version bezogen hatte.

egal was vorher war, nach restart bekomme ich immer die selbe zuordnung.
reale devices gemäss IOgrp, virtuelle devices nach "geheimer" regel.

IOgrp ist ja erst mal gut, als "geheime Regel" könnte "letztes in der cfg stehendes" in Frage kommen (so geht AssignIOPort vor, wenn ich das richtig im Kopf habe)?
Wobei man sich fragt, warum da nicht auch die allgemeinen preferred-Vorgaben aus einer vermutlich vorhandenen VCCU verwendet werden.
Aber warum bekommen die VIRTUALs eine Sonderbehandlung? Gut, die senden nur von intern, aber wenn da mal was festgelegt wurde (und sei es durch IOgrp), dann sollte das doch durchschlagen? Jedenfalls bisher ist mir beim Drüberfliegen über den Code auch nichts aufgefallen, was das "speziell" sein soll.

Code Auswählen Erweitern

2021.05.23 09:45:39.114 0: HMUARTLGW hmuart1: Can't send ACK not originating from my hmId (firmware bug), please use a VCCU virtual device!

Hatte ich bisher noch nicht bewußt wahrgenommen, aber wenn, müßte das auch ein Problem sein, wenn man virtuelle Fensterkontakte gepeert hat. Die dürften ein ACK anfordern, oder?
Muss aber mal schauen, auf welchem IO die jetzt gelandet sind...

[frank]

moin,
zunächst mal folgendes:

die 2 funktionen CUL_HM_operIObyIOHash/CUL_HM_operIObyIOName sind nicht ganz korrekt, denke ich.

1. beide sollten die selben kriterien prüfen, also auch beide IsDisabled, oder?
2. die IsDisabled/IsDummy prüfung in CUL_HM_operIObyIOName ist doch falsch geklammert, oder kapiere ich das nicht?
3. der defaultwert von InternalVal($ioname,'XmitOpen',1) muss doch eigentlich 0 sein, damit zb ein hmlan ohne das internal auch als nicht operabel gilt. eventuell kann dieser fall nicht vorkommen, aber ist das wirklich sicher?
4. die prüfungen xmitopen/disconnected sollen doch laut kommentar abhängig vom io type erfolgen. sie werden aber immer für beide durchgeführt. die disconnected prüfung für hmlan sollte aber zumindestens nicht stören.

ich habe die funktionen bei mir jetzt mal so eingebaut:

Code Auswählen Erweitern

sub CUL_HM_operIObyIOHash($){ # noansi: in iohash, return iohash if IO is operational, else undef
  return if (!defined($_[0]));
  my $ioname = $_[0]->{NAME};
  return if (   !$ioname
             || $_[0]->{TYPE} =~ m/^(HMLAN|HMUARTLGW|TSCUL)$/ && InternalVal($ioname,'XmitOpen',0) == 0 # HMLAN/HMUSB/TSCUL
             || ReadingsVal($ioname,'state','disconnected') eq 'disconnected' # CUL
             || IsDummy($ioname)
             || IsDisabled($ioname)                                                                                               
            );
  return $_[0];
}
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)
             || $iohash->{TYPE} =~ m/^(HMLAN|HMUARTLGW|TSCUL)$/ && InternalVal($_[0],'XmitOpen',0) == 0 # HMLAN/HMUSB/TSCUL
             || ReadingsVal($_[0],'state','disconnected') eq 'disconnected' # CUL
             || IsDummy($_[0])
             || IsDisabled($_[0])                                                                                               
            );
  return $iohash;
}



5. zusätzlich habe ich noch in zeile 234 den actiondetector rausgefiltert, da dieser sonst unnötigerweise ein io bekommt, was später wieder entfernt wird.

Code Auswählen Erweitern

    my @hmdev = devspec2array("TYPE=CUL_HM:FILTER=DEF=......:FILTER=DEF!=000000");   # devices only



6. die folgenden 2 zeilen in cul_hm_updateconfig habe ich getauscht, da das setzen von IOList ebenfalls, aber eine andere auswirkung auf das io zeigt, als IOgrp. so gewinnt wenigstens IOgrp.

Code Auswählen Erweitern

        CUL_HM_Attr('set',$name,'IOList',AttrVal($name,'IOList','')) if AttrVal($name,'IOList',undef); #Beta-User: Fix missing io->ioList in VCCU at startup, https://forum.fhem.de/index.php/topic,122848.msg1174047.html#msg1174047
        CUL_HM_Attr("set",$name,"IOgrp",$IOgrp);

7. auch mit deinen 2 änderungen aus deinem letzten post bleibt es insgesamt noch eine wundertüte.