Diskussion:CUL
Abschnittslöschungen aus dem Artikel
Ich habe mir erlaubt mal diesen ganzen Abschnitt mit den LockUps, Kabeldicken, ach ne doch nicht?, nanCUL Problemen und so aus dem Artikel zu entfernen. Das sind im Grunde eher Forumseinträge und es hilft dem Interessierten nicht unbedingt weiter wenn er im Artikel lesen muss, was eine einzelner Nutzer mal dachte was seine spezifischen Probleme löste und das war - "update"- dann doch nicht der Fall.
Auch die Hinweise auf eine Fehlkonfiguration von Sendpool gehört hier nicht rein, wenn schon dann in den Artikel zu "Sendpool". Es so darzustellen als sei es ein Bug in der culfw, weil das CUL bei Fehlkonfiguration ... fehlfunktioniert ... halte ich auch für eher weit hergeholt.
Kurzum: So funktionieren Wikiartikel eher nicht denke ich, da sollten gesicherte Erkenntnisse stehen.
Insgesamt muss das, wenn es drin bleiben soll, deutlich gekürzt und die Vermutungen und persönliche Einzelerfahrungen bereinigt werden.
_______________gelöschter___abschnitt___________________________________________________
Übertragungs-Stall nach zu vielen Einträgen in der Queue
Ich habe mich ewig damit rumgeärgert, dass die Übertragung zu bestimmten häufig angesprochenen Geräten zusammenbrach, sobald die Queue zu lang wurde (FHEM: 'list CUL'). Irgendwann habe ich dann zufällig herausgefunden, dass dieses sehr fragwürdige Anwachsen der Queue an einer krassen Sendpool-Fehlkonfiguration lag: ich hatte dort ein Transceiver-Device mit angegeben, welches den Sendpool-Mechanismus (noch) gar nicht unterstützt! Sobald ich dieses falsche Gerät aus der Sendpool-Element-Liste entfernt hatte, war Ruhe --> BUG im Modul (es kann nicht sein, dass ein Device ohne Sendpool-Support das Queue-Handling so zerschießt). Dieser Bug existiert allerdings wohl weiterhin (das Perl-Handling war mir etwas zu verwirrend, um direkt zu sehen, wo das Problem ist) --> sollte nachgestellt und gefixt werden.
Harter Lockup des CUL
Trotz behobenem (erkanntem) Queue-Problem gibt es weiterhin Probleme ("Problem #2"): es passiert - recht selten -, dass sich der nanoCUL komplett aufhängt, mit hektisch blinkender LED. Es ist in diesem Fall noch nicht einmal mit dem Reset-Taster möglich, den Stick zu resetten - es ist also tatsächlich nötig, das USB-Kabel komplett zu ziehen. Wenigstens automatisieren lassen würde sich dieser Workaround wohl per uhubctl. Wäre hilfreich, zu wissen, wie man dieses Problem sinnvoll tracen (somit: festnageln) kann.
Device-Attribute wie version etc. könnten evt. den Zeitpunkt der letzten Aktivität verdeutlichen; dann im FHEM-Log um diesen Zeitpunkt herum suchen, um Auffälligkeiten/Spezialitäten zu erkennen. Und dann muss man, wenn man Pech hat, eine custom culfw bauen, die entsprechendes Reporting mit eingebaut hat...
(nanoCUL; V 1.26.00 a-culfw Build: 267).
UPDATE: die Lösung des Problems steht evtl. im Forum (Lockup beseitigt durch Optiboot bootloader):
- [Gelöst Nanocul LED blinkt schnell].
[1] scheint das zu bestätigen: "Weiterhin bieten wir beim nanoCUL an, einen alternativen Bootloader (Optiboot Bootloader) zu flashen. Dieser verhindert das Abstürzen des nanoCUL's im Betrieb z.B. bei FHEM. (Stichwort: opened)"
--> Empfehlung: Redundanz für nahtlosen Weiterbetrieb schaffen: weiteren CUL kaufen, dessen Inbetriebnahme erfolgreich testen, dann einen der CULs auf optiboot umflashen (...lassen? Siehe bekanntes Online-Auktionshaus...), und testen. (Idee: dreckiger Workaround: mit mehreren CULs könnte man sich auch ein Script schreiben, das zwischen ihnen umschalten kann, sobald es mal wieder Probleme gibt)
Ein weiterer Bericht über CUL-Lockups (dort reproduzierbar/deterministisch, und Regression-Bug): Selfmade Cul freezing with blinking LED when sending ITv3 messages #23
Randnotiz: interessante Optiboot-Modifikation, die es trotz Hardware-Sperren erreicht, per Software den Bootloader-Bereich zu flashen: Arduinos (and Other AVRs) Write To Own Flash
Evt. ist auch ein USB-Port-Reset ein funktionierender Workaround (bitte Text als bestätigt umformulieren, falls das hilft): [2], erwähnt in diesem Forenbeitrag. UPDATE: ein erster Test (Device herausfinden [3] via fhem log infos etc., fhem shutdown, usbreset, start fhem) hat bei mir nicht funktioniert ("get ccconf" --> "No FD").
Ständige Lockups Falls Lockups gefühlt "ständig" passieren sollten (alle paar Tage, oder fast täglich insb. bei warmem Wetter), dann könnte es z.B. an einem schlechten/kaputten Kabel liegen (bei mir: dünne USB-2-"Drachenschnur", mit Bissmarken o.ä. - durch ein gutes dickes USB-3-Kabel ersetzt und sofort dramatisch robuster - UPDATE: das war der erste Eindruck innerhalb weniger Tage, aber längerfristig war es gefühlt nicht wirklich besser).
_____________________________________________________________________________________
Ich will hier dem Ersteller dieses Erfahrungsbereichtes nicht auf die Füsse treten, zumal man da eine "Leidengeschichte"rauslesen kann, aber wir sollten überlegen, was andern Lesern tatsächlich verwertbare Informationen liefert. --Soulman (Diskussion) 16:15, 6. Dez. 2023 (CET)