Kommunikationsprobleme CULv3.x -RFRv3.x
stefzi
ich habe zwei CUL's mit v3:
CUL1 v3.1 FW 1.39 als Basis an Sheeva1 mit fhem Version 5.0
CUL2 v3.2 FW 1.39 als RFR an Sheeva2 (testweise zum debuggen mit
screen)
CUL1 geflashed, eprom resetted mit e, anschließend ui0100, X21
CUL2 geflashed, eprom resetted mit e, anschließend ui0201, X21
Wenn ich über fhem mit raw F12345678 sende, kann ich den Befehl an RFR
sehen, wenn ich über fhem ein Kommando sende, sehe ich den Befehl
nicht.
Folgendes Problem:
Es sieht so aus, als wenn die Befehle an das RFR Modul gesendet
werden, von dort aber nie eine Antwort an die Basis zurückkommt.
Es geht auch kein u0201V an der Basis, da gibt es auch in screen nie
eine Antwort.
Ich habe mal mit fr den Snoop-Mode am RFR eingeschaltet, dann sehe ich
dort von der Basis gesendete Befehle z.b. u0201F10100000 oder u0201V
oder u0201C99, ich sehe aber nie einen Antwortbefehl am RFR.
auf dem RFR sieht das so aus:
u0201C35
u0201V
u0201X
u0201C99
u0201V
u0201F10107311
u0201F10100000
bei fhem wird immer timeout angezeigt.
Was könnte die Ursache dafür sein?
2.tes Problem:
Manche Befehle kommen auch nicht am RFR an, z.b. für einen bestimmten
Rolladen, mit Code 1010 2413 fg 4421 lm 1144
woran könnte das liegen?
C99 am RFR:
0D2E2D07D3913D04
320000060021656A
55E43023B9000700
18146C070090876B
F85611EF2D191F41
00597F3F88310B00
C99 an CUL Basis:
0D2E2D07D3913D04
320000060021656A
55E43023B9000700
18146C070090876B
F85611EF2C191F41
00597F3F88310B00
C99 nach fr am RFR:
072E050DD391FF08
0500000C0021656A
2B3B1322F862073F
181D1CC700B0876B
F8B611EF2D191F41
00597F3C88310B00
C99 nach fr am CUL Basis:
072E050DD391FF08
0500000C0021656A
2B3B1322F862073F
181D1CC700B0876B
F8B611EF2C191F41
00597F3C88310B00
Auszug fhem.cfg:
attr global autoload_undefined_devices 1
attr global logfile /var/log/fhem/fhem-%Y-%m.log
attr global modpath /usr/share/fhem
attr global port 7072
attr global statefile /var/log/fhem/fhem.save
attr global verbose 3
define CUL1 CUL /dev/ttyACM0 1010
define CUL2 CUL_RFR 02 01
define WEB FHEMWEB 8083 global
define WEBS FHEMWEB 8084 global
attr WEBS smallscreen 1
define Logfile FileLog /var/log/fhem/fhem-%Y-%m.log fakelog
define Roll_Esszimmer FS20 1010 1113
attr Roll_Esszimmer commment Rolladen
attr Roll_Esszimmer model RS20U
attr Roll_Esszimmer room Esszimmer
define Roll_Schlafz1 FS20 1010 2413 fg 4421 lm 1144
attr Roll_Schlafz1 comment Schlafzimmer links
attr Roll_Schlafz1 model RS20U
attr Roll_Schlafz1 room Schlafzimmer
define Roll_Schlafz2 FS20 1010 2414 fg 4421 lm 1144
attr Roll_Schlafz2 comment Schlafzimmer rechts
attr Roll_Schlafz2 model RS20U
attr Roll_Schlafz2 room Schlafzimmer
define FG_Roll_unten FS20 1010 4411
attr FG_Roll_unten comment Funktionsgruppe4411
attr FG_Roll_unten room FG_Rolladen
define FG_Roll_oben FS20 1010 4421
attr FG_Roll_oben comment Funktionsgruppe4421
attr FG_Roll_oben room FG_Rolladen
...
stefzi
*** PM Antwort von Rudi 19.10. ***
Hallo Stefan,
TOSTi hat mir vor einem Monat 2 CULV3.1 zugeschickt mit einem
aehnlichen
Problem. Nach einem Experimentier-Vormittag stand es fest: die CULV3.1
waren
nicht in der Lage auf 250KHz zu Empfangen oder zu senden. Abhilfe
schafft, wenn
man man in cc1100.c die Zeile "0x2D, // 10 MDMCFG4 (x)" durch 0x2B
austauscht
und damit die Datenrate auf 62kHz reduziert. Die mir zur Verfuegung
stehenden
CUL V1.1, V2.0, V3.0 und V3.2 haben keine Probleme mit 250kHz.
Kannst Du bitte testen, ob 60kHz bei Dir auch hilft? Damit wuerde sich
die
Theorie erhaerten, dass CUL V3.1 Probleme mit hohen Datenraten hat.
Gruss,
Rudi
stefzi
CUL getestet, jedoch war das Verhalten das gleiche wie mit V3.1 ->
V3.2, das Problem scheint also nicht ausschließlich an Version 3.1 zu
liegen.
> man man in cc1100.c die Zeile "0x2D, // 10 MDMCFG4 (x)" durch 0x2B
> austauscht und damit die Datenrate auf 62kHz reduziert.
Auch die Anpassung der Datenrate hatte ich schon gemacht --> keine
Änderung. Diese Änderung gilt doch nur für den "FASTRF-Mode", was wird
den von fhem am Basis-CUL gesetzt ? Muss dieser Modus per Hand an
beiden CUL's gesetzt werden?
Was mit noch auffällt ist folgendes:
- Umschaltung am RFR mit "fr" auf Snooping:
--> Übertragene Kommandos von der Basis werden angezeigt, es sind
keine Antworten ersichtlich.
- Umschaltung am RFR mit "fx" gefolgt von X21
--> jetzt werden am RFR nur noch Sonderzeichen angezeigt:
z.B.
201C9Z�0M��u0201C9Z�0000MZ�u0201MZ�u020M��9100000u
201C9Z�0M��u0201C9Z�0000MZ�u0201MZ�u020M��9100000u
201C9Z�0M��u0201C9Z�0000Z��u0201MZ�u020M��9100000u
201C9Z�0M��u0201C9Z�0000MZ�u0201MZ�u020M��9100000u
201C9Z�0M��u0201C9Z�0000Z��M��u02Z�C991M��00u1X�}
201C9Z�0M��u0201C9Z�0000MZ�u0201MZ�u020M��9100000u
201C9Z�0M��u0201C9Z�0000Z��M��u0Z�1C991M��u020X�}
1CZ�1000M��u0201C99100000u�4�_��.Z�I���M�
201C9Z�0M��u0201C9Z�0000Z��M��u0Z�1C991M��u020XX�}
1C99100000u02011X�}�g7��i$�4�_��.o�I���t/
Stefan
Rudolf Koenig
> Basis-CUL gesetzt ? Muss dieser Modus per Hand an beiden CUL's gesetzt
> werden?
Evtl. hilft dir der RFR Abschnitt im commandref.html. Hier mit anderen Worten:
- Normalmodus heisst 868.3 MHz, 1kHz Datenrate, ASK/OOK Kodierung. FS20/FHT/EM/HMS
senden alle mit diesen Parameter, nur mit unterschiedlichen Timings was 1
bzw. 0 Bit bedeutet. Senden und dekodieren wird vom Atmel MCU durchgefuehrt,
damit kann man theoretisch beliebige Protokolle integrieren, wenn die mit
diese Datenrate senden.
- FastRF ist 868.3 MHz, 250kHz Datenrate, GFSK Kodierung, empfangene Pakete
werden "nur" ausgegeben. Die Uebertragung wird vom CC1101 durchgefuehrt, samt
Sync-Bits und Checksum.
- RFR sendet im Normalmodus 5 bits (RFR-Ping), dann wird auf FastRF geschaltet,
Daten gesendet, und dann wieder auf Normalmodus zurueckgeschaltet. Empfangene
"Befehle" werden ausgefuehrt.
> - Umschaltung am RFR mit "fx" gefolgt von X21
> --> jetzt werden am RFR nur noch Sonderzeichen angezeigt:
> z.B.
> 201C9Z???0M??????u0201C9Z???0000MZ???u0201MZ???u020M??????9100000u
Das ist definitiv Muell. Wobei u... nur auf dem FastRF Kanal uebertragen wird,
die Zurueckschaltung auf Normalmodus (X21) ist also nicht erfolgt.
RFR-Paketformat: uTTSSXXXXX
- u: RFR Kenner
- TT: TARGET-Id: Sendung sollte nur dieser Adressat auswerten.
- SS: Source-Id
- XXXXX: beliebiges culfw Kommando. Ein Spezielles Kommando 'U' ist dabei echo.
Wenn also das RFR mit der id 02 die FS20 Nachricht F12340100 der Basis 01
melden will, dann muesste man mit einem Snoop-CUL im FastRF Modus (fr)
folgendes sehen:
u0102UF12340100
Der Basis wurde dann
0102UF12340100
ausgeben, was normalerweise beim fhem landet, der es an dem 02 erkennen wuerde,
von welchem RFR die Nachricht stammt.
stefzi
1 x RFR mit 0201
1 x Snoop-CUL im FastRF Modus
1 x Basis CUL
Diese 3 CUL's befanden sich im gleichen Raum an 3 unterschiedlichen
Linux-Rechnern mit screen connected auf den Devices. Ich wollte sehen,
wenn ich mit einer FS20 Fernbedienung Befehle sende, ob diese
Kommandos auf dem Snoop-CUL sichtbar sind.
Anbei zwei Dateien, die ich im UTF-8 Code über Screen gleichzeitig
mitgeschnitten habe.
Auffällig sind zum einen die Sonderzeichen und zum anderen, dass am
Snoop CUL auf einen Befehl viele Ausgaben folgen und die uxxx Befehle
immer identisch sind, obwohl unterschiedliche Kommandos an der FS20
Fernbedienung abgesetzt wurden, ich fürchte da ist noch ein Bug in der
Firmware.
Meine während der Eingabe gemachten Kommandos sind mit >>
gekennzeichnet, z.b. >>V
Ich hoffe die Sonderzeichen sind erkennbar, deswegen die Traces bei
den Dateien (geht wohl nicht anders).
Name: Snoop-CUL.txt und RFR-CUL.txt
Gruss
Stefan
stefzi
grrrrr.. die Dateien sind wieder weg, man kann sie zwar hochladen,
verschwinden danach aber wieder, wo kann ich diese ablegen ?
Rudolf Koenig
> verschwinden danach aber wieder, wo kann ich diese ablegen ?
Ich vermute es hat was damit zu tun, dass google die bei allen Gruppen das
Welcome-Message und die Datei-Ablage zumachenwill. Ab Februar werden auch die
alten Dateien aus unsere Gruppenablage verschwinden. Google empfiehlt
google docs, ich kann aber dazu nichts sagen, da ich es selber nie getestet
habe.
stefzi
>X21
>Das ist nicht spezifiziert.
>fr schaltet auf FastRf, d.h. es laedt die CC1101 Register fuer FastRF und
>haengt sich in die Benachritigungs-Schleife. X21 Laedt Register fuer SlowRF,
>aber haengt die FastRf benachritigung nicht aus der schleife, dazu braucht man
>ein fx. Also korrekt:
>fr
>-> Fastrf modus
>fx
>X21
>-> SlowRF modus
>Gruss,
> Rudi
O.k. jetzt habe ich auf dem Snoop-CUL das X21 Kommando nach "fr"
weggelassen, jetzt kommt dort aber überhaupt keine Meldung mehr an,
was jetzt zweierlei bedeuten kann:
1. Das RFR sendet keine Daten aus, es empfängt aber definitv FS20
Meldungen die es mit X01 auch anzeigt.
2. das Snoop-CUL gibt die Meldungen nicht aus oder empfängt diese erst
gar nicht (Abstand zum RFR ca. 3 Meter). Ich habe es am Snoop-CUL auch
mal mit X01 versucht nach, oder vor dem fr-Kommando, danach gibt es
aber auch keine Ausgabe. Ist vielleicht ein X67 erforderlich
(debugging)?
Ich frage mich nur, habe nur ich die Probleme mit CULv3 und RFR-Modus?
Funktioniert das bei allen anderen einwandfrei - oder nutzt das nur
keiner?
Welches Debugging kann man einschalten um dem Problem näher zu kommen?
>X21 Laedt Register fuer SlowRF,
Frage: gilt das auch für alle anderen X<RR> Befehle: (darf ich die
alle nicht nach einem fr Kommando nutzen? wenn ja, dann sollte die
Doku angepaßt werden)
X<RR> Enable data reporting.
<RR> is a one-byte hex value, with following bits (bit 0 is the
LSB bit):
- Bit 0: Report known messages (parity & checksum ok), with type
prefix.
- Bit 1: Report each of the (repeated) packets of a message
- Bit 2: Report detailed data, even with wrong parity /
checksum.
- Bit 3: Monitor mode: output an r on a risings edge and 'f' on
a falling
edge. Output a '.' at the end of the message (no signal
for
4msec).
- Bit 4: Timing: in monitor mode output one additional byte of
the
internal microsecond timer, divided by 16. This is
binary!
- Bit 5: RSSI: report RSSI value as an additional HEX byte after
digested
data or as a separate byte if Bit 3 is set too.
- Bit 6: Report FHT protocol messages (ack, etc)
- Bit 7: CUL/CUN: Report raw RSSI data (a==weak ... p==strong
signal)
CUR: Grafic representation: dark==weak ... light ==
stong signal
Note: 00 disables radio reception, any other value initialize
the radio
chip and enable reception.
Default is 00: do not report anything, radio chip uninitialized.
Example: X01 (normal reporting, no RSSI) or X67 (debugging)
If <RR> is not specified, report the current value and the
available
time for sending RF (in 10 ms units)
Rudolf Koenig
> gar nicht (Abstand zum RFR ca. 3 Meter). Ich habe es am Snoop-CUL auch
> mal mit X01 versucht nach, oder vor dem fr-Kommando, danach gibt es
> aber auch keine Ausgabe. Ist vielleicht ein X67 erforderlich
> (debugging)?
Wie gesagt (bin nicht sicher ob Du es befolgst :)
- Normalmodus nach dem booten
X21
- FastRF (snooping)
fr
- Aus FastRF wieder ins Normal
fx
X21
> Ich frage mich nur, habe nur ich die Probleme mit CULv3 und RFR-Modus?
> Funktioniert das bei allen anderen einwandfrei - oder nutzt das nur
> keiner?
Ich weiss nicht ob andere Probleme haben, z.Zt bist Du der einzige der sich
meldet. Ich habe ausfuehrliche Tests mit allen Moeglichen CUL Versionen von
V1.1 bis V3.2c gemacht, und alle funktionierten einwandfrei bis auf die Version
3.1. Und meine Vermutung bei der V3.1 ist, dass irgendwas mit dem Hochfrequenz
kaputt ist. Hab uebrigens heute Nachmittag mit einem V3.2 gespielt (wg.
FHEM2FHEM), und der hat einwandfrei RFR empfangen, sogar mit der aufgeloeteten
Stabantenne.
> Welches Debugging kann man einschalten um dem Problem n�her zu kommen?
>
> >X21 Laedt Register fuer SlowRF,
> Frage: gilt das auch f�r alle anderen X<RR> Befehle: (darf ich die
> alle nicht nach einem fr Kommando nutzen? wenn ja, dann sollte die
> Doku angepa�t werden)
?? fr muss man halt mit fx beenden, und dann X.. beliebig setzen. Siehe auch
die fastrf_on Variable im fastrf_func() in culfw/clib/fastrf.c bzw. in
culfw/clib/rf_receive.c
Und nein, ich will das nicht umbauen, das ist ein Firmware und muss nicht
Benutzerfreundlich sein...
stefzi
So, jetzt habe ich mal folgendes gemacht, da ich mir schon blöde
vorkam:
a) die Firmware im Originalzustand (ohne die 0x2B, // 10 MDMCFG4 (x)
Änderung) auf Debian-Testing 32-bit System neu übersetzt (statt wie
bisher auf 64-bit Ubuntu-10.04)
b) alle 3 CUL's neu geflashed
Diesmal hatte ich insofern Erfolg, dass es mit den 2 Version 3.2 CUL's
jetzt funktioniert hat, nur nicht mit dem Version 3.1 CUL, trotz der
gleichen Befehle, das lässt sich jetzt nachvollziehen.
Die Vermutung, dass die HW-Version 3.1 ein Problem hat ist jetzt von
mir bestätigt worden, ich werde jetzt versuchen, das CUL über
"busware" umzutauschen. Immerhin ist ja da noch Garantie drauf.
Vielen Dank,
Stefan
Willi
eine CUL V 3.1 per RFR zu verbinden.
Ich bin bzgl. RFR strikt nach Anleitung vorgegangen.
Hat bei mir auch nicht funktioniert, obwohl beide CULs ansonsten ohne
Probleme mit FHEM laufen.
Ich habe danach eine CUL an FHEM angeschlossen gelassen und die zweite
CUL an ein Notebook angeschlosen und mir per Screen am Notebook
angesehen, was für Pakete bei der CUL ankommen. Leider konnte ich
keinelei RFR-Kommunikation feststellen.
Ich habe es dann nach einigen Stunden Tests aufgegeben und habe
seitdem eine CUL unbenutzt herumliegen. Diese wollte ich jetzt ein
einem anderen Teil des Hauses nutzen, um einige S300TH besser
empfangen zu können.
Falls ich jetzt doch noch mal RFR in Betrieb nehmen will: Wie sollte
ich am besten vorgehen?
Rudolf Koenig
> ich am besten vorgehen?
Wie im commandref.html beschrieben. Es ist dabei zu beachten, dass als RFR
Client konfigurierte CULs der Version 2.x oder kleiner wg. Speichermangel RFR
Befehle nicht auf dem USB Port ausgeben, man kann also bei solchen CUL's nicht
mit screen/hyperterminal zuschauen (Feature RFR_SHADOW).
Falls diese Eigenschaft unerwuenscht ist, dann muss man in culfw/Devices/CUL/board.h
im CUL_V2 Abschnitt TTY_BUFSIZE von 48 auf 32 gesenkt werden, und dann kann
RFR_SHADOW auskommentiert werden.
Wg. dem kleineren Speicher koennen V2.x CULs im Standardkonfiguration RFR
Pakete der Groesse 48Byte verarbeiten, ab V3 bzw CUN sind das 64 Byte.
Beim aelteren culfw Versionen (vor 1.37) waren das noch 32Byte
Willi
CUL v3.1 war die RFR CUL. Also umgekehrt wie beim letzten Mal.
Beide CUL haben Firmware V 1.39.
Ich bin wie im commandref.html angegeben vorgegangen.
Leider auch diesmal kein kein Erfolg. "get MyRFR version" ergibt "no
answer". "list MyRFR" sieht nicht vielversprechend aus.
Wenn ich die RFR-CUL per screen ansehe, sehe ich, dass diese die
normalen Geräte wie immer empfängt. Aber sonst nichts.
"ud" auf der RFR-CUL gibt folgende Antwort:
8A1C.00
"us" auf der RFR-CUL gibt folgende Antwort:
0.0.0.0.0.3A.2CB
Scheitere ich an demselben Problem wie stefzi (RFR-Problem mit CUL
3.1)?
Was kann ich sonst noch tun? Leider habe ich nur eine CUL v2 und eine
v 3.1 zur Verfügung, so dass ich den Test nicht um eine weitere CUL
erweitern kann.
MfG
Willi
-------
fhem> get MyRFR version
MyRFR version => No answer
fhem> fhem> list MyRFR
Internals:
DEF 02 01
ID 02
IODev CUL
NAME MyRFR
NR 139
ROUTERID 01
STATE ???
TYPE CUL_RFR
Readings:
2010-10-26 16:18:24 raw No answer
2010-10-26 18:29:21 version No answer
Rudolf Koenig
> 3.1)?
Ich gehe davon aus...
> Was kann ich sonst noch tun?
Ich hatte bei 62kHz RFR Datenrate keine Probleme mit der Version V3.1
->
Bei beiden die FastRF Datenrate von 250kHz auf 62kHz drehen indem man in
culfw/cc1100.c die Zeile "0x2D, // 10 MDMCFG4 (x)" durch "0x2B," austauscht,
culfw uebersetzt und neu brennt. Das muesste auch ohne flashen mit dem culfw
Befehl W472B klappen, getestet habe ich das aber nicht. R47 sollte vorher auf
jedenfall 2D zurueckliefern. Das "W472B" wird nach einem reset (e) bzw. flashen
mit einer anderen(!) culfw Version zurueckgesetzt.
Willi
> culfw uebersetzt und neu brennt. Das muesste auch ohne flashen mit dem culfw
> Befehl W472B klappen, getestet habe ich das aber nicht. R47 sollte vorher auf
> jedenfall 2D zurueckliefern. Das "W472B" wird nach einem reset (e) bzw. flashen
> mit einer anderen(!) culfw Version zurueckgesetzt.
Um es einfach zu machen, habe ich auf beiden CUL mit R47 geprüft, dann
mit W472B geschrieben und dann mit R47 erneut geprüft, dass die Werte
ok sind.
Leider hat dies am Verhalten nichts geändert.
Ich sehe, dass beide CULs die normalen Devices (S555TH, FHT, etc.)
ohne Probleme empfängt.
Ich habe testweise per FS20-Befehl ("F12340111") von beiden CULS
gesendet. Die jeweils andere CUL sieht dies.
Andere Optionen (außer die Firmware selbst zu compilieren und komplett
neu flashen? Bisher verwende ich die bereits vorcompilierte V1.39).
Das Compilieren und Flashen würde ich dann mal als nächstes angehen.
MfG Willi
Rudolf Koenig
Kannst Du bitte folgendes testen (mit 62kHz):
- beide CULs in fastrf mode setzen mit "fr".
- die beiden sollten nicht direkt nebeneinander liegen (ca 2-10m Abstand).
- mit dem einen eine Nachricht ans andere schicken mit "fsTestDaten"
- auf der anderen Seite sollte TestDaten erscheinen
Willi
Bei der V2 CUL gibt es den Befehl nicht: "fr is unknown".
Klappt das generell bei einer V2 nicht oder ist die Firmware auf der
CUL v2 nicht in Ordnung?
MfG Willi
Willi
RFR funktioniert nicht und fr ist auch unknown.
Liegt dies daran, dass bei CULv2 RFR_DEBUG nicht definiert ist?
Wenn ich das in board.h setze, scheint der Code zu gross zu werden:
>dfu-programmer at90usb162 flash CUL_V2.hex
>Bootloader and code overlap.
>Use --suppress-bootloader-mem to ignore
Alternativen?
Willi
- culfw für CUL v2 habe ich mit RFR_DEBUG und HAS_FASTRF übersetzt und
geflasht. Damit das ins Flash passte musste ich HAS_FHT_80b und
HAS_FHT_8v herausnehmen.
On 26 Okt., 21:02, Rudolf Koenig <inf...@koeniglich.de> wrote:
> > Leider hat dies am Verhalten nichts ge ndert.
>
> Kannst Du bitte folgendes testen (mit 62kHz):
> - beide CULs in fastrf mode setzen mit "fr".
> - die beiden sollten nicht direkt nebeneinander liegen (ca 2-10m Abstand).
> - mit dem einen eine Nachricht ans andere schicken mit "fsTestDaten"
> - auf der anderen Seite sollte TestDaten erscheinen
TestDaten bei der V2 an.
Umgekehrt, also von der v2 an die v3.1 kommt aber bei der v3.1 NICHTS
an.
Es scheint also am Empfang der v3.1 zu liegen? das RFR-Senden der v3.1
scheint dagegen zu funktionieren.
Jetzt bin ich wieder am Ende.............
Michael Bussmann
On Oct 26, 9:36 pm, Willi <willi.her...@googlemail.com> wrote:
> Es scheint also am Empfang der v3.1 zu liegen? das RFR-Senden der v3.1
> scheint dagegen zu funktionieren.
>
> Jetzt bin ich wieder am Ende.............
einem V2 und V3.2:
In der Konfiguration V2 als RFR, V3.2 als Basis kommt es hin und
wieder
zu der Situation, daß der V2-RFR weiterhin wunderbar die Nachrichten
zum
V3.2 schickt, wo sie auch empfangen werden, der umgekehrte Weg (also
von der
3.2 Basis zum V2) aber nicht funktioniert. Befehle wie get RFR
version/ccconf
etc liefern nur einen Timeout (oder zufällig empfangene Daten) und
über das RFR
relayte Befehle werden nicht verschickt (vermutlich, weil sie dort nie
ankommen).
Das wäre dann aber ein genau umgekehrtes Verhalten wie von Dir
berichtet.
Womöglich sind es zwei verschiedene Probleme (zumal hier eben kein 3.1
beteiligt ist), aber auffällig finde ich das schon. Hin und wieder
scheint
sich das Problem auch von selnst wieder zu lösen, ein Reset mit "e"
hilft
meist immer. Ich tausche nun mal die CUL aus (V2 Basis, V3.2 RFR),
vielleicht
passiert nun etwas anderes...
MfG
MB
Willi
> Um die Verwirrung noch etwas zu erhöhen, hier meine Beobachtung mit
> einem V2 und V3.2:
V3.2 als RFR (übrigens auch die V3.2 auch als Basis) im Einsatz hatte,
hat dies zwar in den ersten Tagen funktioniert, hat dann aber nach
einigen Tagen Probleme bereitet.
Siehe auch mein Posting "CUL teilweise abgestürzt? Evtl. Probleme mit
CUL-Firmware und Kopp-Funkschaltern?"
Ich hatte erst den neu installierten Kopp-Funkschalter in Verdacht.
Aber nachdem ich jetzt testweise beide CULs an separaten FHEM-Servern
ohne RFR angeschlossen habe, gibt es bisher keine Probleme mehr.
Mich würde mal interessieren, ob jemand zwei CUL V3.2 mit RFR längere
Zeit ohne Probleme im Einsatz hat. Evtl. hole ich mir dann noch einen
V3.2 und verwende den V2 für andere Zwecke (Testsystem, HomMeatic-
Test, oder anderes).
Michael Bussmann
Mal als Rückmeldung zu den RFR-Problemen:
On 2010-11-12 06:04:36 -0800, Willi wrote:
> Ah, das ist ja interessant. Nachdem ich jetzt auch eine V2 und eine
> V3.2 als RFR (übrigens auch die V3.2 auch als Basis) im Einsatz hatte,
> hat dies zwar in den ersten Tagen funktioniert, hat dann aber nach
> einigen Tagen Probleme bereitet.
On 12 Nov., 14:17, Michael Bussmann <goo...@mb-net.net> wrote:
> meist immer. Ich tausche nun mal die CUL aus (V2 Basis, V3.2 RFR),
> vielleicht passiert nun etwas anderes...
Seit einem Monat funktioniert dieses Setup (V2 Basis, V3.2 RFR) zumindest
hier wesentlich stabiler, als mit dem V2 als RFR. Schwierigkeiten gibt es
mit der Kommunikation mit den FHT, die über den RFR geroutet werden (wenn
viele Nachrichten geschickt werden) - das war aber auch im alten Setup der
Fall.
Aber diese Aussetzer, die nur per Reset zu beheben waren, sind bislang nicht
mehr aufgetreten.
Der nächste Schritt ist, den (noch) RFR CUL direkt an einem WLAN-AP mit
socat als eine Art "CUWLAN" zu betreiben. Dann wäre der Faktor "RFR"
testweise eliminiert.
MfG
MB
--
Michael Bussmann <b...@mb-net.net>
But I can see you -- Your brown skin shinin' in the sun; You got your hair
combed back and your sunglasses on, baby. And I can tell you my love for
you will still be strong; After the boys of summer have gone.
-- Don Henley, 'The Boys Of Summer', 1985
Michael Bussmann
[ Die zweite Rückmeldung ]
On 2010-12-13 20:31:56 +0100, Michael Bussmann wrote:
> Der nächste Schritt ist, den (noch) RFR CUL direkt an einem WLAN-AP mit
> socat als eine Art "CUWLAN" zu betreiben. Dann wäre der Faktor "RFR"
> testweise eliminiert.
Weihnachtszeit ist Bastelzeit... Zwar habe ich noch keine
Langzeitergebnisse, aber zu einer ersten Einscätzung reicht es wohl:
Der (Ex-RFR) CUL ist jetzt an einem WLAN-Router im Client-Mode angeschlossen
und arbeitet nun als emulierter CUN per
| while (true)
| > do
| > nc -l -p 10000 < /dev/ttyACM0 >/dev/ttyACM0
| > done
Obwohl der WLAN-Link auch recht grenzwertig ist und man die Latenz deutlich
spürt, scheint dieses Setup weitaus zuverlässiger zu sein (ohne jetzt den
Umstand einzuberechnen, daß nun WLAN AP und WLAN Client weitere
Risikofaktoren sind). Refreshvalues von den FHTs, die über den
(remote/Ex-RFR) CUL erreicht werden, rutschen nun in max. 2 Durchläufen
durch, was früher 1 Tag gedauert hat (obwohl ein FHR gerade mal 4m vom CUL
entfernt ist). Einige Nachrichten kommen nun zwar doppelt an, was aber
verschmerzbar ist. Das ist wohl ein Ansporn für mich, doch ein paar
Netzwerkkabel ins Obergeschoss zu legen...
Um mal Ursachenforschung zu betreiben: Kann es sein, daß die Umschaltzeit
vom "normal" in den 250kHz-Mode einfach zu lange ist, so daß weitere
Nachrichten vom FHT in der Zeit einfach versumpfen? Dies könnte vielleicht
auch erklären, warum es mit dem CULv3 als RFR etwas besser funktioniert:
Dadurch, daß er einen größeren Puffer nutzt, kann er länger das
FHT-Handshaking betreiben, eh weitere Nachhrichten an den Basis-CUL
geschickt werden. Bei FS20 und WS300-Meldungen wird das eher unkritisch
sein. Ist jetzt aber nur eine aus der Hüfte geschossene Theorie.
Schöne Grüße und noch einen schönen 2. Feiertag,
MB
--
Michael Bussmann <b...@mb-net.net>
And I think I'm gonna write it on the walls of the world, so everyone will
know today the love I hold for you. I will write it on the walls of the
world, so that the sun won't fade away the words I say to you, I love you.
-- Mike Batt, 'The Walls Of The World', 1977
Rudolf Koenig
> vom "normal" in den 250kHz-Mode einfach zu lange ist, so da� weitere
> Nachrichten vom FHT in der Zeit einfach versumpfen?
Eine Frequenzumschaltung dauert weniger als 3 ms, das habe ich beim RFR
Implementierung getestet. Eigentlich dauert es laut Handbuch mit Kalibrierung
ca 1ms, aber zuverlaessiger Empfang ist erst nach 3ms moeglich.
RFR sendet erst dann die empfangenen Pakete weiter, wenn es in der Umgebung
"leise" ist, d.h. fuer ca 48ms (2*3/125sec) nichts empfangen wurde. Grund:
FS20 sendet 3-mal (60ms-Funk gefolgt von 10ms-Pause), und das RFR soll
abwarten, bis alle Pakete "durch" sind.
Das ist nicht optimal fuer FHT, da es hier nicht unbegruendet wiederholt wird.
Bei refreshvalues ist der Funkraum alle 100-200ms fuer ca 60ms zu (gerade
geprueft), und das solange, bis alle 40+ Werte einzeln uebermittelt wurden.
40*0.2*2 = 16Sek in optimalfall, d.h. wenn alle Nachrichten/Acks auf Anhieb
empfangen wurden.
Das RFR hat also wahrscheinlich alle Daten bekommen und bestaetigt, konnte aber
nur das an dem Basis-CUL weiterschicken was in dem 48/64 Byte RFR-Puffer
reinpasst (4/5 Nachrichten), und das mit gut 20 Sekunden Verspaetung.
Man koennte fuer nicht FS20 Nachrichten den timeout anders waehlen, aber:
Gibt es fuer refreshvalues einen Grund?
Michael Bussmann
On 2010-12-27 11:27:54 +0100, Rudolf Koenig wrote:
> Eine Frequenzumschaltung dauert weniger als 3 ms, das habe ich beim RFR
Ok, soviel zur schnellen Theorie :-)
> Gibt es fuer refreshvalues einen Grund?
Es dient mit hauptsächlich als Härtetest für den RFR, um das Problem mit
den verlorenen Datagrammen zu reproduzieren. Als etwas milderes Mittel
geht z.B. auch ein "get cul ccconf", was immerhin 6 Abfragen stellt. Auch
hier gab es im Setup Basis=V3, RFR=V2 mehr, bei Basis=V2, RFR=V3 etwas
seltener, im jetzigen USB+WLAN-Basis-Betrieb noch gar keine Probleme.
MfG