Hallo,
hat schon jemand hier im Forum einen RFR CUL unter Verwendung eines nanoCUL (868MHz) zum Laufen bekommen? Ich verzweifle gerade daran...
Status:
- ich verwende einen CubiTruck als 'produktive' FHEM-Platform und einen RasPi als FHEM Spielwiese (Flashen, Basteln, ...)
- nanoCUL gebaut & am RasPi geflasht - funktioniert prima als 'normaler' 868MHz CUL am RasPi
- gemäß FHEMWiki versucht, einen RFR CUL daraus zu machen (ohne Hin- und Hertauschen zweier CULs, da am RasPi ja nur der nanoCUL hängt), define für den nanoCUL am CubieTruck eingebaut, dem CUL am CubieTruck 0100 als (Router)ID gegeben
- Ergebnis: RFR CUL geht nicht ('repeatet' nicht, bei get raw u kommt Command 'u' unknown) - liegt wohl daran, daß ich aus dem culfw-Source den Source für nanoCUL (/Devices/nanoCUL) nehme und da kein HAS_RF_ROUTER definiert ist
- gemäß http://blog.steveundkristin.de/2015/01/08/fhem-ein-selbstbau-cul-868/ (http://blog.steveundkristin.de/2015/01/08/fhem-ein-selbstbau-cul-868/) das 'define HAS_RF_ROUTER' und den Verweis auf rf_router.c in board.h des Sources für culfw 1.63 (Folder /Devices/nanoCUL) aufgenommen, kompiliert, am RasPi geflasht...geht nicht (Command 'u' wird nun erkannt solange der CUL direkt an meinem Test-FHEM-RasPi steckt - aber immer 'no answer' bei get ccconfig/credit10ms/u/..., wenn der RFR-nanoCUL standalone an einem USB-Netzteil betrieben wird)
- Wenn der RFR-nanoCUL nicht mehr am FHEM-Test-RasPi hängt, sondern mit dem richtigen CUL am 'produktiven' FHEM (CubieTruck) sprechen soll, wird auf dem CubieTruck für den RFR-nanoCUL als State '0' angezeigt, RFR_CUL_MSGCNT ist 10, RFR_CUL_TIME ist 0. ID (02) und ROUTERID (01) für den RFR nanoCUL werden angezeigt, sind so ja auch im define definiert.
- [size=78%]FHT ID für CUL und RFR-nanoCUL sind unterschiedlich.[/size]
Jetzt habe ich in http://forum.fhem.de/index.php/topic,11800.msg69592.html#msg69592 (http://forum.fhem.de/index.php/topic,11800.msg69592.html#msg69592) und http://forum.fhem.de/index.php/topic,24436.msg176870.html#msg176870 (http://forum.fhem.de/index.php/topic,24436.msg176870.html#msg176870) gelesen, daß gcc größer Version 4.3.3 wohl Probleme beim Compilieren des RFR-Code (?) hat...ich habe auf dem RasPi Version 4.6.3.
Hier nun (endlich) meine Fragen:
- Was kann ich testen, um dem Problem weiter auf die Spur zu kommen?
- Wie kann ich unterschiedliche gcc-Versionen auf dem RasPi installieren und z.B. gcc 4.3.3 zum Kompilieren des RFR-nanoCUL Sources nehmen? gcc 4.3.3 steht m. E. via apt-get gar nicht mehr zur Verfügung...?
Besten Dank für jeden Hinweis und Gruß aus Regensburg,
Stefan
Hallo Stefan,
sieht soweit gut aus. 10 Messages wurden schon empfangen. Bei RAWMSG siehst Du das letzte empfangene Datum.
Zitat von: SVLoneStar am 06 Mai 2015, 14:23:27Wenn der RFR-nanoCUL nicht mehr am FHEM-Test-RasPi hängt, sondern mit dem richtigen CUL am 'produktiven' FHEM (CubieTruck) sprechen soll, wird auf dem CubieTruck für den RFR-nanoCUL als State '0' angezeigt, RFR_CUL_MSGCNT ist 10, RFR_CUL_TIME ist 0. ID (02) und ROUTERID (01) für den RFR nanoCUL werden angezeigt, sind so ja auch im define definiert.
Genauso sieht es bei mir auch aus, nur das mein MSGCNT schon bei 91141 liegt. Allen Anschein nach funktioniert der RFR_CUL. Wenn Du beim FHEM vom CubieTruck ein "get
CUL raw u" absetzt kommt als Ergebnis raw => 0100?
Gruß,
Steve
Hallo Steve,
erstmal: Danke für Deine Hilfe! :-)
Ich hatte in der Zwischenzeit
- die culfw nochmal kompiliert und geflasht (aber wieder mit gcc 4.6.3)
- das define für den RFR direkt nach dem define für den CUL in die fhem.cfg eingefügt (stand davor gaaaanz unten)
Beides klingt für mich nicht nach 'maßgeblichen Änderungen', aber sei's drum...
Seitdem tut der RFR CUL in der Tat was:
Ein get CUL_0 raw u am CubieTruck liefert CUL_0 raw => 0100
Ein get RFR_CUL raw u am CubieTruck liefert RFR_CUL raw => 0201
Ein list CUL_0 liefert
Internals:
CMDS BbCFiAZEGMKUYRTVWXefmltux
CUL_0_MSGCNT 3877
CUL_0_TIME Initialized
Clients :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:CUL_RFR::CUL_TCM97001:
DEF /dev/serial/by-id/usb-busware.de_CUL868-if00@9600 1234
DeviceName /dev/serial/by-id/usb-busware.de_CUL868-if00@9600
FD 15
FHTID 1234
NAME CUL_0
NR 88
NR_CMD_LAST_H 4
PARTIAL
RAWMSG T575100BA00FF
RSSI -74.5
STATE Initialized
TYPE CUL
VERSION V 1.61 CUL868
initString X21
CHANGETIME:
Helper:
Dblog:
State:
Logdb:
TIME 1431064369.64333
VALUE UNKNOWNCODE SD45461011E00010DA0000400000000F0B
Matchlist:
1:USF1000 ^81..(04|0c)..0101a001a5ceaa00....
2:BS ^81..(04|0c)..0101a001a5cf
3:FS20 ^81..(04|0c)..0101a001
4:FHT ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
5:KS300 ^810d04..4027a001
6:CUL_WS ^K.....
7:CUL_EM ^E0.................$
8:HMS ^810e04....(1|5|9).a001
9:CUL_FHTTK ^T[A-F0-9]{8}
A:CUL_RFR ^[0-9A-F]{4}U.
B:CUL_HOERMANN ^R..........
C:ESA2000 ^S................................$
D:CUL_IR ^I............
E:CUL_TX ^TX[A-F0-9]{10}
F:Revolt ^r......................$
G:IT ^i......
H:STACKABLE_CC ^\*
I:UNIRoll ^[0-9A-F]{5}(B|D|E)
J:SOMFY ^Y[r|t|s]:?[A-F0-9]+
K:CUL_TCM97001 ^s[A-F0-9]+
Readings:
2015-05-08 02:19:29 ccconf freq:868.300MHz bWidth:464KHz rAmpl:42dB sens:8dB
2015-05-08 01:01:09 cmds B b C F i A Z E G M K U Y R T V W X e f m l t u x
2015-02-21 15:35:27 credit10ms 900
2015-02-21 15:35:32 fhtbuf AE
2015-05-08 10:33:51 raw 0100
2015-05-08 10:44:10 state Initialized
2015-02-21 13:49:33 uptime 3 02:56:45
2015-05-08 01:11:55 version V 1.61 CUL868
Softbuffer:
XMIT_TIME:
1431072695.63377
1431073043.0866
1431073888.96761
1431074552.48092
Attributes:
addvaltrigger 1
alias CUL_868MHz
icon cul_cul
model CUL
rfmode SlowRF
room 9 - System
verbose 5
Ein list RFR_CUL liefert
Internals:
Clients :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:CUL_RFR::CUL_TCM97001:
DEF 02 01
ID 02
IODev CUL_0
NAME RFR_CUL
NR 93
NR_FMSG 94
NR_KMSG 154
NR_RMSG 90
NR_TMSG 1484
RAWMSG T620200AA001A
RFR_CUL_MSGCNT 2101
RFR_CUL_TIME 0
ROUTERID 01
RSSI -61
STATE 0
TYPE CUL_RFR
Matchlist:
1:USF1000 ^81..(04|0c)..0101a001a5ceaa00....
2:BS ^81..(04|0c)..0101a001a5cf
3:FS20 ^81..(04|0c)..0101a001
4:FHT ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
5:KS300 ^810d04..4027a001
6:CUL_WS ^K.....
7:CUL_EM ^E0.................$
8:HMS ^810e04....(1|5|9).a001
9:CUL_FHTTK ^T[A-F0-9]{8}
A:CUL_RFR ^[0-9A-F]{4}U.
B:CUL_HOERMANN ^R..........
C:ESA2000 ^S................................$
D:CUL_IR ^I............
E:CUL_TX ^TX[A-F0-9]{10}
F:Revolt ^r......................$
G:IT ^i......
H:STACKABLE_CC ^\*
I:UNIRoll ^[0-9A-F]{5}(B|D|E)
J:SOMFY ^Y[r|t|s]:?[A-F0-9]+
K:CUL_TCM97001 ^s[A-F0-9]+
Readings:
2015-05-08 13:01:53 ccconf freq:868.300MHz bWidth:464KHz rAmpl:42dB sens:8dB
2015-05-10 00:13:26 cmds B b C F i A Z E G M K U Y R T V W X e f m l t u x
2015-05-08 02:22:32 credit10ms 454
2015-05-08 10:40:40 raw 0201
2015-05-10 00:12:41 state 0
2015-05-10 00:12:46 version V 1.63 nanoCUL868
Attributes:
IODev CUL_0
addvaltrigger 1
icon cul_cul
model CUL
room 9 - System
verbose 5
(Das Verbose 5 bei beiden ist Absicht, damit ich dahinter komme, wo was ankommt...temporär)
In Log sehe ich nun unter anderem Folgendes:
2015.05.08 10:39:04 4: CUL_Parse: CUL_0 0102UT220C00BA00F8;
2015.05.08 10:39:04 5: CUL_0 dispatch 0102UT220C00BA00F8;
2015.05.08 10:39:04 4: CUL_Parse: RFR_CUL T220C00BA00F8 -78
2015.05.08 10:39:04 5: RFR_CUL dispatch 810c04xx0909a001220c0000ba00
2015.05.08 10:39:04 5: CUL/RAW: /TB2931D0219
Die Internals eines Devices (HMS100 WD), das den RFR CUL als IODev hat, schauen so aus:
Internals:
CODE 3324
CUL_0_MSGCNT 13
CUL_0_RAWMSG 810e04xx0212a0013324000000000000
CUL_0_RSSI -92.5
CUL_0_TIME 2015-05-09 23:21:47
DEF 3324
IODev RFR_CUL
LASTInputDev CUL_0
MSGCNT 15
NAME HMS100WD_3324
NR 644
RFR_CUL_MSGCNT 14
RFR_CUL_RAWMSG 810e04xx0212a0013324000000000000
RFR_CUL_RSSI -67
RFR_CUL_TIME 2015-05-09 23:21:47
STATE Water Detect: off
TYPE HMS
CHANGETIME:
Helper:
Dblog:
Rawmsg:
Logdb:
TIME 1431206507.5546
VALUE 810e04xx0212a0013324000000000000
Rssi:
Logdb:
TIME 1431206507.5546
VALUE -92.5
Water detect:
Logdb:
TIME 1431206507.5546
VALUE off
Battery:
Logdb:
TIME 1431206507.5546
VALUE 1
Type:
Logdb:
TIME 1431206507.5546
VALUE HMS100WD
Water_detect:
Logdb:
TIME 1431206507.5546
VALUE off
Readings:
2015-05-09 23:21:47 battery ok
2015-05-09 23:21:47 state Water Detect: off
2015-05-09 23:21:47 type HMS100WD
2015-05-09 23:21:47 water_detect off
Attributes:
IODev RFR_CUL
alias Wassermelder
fp_4_UG 654,821,1,,
group Wassermelder
icon humidity
room 4 - UG Waschraum,7 - Wassermelder
sortby 1
Insofern: Stimmt, schaut jetzt eigentlich gut aus.
Was mich aber wundert: ich schreibe Charts mit den RSSI-Werten der diversen Geräte mit - und hatte erhofft, da einen verbesserten RSSI für die 'RFR CUL Geräte' zu sehen.
Im Anhang 3 Beispiele aus meinem Kellergeschoss:
1. Alle RSSI-Werte
2. RSSI eines Wassermelders HMS100 WD
3. RSSI einer Wetterstation KS300
4. RSSI eines FHTTK an meiner Haustür (ja, die ist im Keller ;))
Im 1. Bild sieht man schön, ab wann der RSR seine Tätigkeit aufgenommen hat.
Der Wassermelder steht ca. 2 Meter vom RFR-CUL entfernt, zum CUL geht's durch Stahlbeton ein Stockwerk nach oben. Der spricht aber wohl eher selten mit dem RFR CUL, sondern häufiger mit dem CUL...?
Die KS300 ist ca. 4 Meter vom RSR entfernt (durch 1 Fenster, der RSR steht auf dem Fensterbrett), zum CUL muss die KS300 durch 4 Meter 'Garten', eine 50er Wand und im Haus über ca. 5 Meter mit noch einer Wand. Die KS300 spricht scheinbar gleich gerne mit beiden CULs...?
Die Haustür ist ca. 3 Meter vom RFR CUL entfernt. Seit der RFR CUL aktiv ist, sind die RSSIs der Haustür deutlich schlechter...?
Zugegebenermaßen verwenden beide CULs sehr unterschiedliche Antennen (Groundplane am CUL, Original-Mini-868-Wendel von einem CC1101 am RFR.
Ich habe mal gelesen, daß die Definition eines IODev nur wichtig ist, wenn an Geräte gesendet werden soll - der Empfang auf FHEM-Seite kann (und soll) über alle möglichen Kanäle parallel laufen...das erklärt ja, warum nicht nur die RSSIs der beiden Geräte, denen ich den RFR-CUL als IODev gegeben habe (HMS100 WD und KS300), auf den RFR 'reagieren'.
Aus den stark schwankenden RSSI-Werten schliesse ich nun, daß FHEM beide Signale empfängt (CUL und RFR-CUL)...muss das so sein? dupTimeout stand auf 0,5 und 1 und steht jetzt auf 2...ich sehe keine Änderung in den RSSI-Verläufen.
Denkfehler (RSSIs 'doppelter' Meldungen werden nicht gefiltert), oder Fehler in meinem Setup?
Danke,
Stefan
Hallo Stefan,
schonmal sehr gut das der RFR Cul funktioniert.
Zitat von: SVLoneStar am 10 Mai 2015, 00:27:05
Im 1. Bild sieht man schön, ab wann der RSR seine Tätigkeit aufgenommen hat.
Der Wassermelder steht ca. 2 Meter vom RFR-CUL entfernt, zum CUL geht's durch Stahlbeton ein Stockwerk nach oben. Der spricht aber wohl eher selten mit dem RFR CUL, sondern häufiger mit dem CUL...?
Die KS300 ist ca. 4 Meter vom RSR entfernt (durch 1 Fenster, der RSR steht auf dem Fensterbrett), zum CUL muss die KS300 durch 4 Meter 'Garten', eine 50er Wand und im Haus über ca. 5 Meter mit noch einer Wand. Die KS300 spricht scheinbar gleich gerne mit beiden CULs...?
Ist völlig normal. Wenn es der HauptCUL nicht empfängt, dann ist der RFR noch da um auszuhelfen. :) Der RFR sendet verzögert nachdem Empfang der Daten, also immer nachdem der HauptCUL möglicherweise die Daten empfangen hat. Doppelte werden dann ignoriert. Kann durch das Attribute dupTimeout wie Du schon geschrieben hattest, angepasst werden. Ich habe einen Wert von 1.
Zitat von: SVLoneStar am 10 Mai 2015, 00:27:05
Die Haustür ist ca. 3 Meter vom RFR CUL entfernt. Seit der RFR CUL aktiv ist, sind die RSSIs der Haustür deutlich schlechter...?
Ich kann mir keinen Grund vorstellen, warum der RFR das beeinträchtigen sollte. Sonst müsste dieser dauerend Senden und das würde ich ausschließen.
Zitat von: SVLoneStar am 10 Mai 2015, 00:27:05
Ich habe mal gelesen, daß die Definition eines IODev nur wichtig ist, wenn an Geräte gesendet werden soll - der Empfang auf FHEM-Seite kann (und soll) über alle möglichen Kanäle parallel laufen...das erklärt ja, warum nicht nur die RSSIs der beiden Geräte, denen ich den RFR-CUL als IODev gegeben habe (HMS100 WD und KS300), auf den RFR 'reagieren'.
Ich habe nur den HauptCUL als IODev eingestellt, da es bei mir hauptsächlich nur um den Empfang der KS300 auf dem Dach ging. Der Empfang ist klar unabhänig vom IOdev, einer von beiden wird hoffentlich die Daten empfangen :)
Zitat von: SVLoneStar am 10 Mai 2015, 00:27:05
Aus den stark schwankenden RSSI-Werten schliesse ich nun, daß FHEM beide Signale empfängt (CUL und RFR-CUL)...muss das so sein? dupTimeout stand auf 0,5 und 1 und steht jetzt auf 2...ich sehe keine Änderung in den RSSI-Verläufen.
Denkfehler (RSSIs 'doppelter' Meldungen werden nicht gefiltert), oder Fehler in meinem Setup?
Ganz klar, beide Signale werden an FHEM weitergeleitet und das muss so sein um evtl. dopplete filtern zu könne. dupTimeout hat keinen Einfluss auf die RSSI Werte, lediglich die Zeitspanne in dem doppelte Einträge erkannt werden können.
Zum Denkfehler: Doppelte werden gefiltert, solange diese in einer bestimmten Zeitspanne auftreten.
Zum Fehler im Setup: Möglicherweise die Auswertung der RSSI Werte.
In den Device Internal sind in Deinem, wie im meinem Fall die RSSI vom RFR und vom HauptCUL vorhanden. Lediglich der Timestamp ist verschieden. Denn wie oben erwähnt, werden doppelte Einträge entfernt bzw. ignoriert. Ich weiß nicht wie Du die RSSI auswertest, aber schwanken sollten diese von einem CUL nicht, es sei denn die Auswertung berücksichtig beide Werte zugleich. Dann liegt es auf der Hand warum die RSSI Werte unterschiedlich sind, da dies ja auch der Sinn eines zwieten CULs, bessere Werte zu erzielen.
Viele Grüße,
Steve