RFR CUL mit nanoCUL 868MHz

[SVLoneStar]

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/ 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  und 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

[Matscher]

Hallo Stefan,

sieht soweit gut aus. 10 Messages wurden schon empfangen. Bei RAWMSG siehst Du das letzte empfangene Datum.

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.

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

[SVLoneStar]

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

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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

[Matscher]

Hallo Stefan,

schonmal sehr gut das der RFR Cul funktioniert.

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.

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.

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

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