[jetzt im svn] [CUL_HM +] patches November 2021

[Beta-User]

Hi Martin, hallo zusammen,

vielleicht kurz mein Kenntnisstand zum HMLAN-Update:

Zeile 916: hat Martin herausgenommen:  $hash->{helper}{q}{sending} = 1;

Die Zeile stammt aus noansis (?) "anti-Reboot"-Patch, die hatte ich schlicht so übernommen, da als funktionierend berichtet. Kann sein, dass die nicht notwendig ist, ich gehe davon aus, dass Martin das geprüft hat und es schlicht besser weiß .

Zeile 841:   return DevIo_OpenDev($hash, 1, "HMLAN_DoInit",  sub(){}); -> den sub-Teil hat Martin rausgenommen

Da hätte ich vermutlich etwas mehr Erläuterung dazu schreiben sollen, das ist uU. etwas "watndat":
- Es funktioniert auch ohne (und hatte es ja auch lange).
- Die Wirkung ist die, dass durch diesen "Pseudo-Callback" bei gekappter Verbindung nicht bei praktisch jedem fhem-pl-Schleifendurchlauf versucht wird, diese wieder herzustellen, sondern dann nur noch alle 60 Sekunden (einstellbar).
Ist eine Abwägungsfrage, die man "irgendwie" entscheiden kann. Nach meinem persönlichen Bauchgefühl wäre vermutlich der Pseudo-Callback iVm. einem kürzeren Einstellwert (10 Sekunden) für den timeout ein guter Kompromis.

devIo inkludiert Martin erst beim HMLAN_Initialize

Nicht ganz korrekt: DevIo wird _nochmals_ via "use" eingebunden. Grund ist irgendein komischer pre-commit-Hook, den zu knacken Martin erst im x-ten-Anlauf durch diese etwas seltsame Doppelung geschafft hat (https://forum.fhem.de/index.php/topic,110125.msg1185281.html#msg1185281).

Was in der Differenzbetrachtung noch fehlt (Define):

Code Auswählen Erweitern

$hash->{Clients} = ":CUL_HM:";
Damit ist es wieder kompatibel mit der im svn verfügbaren CUL_HM-Version, in "meiner" Fassung war das auskommentiert und dafür ein paar Zeilen in CUL_HM darauf angepaßt. Die werde ich wieder ändern.

@Benni:
konntest du ggf. schon checken, ob die Änderungen in #9642f das bewirken, was sie sollen: keine Logeinträge+gesäuberte Devices?
Dann würde ich diesen Teil bei Gelegenheit auch noch in "meine" CUL_HM-Fassung reinbasteln...

[Benni]

@Benni:
konntest du ggf. schon checken, ob die Änderungen in #9642f das bewirken, was sie sollen: keine Logeinträge+gesäuberte Devices?
Dann würde ich diesen Teil bei Gelegenheit auch noch in "meine" CUL_HM-Fassung reinbasteln...

Das ist jetzt leider blöd gelaufen, denn zwischenzeitlich habe ich meinen config bereinigt und konnte den _chn-Müll aus den Weather-Channels rausschmeißen (tatsächlich nur per Reset der Devices).

Ich kann dir jetzt also leider nicht bestätigen, dass deine Änderung wirkt (obwohl sie das damit sollte, wenn ich es richtig sehe )
Die Warnungen bei mir sind jedenfalls mit Verschwinden der "falschen" _chn ebenfalls verschwunden.

Das ist dann zumindest eine Bestätigung für die ermittelte Ursache

gb#

[Beta-User]

Danke für die Rückmeldung!
Hätte ja sein können, du hättest irgendwo noch ein RAW-listing von einem kaputten Device gehabt, das du testweise hättest einspielen können...

Na ja, habe jetzt jedenfalls auch diesen Teil vorsorglich eingearbeitet, weil es einen zweiten Betroffenen gibt; vielleicht hat er diesen Thread zwischenzeitlich auch gefunden und ist willens, sich dazu zu äußern .

Kompletten Code wieder hier anbei, da bisher nur kurz auf generelle Lauffähigkeit getestet .

Wer HMLAN im Einsatz hat - entweder die svn-Fassung nehmen, oder in meiner diese Zeile in Initialize aktivieren:

Code Auswählen Erweitern

$hash->{Clients} = ":CUL_HM:";

[mgernoth]

Hallo,

Zeile 916: hat Martin herausgenommen:  $hash->{helper}{q}{sending} = 1;

Damit ist mein no-reboot-Patch wirkungslos, diese Zeile ist essentiell für die Funktion.

Viele Grüße
  Michael

[Beta-User]

Hallo,

Damit ist mein no-reboot-Patch wirkungslos, diese Zeile ist essentiell für die Funktion.

Viele Grüße
  Michael

Danke für die schnelle Klarstellung!

Anbei dann also wieder eine "patches"-Fassung von HMLAN, die diese Zeile beinhaltet und mit der CUL_HM aus dem Vorpost zusammenpaßt.

Da ist dann auch der Pseudo-Call noch/wieder drin und (neu) ein timeout von 10 Sekunden vorgeschlagen (als Referenzpunkt für Skeptiker: HMUARTLGW hat das etwas anders mit 5 Sekunden vercoded, und darüber hat sich mind. die letzten 2 Jahre auch keiner beschwert).

Wäre super, wenn das jemand auf Funktionalität testen könnte, der einen HMLAN hat und mal kurzfristig ein "paar" Log-Einträge verkraften kann (die Zeile mit der Log-Anweisung in HMLAN_Ready() (am Anfang) einfügen).

[martinp876]

HMLAN updated.
use DEVio ist an einer seltsamen Stelle - allerdings hat Rudi das einchecken unterbunden, wenn es nicht hier implementiert ist. Hm.

DEVio nextOpenDelay ist wirklich eine spezielle implementierung, parameter zu übergaben. Da muss man erst einmal drauf kommen, hier einstellungen zu suchen, wenn man das Modul nutzt! Wer hat sich den Orden verdient?

Anyway - ich hoffe, wir sind jetzt auf Stand - sorry für meine Bugs ("sending")

[Timmäää]

Danke Beta-User für deine vielen Vorschläge und Testversionen und dir martinp876 für das ständige Prüfen und Einchecken
Ich bin seit heute Morgen mit der 2021-11-08 von Beta-User fehlerfrei unterwegs und werde die Datei ausm SVN morgen per Update reinziehen.

Großen Dank euch!

*update*
Ist ja heute noch mit ins Update gerutscht, gar nicht gemerkt durch mein exclude.

[Beta-User]

Vorab mal ein fettes Danke zurück an alle Mit-Tester und Mit-Überlegenden!

Anyway - ich hoffe, wir sind jetzt auf Stand

Was HMLAN angeht: Ja.
Bzgl. CUL_HM gibt es m.E. noch Diskussionsbedarf, s.u.

sorry für meine Bugs ("sending")

Kein Problem, es haben ja ein paar Leute aufgepaßt . Und irgendwie bin ich manchmal auch nicht sicher, ob mir nicht auch das eine oder andere jetzt durchgerutscht ist, anbei daher nochmal eine aktuelle CUL_HM-Fassung (#1034 hatte ich beim Bereinigen nach dem HMLAN-update wohl übersehen).

DEVio nextOpenDelay ist wirklich eine spezielle implementierung, parameter zu übergaben. Da muss man erst einmal drauf kommen, hier einstellungen zu suchen, wenn man das Modul nutzt! Wer hat sich den Orden verdient?

Das hatte ich irgendwann mal für MYSENSORS aus MQTT2_CLIENT geklaut, wenn ich das richtig in Erinnerung habe. Habe damals auch erst gedacht "watndat...?!?" Finde es an sich ist es nichts ungewöhnliches, dass im Instanzhash Parameter zu finden sind, die das Verhalten beeinflussen, aber eine "nutzlose" anonyme sub zu gebrauchen, fand ich auch "öhm..."

Was CUL_HM angeht, gibt es m.E. noch (mind.) folgende Baustellen, die man klären sollte:
- rereadcfg: Das funktioniert nur, wenn mit dem letzten "delete" einer CUL_HM-Instanz auch wieder NOTIFYDEF bereinigt wird (m.E.: urgent!)
- automatisches Anlegen von Geräten: Sollte m.E. nur aktiv sein, wenn der User etwas veranlasst. Alles andere gibt Probeme (!)! Die Minimalfassung ist hier enthalten, die volle (Unterstützung von "TYPE=autocreate") war in den OktoberII-patches mal drin, da fehlte eigentlich nur das "ver-room-en" nach CUL_HM für die Hauptinstanz (Teil a) - nur nach User-Anforderung - ist m.E. wichtig!)
- Benni's "uninitialized"-Baustelle (war irgendwo nochmal zu finden): Die Pflaster scheinen nicht zu schaden, die letzten Änderungen sind nicht durchgetestet, aber von Benni für "müßte passen" erklärt worden... (na ja, sind nur komische Log-Einträge => low prio);
- frank's Liste in https://forum.fhem.de/index.php/topic,120857.0.html ist vermutlich jetzt auch wieder kürzer geworden, aber afaik gäbe es da auch noch ein paar offene Punkte.
Da ich selbst das alles (vermutlich) nicht brauche (ich wohne auf dem Land und erwarte nicht, dass einer meiner Nachbarn noch mit BidCoS anfangen wird und habe configDB im Einsatz), werde ich meine Aktivitäten jetzt einstellen. Die Langform der Erklärung (zu autocreate) ist jeweils irgendwo in diesem Thread oder den anderen patches-Threads zu finden.

Den Thread lasse ich (zumindest erst mal) offen, falls jemand Fragen v.a. zu den obigen Punkten hat, stehe ich dafür gerne bereit.

CU.

[Beta-User]

- automatisches Anlegen von Geräten: [...] die volle (Unterstützung von "TYPE=autocreate") war in den OktoberII-patches mal drin, da fehlte eigentlich nur das "ver-room-en" nach CUL_HM für die Hauptinstanz (Teil a) - nur nach User-Anforderung - ist m.E. wichtig!)

Da Wiederfinden Freude macht, hier nochmal die "volle Fassung" als Diskussionsgrundlage incl. Zuweisung des "richtigen Rooms" nach TYPE=autocreate-Aktivität. Würde den Teil ab Zeile 1769 ersetzen, ist ungetestet.

Code Auswählen Erweitern

  if(!$mh{devH} && $mh{mTp} eq "00") { # generate device
    my $sname = "HM_$mh{src}";
    my $acdone;
    if ( InternalVal($mh{ioName},'hmPair',InternalVal(InternalVal($mh{ioName},'owner_CCU',''),'hmPair',0 ))) { # initiated via hm-pair-command => User wants actively have the device created
        if (IsDisabled((devspec2array('TYPE=autocreate'))[0]) ) {
            my $defret = CommandDefine(undef,"$sname CUL_HM $mh{src}");
            Log 1,"CUL_HM Unknown device $sname is now defined ".(defined $defret ? " return: $defret" : "");
        } else {
            DoTrigger('global', "UNDEFINED $sname CUL_HM $mh{src}"); #Beta-User: procedure similar to ZWave
            CommandAttr(undef,"$sname room CUL_HM");
        }
        $acdone = 1;
    } elsif (!IsDisabled((devspec2array('TYPE=autocreate'))[0]) && !defined InternalVal($mh{ioName},'owner_CCU',undef)) {
        #Beta-User: no vccu, write Log
        Log3($mh{ioName},2,"CUL_HM received learning message from unknown id $mh{src} outside of pairing mode. Please enable pairing mode first or define a virtual device w. model: CCU-FHEM.");
    }
    if ($acdone) {
        $mh{devH} = CUL_HM_id2Hash($mh{src}); #sourcehash - changed to channel entity
        $mh{devH}->{IODev} = $iohash;
        if (!$modules{CUL_HM}{helper}{hmManualOper}){
          my $ioOwn = InternalVal($mh{ioName},'owner_CCU','');
          $defs{$sname}{IODev} = $defs{$mh{ioName}};
          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;
            }
          }
          else{
            $attr{$sname}{IODev} = $mh{ioName};
          }
        }
        $mh{devH}->{helper}{io}{nextSend} = $mh{rectm}+0.09 if(!defined($mh{devH}->{helper}{io}{nextSend}));# io couldn't set
    }
  }

[FFHEM]

Hallo zusammen,
da hier ja fleißig an den HM-Modulen gearbeitet wird, erst einmal mein Dankeschön an alle!
Ich habe den Oktober- und November-Thread soweit durchgearbeitet, aber für mich steht immer noch eine Frage aus:
Seit einigen Monaten habe ich Probleme mit dem weekprofile für Heizungsthermostate, ähnlich diesem User hier:

Mit kaputt meinte ich dass im Reading "R_tempList_State" der Wert "incomplete" steht und sich dieses auch nicht mehr ändert.
Teilweise steht auch in den Readings "R_3_..." incomplete und andere Readings haben ein "set_" vor dem Wert.

Habe nun das Ganze mal mit weekprofile für ein Thermostat probiert, da habe ich das gleiche Problem.

Wie gesagt, habe ich das gleiche Problem schon seit einigen Monaten und kann eine weekprofile-Änderung manchmal nur mit zusätzlichem getconfig übertragen.
Irgendeine Kombination von HMinfo/10_CUL_HM hatte dies auch gekonnt, ich steige aber nicht mehr durch, welche.
Ein aktuelles Update aller HM-Module mit dem neuesten

Code Auswählen Erweitern

# $Id: 10_CUL_HM.pm 25158 2021-11-09 Beta-User $
bringt auch nicht den Erfolg. Bei mir steht dann im Thermostaten immer noch "incomplete".

Frage: Stammt dieser Fehler aus HMinfo.pm? Und wenn ja, wird daran auch gearbeitet und welche Version von HMinfo.pm kann ich verwenden?
Vielen Dank!
Gruß,
Friedhelm

[Beta-User]

Soweit ich das noch in Erinnerung habe, war das in dem von dir zitierten Fall eigentlich kein originäres weekprofile oder CUL_HM-Problem, sondern v.a. auch eines, das mit Funkproblemem zu tun hatte (optimale IO-Zuweisung etc.). Vor allem: das jetzt gelöst ist.

Du solltest m.E. dazu einen neuen Thread aufmachen und etwas "Futter bei die Fische" geben (lists etc.).

[FFHEM]

Hallo Beta-User,
Thread ist jetzt hier eröffnet:

https://forum.fhem.de/index.php/topic,124136.0.html

[Beta-User]

...hier doch mal wieder ein update, auch wenn mich weiter wundert, dass Martin zu den offenen Fragen aus https://forum.fhem.de/index.php/topic,123874.msg1185568.html#msg1185568 bisher geschwiegen hat.

Änderungen gg. der letzten Fassung:
- "autocreate" ist in der "Vollversion" drin (nachdem @Pfriemler in https://forum.fhem.de/index.php/topic,124179.msg1187590.html#msg1187590 zu der Frage etwas kritisches geäußert hatte, das ich nicht komplett verstanden habe);
- franks Anliegen aus https://forum.fhem.de/index.php/topic,124090.0.html sollte bis auf die "uninitialized"-Warnings gelöst sein;
- manche der Punkte aus https://forum.fhem.de/index.php/topic,120857.msg1154321.html#msg1154321 habe ich mir angesehen, glaube aber, dass da noch Dinge drauf sind, die gelöst sein dürften, insbesondere:
-- Löschen der logIDs in den IOs (#1252)
-- falsche io zuweisungen nach fhem restart (da waren doch die wesentlichen Teile in die jetzige svn-Version eingearbeitet gewesen, oder irre ich mich?)

[Pfriemler]

moinsen,

Meine Meinung ist: "Fremde" Geräte sollten grundsätzlich nicht automatisch angelegt werden, wenn eine VCCU vorhanden ist.

Prinzipiell ebenfalls ACK, weil es den Normaluser vor überflüssigen Infos bewahrt. Ich persönlich hatte mit dem autocreate fremder Geräte noch nie ein Problem, es war eher hilfreich zu wissen was in der Nachbarschaft so neues aufläuft. Wenn "autocreate" fremder Geräte ohne vorherigens "pair" seitens VCCU also (für Experten) zuschaltbar wäre: optimal.
Ebenfalls ACK: was die VCCU da teilweise unter "unknown" angelegt hatte bisher, war aus meiner bescheidenen Sicht ein eher bunter Mix aus Fremd- und (später) eigenen angelegten Gerätschaften. Ich lösche die Liste regelmäßig ohne Probleme...

Wer die "braucht", sieht die HmID in der VCCU und kann dann ja manuell anlegen.

Seit wann ist ein unkompliziertes Anlegen von HM-Geräten durch einen define-Befehl wieder möglich?

[Beta-User]

Seit wann ist ein unkompliziertes Anlegen von HM-Geräten durch einen define-Befehl wieder möglich?

War irgendwo von "unkompliziert" die Rede ?!? Ein Define kann man (mWn. schon immer) stressfrei absetzen, und ich würde auch davon ausgehen, dass passende Nachrichten dann zugestellt werden und den Nebel nach und nach lichten... Inwieweit Kanäle angelegt werden usw.: k.A., aber Experten werden das hinbekommen, modelForce sei Dank .

Wenn "autocreate" fremder Geräte ohne vorherigens "pair" seitens VCCU also (für Experten) zuschaltbar wäre: optimal.

Bin für Vorschläge für Vorschläge offen, aber erst mal warte ich immer noch auf Martins ausführlicherer Rückmeldung zu dem "autocreate"-Thema "as is", das ist ja so schon kompliziert genug.
(Der aktuelle Code im svn führt jedenfalls nach meinem Verständnis eine Anlernmessage unabhängig von jeglichem User-Willen zum Anlegen des Devices samt aller Kanäle und ist daher eher bei deinem "lass alles autocreate-n, was so in die Gegend funkt" (aber ohne LogFile und die sonstigen "services" von TYPE=autocreate)).