[10.08.21] neues cul_hm schreibt ein paar warnings ...

[Beta-User]

Vermutlich wäre es besser, du würdest ihn das direkt fragen. Bis auf weiteres gehe ich davon aus, dass er schlicht und ergreifend irgendwann auch mal die Gelegenheit zum Urlaubmachen ergriffen hat und ohne Handwerkszeug und Muße eh' nicht helfen kann...

Ansonsten klangen die letzten Umbauten durchaus so, dass er sich weiter langfristig um die Module kümmern will. Da ging ja vieles auch eher in Richtung einer klaren Nutzerführung, was zulässig/sinnvoll ist usw..

Kleiner Hinweis am Rande noch: im "Nebenthread" bin ich vorhin noch über was gestolpert, das die Erstinitialisierung bei VCCU-Verwendung angeht. Mein Bauchgefühl sagt mir, dass es ggf. hilfreich wäre, wenn zumindest mutige Tester gleich diese letzte Version (mit vorgezogener Attributprüfung) verwenden würden .

[the ratman]

dank dir für die gedanken - wirst wohl recht haben.

vccu testen - nicht so meines. schon gar ned, wenn man mut braucht *g*
das dürfen dann doch gerne leute mit ahnung machen.

[frank]

vccu testen - nicht so meines. schon gar ned, wenn man mut braucht *g*
das dürfen dann doch gerne leute mit ahnung machen.

ich behaupte, dass viele fehler eher durch leute mit weniger ahnung gefunden werden.
da werden "kombinationen" probiert, an die sonst keiner gedacht hätte. 

[Beta-User]

...sehe ich auch so, und bei meinen Modulen fühle ich mich auch eher wohl, wenn ein paar wenige Leute das schon mal vorab testen...

Wenn wir jetzt (aes ist noch unklar) auch noch dieses blöde Thema mit dem tempListTmpl in den Griff bekommen könnten, dann wäre ggf. auch alles wieder einigermaßen auf Stand. Leider will das überhaupt nicht so richtig, stattdessen habe ich mir mit einem set-Befehl (set therm_Clima tempTmplSet aa:bb) zuverlässig FHEM abschießen können, wenn HMinfo nicht definiert war (mit ist die Funktion da). Soviel zum Thema "Kombinationen"...

Dafür meine ich, noch einen Wackler bei der Erstinitialisierung gefunden zu haben, da müßte mAn. eigentlich ein anderer Startparameter übergeben werden, wenn wegen !$init_done getimert wird.

Damit wieder alle update-Angebote an einer Stelle (=hier) versammelt sind, und zumindest die Fehlermeldung aus dem Nachbarpost erledigt zu sein scheint, dieses update dann wieder hier (HMLAN nur der Vollständigkeit halber).

[Beta-User]

@frank: Nachdem ich jetzt einige Zeit durch den Code gestolpert bin auf der Suche danach, warum das mit dem Setzen von "tempListTmpl" nicht so recht will...: Kann es sein, dass das u.A. auch deswegen nicht klappt, weil auf meinem Testsystem keine HMinfo Instanz definiert ist?

Soweit ich den Code interpretiere, ist es (ab #1395) so, dass das Attribut nicht nur den setter voraussetzt, sondern auch das Vorhandensein eines Hashes unter $hash->{tempListTmplLst} (= $modules{CUL_HM}->{tempListTmplLst}). Den wiederrum setzt CUL_HM gar nicht selbst, sondern HMinfo.
Das ist jedenfalls dann "tödlich", wenn man ohne HMinfo nur mit einer cfg-file arbeitet...

[Beta-User]

Hier erst mal die angekündigten patches.

Zur Feier des Tages habe ich in meinem HMinfo alte templist-Files reaktiviert. Aber auch damit bekam ich keine tempList.*-Attribute angeboten....

Meinem Gefühl nach greift her der Versuch zu weit, das von dem betreffenden Hash und damit von HMinfo abhängig zu machen. Mal schauen, was Martin dann zu gegebener Zeit dazu meint.

[martinp876]

sorry, late.
die VCCU ist scheinbar mit nichts gepeert - die Schleife ist mit "leerer peerID" gestartet.
Fange ich jetzt ab

[the ratman]

meine nächste blöde frage:

Code: [Auswählen]

Revision 24961: CUL_HM:change IO clients support detection, ignore empty peerlist at ...auch noch kein grund, beta-users version zu überschreiben, oder?

[Beta-User]

Na ja, das Problem, dass hier zur Diskussion stand, ist damit gelöst.

Es macht auch Sinn, die einzelnen Themen gesondert im svn zu kennzeichnen, von daher gehe ich davon aus, dass Martin sich dann in den passenden Threads melden wird, wenn er die betreffenden Punkte angegangen war. Er wird schon besser wissen, was wie wichtig ist und wie herum es sinnvoll ist, das - unter Berücksichtigung seiner eigenen Ressourcen - jeweils anzugehen.

Falls das länger dauert, kann ich gerne versuchen, das vorläufig wieder soweit zusammenzuführen (und ggf. auch klarer zu machen, was wogegen gedacht war), dass die Tester aus diesem Thread weiter eine "hotfix"-Variante einsetzen können...

Falls jemand die "id"-Umstellung für HMLAN vorbereiten möchte:  ich gehe mal davon aus,
dass Martin nichts dagegen hat, wenn ihm jemand da was vorbereiten würde? => Freiwillige vor (ich nutze das Modul nicht und bin raus, wie es geht, ist an dem patch gut zu erkennen, und man braucht 0 Programmiererfahrung, das ist reine Fleißarbeit!)

@Martin: Bitte um Rückmeldung, falls das (in Teilen) nicht gewünscht ist .

[Beta-User]

Nachdem ich grade beim Testen der neuen Version aus dem svn gesehen habe, dass tempListTmpl wieder da ist  , bin ich's nochmal durchgegangen, was denn so an Änderungsvorschlägen da ist.

Manches ist aus sicher heraus vermutlich nicht verständlich bzw. nur mit etwas Zusatzinfo oder einer Referenz, wo es herkommt. Daher anbei eine konsolidierte Fassung samt patch, die dazu  etwas weniger schweigsam ist und hoffentlich Arbeit spart...

EDIT: Einige Anmerkungen waren unnötig bzw. auch schlicht weil der Editor da irgendeine Formatierung scheinbar durcheinandergewürfelt hat; hier daher das nochmals aktualisierte Paket... Der besseren Übersichtlichkeit halber jetzt aufgeteilt in den Nachtrag zur commandref-Überarbeitung und die eigentlichen funktionalen Änderungen.

[Beta-User]

@Martin und andere interessierte Mitleser:

Die vorgeschlagenen Modifikationen zur Konfiguration der VCCU's@startup scheinen auch gegen das AES-Kommunikationsproblem zu helfen.

[Beta-User]

Anbei dann noch ein Fix für das tempListTempl-Attribut-Thema (hoffentlich).

@Martin: Ursache war m.E. ein Dreher in den Funktionsaufrufen bei CUL_HM_AttrCheck() (neue Fassung).

#529 (Beta-User-Version)

Code: [Auswählen]

- delete $attr{$name}{$_} if (CUL_HM_AttrCheck('set',$name,$_,$attr{$name}{$_})); 
+ delete $attr{$name}{$_} if (CUL_HM_AttrCheck($name,'set',$_,$attr{$name}{$_}));  #Beta-User: fixes missing tempListTempl
EDIT: siehe auch @noansi in https://forum.fhem.de/index.php/topic,122107.msg1166930.html#msg1166930

In dem o.g. Thread sind auch noch weitere Kleinigkeiten genannt, ich werde mal versuchen, auch das vollends zu konsolidieren, update + patch folgt.

[Beta-User]

Anbei die angekündigte "konsolidierte Fassung" mit den (hoffentlich soweit vollständigen) noch nicht durch martinp876 mit eingearbeiteten Anmerkungen von noansi aus dem bereits oben verlinkten Thread - diesmal wieder als "Einheitspatch".

Ein paar Sachen kommen mir noch seltsam vor:
zum einen gibt es viele Meldungen wie diese im Log:

Code: [Auswählen]

2021.09.21 20:02:29 3: CUL_0: Unknown code ? (remove:332211 is unknown) Use one of A B b C e F G h i K k L l M m N R T t U u V W X x Y Z, help me!
Zum anderen behauptet die CUL_HM-commandref, man solle tempListTmpl auf "0" stellen, wenn man das feature deaktivieren will. Jedenfalls via FHEMWEB klappt das aber nicht, weder über das drop-down, noch über die Kommandozeile, sieht so aus, als wäre "none" gemeint, aber da meint configCheck danach immer noch, da würde was nicht zusammenpassen....

Für ersteres habe ich erst mal keine Idee, das Ding ist einfach ein VIRTUAL-model mit zwei Kanälen. Macht da HMinfo ein getConfig drauf...?
Beim zweiten paßt vermutlich irgendeine Kleinigkeit nicht, mal schauen, aber nicht mehr heute.

[Beta-User]

zum einen gibt es viele Meldungen wie diese im Log:

Code: [Auswählen]

2021.09.21 20:02:29 3: CUL_0: Unknown code ? (remove:332211 is unknown) Use one of A B b C e F G h i K k L l M m N R T t U u V W X x Y Z, help me!

Das scheint durch Zeile #10856 verursacht zu sein. Nach meinem Verständnis dürfte ein "remove"-Befehl nicht an CUL-TYPE "alte" IO's gehen, was sich durch Abfragen analog #10859  verhindern lassen sollte.

Und dann stellt sich weiter die Frage, warum das so oft durchlaufen wird. Da wurden in #10854 zwei Hash-Referenzen (?) mit != verglichen. Kommt mir komisch vor, ein "eq" sollte jedenfalls unschädlich sein.
Jedenfalls sind jetzt die unzähligen Einträge im Log passée.

Zum anderen behauptet die CUL_HM-commandref, man solle tempListTmpl auf "0" stellen, wenn man das feature deaktivieren will. Jedenfalls via FHEMWEB klappt das aber nicht, weder über das drop-down, noch über die Kommandozeile, sieht so aus, als wäre "none" gemeint, aber da meint configCheck danach immer noch, da würde was nicht zusammenpassen....

Jedenfalls nach dem Code in #11332 ist die commandref nicht aktuell, das in FHEMWEB exklusiv angebotene "none" sollte genauso gehen.
Noch unklar ist mir aber, ob die Behandlung von "unused" überall paßt, für HMinfo wird es gebraucht.

Aktualisierte Fassung wieder anbei.
Bei der ist noch "merkwürdig", dass das tempListTmpl-Attribut jetzt bei einigen wenigen meiner HM-CC-RT-DN (und dem einen WT) verfügbar ist, aber (bei weitem) nicht bei allen...? Bisher bin ich noch nicht drauf gekommen, was die Logik dahinter ist, meine im Moment einzige Vermutung wäre: Das sind die Geräte, die die bei ihnen eingestellten Solltemperaturen verteilen?

@frank (und @noansi, falls ihr mitlest): Bitte um Rückmeldung, falls ich was schwerwiegendes übersehen haben sollte.

[frank]

Das scheint durch Zeile #10856 verursacht zu sein. Nach meinem Verständnis dürfte ein "remove"-Befehl nicht an CUL-TYPE "alte" IO's gehen, was sich durch Abfragen analog #10859  verhindern lassen sollte.

sehe ich auch so.
homematic io werden prepariert, damit sie autonom mit bestimmten devices kommunizieren können (ACK, AES, ...).
für tscul io gilt es im prinzip auch, aber das handling ist teilweise unterschiedlich.
bei normalen cul werden alle messages über fhem initiiert.
für hmlan/hmuart sieht man die assigned devices über "get assignIDs". jedes device darf natürlich nur einmal assigned sein. diese listen müssen mit "get vccu listDevice" korrelieren.

Und dann stellt sich weiter die Frage, warum das so oft durchlaufen wird.

meinst du beim start, oder grundsätzlich?