CUL_RFR spricht nicht mit CUL

[Kako]

So, jetzt komme ich nicht mehr weiter. Ich hoffe nun auf Tipps aus dem Forum, dass ich schon intensiv nach dem Thema abgesucht habe.

Ich habe schon fast zwei Jahre FHEM mit einem CUL im Einsatz. Durch Optimierung der Einstellungen und Ausrichtung habe ich ordentlichen Kontakt zu allen FHTs, aber der FS20TK arbeitet mir nicht zuverlässig genug. Zur besseren Abdeckung im FS20-Bereich versuche ich nun langsam schon verzweifelt einen CUL_RFR zum Laufen zu bringen, aber es klappt nicht.

Meine Zenrale ist eine FritzBox 7390 mit Firmware 06.01.

Mein Haupt-CUL hat die Version 3.2 mit culfw V 1.57 CUL686.

Den CUL (CUL_RFR) Version 3.4 habe ich über die FritzBox ebenfalls auf culfw V 1.57 CUL686 geflashed.

Ursprünglich habe ich das über den gleichen USB-Port an der FritzBox gemacht und mir durch die fhem.cfg und den Zeilen

define CUL_0 CUL /dev/ttyACM0@9600 1034
attr CUL_0 rfmode SlowRF

versehentlich die gleiche FHTID auf beide CULs konfiguriert. Das habe ich dann behoben, in dem ich beide CULs auf Werkszustand (set CUL_0 raw e und set CUL_1RFR raw e) zurücksetzte und beide PORTs der FritzBox benutzte. In der fhem.cfg stand dann:

define CUL_1RFR CUL /dev/ttyACM1@9600 0000
attr CUL_1RFR rfmode SlowRF

define CUL_0 CUL /dev/ttyACM0@9600 1034
attr CUL_0 rfmode SlowRF

Die sens- und freq-Werte habe ich dann einheitlich auf meine optimierten Werte geändert. Außerdem sind die Sendestärke (raw x08) und LED (raw l00) geändert.

Die besonderen Einstellungsänderungen waren dann:

set CUL_0 raw ui0100
set CUL_1RFR raw ui0201

In der fhem.cfg habe ich dann nach dem Abziehen des CUL_1RFR die folgenden zwei Zeilen auskommentiert

# define CUL_1RFR CUL /dev/ttyACM1@9600 0000
# attr CUL_1RFR rfmode SlowRF

und dafür

define CUL_1RFR CUL_RFR 02 01

eingetragen.

Wenn beide CULs an der FritzBox stecken, dann scheinen beide zu arbeiten. Wenn ich dupTimeout klein mache, dann schlagen die Signale doppelt ein.

Wenn ich den CUL_1RFR an eine USB-Stromquelle anschließe, dann ist er nicht erreichbar. Kommandos wie version, ccconf etc. liefern einen Timeout oder No answer. Die LED am CUL_1RFR blink allerdings beim Senden/Empfangen.

Getestet:

get CUL_0 raw u (Antwort: CUL_0 raw => 0100)
get CUL_1RFR raw u (Antwort: CUL_1RFR raw => No answer meistens und auch mal CUL_1RFR raw => T250A00A60017 oder CUL_1RFR raw => T315800A6010F)
get CUL_1RFR raw u (Antwort wenn der Stick an der FritzBox hängt: CUL_1RFR raw => 0201)
{ $defs{CUL_1RFR}{TYPE} } (Antwort: CUL_RFR)
{ $modules{CUL_1RFR}{Clients} } (Antwort: nix) oder muss es heißen
{ $modules{CUL_RFR}{Clients} } (Antwort: auch nix)

Hat jemand eine Idee woran es liegt, oder was ich falsch gemacht habe. FHEM ist die aktuelle Version.

Gruß, Karsten

[rudolfkoenig]

Es klingt alles richtig, hier ein paar Ideen zum debuggen:

- mit "get CUL raw u" sieht man die eingestellten RFR-Adressen

- evtl. vertragen sich die "optimalen" sens/freq/x Werte nichtmit RFR-Uebertragung: das RFR fordert das CUL per "normalen" SlowRF-Ping auf, auf FastRF zu wechseln. Wenn SlowRF unguenstig verstellt ist, dann klappt das nicht. Am besten sollten beide gleich eingestellt sein. l00 hat keine Auswirkung.

- debuggen ist aufwendig: RFR an Rechner anschliessen, und hier mit screen/hyperterm beobachten. Man muss feststellen, ob das RFR die Aufforderung des CULs nicht hoert, bzw. ob das CUL die Antwort des RFRs. Im screen/hyperterm muesste man diverse Ausgaben sehen. Man kann  das RFR mit "X21" gefolgt von "fr" manuell ins FastRF schalten, um das Problem weiter einzugrenzen. Reset der FastRf ist mit "fx", "X21" oder eber abstecken/einstecken.

- bei mir ist CUL mit Version 1.55 und RFR mit Version 1.53 in Betrieb, neuere habe ich nicht getestet.

Nur aus Neugier: wieso $modules{CUL_1RFR}{Clients} ? Richtig waere $defs{CUL_1RFR}{Clients}, aber daraus lernt man wenig.

[Kako]

Hallo Rudorf,
danke für die Info, dass ich mich wohl nicht ganz blöd angestellt und nichts offensichtliches übersehen habe.

get CUL_0 raw u (Antwort: CUL_0 raw => 0100)
get CUL_1RFR raw u (Antwort: CUL_1RFR raw => No answer meistens und auch mal CUL_1RFR raw => T250A00A60017 oder CUL_1RFR raw => T315800A6010F)
get CUL_1RFR raw u (Antwort wenn der Stick an der FritzBox hängt: CUL_1RFR raw => 0201)

Scheint mir soweit richtig eingestellt zu sein, sofern der RFR an der FritzBox hängt und dann antwortet.

Die CULs sind gleich eingestellt und die Werte nicht unbedingt ungewöhnlich:

CUL_0 ccconf => freq:868.330MHz bWidth:325KHz rAmpl:42dB sens:8dB
CUL_1RFR ccconf => freq:868.330MHz bWidth:325KHz rAmpl:42dB sens:8dB

Mit diesen Werten waren die RSSi für alle Geräte dann im nutzbaren Bereich.

Mit dem Debuggen muss ich mich erst noch beschäftigen, so tief bin ich bisher nicht eingestiegen. Ich habe aber auch schon vermutet, dass das Hochschalten in die höhere Übertragungsfrequenz zwischen den CULs das Problem sein könnte. Irgendwo stand, dass es bei bestimmten Hardwareversionen (3.1?) nicht geht. Trifft das auf 3.2 oder 3.4 eventuell auch zu?

Vielleicht sollte ich mal mit Deine Firmware-Versionen flashen, da gab es wohl gelegentlich auch schon Probleme in manchen Versionen, soweit ich das im Forum sehen konnte.

Zur Neugier...
Das hatte ich aus einer Antwort von Dir, aber da hast Du Dich möglicherweise selbst verschrieben.
http://forum.fhem.de/index.php/topic,5827.msg22771.html#msg22771

Danke und Gruß,
Karsten

P.S.: FHEM ist klasse!

[rudolfkoenig]

 

Das hatte ich aus einer Antwort von Dir, aber da hast Du Dich möglicherweise selbst verschrieben.

Aah: 29 Mai 2010. Das war damals noch korrekt , die Clients sind danach vom $module optional nach $def umgezogen, wenn ich mich recht erinnere, wegen FHEM2FHEM.

Eine bestimmte CUL-Serie (ich meine 3.1, siehe https://groups.google.com/forum/#!topic/cul-fans/pEMFxgXiK-o) hat Probleme mit RFR (d.h. mit FastRF, 250kHz Uebertragungsrate). Auf meinem Base-CUL ist "V1.1 (TOSTi 2008)" eingeaetzt, auf dem RFR "V2.1Xrc1"

[Kako]

So, zumindest einen Teilerfolg kann ich verzeichnen. Nach dem ich ein Antennenproblem am CUL_RFR (konkret CUL_1RFR) behoben habe, trudeln fleißig CUL_1RFR_MSGCNT und CUL_1RFR_TIME Meldungen ein. Die Anzahl liegt nur leicht unter den Werten meines CULs an der FritzBox. Kann man dann davon ausgehen, dass die Daten vom CUL_RFR erfolgreich an den CUL übermittelt wurden?

Mich wundert nämlich, dass weiterhin Anfragen wie
get CUL_1RFR raw u
get CUL_1RFR version
nur ,,No answer" liefern.

Und
get CUL_1RFR ccconf
bringt nur "Timeout reading answer for get C0D".

Ist doch nicht normal, oder?

Gruß, Karsten

CUL_1RFR_MSGCNT   1451
CUL_1RFR_TIME   2013-12-17 13:33:23
Clients   :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_RFR:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:
DEF    02 01

ID   02
IODev   CUL_0

NAME   CUL_1RFR
NR   21
NR_FMSG   1
NR_TMSG   1206
RAWMSG   T044600A62DF7
ROUTERID   01
RSSI   -78.5
STATE   Defined
TYPE   CUL_RFR

Readings
ccconf   freq:868.330MHz bWidth:325KHz rAmpl:42dB sens:8dB   2013-12-15 22:12:40
cmds   B C F i A Z E G M R T V W X e f m l t u x   2013-12-15 22:20:06
raw   No answer   2013-12-17 13:24:46
state   0   2013-12-17 13:33:23
version   No answer   2013-12-17 13:33:43

[rudolfkoenig]

> Kann man dann davon ausgehen...

Ja.

> Ist doch nicht normal, oder?

Naja, super stabil ist eine RFR Verbindung per-design schon nicht, da es kein retransmit kennt.
cconf benoetigt noch dazu 6 erfolgreiche gets (C0D ist das erste), und dafuer muss 12-mal hintereinander ping + Frequenzwechsel + Uebertragung + Frequenzwechsel auf zwei Geraeten gelingen. Andererseits klappt "get RFR ccconf" bei mir haeufig.
Wenn es bei dir in die andere Richtung klappt, heisst, dass dein RFR nicht mitkriegt, wenn das CUL per SlowRF ein ping sendet.