ERR:CCA Fehler beim Senden

Begonnen von Tjareson, 26 Mai 2017, 18:03:21

Vorheriges Thema - Nächstes Thema

Tjareson

Hallo,

ich habe FHEM kürzlich vom HMLan Adapter auf die USB-CUL von busware migriert. Dabei stelle ich nun fest, dass die CUL nicht in der Lage ist zu senden, sondern quasi jeden Sendeversuch mit einem ERR:CCA Fehler quittiert. Das ist mir erst aufgefallen, als ich einen Homematic Wandtaster neu pairen wollte. (Die meisten Taster senden einfach broadcast und zudem nutze ich keine Homematic Aktoren, womit das Problem nicht sofort sichtbar wird.)
Typischerweise wird im Zusammenhang mit einem Clear Channel Assessment Fehler darauf verwiesen, dass es einen Störsender geben muss, soll heissen, eine Homematic Komponente dauerhaft sendet. Was dagegen spricht:
- Ich habe keine homematic-Aktoren und den Wandtastern wäre vermutlich längst die Batterie ausgegangen.
- Der HMLan Adapter hat kein solches Problem und kann auch Wandschalter jederzeit pairen.

Der Event-Monitor zeigt reproduzierbar folgende Einträge, wenn ich einen Wandschalter versuche zu pairen:
2017-05-26 11:40:54 CUL_HM push_bedroom02 D-firmware: 1.4
2017-05-26 11:40:54 CUL_HM push_bedroom02 D-serialNr: LEQ0572216
2017-05-26 11:40:55 CUL HMLAN1 UNKNOWNCODE ERR:CCA
2017-05-26 11:40:59 CUL_HM push_bedroom02 CMDs_pending

Die CUL ist wie folgt eingebunden:
define HMLAN1 CUL /dev/ttyACM0@9600 0000
attr HMLAN1 event-on-change-reading .*
attr HMLAN1 hmId 26EC21
attr HMLAN1 rfmode HomeMatic
Der ursprüngliche HMLan Adapter ist auskommentiert und war auf die gleiche hmId eingestellt.

Ich nutze folgende Versionen: CUL FW 1.66, FHEM Revision: 14355
HMLAN1 ccconf => freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB

Ich habe aus der firmware versuchsweise auch schon den entsprechenden CCA check aus der rf_asksin.c auskommentiert, das hat aber nicht das gewünschte Ergebnis gebracht. Ich verstehe im Moment auch zu wenig, wie der CCA tatsächlich durchgeführt wird und was die Voraussetzung für das Senden in der firmware sind.
Die Frage ist also: wieso kann der HMLan Adapter senden, die CUL aber nicht?

besten Gruß
Tjareson

amenomade

ZitatDer ursprüngliche HMLan Adapter ist auskommentiert und war auf die gleiche hmId eingestellt.
Auskommentiert heisst nicht, dass er gar nicht mehr funkt, und kein Konflikt anstosst. Ich würde versuchen, den komplett ausser Betrieb zu nehmen.

CCA = Clear Channel Assessment, und das sollte der CUL innerhalb von 2s bekommen. Wenn die Frequenz belegt ist, funktioniert das nicht. Also... erstmal den ursprüngliche HMLan stromlos machen. Dann evtl nach andere Störsender suchen.
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

Tjareson


Ach so, der HMLAN Adapter ist natürlich ausgeschaltet währenddessen, damit es da nicht zu irgendwelchen Interferenzen kommt, trotzdem bleibt der Fehler weiterhin bestehen.
Ob andere Störsender vorhanden sind, kann ich letztlich nicht sagen. Ich kann im Moment nur ausschließen, das Homematic-Komponenten wild herumfunken und muss vor allem eben auch feststellen, dass der HMLAN-Adapter keine Schwierigkeiten hat, in der gleichen Umgebung zu senden.

amenomade

Gib mal hier ein list von deinem CUL und von ein paar HM Geräte, die vermutlich noch in deiner Konfig definiert sind.

Auch ein Extrakt von der Log des CUL mit verbose 5

Ich weiss nicht, wie die HM Geräte reagieren, wenn die die gleiche hmID finden, aber nicht das selbe Gerät. Vielleicht wird es dann besser eine andere hmId zu nutzen.
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

Ralf9

Zitatich habe FHEM kürzlich vom HMLan Adapter auf die USB-CUL von busware migriert.
Gibt es eigentlich einen besonderen Grund, warum Du Dir das antust, einen gut funktionierenden HMLan gegen einen CUL, der nur unter bestimmten Bedingungen gut funktioniert, zu tauschen?

Zitat von: Otto123 am 07 Mai 2017, 10:01:04
Auf alle Fälle habe ich mit der Erklärung von Martin verstanden warum offenbar bei einigen HM mit CUL gut läuft und ansonsten viele Probleme auftauchen.
Schnelles System, wenig Last von FHEM, "einfache" HM Komponenten -> CUL geht gut.
Stark belastetet FHEM System, komplexe HM Komponenten (z.B. HM-PB-4DIS-WM) + AES -> mit CUL geht es wahrscheinlich gar nicht.
Dazwischen ist sicher jede Variante möglich.

Fallst Du es jetzt mit dem CUL einigermaßen gut hinbekommst, kannst Du es für die Zukunft ausschließen, daß Du auch komplexe HM Komponenten haben wirst?

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Tjareson

Auch wenn die Diskussion um HMLAN Adapter etwas off-topic ist: wenn das Teil funktioniert, dann ist es ok. Aber betreffend Verlässlichkeit habe ich bisher mit 2 Adaptern nur schlechte Erfahrungen gemacht: der erste war einfach irgendwann tot, auch Rücksetzen via Firmware-Update hat nicht mehr funktioniert. Bei dem zweiten musste ich in der Tat 1-2 mal pro Jahr die Firmware neu installieren via update (was dann ja eigentlich keins war, sondern nur nochmal EEPROM überschreiben). Und selbst das ist nicht unproblematisch bei den Teilen: https://forum.fhem.de/index.php?topic=21537.0
Komponenten für "Basis-Infrastruktur" müssen einfach 100% zuverlässig sein, ansonsten werden sie abgelöst.

Mein Problem habe ich zwischenzeitlich auch gelöst und lustigerweise ist die Homematic relevante Einstellung im Sourcecode für die CUL im Prinzip sogar dokumentiert. Ich bin aber erst darauf gekommen, als ich mir angesehen habe, wie für den C1101 auf der CUL die CCA Prüfung an- und abgeschaltet wird. (Für den geneigten Leser: cc1101.pdf googeln, Seite 81 im PDF)

Die Einstellungen des entsprechenden Registers finden in rf_asksin.c statt. Dort wird für das Register 0x17 (MCSM1) der Wert 0x33 angegeben, d.h. 5. und 6. Bit ist gesetzt, damit CCA aktiv. Für abgeschaltetes CCA müssen diese beiden Bits 0 sein, also 0x03. Der Quellcode hat dieses Setup auch kommentiert: "go into RX after TX, CCA; EQ3 uses 0x03".
Und siehe da: nach übersetzten mit 0x03 keine ERR:CCA Fehler mehr mit der CUL und es lässt sich auch an die Homematic Komponenten senden, Pairing machen usw.
Ich wundere mich, wie das eigentlich bei anderen funktioniert... (v1.66)

Besten Gruß.
Tjareson

rudolfkoenig

Der HM-Code in culfw ist seit langen unveraendert, Ansgar entwickelt aber aktiv sein culfw-Branch, und liegt mW den Fokus auf die Verbesserung der HM-Unterstuetzung. Achtung, sein firmware erfordert leider angepasste FHEM-Module, die nicht per FHEM-Update verteilt werden.

noansi

Hallo Tjareson,

auch ich verwende CCA in der tsculfw.
Der Vorteil liegt darin, nicht sinnlos zu senden, wenn der Kanal belegt ist, und damit auch gleichzeitig nicht zu stören.

Wenn es damit nicht klappt, dann ist Dein CUL entweder zu dicht an einer Störquelle (Absetzen mit Kabel von Deinem Host kann z.B. schon helfen) oder Du hast 868,3 MHz Störquellen in der Nähe.
Bei mir war es mal ein S200A Temperatursender, der mit nachlassender Batterie meinte, auf Dauersenden gehen zu müssen, bis die Batterie endlich leer war.

Gruß, Ansgar.