CUL - Versionsgeschichte

Soulman: /* Geräte, die an USB angeschlossen sind (CUL/CUN) */

2026-01-05T19:34:46Z

Geräte, die an USB angeschlossen sind (CUL/CUN)

← Nächstältere Version		Version vom 5. Januar 2026, 21:34 Uhr
Zeile 62:		Zeile 62:

	anzubinden. Damit ist sichergestellt, das "CUL1" immer das 433Mhz CUL ist.		anzubinden. Damit ist sichergestellt, das "CUL1" immer das 433Mhz CUL ist.
	~~Dabei ist allerdings zu beachten, dass original Busware CULs sich immer gleich melden.~~
	~~Wenn man also z.b. mehrere Busware 868Mhz CULs einsetzen will, werden die sich alle mit~~
	~~usb-busware.de_CUL868-if00~~
	~~melden und sind nicht unterscheidbar, während nano CULs und ähnlich oft eigene Seriennummern haben.~~

	Wenn die Baudrate mit "directio" angegeben wird (z.B.: /dev/ttyACM0@directio), wird das Perl Modul Device::SerialPort nicht benötigt und FHEM öffnet die Schnittstelle mit einfachem Dateizugriff. Dies sollte dann funktionieren, wenn das Betriebssystem vernünftige Standardwerte für die serielle Schnittstelle verwendet, wie z.B. einige Linux Distributionen oder macOS.		Wenn die Baudrate mit "directio" angegeben wird (z.B.: /dev/ttyACM0@directio), wird das Perl Modul Device::SerialPort nicht benötigt und FHEM öffnet die Schnittstelle mit einfachem Dateizugriff. Dies sollte dann funktionieren, wenn das Betriebssystem vernünftige Standardwerte für die serielle Schnittstelle verwendet, wie z.B. einige Linux Distributionen oder macOS.

Soulman: /* Geräte, die an USB angeschlossen sind (CUL/CUN) */

2026-01-05T18:52:20Z

Geräte, die an USB angeschlossen sind (CUL/CUN)

← Nächstältere Version		Version vom 5. Januar 2026, 20:52 Uhr
Zeile 48:		Zeile 48:
	/dev/ttyACM0@38400.		/dev/ttyACM0@38400.

	Wenn mehrer CULs an einem System ~~betreiben~~ werden sollen, ist es besser die CULs "by-ID" einzubinden. Es kann nämlich ansonsten sein, dass nach einem Neustart die CULs in anderen Reihenfolge zugewiesen werden als bei der Einrichtung. Insbesondere wenn man CUL868 und ~~CUL 433~~ zugleich betreibt ist das riskant, da falls die CULs sich vertauscht melden, 668 Schaltbefehle an das 433 CUL gehen und umgekehrt. Besser ist es dann die CULs an den USB Port anzustecken, dann mit		Wenn mehrer CULs an einem System betrieben werden sollen, ist es besser die CULs "by-ID" einzubinden. Es kann nämlich ansonsten sein, dass nach einem Neustart die CULs in anderen Reihenfolge zugewiesen werden als bei der Einrichtung. Insbesondere wenn man CUL868 und CUL433 zugleich betreibt ist das riskant, da falls die CULs sich vertauscht melden, 668 Schaltbefehle an das 433 CUL gehen und umgekehrt. Besser ist es dann die CULs an den USB Port anzustecken, dann mit

	ls /dev/serial/by-id		ls /dev/serial/by-id

	zu ermittlen wie sich diese melden, z.B.		zu ermittlen wie sich diese melden, z.B.

	usb-busware.de_CUL868-if00 usb-SHK_NANO_CUL_433-if00-port0		usb-busware.de_CUL868-if00 usb-SHK_NANO_CUL_433-if00-port0

Zeile 61:		Zeile 62:

	anzubinden. Damit ist sichergestellt, das "CUL1" immer das 433Mhz CUL ist.		anzubinden. Damit ist sichergestellt, das "CUL1" immer das 433Mhz CUL ist.
	Dabei ist allerdings zu beachten, ~~das~~ original Busware CULs sich immer gleich melden.		Dabei ist allerdings zu beachten, dass original Busware CULs sich immer gleich melden.
	Wenn man also z.b. mehrere Busware 868Mhz CULs einsetzen will, werden die sich alle mit		Wenn man also z.b. mehrere Busware 868Mhz CULs einsetzen will, werden die sich alle mit
	usb-busware.de_CUL868-if00		usb-busware.de_CUL868-if00

Soulman: /* Geräte, die an USB angeschlossen sind (CUL/CUN) */ Anbidung per by-ID ergänzt

2026-01-05T18:51:14Z

Geräte, die an USB angeschlossen sind (CUL/CUN): Anbidung per by-ID ergänzt

← Nächstältere Version		Version vom 5. Januar 2026, 20:51 Uhr
Zeile 46:		Zeile 46:
	Wenn der Name der Schnittstelle ein @ enthält, kann nachfolgend die verwendete Baudrate angegeben werden, z.B.:		Wenn der Name der Schnittstelle ein @ enthält, kann nachfolgend die verwendete Baudrate angegeben werden, z.B.:

	/dev/ttyACM0@38400.		/dev/ttyACM0@38400.

	Wenn mehrer CULs an einem System betreiben werden sollen, ist es besser die CULs "by-ID" einzubinden. Es kann nämlich ansonsten sein, dass nach einem Neustart die CULs in anderen Reihenfolge zugewiesen werden als bei der Einrichtung. Insbesondere wenn man CUL868 und CUL 433 zugleich betreibt ist das riskant, da falls die CULs sich vertauscht melden, 668 Schaltbefehle an das 433 CUL gehen und umgekehrt. Besser ist es dann die CULs an den USB Port anzustecken, dann mit		Wenn mehrer CULs an einem System betreiben werden sollen, ist es besser die CULs "by-ID" einzubinden. Es kann nämlich ansonsten sein, dass nach einem Neustart die CULs in anderen Reihenfolge zugewiesen werden als bei der Einrichtung. Insbesondere wenn man CUL868 und CUL 433 zugleich betreibt ist das riskant, da falls die CULs sich vertauscht melden, 668 Schaltbefehle an das 433 CUL gehen und umgekehrt. Besser ist es dann die CULs an den USB Port anzustecken, dann mit

Soulman: /* Geräte, die an USB angeschlossen sind (CUL/CUN) */

2026-01-05T18:49:50Z

Geräte, die an USB angeschlossen sind (CUL/CUN)

← Nächstältere Version		Version vom 5. Januar 2026, 20:49 Uhr
Zeile 44:		Zeile 44:
	In diesem Fall ist diese Schnittstelle dann wahrscheinlich /dev/ttyUSB0.		In diesem Fall ist diese Schnittstelle dann wahrscheinlich /dev/ttyUSB0.

	Wenn der Name der Schnittstelle ein @ enthält, kann nachfolgend die verwendete Baudrate angegeben werden, z.B.: /dev/ttyACM0@38400.		Wenn der Name der Schnittstelle ein @ enthält, kann nachfolgend die verwendete Baudrate angegeben werden, z.B.:

			/dev/ttyACM0@38400.

	Wenn mehrer CULs an einem System betreiben werden sollen, ist es besser die CULs "by-ID" einzubinden. Es kann nämlich ansonsten sein, dass nach einem Neustart die CULs in anderen Reihenfolge zugewiesen werden als bei der Einrichtung. Insbesondere wenn man CUL868 und CUL 433 zugleich betreibt ist das riskant, da falls die CULs sich vertauscht melden, 668 Schaltbefehle an das 433 CUL gehen und umgekehrt. Besser ist es dann die CULs an den USB Port anzustecken, dann mit		Wenn mehrer CULs an einem System betreiben werden sollen, ist es besser die CULs "by-ID" einzubinden. Es kann nämlich ansonsten sein, dass nach einem Neustart die CULs in anderen Reihenfolge zugewiesen werden als bei der Einrichtung. Insbesondere wenn man CUL868 und CUL 433 zugleich betreibt ist das riskant, da falls die CULs sich vertauscht melden, 668 Schaltbefehle an das 433 CUL gehen und umgekehrt. Besser ist es dann die CULs an den USB Port anzustecken, dann mit

Soulman: /* Geräte, die an USB angeschlossen sind (CUL/CUN) */

2026-01-05T18:49:08Z

Geräte, die an USB angeschlossen sind (CUL/CUN)

← Nächstältere Version		Version vom 5. Januar 2026, 20:49 Uhr
Zeile 45:		Zeile 45:

	Wenn der Name der Schnittstelle ein @ enthält, kann nachfolgend die verwendete Baudrate angegeben werden, z.B.: /dev/ttyACM0@38400.		Wenn der Name der Schnittstelle ein @ enthält, kann nachfolgend die verwendete Baudrate angegeben werden, z.B.: /dev/ttyACM0@38400.

			Wenn mehrer CULs an einem System betreiben werden sollen, ist es besser die CULs "by-ID" einzubinden. Es kann nämlich ansonsten sein, dass nach einem Neustart die CULs in anderen Reihenfolge zugewiesen werden als bei der Einrichtung. Insbesondere wenn man CUL868 und CUL 433 zugleich betreibt ist das riskant, da falls die CULs sich vertauscht melden, 668 Schaltbefehle an das 433 CUL gehen und umgekehrt. Besser ist es dann die CULs an den USB Port anzustecken, dann mit

			ls /dev/serial/by-id

			zu ermittlen wie sich diese melden, z.B.
			usb-busware.de_CUL868-if00 usb-SHK_NANO_CUL_433-if00-port0

			und diese dann mit

			define CUL1 CUL /dev/serial/by-id/usb-SHK_NANO_CUL_433-if00-port0@38400 0000
			define CUL2 CUL /dev/serial/by-id/usb-busware.de_CUL868-if00@38400 1234

			anzubinden. Damit ist sichergestellt, das "CUL1" immer das 433Mhz CUL ist.
			Dabei ist allerdings zu beachten, das original Busware CULs sich immer gleich melden.
			Wenn man also z.b. mehrere Busware 868Mhz CULs einsetzen will, werden die sich alle mit
			usb-busware.de_CUL868-if00
			melden und sind nicht unterscheidbar, während nano CULs und ähnlich oft eigene Seriennummern haben.

	Wenn die Baudrate mit "directio" angegeben wird (z.B.: /dev/ttyACM0@directio), wird das Perl Modul Device::SerialPort nicht benötigt und FHEM öffnet die Schnittstelle mit einfachem Dateizugriff. Dies sollte dann funktionieren, wenn das Betriebssystem vernünftige Standardwerte für die serielle Schnittstelle verwendet, wie z.B. einige Linux Distributionen oder macOS.		Wenn die Baudrate mit "directio" angegeben wird (z.B.: /dev/ttyACM0@directio), wird das Perl Modul Device::SerialPort nicht benötigt und FHEM öffnet die Schnittstelle mit einfachem Dateizugriff. Dies sollte dann funktionieren, wenn das Betriebssystem vernünftige Standardwerte für die serielle Schnittstelle verwendet, wie z.B. einige Linux Distributionen oder macOS.

Soulman: Umformatiert, typos

2023-12-06T16:05:12Z

Umformatiert, typos

← Nächstältere Version		Version vom 6. Dezember 2023, 18:05 Uhr
Zeile 1:		Zeile 1:
	Ein '''CUL''' ('''C'''C1101 '''U'''SB '''L'''ite) ist eine Radiofrequenz/USB-Schnittstelle bestehend aus einem USB-Dongle mit externer [[CUL Ausstattung\|Antenne]]. Im USB-Stecker kann ein 8 bit Atmel Prozessor die im ISM/SRD-Band empfangenen RF-Daten onboard vorverarbeiten. Je nach aufgespielter [[#FW\|Firmware]] kann das CUL verschiedene 868MHz [[CUL HomeMatic und FS20\|Protokolle]] empfangen und senden, insbesondere die FS20/FHT/S300/EM/HMS Protokollfamilien. Durch eine kurzzeitige Umschaltung auf 433 MHz sind weitere Protokolle zugänglich, z. B. Intertechno, viele Baumarkt-Funksteckdosen.		Ein '''CUL''' ('''C'''C1101 '''U'''SB '''L'''ite) ist eine Radiofrequenz/USB-Schnittstelle bestehend aus einem USB-Dongle mit externer [[CUL Ausstattung\|Antenne]]. Im USB-Stecker kann ein 8 bit Atmel Prozessor die im ISM/SRD-Band empfangenen RF-Daten onboard vorverarbeiten. Je nach aufgespielter [[#FW\|Firmware]] kann das CUL verschiedene 868MHz [[CUL HomeMatic und FS20\|Protokolle]] empfangen und senden, insbesondere die FS20/FHT/S300/EM/HMS Protokollfamilien. Durch eine kurzzeitige Umschaltung auf 433 MHz sind weitere Protokolle zugänglich, z. B. Intertechno, viele Baumarkt-Funksteckdosen.

			== CUL HW ==
			Im Zusammenhang mit diesem Artikel ist vor allem vom "echten" CUL die Rede, als dem USB Hardware-Dongle des Hersteller Busware. Es gibt aber diverse andere Hardware-Schnittstellen, die sich ebenfalls wie ein CUL verhalten, z.b. Netzwerkattached Module ([[CUN]]O), Module zum direkten Aufstecken auch einen Raspberry Pi ([[COC]]), und auf Arduino basierende Lösungen ([[SIGNALduino]]).


			== Einführung ==
	Die Firmware (culfw) ist quelloffen. Sie wird auch von verwandten Schnittstellen verwendet, siehe [[CUNO]] (RF+OneWire/LAN-Übergang), [[COC]] (RF+OneWire/Rasberrybus-Übergang), CSM usw.		Die Firmware (culfw) ist quelloffen. Sie wird auch von verwandten Schnittstellen verwendet, siehe [[CUNO]] (RF+OneWire/LAN-Übergang), [[COC]] (RF+OneWire/Rasberrybus-Übergang), CSM usw.

Zeile 19:		Zeile 24:
	Frequenz und Bandbreite können daher im ''SlowRF'' Mode frei angepasst und somit für die örtlichen Empfangsgegebenheiten optimiert werden.		Frequenz und Bandbreite können daher im ''SlowRF'' Mode frei angepasst und somit für die örtlichen Empfangsgegebenheiten optimiert werden.

	~~== CUL HW ==~~
	Im Zusammenhang mit diesem Artikel ist vor allem vom "echten" CUL die Rede, als dem USB Hardware-Dongel des Hersteller Busware. Es gibt aber diverse andere Hardware-Schnittstellen, die sich ebenfalls wie ein CUL verhalten, z.b. Netzwerkaattached Module (CUNO), modulle zum direkten aufstecken auch einen Rapbi (COC), und auf Ardunino basierenende Lösugnen.

	== Definition in FHEM ==		== Definition in FHEM ==

Soulman: definition ergänzt

2023-12-06T16:00:11Z

definition ergänzt

@@ Zeile 18: / Zeile 18: @@
 Frequenz und Bandbreite können daher im ''SlowRF'' Mode frei angepasst und somit für die örtlichen Empfangsgegebenheiten optimiert werden.
 == Hinweise zum Betrieb mit FHEM ==
@@ Zeile 173: / Zeile 203: @@
 * Hersteller / Bezugsquelle für CUL: [http://www.busware.de/tiki-index.php?page=CUL busware.de]
 * Google groups [https://groups.google.com/group/cul-fans/ CUL fans], mittlerweile durch das Board {{Link2Forum|Area=cul-fans}} im FHEM Forum ergänzt/ersetzt
 [[Kategorie:Interfaces]]

Soulman: Umfangreiche Löschung von forenartigen Einträgen der Lösungsgeschichte einer Einzelperson, siehe Diskussion

2023-12-06T15:17:29Z

Umfangreiche Löschung von forenartigen Einträgen der Lösungsgeschichte einer Einzelperson, siehe Diskussion

← Nächstältere Version		Version vom 6. Dezember 2023, 17:17 Uhr
Zeile 162:		Zeile 162:
	*: <code>set CUL bWidth 464</code>		*: <code>set CUL bWidth 464</code>

	~~=== Ü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).

	== Selbstbau-/Bastelprojekte ==		== Selbstbau-/Bastelprojekte ==

Ph1959de: Link auf Modul(Stub-)Seite eingefügt

2023-03-06T16:23:30Z

Link auf Modul(Stub-)Seite eingefügt

← Nächstältere Version		Version vom 6. März 2023, 18:23 Uhr
Zeile 5:		Zeile 5:
	Im Umfeld von FS20/FHT/EM/S300/HMS ("[[Rfmode\|rfmode]] - [[SlowRF]]") werden die amplitudenmodulierten 1 kHz breiten Signale per [[#FW\|culfw]] direkt dekodiert und dann per USB weitergegeben.		Im Umfeld von FS20/FHT/EM/S300/HMS ("[[Rfmode\|rfmode]] - [[SlowRF]]") werden die amplitudenmodulierten 1 kHz breiten Signale per [[#FW\|culfw]] direkt dekodiert und dann per USB weitergegeben.

	Das CUL kann mittels des ~~CULModuls~~ von FHEM angesprochen und somit wie eine FHZ1X00PC verwendet werden.		Das CUL kann mittels des '''[[CUL (Modul)\|CUL Moduls]]''' (00_CUL.pm) von FHEM angesprochen und somit wie eine FHZ1X00PC verwendet werden.

	Das CUL kann auch im HM-Mode als HomeMatic Zentrale alternativ zur CCU oder dem [[HMLAN Konfigurator]] betrieben werden. Bei CULs älter als Version 3 ist jedoch der Speicher zu klein, um die Software für FS20/FHT/S300/EM/HMS und HomeMatic zugleich im Speicher zu halten, hier muss man sich beim [[CUL an einer Fritzbox 7390 flashen\|Flashen]] der Firmware für eine Protokollfamilie entscheiden. Mit zwei CULs ist aber auch der Mischbetrieb an einem FHEM Hostrechner möglich. Es ist jedoch nicht angeraten, den CUL bei HM-Geräten zu verwenden, siehe {{Link2Forum\|Topic=68145\|LinkText=Link}}		Das CUL kann auch im HM-Mode als HomeMatic Zentrale alternativ zur CCU oder dem [[HMLAN Konfigurator]] betrieben werden. Bei CULs älter als Version 3 ist jedoch der Speicher zu klein, um die Software für FS20/FHT/S300/EM/HMS und HomeMatic zugleich im Speicher zu halten, hier muss man sich beim [[CUL an einer Fritzbox 7390 flashen\|Flashen]] der Firmware für eine Protokollfamilie entscheiden. Mit zwei CULs ist aber auch der Mischbetrieb an einem FHEM Hostrechner möglich. Es ist jedoch nicht angeraten, den CUL bei HM-Geräten zu verwenden, siehe {{Link2Forum\|Topic=68145\|LinkText=Link}}

AndreasMohr: Typos

2022-09-13T20:48:40Z

Typos

← Nächstältere Version		Version vom 13. September 2022, 22:48 Uhr
Zeile 39:		Zeile 39:
	*: <code> get myCUL raw T03</code> Ergebnis Bytes in HEX. Leer = 4a		*: <code> get myCUL raw T03</code> Ergebnis Bytes in HEX. Leer = 4a
	* Inhalt des FHT Buffers		* Inhalt des FHT Buffers
	*: <code> get myCUL raw T02</code> (CUL V2 Buffer ist 74 Bytes ~~gross~~, Platz für 14 bis 31 FHT Messages). Rückgabe n/a = Buffer ist leer		*: <code> get myCUL raw T02</code> (CUL V2 Buffer ist 74 Bytes groß, Platz für 14 bis 31 FHT Messages). Rückgabe n/a = Buffer ist leer
	* Eingestellte [[Was_ist_der_Hauscode%3F\|FHT-ID]]		* Eingestellte [[Was_ist_der_Hauscode%3F\|FHT-ID]]
	*: <code> get myCUL raw T01</code>		*: <code> get myCUL raw T01</code>
Zeile 70:		Zeile 70:
	Das CUL gibt es in mehreren Versionen, die sich überwiegend in Prozessor und Speicherkonfiguration unterscheiden.		Das CUL gibt es in mehreren Versionen, die sich überwiegend in Prozessor und Speicherkonfiguration unterscheiden.

	* CUL V1 - AT90USB162 Prozessor, 0,~~5Kb~~ RAM, ~~16Kb~~ Flashmemory, 0,5 ~~kByte~~ EEPROM. Einsatzfähigkeit unbekannt (aber vermutlich wie V2). Wird nicht mehr hergestellt.		* CUL V1 - AT90USB162 Prozessor, 0,5 kB RAM, 16 kB Flashmemory, 0,5 kB EEPROM. Einsatzfähigkeit unbekannt (aber vermutlich wie V2). Wird nicht mehr hergestellt.
	* CUL V2 - AT90USB162 Prozessor, 0,~~5Kb~~ RAM, ~~16Kb~~ Flashmemory, 0,5 ~~kByte~~ EEPROM. Einsatzfähig. Der Flashspeicher ist jedoch zu klein für eine culfw (CUL Firmware), die Code für ''SlowRF'' Geräte und zugleich ''HomeMatic'' Geräte enthält. Es muss also vor dem Flashen der Firmware zwischen zwei jeweils reduzierten Versionen gewählt werden. Da ein CUL ohnehin nicht beide Sendemodi '''zeitgleich''' betreiben kann, ist dies keine wirkliche Einschränkung. Wird nicht mehr hergestellt.		* CUL V2 - AT90USB162 Prozessor, 0,5 kB RAM, 16 kB Flashmemory, 0,5 kB EEPROM. Einsatzfähig. Der Flashspeicher ist jedoch zu klein für eine culfw (CUL Firmware), die Code für ''SlowRF'' Geräte und zugleich ''HomeMatic'' Geräte enthält. Es muss also vor dem Flashen der Firmware zwischen zwei jeweils reduzierten Versionen gewählt werden. Da ein CUL ohnehin nicht beide Sendemodi '''zeitgleich''' betreiben kann, ist dies keine wirkliche Einschränkung. Wird nicht mehr hergestellt.
	* CUL V3 - ATMega32U4 Prozessor, 2,5 kB RAM, 32 kB Flashmemory, 1 ~~kByte~~ EEPROM). Voll einsatzfähig.		* CUL V3 - ATMega32U4 Prozessor, 2,5 kB RAM, 32 kB Flashmemory, 1 kB EEPROM). Voll einsatzfähig.
	* CUL V4 - ATMega32U2 Prozessor, 1 kB RAM 32 kB Flashmemory, 1 ~~kByte~~ EEPROM. Voll einsatzfähig. Genaugenommen ein "Sparmodell" des V3, um Lieferengpässe des ATMega32U4 Prozessors zu umgehen. Der reduzierte RAM-Speicher verursacht (zumindest gegenwärtig) beim Betrieb mit culfw und FHEM keine Einschränkungen oder Nachteile. Achtung: Flashen des CULv4 setzt DFU-Programmer 0.5.4 oder höher voraus.		* CUL V4 - ATMega32U2 Prozessor, 1 kB RAM, 32 kB Flashmemory, 1 kB EEPROM. Voll einsatzfähig. Genaugenommen ein "Sparmodell" des V3, um Lieferengpässe des ATMega32U4 Prozessors zu umgehen. Der reduzierte RAM-Speicher verursacht (zumindest gegenwärtig) beim Betrieb mit culfw und FHEM keine Einschränkungen oder Nachteile. Achtung: Flashen des CULv4 setzt DFU-Programmer 0.5.4 oder höher voraus.

	Die für die aktuellen Modelle lieferbare Abschirmung ist in der Regel nicht notwendig.		Die für die aktuellen Modelle lieferbare Abschirmung ist in der Regel nicht notwendig.
Zeile 120:		Zeile 120:
	Weitere Informationen sind im {{Link2Forum\|Topic=93021\|LinkText=Antennenthread}} des Forums zu finden.		Weitere Informationen sind im {{Link2Forum\|Topic=93021\|LinkText=Antennenthread}} des Forums zu finden.

	Über besondere Antennenkonstruktionen (bitte nach Colinear, Jpole, Yagi suchen) oder Antennen die "Lambda/2" oder gar ("Lambda") lang sind (also ca. 17,2 bzw. 34,5 Zentimeter) kann ein höherer Gewinn erreicht werden. Einher geht aber gleichzeitig eine stärkere Richtwirkung der Antenne. Je kürzer die Antenne, desto kugelförmiger die Abstrahlung. Bei längeren Antennen wird die Abstrahlung mehr und mehr zylinderähnlich, also mit horizontaler Richtwirkung (und in die Richtung ist das Signal dann stärker, daher der Antennen"gewinn").		Über besondere Antennenkonstruktionen (bitte nach Colinear, Jpole, Yagi suchen) oder Antennen die "Lambda/2" oder gar "Lambda" lang sind (also ca. 17,2 bzw. 34,5 Zentimeter) kann ein höherer Gewinn erreicht werden. Einher geht aber gleichzeitig eine stärkere Richtwirkung der Antenne. Je kürzer die Antenne, desto kugelförmiger die Abstrahlung. Bei längeren Antennen wird die Abstrahlung mehr und mehr zylinderähnlich, also mit horizontaler Richtwirkung (und in die Richtung ist das Signal dann stärker, daher der Antennen"gewinn").
	Das hat auch Nachteile, speziell wenn man auch "nach oben" funken will. Besonders wenn man Antennen länger als eine λ/4 Antenne (8,6 Zentimeter) in einem mehretagigen Haus verwenden will, muss man diese daher in der Regel waagerecht/horizontal ausrichten, da alles was in Richtung der Spitze (und dem Fuss) der Antenne liegt schlecht empfangen wird.		Das hat auch Nachteile, speziell wenn man auch "nach oben" funken will. Besonders wenn man Antennen länger als eine λ/4 Antenne (8,6 Zentimeter) in einem mehretagigen Haus verwenden will, muss man diese daher in der Regel waagerecht/horizontal ausrichten, da alles was in Richtung der Spitze (und dem Fuss) der Antenne liegt schlecht empfangen wird.

Zeile 130:		Zeile 130:

	== Antennenlänge ==		== Antennenlänge ==
	Die genauen Antennenlängen sind praktisch schwer zu ermitteln, da auch Zuleitung auf dem CUL zugerechnet werden müssten und ggf Dämpfungen (also z.B. Durchführung der Antenne durch ~~eine~~ Gehäuse, oder gebogene Antennen) die Antennenlänge weiter beeinflussen. Gleichzeitig haben schon Abweichungen von wenigen Millimetern messbaren Einfluss. Die Antennenlänge ist daher immer nur ein Kompromiss.		Die genauen Antennenlängen sind praktisch schwer zu ermitteln, da auch Zuleitung auf dem CUL zugerechnet werden müssten und ggf Dämpfungen (also z.B. Durchführung der Antenne durch ein Gehäuse, oder gebogene Antennen) die Antennenlänge weiter beeinflussen. Gleichzeitig haben schon Abweichungen von wenigen Millimetern messbaren Einfluss. Die Antennenlänge ist daher immer nur ein Kompromiss.

	Exakt berechnet ohne Störeinflüsse wären folgende Antennenlängen nutzbar:		Exakt berechnet ohne Störeinflüsse wären folgende Antennenlängen nutzbar:
Zeile 151:		Zeile 151:

	=== RF-Tuning ===		=== RF-Tuning ===
	Im Gegensatz zu den original FHZ-Zentralen ist das CUL recht schmalbandig, d.h. die Sende- und Empfangsfrequenz wird genauer eingehalten als z. B. bei einer FHZ1x00PC. Dies kann im Zusammenhang mit den eher ungenauen Sendern z. B. der FHT Raumregler zu Empfangsproblemen führen. Es kann daher mitunter sinnvoll sein, die Sende- und Empfangsbandbreite des CUL etwas zu erhöhen. Dies senkt jedoch gleichzeitig die Empfindlichkeit.		Im Gegensatz zu den original FHZ-Zentralen ist das CUL recht schmalbandig, d.h. die Sende- und Empfangsfrequenz wird genauer eingehalten als z. B. bei einer FHZ1x00PC. Dies kann im Zusammenhang mit den eher ungenauen Sendern (z. B. der FHT Raumregler) zu Empfangsproblemen führen. Es kann daher mitunter sinnvoll sein, die Sende- und Empfangsbandbreite des CUL etwas zu erhöhen. Dies senkt jedoch gleichzeitig die Empfindlichkeit.

	Bei Empfangsproblemen von z. B. HEM-Sensoren oder dem S300TH kann man folgendes testen:		Bei Empfangsproblemen von z. B. HEM-Sensoren oder dem S300TH kann man folgendes testen: