FHEM - Hausautomations-Systeme > Homematic

[CUL_HM] patches Oktober 2021 - die Zweite

<< < (23/25) > >>

Benni:

--- Zitat von: Rampler am 31 Oktober 2021, 17:06:59 ---SVN und hier sollten momentan gleich sein oder ?

--- Ende Zitat ---

Würde mich auch interessieren!
Ist das was gestern noch von martinp876 und mgernoth eingecheckt wurde der Stand, der auch hier anhängt?

Aktuell habe ich nämlich bei mir genau das alles erst mal vom update ausgeschlossen.

gb#

Beta-User:
Hallo zusemmen,

--- Zitat von: Rampler am 31 Oktober 2021, 17:06:59 ---Bin mir jetzt nicht sicher, ob das hier interessiert...
Jedenfalls habe ich heute früh einen update gemacht (via SVN), bis jetzt alles gut..
SVN und hier sollten momentan gleich sein oder ?

--- Ende Zitat ---
Ganz gleich nicht, meine Kommentare sind z.B. ja zum überwiegenden Teil dafür da festzuhalten, wo die Quelle zur Lösung zu finden ist bzw. das Problem zu finden.

Im ersten Post war zu HMUARTLGW schon gestern was zu lesen, und zum Rest seit eben.

 HMLAN scheint ein Problem mit dem Einchecken zu haben, Details hatte Martin nicht mitgeteilt. Ich hatte erst die commandref im Verdacht, vermute jetzt aber eher einen neueren pre-commit-hook, z.B.  "my $foo= 'Bäh' if $baz". Mehr weiß ich im Moment nicht, also falls jemand Ideen hat oder die betreffende Stelle identifizieren kann: gerne!

Was CUL_HM betrifft, gibt es zum einen gewisse Teile (rund um autocreate), die Martin nicht übernommen hat, aber die wesentlichen Teile schon. Das im Detail durchzugehen, wird etwas dauern, bei autocreate scheine ich das nicht gut erklärt zu haben...

Nach der Meldung von @benni wg. des Loggings gehe ich auch davon aus, dass wir da so oder so noch mal nacharbeiten sollten. Aktueller Ansatz dazu wäre, ein Internal hochzählen zu lassen und bei Nichtvohandensein des Internals auch eine (erweiterte) verbose 0-Meldung ins Log zu schreiben. So sollte das einmalig passieren, und man kann am Zähler erkennen, wie gravierend das Problem ist?

Weiter war da noch was mir den AES-Keys, das noch unrund war.

Was heißt das nun:
- die svn-Fassung sollte für die meisten User ok sein, wer HMLAN im Einsatz hat, sollte bis zum Einchecken eines Updates die gepatchte von hier verwenden.
- Wer noch nicht die gepatchte Fassung hatte oder bisher nicht ins Log geschaut hatte, sollte so oder so  (von der svn-Vorversion oder einer früheren patch-Version kommend nach dem update) ins Log schauen, ob das wegen eines Konfigurationsproblems "explodiert" und die Ursache beheben
- dringliche Aktionen bzgl. update vs. Version von hier sind m.E. nicht erforderlich.
- Es wird vermutlich nochmal eine Runde geben zu den o.g. Problemen. Von daher wäre ich dankbar, wenn es wieder ein paar Tester gäbe, oder:

Falls jemand Muße hat:
- Mein nächster Ausgangspunkt betr. CUL_HM wäre wieder eine "verglichene" Version auf aktuellem svn-Stand.
- Über TYPE=autocreate kann man streiten, ich meine aber, die Prüfung auf aktiviertes Pairing sei sinnvoll. Vielleicht sollte man Martin diese vereinfachte Variante vorschlagen? (Falls ichwas übersehe, darf mich an der Stelle auch jemand wissendes bremsen).
- Es dürfte nicht so schwierig sein, die o.g. Punkte noch abzuarbeiten.
-- Speziell @benni: ggf. könntest du einen Vorschlag zu dem Counter-Thema liefern? (kann auch in die letzte patch-Fassung eingebaut sein)
-- das mit den AES-keys ist ein Sonderthema bei der Attr-Routine bzw. der NotifyFn, aber vermutlich auch nicht übermäßig komplex. Je schneller wir einen getesteten Lösungsvorschlag haben, desto schneller wird es im svn landen - also "Freiwillige vor" (auch hier ist es m.E. prinzipiell egal, welche Basis).

Hoffe, der Stand ist jetzt klarer.

frank:

--- Zitat ---HMLAN scheint ein Problem mit dem Einchecken zu haben, Details hatte Martin nicht mitgeteilt.
--- Ende Zitat ---
die lösung hatte rudi umgehend gepostet
https://forum.fhem.de/index.php/topic,110125.msg1183519.html#msg1183519

frank:

--- Zitat ---Nach der Meldung von @benni wg. des Loggings gehe ich auch davon aus, dass wir da so oder so noch mal nacharbeiten sollten. Aktueller Ansatz dazu wäre, ein Internal hochzählen zu lassen und bei Nichtvohandensein des Internals auch eine (erweiterte) verbose 0-Meldung ins Log zu schreiben. So sollte das einmalig passieren, und man kann am Zähler erkennen, wie gravierend das Problem ist?
--- Ende Zitat ---
warum so ein aufwand mit dem zähler? das ist kontraproduktiv und falsch, finde ich.
user handeln in der regel sofort, wenn das blütenweisse log beschmuddelt wird.  ;)
also: viele einträge => viel aufmerksamkeit => schnelles handeln.

benni hatte ja vermutlich schon immer einen konfigurationsfehler, der bisher nicht aufgefallen war.
wenn bennis erinnerung richtig ist und cul_hm deviceabhängig sowohl mit als auch ohne vccu arbeitet, hat cul_hm hier auch falsch gehandelt. die vccu darf hier kein io aussuchen, da nur attr IODev gesetzt war.
vermutlich war in diesen devices helper/io/vccu falsch gesetzt.

in die meldung gehört der devicename, damit man weiss welches device betroffen ist, um die konfiguration zu checken.


edit: martin erlaubt explizit gemischtes io handling

--- Zitat ---Beispiel Obsolet
Die Attribute "IOgrp" und "IOdev" schliessen sich aus. Der User kann einstellen, das die vccu sich um das IO kümmert ODER er definiert sein eigenes ODER er überlässt alles dem fhem-kernel.
--- Ende Zitat ---
https://forum.fhem.de/index.php/topic,122107.0.html

Benni:

--- Zitat von: frank am 01 November 2021, 11:08:04 ---in die meldung gehört der devicename, damit man weiss welches device betroffen ist, um die konfiguration zu checken.

--- Ende Zitat ---

Genau das hatte ich eigentlich auch gemeint mit dem "besseren Logging."

Mir ging es gar nicht um eine Reduzierung der Messages, sondern (generell) um den Informationsgehalt der Meldungen, also woher kommt der Fehler, bzw. welches device ist davon betroffen, das ist in so einem Fall hilfreich und Zielführend!

Gehäufte (gleich lautende?) Messages zu sammeln und zu reduzieren um das Log nicht zu überfüllen wäre wahrscheinlich wesentlich zentraler aufzuhängen, Da müsste man ggf. erweiterte Log-Funktionen schaffen. Glaube nicht, dass Rudi oder sonst wer da so spontan Lust dazu hat. :)

Ich denke auch: Viele Meldungen => größerer Handlungsdruck => schnellere Problemlösung!

gb#


Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete

Zur normalen Ansicht wechseln