Soulman am 6. Dezember 2023 um 15:16 Uhr

2023-12-06T15:16:23Z

← Nächstältere Version		Version vom 6. Dezember 2023, 17:16 Uhr
Zeile 1:		Zeile 1:
			== 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.		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.		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.

Soulman: Begründung einer grösseren Löschung

2023-12-06T15:15:41Z

Begründung einer grösseren Löschung

← Nächstältere Version	Version vom 6. Dezember 2023, 17:15 Uhr
Zeile 1:	Zeile 1:
		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 [https://stackoverflow.com/questions/4702216/controlling-a-usb-power-supply-on-off-with-linux uhubctl].
		Wäre hilfreich, zu wissen, wie man dieses Problem sinnvoll tracen (somit: festnageln) kann.

		Device-Attribute wie <code>version</code> 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):
		: {{Link2Forum\|Topic=73144\|Message=977406\|LinkText=[Gelöst] Nanocul LED blinkt schnell}}.
		[https://www.ebay.de/itm/1-3-mal-Flash-Service-fur-ZigBee-nanoCUL-JeeLink-Shelly-Sonoff-Blitzwolf-Gosund/264472055531] 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): [https://github.com/heliflieger/a-culfw/issues/23 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: [https://hackaday.com/2015/07/03/arduinos-and-other-avrs-write-to-own-flash/ 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): [https://www.computerhilfen.de/info/usb-reset-am-raspberry-pi-usb-ports-zuruecksetzen.html], erwähnt in diesem {{Link2Forum\|Topic=77380\|Message=783352\|LinkText=Forenbeitrag}}.
		UPDATE: ein erster Test (Device herausfinden [https://unix.stackexchange.com/questions/81754/how-to-match-a-ttyusbx-device-to-a-usb-serial-device] 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.
		--[[Benutzer:Soulman\|Soulman]] ([[Benutzer Diskussion:Soulman\|Diskussion]]) 16:15, 6. Dez. 2023 (CET)

Hauswart: Die Seite wurde geleert.

2017-01-09T13:09:13Z

Die Seite wurde geleert.

← Nächstältere Version		Version vom 9. Januar 2017, 15:09 Uhr
Zeile 1:		Zeile 1:
	~~Ist der Kommentar zur Sendestärke einstellen nicht falsch?~~

	~~Laut Dokumentation: http://culfw.de/commandref.html#cmd_X~~

	~~Sind genau die ersten 5 Werte (00-04) ohne Ramping und 05-09 mit Ramping?~~

	~~Standard ist 03 (5db) und nicht 09~~

Hauswart: Die Seite wurde neu angelegt: „Ist der Kommentar zur Sendestärke einstellen nicht falsch? Laut Dokumentation: http://culfw.de/commandref.html#cmd_X Sind genau die ersten 5 Werte (00-04) o…“

2017-01-09T13:03:32Z

Die Seite wurde neu angelegt: „Ist der Kommentar zur Sendestärke einstellen nicht falsch? Laut Dokumentation: http://culfw.de/commandref.html#cmd_X Sind genau die ersten 5 Werte (00-04) o…“

Neue Seite

Ist der Kommentar zur Sendestärke einstellen nicht falsch?

Laut Dokumentation: http://culfw.de/commandref.html#cmd_X

Sind genau die ersten 5 Werte (00-04) ohne Ramping und 05-09 mit Ramping?

Standard ist 03 (5db) und nicht 09

Diskussion:CUL - Versionsgeschichte

Soulman am 6. Dezember 2023 um 15:16 Uhr

Soulman: Begründung einer grösseren Löschung

Hauswart: Die Seite wurde geleert.

Hauswart: Die Seite wurde neu angelegt: „Ist der Kommentar zur Sendestärke einstellen nicht falsch? Laut Dokumentation: http://culfw.de/commandref.html#cmd_X Sind genau die ersten 5 Werte (00-04) o…“