Autor Thema: [10.08.21] neues cul_hm schreibt ein paar warnings ...  (Gelesen 5007 mal)

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16252
Antw:[10.08.21] neues cul_hm schreibt ein paar warnings ...
« Antwort #30 am: 10 September 2021, 13:48:24 »
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 ;) .
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline the ratman

  • Hero Member
  • *****
  • Beiträge: 2735
  • cosmoprolet & intelligenzdiabetiker
Antw:[10.08.21] neues cul_hm schreibt ein paar warnings ...
« Antwort #31 am: 10 September 2021, 15:50:52 »
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.
→do↑p!dnʇs↓shit←

Offline frank

  • Hero Member
  • *****
  • Beiträge: 10526
Antw:[10.08.21] neues cul_hm schreibt ein paar warnings ...
« Antwort #32 am: 10 September 2021, 15:59:36 »
Zitat
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.  8)
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16252
Antw:[10.08.21] neues cul_hm schreibt ein paar warnings ...
« Antwort #33 am: 10 September 2021, 17:11:04 »
...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).
« Letzte Änderung: 12 September 2021, 17:20:31 von Beta-User »
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16252
Antw:[10.08.21] neues cul_hm schreibt ein paar warnings ...
« Antwort #34 am: 10 September 2021, 18:25:40 »
@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...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16252
Antw:[10.08.21] neues cul_hm schreibt ein paar warnings ...
« Antwort #35 am: 10 September 2021, 21:10:46 »
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.
« Letzte Änderung: 12 September 2021, 17:20:12 von Beta-User »
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline martinp876

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 11040
Antw:[10.08.21] neues cul_hm schreibt ein paar warnings ...
« Antwort #36 am: 12 September 2021, 07:59:17 »
sorry, late.
die VCCU ist scheinbar mit nichts gepeert - die Schleife ist mit "leerer peerID" gestartet.
Fange ich jetzt ab

Offline the ratman

  • Hero Member
  • *****
  • Beiträge: 2735
  • cosmoprolet & intelligenzdiabetiker
Antw:[10.08.21] neues cul_hm schreibt ein paar warnings ...
« Antwort #37 am: 12 September 2021, 11:14:30 »
meine nächste blöde frage:Revision 24961: CUL_HM:change IO clients support detection, ignore empty peerlist at ...auch noch kein grund, beta-users version zu überschreiben, oder?
→do↑p!dnʇs↓shit←

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16252
Antw:[10.08.21] neues cul_hm schreibt ein paar warnings ...
« Antwort #38 am: 12 September 2021, 15:21:37 »
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 :) .
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16252
Antw:[10.08.21] neues cul_hm schreibt ein paar warnings ...
« Antwort #39 am: 12 September 2021, 17:01:44 »
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.
« Letzte Änderung: 15 Oktober 2021, 23:11:03 von Beta-User »
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16252
Antw:[10.08.21] neues cul_hm schreibt ein paar warnings ...
« Antwort #40 am: 13 September 2021, 12:09:50 »
@Martin und andere interessierte Mitleser:

Die vorgeschlagenen Modifikationen zur Konfiguration der VCCU's@startup scheinen auch gegen das AES-Kommunikationsproblem zu helfen.
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16252
Antw:[10.08.21] neues cul_hm schreibt ein paar warnings ...
« Antwort #41 am: 21 September 2021, 11:27:09 »
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)
- 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.
« Letzte Änderung: 21 September 2021, 22:52:05 von Beta-User »
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16252
Antw:[10.08.21] neues cul_hm schreibt ein paar warnings ...
« Antwort #42 am: 21 September 2021, 21:12:25 »
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:
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.
« Letzte Änderung: 15 Oktober 2021, 23:10:27 von Beta-User »
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16252
Antw:[10.08.21] neues cul_hm schreibt ein paar warnings ...
« Antwort #43 am: 22 September 2021, 20:44:49 »
zum einen gibt es viele Meldungen wie diese im Log:
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.

Zitat
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.
« Letzte Änderung: 15 Oktober 2021, 23:10:10 von Beta-User »
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline frank

  • Hero Member
  • *****
  • Beiträge: 10526
Antw:[10.08.21] neues cul_hm schreibt ein paar warnings ...
« Antwort #44 am: 23 September 2021, 11:35:32 »
Zitat
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.


Zitat
Und dann stellt sich weiter die Frage, warum das so oft durchlaufen wird.
meinst du beim start, oder grundsätzlich?
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html