[gelöst] keine kommunikation zwischen vd und virtuellem tc nach fhem restart

[Beta-User]

  Hmm, dann legen wir diese Idee mal besser zur Seite...

Wo kommt eigentlich die "Salve" vor "initial cleanup" her:

Code Auswählen Erweitern

2021.09.29 20:47:50.868 3: set VentilControler.Bad_Btn1 valvePos 32 : Unknown argument valvePos, choose one of press getRegRaw regSet clear:msgErrors,noArg,readings,trigger,register,oldRegs,rssi,msgEvents,attack,all regBulk peerBulk peerSmart:DimPBU01_Dim,DimPBU01_Dim_V_01,DimPBU01_Dim_V_02,DimUP01,Fenster.Bad,SD.AZ,SD.SZ,SD.WZ,SDTeam_Btn1,SwitchES01_SenF,SwitchES01_SenI,SwitchES01_SenPwr,SwitchES01_SenU,SwitchES01_Sw,SwitchPBU01_Btn_01,SwitchPBU01_Btn_02,SwitchPBU01_Sw_01,SwitchPBU01_Sw_02,SwitchPBU03,SwitchPBU05,SwitchPBU06,SwitchUP01,SwitchUP02,Tuer.SZ,Tuer.WZ.Terrasse,VentilControler.AZ.Nord_Btn1,VentilControler.AZ.West_Btn1,VentilControler.Kueche_Btn1,VentilControler.SZ_Btn1,VentilControler.WZ_Btn1,ccu_Btn1,rssi_hmuart_Btn1,virtAktorAlarmOff_Btn1 postEvent:slider,0,1,255 getConfig:noArg peerChan
2021.09.29 20:47:51.022 3: set VentilControler.Kueche_Btn1 valvePos 91 : Unknown argument valvePos, choose one of press getRegRaw regSet clear:msgErrors,noArg,readings,trigger,register,oldRegs,rssi,msgEvents,attack,all peerSmart:DimPBU01_Dim,DimPBU01_Dim_V_01,DimPBU01_Dim_V_02,DimUP01,Fenster.Bad,SD.AZ,SD.SZ,SD.WZ,SDTeam_Btn1,SwitchES01_SenF,SwitchES01_SenI,SwitchES01_SenPwr,SwitchES01_SenU,SwitchES01_Sw,SwitchPBU01_Btn_01,SwitchPBU01_Btn_02,SwitchPBU01_Sw_01,SwitchPBU01_Sw_02,SwitchPBU03,SwitchPBU05,SwitchPBU06,SwitchUP01,SwitchUP02,Tuer.SZ,Tuer.WZ.Terrasse,VentilControler.AZ.Nord_Btn1,VentilControler.AZ.West_Btn1,VentilControler.Bad_Btn1,VentilControler.SZ_Btn1,VentilControler.WZ_Btn1,ccu_Btn1,rssi_hmuart_Btn1,virtAktorAlarmOff_Btn1 postEvent:slider,0,1,255 regBulk peerBulk getConfig:noArg peerChan
2021.09.29 20:47:51.083 3: set VentilControler.WZ_Btn1 valvePos 0 : Unknown argument valvePos, choose one of clear:msgErrors,noArg,readings,trigger,register,oldRegs,rssi,msgEvents,attack,all regSet press getRegRaw getConfig:noArg peerChan regBulk peerBulk peerSmart:DimPBU01_Dim,DimPBU01_Dim_V_01,DimPBU01_Dim_V_02,DimUP01,Fenster.Bad,SD.AZ,SD.SZ,SD.WZ,SDTeam_Btn1,SwitchES01_SenF,SwitchES01_SenI,SwitchES01_SenPwr,SwitchES01_SenU,SwitchES01_Sw,SwitchPBU01_Btn_01,SwitchPBU01_Btn_02,SwitchPBU01_Sw_01,SwitchPBU01_Sw_02,SwitchPBU03,SwitchPBU05,SwitchPBU06,SwitchUP01,SwitchUP02,Tuer.SZ,Tuer.WZ.Terrasse,VentilControler.AZ.Nord_Btn1,VentilControler.AZ.West_Btn1,VentilControler.Bad_Btn1,VentilControler.Kueche_Btn1,VentilControler.SZ_Btn1,ccu_Btn1,rssi_hmuart_Btn1,virtAktorAlarmOff_Btn1 postEvent:slider,0,1,255
2021.09.29 20:47:51.122 3: set VentilControler.AZ.Nord_Btn1 valvePos 0 : Unknown argument valvePos, choose one of regSet clear:msgErrors,noArg,readings,trigger,register,oldRegs,rssi,msgEvents,attack,all press getRegRaw getConfig:noArg peerChan regBulk peerBulk peerSmart:DimPBU01_Dim,DimPBU01_Dim_V_01,DimPBU01_Dim_V_02,DimUP01,Fenster.Bad,SD.AZ,SD.SZ,SD.WZ,SDTeam_Btn1,SwitchES01_SenF,SwitchES01_SenI,SwitchES01_SenPwr,SwitchES01_SenU,SwitchES01_Sw,SwitchPBU01_Btn_01,SwitchPBU01_Btn_02,SwitchPBU01_Sw_01,SwitchPBU01_Sw_02,SwitchPBU03,SwitchPBU05,SwitchPBU06,SwitchUP01,SwitchUP02,Tuer.SZ,Tuer.WZ.Terrasse,VentilControler.AZ.West_Btn1,VentilControler.Bad_Btn1,VentilControler.Kueche_Btn1,VentilControler.SZ_Btn1,VentilControler.WZ_Btn1,ccu_Btn1,rssi_hmuart_Btn1,virtAktorAlarmOff_Btn1 postEvent:slider,0,1,255
2021.09.29 20:47:51.162 1: CUL_HM start inital cleanup
2021.09.29 20:47:56.055 1: CUL_HM finished initial cleanup


Ist das "on board" von CUL_HM oder ein "initialized"-notify (oä.)? Wenn ja: könnte man da einen (kurzen) Timer davor setzen, dass erst initial cleanup durchlaufen kann und die Peers etc. ausgewertet sind?

[frank]

guter hinweis... , das habe ich völlig verdrängt und dann falsch "eingeordnet". zu viele baustellen gleichzeitig. 

das muss aus meinem at kommen, dass die hzg regelung alle 60s prüft und ggf ändert. deshalb auch nur immer 4 von 6. diese meldungen kommen aber erst mit aktueller cul_hm.

das bedeutet aber, dass der vtc start in cul_hm_updateconfig doch gar nicht zündet, wovon ich fälschlicherweise ausgegangen bin.

da müssen wohl doch mal ein paar logs in den code.

eigentlich müsste cul_hm ein "homematic_ready" event erzeugen. scheinbar ist global:initialized jetzt viel zu früh.

[Beta-User]

Boa, alles sehr abstrakt...

Das mit dem CUL_HM:ready-trigger halte ich für eine gute Idee, kann eigentlich nicht schaden, das zusammen mit dem Log-Eintrag für "initial cleanup" rauszuhauen.

Was das at angeht, müßte ggf. ein Hash-Element geprüft werden, in dem steht, ob CUL_HM jetzt "initdone" ist (oder .AttrList vorhanden?). Andererseits sind die Log-Einträge ja gar nicht das Problem, ist halt unschön. Generell ist aber zum einen die Frage, ob das initiale Senden des letzten Werts wirklich nicht implementiert ist (ich meine schon, kann nur sein, dass es (Voodoo?) nicht funktioniert?)? Zum anderen: Wenn man einen Timer braucht (?), wäre es dann nicht besser, den auch direkt in CUL_HM mit reinzucoden und nur (via param-Attribut?) die Timerdauer jeweils einstellbar zu machen? (Schon klar, dass das noch eine Sonderlocke ist, aber irgendwie, na ja... weiß auch nicht...).

Zuletzt&hier OT: Da gibt es eine Variable in main:: ($evtDly). die ist mir hochgradig suspekt, auch wenn irgendwo die Entschuldigung steht, dass das zu verwalten doch eigentlich fhem.pl besser übernehmen sollte.

[Beta-User]

Nochmal zurück zum Startup-Mechanismus in CUL_HM: Das/die at feuern vor dem CUL_HM_updateConfig(), weil da initial gar kein Timer gesetzt wird, sondern der erst in der NotifyFn erzeugt wird.

Könnte man dadurch bereinigen, dass man es in DefFn mit reinnimmt, was aber dann (so man nicht noch eine Abfrage reinbastelt) viele Timer erzeugt (die dann aber sowieso alle wieder abgeräumt würden, sobald der erste CUL_HM_updateConfig() aufruft). Hab' mal testweise nach "Initialize" gedoppelt, das funktioniert auch und sollte dann genau einen (zusätzlichen) Timer erzeugen (ggf. zu dem aus der NotifyFn).
Das hat nur zwei Probleme: a) ist es vermutlich nicht "rereadcfg-fest" (was mir persönlich aber herzlich gleichgültig wäre) und b) bleibt es (zumindest auf den ersten Blick) empfindlich gegen eine "falsche Reihung" in der cfg. Evtl. kann man da noch tricksen, indem man nicht "1" als Zeit mitgibt, sondern "0.1", aber "na ja"...
Meinungen dazu?


Weiter ist in (ca.) #427 eigentlich eine Timer-Funktion für den vdCrtl eingebaut. Die Frage wäre also: Funktioniert die nicht, oder warum braucht man ein at?

Als erstes fällt auf, dass da kein nummerischer Wert als default hinterlegt ist. Kann natürlich sein, dass das sinnvoll ist, aber wenn es nur nummerische (Prozent-) Werte geben darf, würde ich eher vorschlagen, gleich ReadingsNum zu verwenden und "halbe Kraft voraus" als default zu hinterlegen?

Code Auswählen Erweitern

if ($hash->{helper}{fkt} eq "vdCtrl"){
          my $d = ReadingsNum($name,'valvePosTC','50');
          CUL_HM_Set($hash,$name,"valvePos",$d);
          CUL_HM_UpdtReadSingle($hash,"valveCtrl","restart",1) if ($d =~ m/^[-+]?[0-9]+\.?[0-9]*$/);
          RemoveInternalTimer("valvePos:$vId");
          RemoveInternalTimer("valveTmr:$vId");
          InternalTimer($hash->{helper}{vd}{next},"CUL_HM_valvePosUpdt","valvePos:$vId",0);

Meinungen?

Betr. "reg not found" (https://forum.fhem.de/index.php/topic,123139.0.html):
Das bezieht sich auf die offizielle Version und das Problem ist auch nicht durch die Sortiererei "gegessen"?

[frank]

Weiter ist in (ca.) #427 eigentlich eine Timer-Funktion für den vdCrtl eingebaut. Die Frage wäre also: Funktioniert die nicht, oder warum braucht man ein at?

mein at ist für die regelung meiner therme und in den räumen für die einstellung der ventile, die ich über fhem/pid20 einstelle. damit berechne ich die nötigen ventileinstellungen.
der timer in fhem sorgt dafür, dass regelmässig und nur zu ganz bestimmten zeiten die messages mit der valvepos (keepalive) an den vd gesendet werden. empfängt der vd 6x nichts, schläft der vd 60min ein.
so ähnlich wie die virtuellen tempfühler für den rt, aber etwas komplizierter.

die logmeldungen sind aber erstmal völlig egal, vielleicht sind sie wieder weg, wenn der autostart wieder funktioniert.

Als erstes fällt auf, dass da kein nummerischer Wert als default hinterlegt ist. Kann natürlich sein, dass das sinnvoll ist, aber wenn es nur nummerische (Prozent-) Werte geben darf, würde ich eher vorschlagen, gleich ReadingsNum zu verwenden und "halbe Kraft voraus" als default zu hinterlegen?

Code Auswählen Erweitern

if ($hash->{helper}{fkt} eq "vdCtrl"){
          my $d = ReadingsNum($name,'valvePosTC','50');
          CUL_HM_Set($hash,$name,"valvePos",$d);
          CUL_HM_UpdtReadSingle($hash,"valveCtrl","restart",1) if ($d =~ m/^[-+]?[0-9]+\.?[0-9]*$/);
          RemoveInternalTimer("valvePos:$vId");
          RemoveInternalTimer("valveTmr:$vId");
          InternalTimer($hash->{helper}{vd}{next},"CUL_HM_valvePosUpdt","valvePos:$vId",0);


zur zeit habe ich den verdacht, dass diese stelle nicht erreicht wird, weil irgendwelche bedingungen noch nicht gesetzt sind.

[Beta-User]

mein at ist für die regelung meiner therme und in den räumen für die einstellung der ventile, die ich über fhem/pid20 einstelle. damit berechne ich die nötigen ventileinstellungen.

Damit ist jedenfalls mAn. die Umstellung auf eine rein timerbasierte Initialisierung zwingend, und evtl. sollten wir versuchen, die CUL_HM-Initialisierung im Timer-Array ganz nach vorne zu mogeln. Deine Lösung ist m.E. ein typischer Anwendungsfall...

der timer in fhem sorgt dafür, dass regelmässig und nur zu ganz bestimmten zeiten die messages mit der valvepos (keepalive) an den vd gesendet werden. empfängt der vd 6x nichts, schläft der vd 60min ein.
so ähnlich wie die virtuellen tempfühler für den rt, aber etwas komplizierter.

Von daher dürfte es wichtig sein, dieses System so schnell wie möglich nach einem FHEM-Start wieder zum Einschwingen zu bringen und nicht erst lange zu warten.

die logmeldungen sind aber erstmal völlig egal, vielleicht sind sie wieder weg, wenn der autostart wieder funktioniert.

Nach meinem Verständnis wären die Einträge an sich wirklich egal . Das dahinterliegende Problem dürfte nur sein, dass der Code so geschrieben und kommentiert ist, dass das eigentlich nicht passieren sollte. Ergo gehe ich davon aus, dass es wichtig ist, erst mal zu verhindern, dass der Code zur falschen Zeit (schon) aufgerufen wird, weil dadurch uU. inkonsistente Systemzustände vermieden werden (deren Symptome wir hier ggf. diskutieren?).

zur zeit habe ich den verdacht, dass diese stelle nicht erreicht wird, weil irgendwelche bedingungen noch nicht gesetzt sind.

Dann wäre das m.E. einer der nächsten Punkte rauszufinden, woran es dafür genau hakt. Es könnte der "falsche" nicht-nummerische default gewesen sein (iVm. einem Aufruf vor $init_done).

Die Bausteinchen sind hier ja verteilt, ich würde nur gerne das ganze erst mal in Ruhe auf mein Echtsystem loslassen, bevor es wieder einen konsolidierten Stand zum Testen gibt, das kann uU. etwas dauern.

[OT]
Mit (oder wegen?) der "großen Schwester" habe ich im Browser (nur noch*) bei CUL_HM-Geräten ständig Timeout-Meldungen und offenbar refreshes der Detail-View-Seiten. Bisher war ich sowieso selten veranlaßt, die aufzurufen, aber derzeit... Irgendeinen Tipp auf die Schnelle und ins Blaue?
* = das war auch bei HMinfo so, das ist aber dort seit dem saveConfig anscheinend weg?
[/OT]

[frank]

ich habe jetzt 3 logmeldungen eingebaut.

Code Auswählen Erweitern

    elsif ($st eq "virtual" ) {#setup virtuals
  Log(1,"----- test1 ----- -> n:$name");
      $hash->{helper}{role}{vrt} = 1;
      if (   $hash->{helper}{fkt}
          && $hash->{helper}{fkt} =~ m/^(vdCtrl|virtThSens)$/){
    Log(1,"----- test2 ----- -> n:$name");
        my $vId = substr($id."01",0,8);
        $hash->{helper}{vd}{msgRed}= 0 if(!defined $hash->{helper}{vd}{msgRed});
        if(!defined $hash->{helper}{vd}{next}){
          ($hash->{helper}{vd}{msgCnt},$hash->{helper}{vd}{next}) =
                    split(";",ReadingsVal($name,".next","0;".gettimeofday()));
          $hash->{helper}{vd}{idl} = 0;
          $hash->{helper}{vd}{idh} = 0;
        }
        if ($hash->{helper}{fkt} eq "vdCtrl"){
      Log(1,"----- test3 ----- -> n:$name");
          my $d = ReadingsVal($name,"valvePosTC","");
          $d =~ s/ %//;
          CUL_HM_Set($hash,$name,"valvePos",$d);
          CUL_HM_UpdtReadSingle($hash,"valveCtrl","restart",1) if ($d =~ m/^[-+]?[0-9]+\.?[0-9]*$/);
          RemoveInternalTimer("valvePos:$vId");
          RemoveInternalTimer("valveTmr:$vId");
          InternalTimer($hash->{helper}{vd}{next},"CUL_HM_valvePosUpdt","valvePos:$vId",0);
        }
        elsif($hash->{helper}{fkt} eq "virtThSens"){
          my $d = ReadingsVal($name,"temperature","");
          CUL_HM_Set($hash,$name,"virtTemp",$d) if($d =~ m/^[-+]?[0-9]+\.?[0-9]*$/);
          $d = ReadingsVal($name,"humidity","");
          CUL_HM_Set($hash,$name,"virtHum" ,$d) if($d =~ m/^[-+]?[0-9]+\.?[0-9]*$/);
        }

        # delete - virtuals dont have regs
        delete $attr{$name}{$_} foreach ("autoReadReg","actCycle","actStatus","burstAccess","serialNr");
      }
    }


Code Auswählen Erweitern

2021.10.01 16:39:09.216 1: CUL_HM start inital cleanup
2021.10.01 16:39:12.174 1: ----- test1 ----- -> n:SDTeam
2021.10.01 16:39:12.215 1: ----- test1 ----- -> n:SDTeam_Btn1
2021.10.01 16:39:13.297 1: ----- test1 ----- -> n:VentilControler.AZ.Nord
2021.10.01 16:39:13.321 1: ----- test1 ----- -> n:VentilControler.AZ.Nord_Btn1
2021.10.01 16:39:13.326 1: ----- test1 ----- -> n:VentilControler.AZ.West
2021.10.01 16:39:13.370 1: ----- test1 ----- -> n:VentilControler.AZ.West_Btn1
2021.10.01 16:39:13.375 1: ----- test1 ----- -> n:VentilControler.Bad
2021.10.01 16:39:13.399 1: ----- test1 ----- -> n:VentilControler.Bad_Btn1
2021.10.01 16:39:13.405 1: ----- test1 ----- -> n:VentilControler.Kueche
2021.10.01 16:39:13.428 1: ----- test1 ----- -> n:VentilControler.Kueche_Btn1
2021.10.01 16:39:13.434 1: ----- test1 ----- -> n:VentilControler.SZ
2021.10.01 16:39:13.477 1: ----- test1 ----- -> n:VentilControler.SZ_Btn1
2021.10.01 16:39:13.483 1: ----- test1 ----- -> n:VentilControler.WZ
2021.10.01 16:39:13.506 1: ----- test1 ----- -> n:VentilControler.WZ_Btn1
2021.10.01 16:39:13.784 1: ----- test1 ----- -> n:rssi_hmuart
2021.10.01 16:39:13.826 1: ----- test1 ----- -> n:rssi_hmuart_Btn1
2021.10.01 16:39:13.971 1: ----- test1 ----- -> n:virtAktorAlarmOff
2021.10.01 16:39:14.014 1: ----- test1 ----- -> n:virtAktorAlarmOff_Btn1
2021.10.01 16:39:14.043 1: ----- test1 ----- -> n:virt_vd
2021.10.01 16:39:14.110 1: ----- test1 ----- -> n:virt_vd_Btn1
2021.10.01 16:39:14.114 1: CUL_HM finished initial cleanup


danach fehlt zu diesem zeitpunkt mindestens {helper}{fkt} in den 6 entities VentilControler.*_Btn1 (vtc)

[Beta-User]

Demnach wären zwingend die Peers in diesem Fall vorab auszulesen?

Könnte so klappen (unsicher, was 1 oder 0 angeht):

Code Auswählen Erweitern

elsif ($st eq "virtual" ) {#setup virtuals
      $hash->{helper}{role}{vrt} = 1;
      CUL_HM_ID2PeerList($name,'peerUnread',1) if !defined $defs{$name}{helper}{peerIDsH};
      if (   $hash->{helper}{fkt}
          && $hash->{helper}{fkt} =~ m/^(vdCtrl|virtThSens)$/){
        my $vId = substr($id."01",0,8);

[frank]

leider keinen schritt weiter

[Beta-User]

Mal ohne defined- Bedingung?
Kann auch der Parameter sein...

[frank]

Mal ohne defined- Bedingung?

hat nur frust gebracht, da die peers dann weg waren.

[Beta-User]

  Muss ich mir ansehen, aber eigentlich dürfte das nur der Fall sein, wenn der Code vor $init_done ausgeführt wird (weil dann die Attribute nicht komplett eingelesen sein müssen).

Irgendwas hängt da noch schräg...

[frank]

du hattest doch mal virtuelle tempsensoren für die rt, oder?
die sollten doch ähnliche probleme haben und ihren if block nicht erreichen:

Code Auswählen Erweitern

        elsif($hash->{helper}{fkt} eq "virtThSens"){
          my $d = ReadingsVal($name,"temperature","");
          CUL_HM_Set($hash,$name,"virtTemp",$d) if($d =~ m/^[-+]?[0-9]+\.?[0-9]*$/);
          $d = ReadingsVal($name,"humidity","");
          CUL_HM_Set($hash,$name,"virtHum" ,$d) if($d =~ m/^[-+]?[0-9]+\.?[0-9]*$/);
        }

[Beta-User]

zu viele baustellen gleichzeitig. 

A propos: Hattest du bei dem Experiment vorher HMinfo angefasst? Das hatte ich nämlich gedanklich als "abgehakt" behandelt, aber leider evtl. nicht deutlich genug geäußert:

Für's erste wäre dann wohl ein hotfix, $init_done mit abzufragen?

Code Auswählen Erweitern

if (   !$evtDly && $init_done           #noansi: first Readings must be set, helps also not to disturb others

Wenn nicht, ist es einigermaßen wahrscheinlich, dass irgendwas (mangels Kenntnis der Attribut-Werte) Amok läuft,( weil verfrüht der Teil aus CUL_HM rückwärts aufgerufen wird, die 700+ Zeilen im Log)...

M.E. ist es nach etwas Nachdenken über den Punkt eigentlich eine Art "Muss", dass ein "optionales Hilfsmodul" wie HMinfo nicht die Art und Weise beeinflussen darf, wie sich "Münchhausen aus dem Sumpf zieht".

Muss das aber vermutlich wirklich alles im Zusammenhang auch selbst nochmal im Echtsystem laufen lassen, sonst ist es zu unübersichtlich.

PS: Mit den Versionen von gestern hatte ich im Echtsystem jedenfalls keine offensichtlichen Probleme mit meinen virtuellen entities: Einer der virtuellen Tempsensoren ist weg, da blinkt der RT. Das ist aber definitiv ok, weil der echte Sensor in der Tat keine aktuellen Daten liefert, die anderen scheinen online zu sein (sch... ZigBee (hier: Xiaomi), komischerweise sind die BT-Varianten einfach zuverlässigere Datenlieferanten...)

[Beta-User]

Guten Morgen,

das mit dem Weglassen der Abfrage ist in den gesammelten Werken in https://forum.fhem.de/index.php/topic,123198.msg1177351.html#msg1177351 immer noch so:

hat nur frust gebracht, da die peers dann weg waren.

Daher ist die Abfrage da weiter drin. Meine virtuellen Temp-Sensoren werden aber auch nicht in der Initialisierung mit angefahren/geloggt, aber sowohl Werte wie Peers sind da; müßte daher ok sein.

fyi: Alle Funktionalität aus HMinfo ist jetzt "mit Gewalt" weg von Serverstart verschoben (mind. 30 Sek. müssen um sein, bevor die configCheck -f rausgehen).

Kann dieses WE nicht mehr viel machen, vielleicht findest du ja noch einen Dreh, wie man den virtuellen subType in der Initialisierung beibiegt, wes Geistes Kind sie sind...?