RFXtrx

Fhem unterstützt viele durch einen RFXtrx433 Transceiver erreichbare Geräte durch eigene Module.

Übersicht

RFXtrx433 ist ein Transceiver (Funkempfänger und Funksender) mit USB-Anschluss für den Frenzbereich 433,92 MHz. Die Stromversorgung erfolgt über USB. Das Gerät hat einen FTDI-FT232R-USB-Interface-Chip installiert. Um RFXtrx433 nutzen zu können, muss das Betriebssystem einen entsprechenden Treiber für diesen Chip haben. Genutzt wird RFXtrx433 von Anwendern mit FHEM unter Linux, Fritzbox 7390 oder Windows.

Mit der mitgelieferten Firmware können viele Funksensoren in diesem Frequenzbereich empfangen werden und es ist möglich bestimmte Protokolle auch zu senden. Die unterstützten Protokolle sind von der installierten Firmware abhängig, die über das Windows-Programm RFXflash aktualisiert werden kann. Die neueste Firmware ist unter http://www.rfxcom.com/Downloads zu finden.

Weitere Informationen zu den von diesem Transceiver verfügbaren Protokolle beim Hersteller unter www.rfxcom.com. Da der Hersteller die Anzahl der Geräte ständig aktualisiert und die FHEM-Treiber in der Freizeit des Autors geschrieben werden, sind in den FHEM-Treibern nur eine Untermenge implementiert. Sollte ein Gerät/Protokoll fehlen, das die Firma RFXCOM unterstützt, können Sie im FHEM-Forum in der Untergruppe RFXTRX nachfragen, ob dieses implementiert werden kann.

TRXtrx433 wird derzeit von FHEM mit den Modulen TRX, TRX_LIGHT, TRX-SECURITY und TRX_WEATHER für eine Reihe von Protokollen unterstützt.

Nachfolgend werden nur Geräte aufgezeigt, die bei der Erstellung dieses WIKI-Eintrages eingepflegt werden.

FHEM-Modul: TRX_WEATHER

Dieses Modul unterstützt Wettersensoren, insbesondere Sensoren des Herstellers Oregon-Scientific. Unter Wetter-Sensoren finden Sie eine Liste der von der RFXtrx433-Firmware unterstützten Wetter-Sensoren (Oregon-Scientific, Cresta, La Crosse, TFA, UPM, ...). Das FHEM-Modul TRX_WEATHER implementiert derzeit den Empfang folgender Sensorentypen und Sensoren:

- Temperatursensoren:

• "THR128": Oregon-Scientific THR128/138, THC138
• "THGR132N": Oregon-Scientific THC238/268,THN132,THWR288,THRN122,THN122,AW129/131
• "THWR800": Oregon-Scientific THWR800
• "RTHN318": Oregon-Scientific RTHN318
• "TS15C": TS15C
• "VIKING_02811" : Viking 02811
• "WS2300" : La Crosse WS2300
• "RUBICSON" : RUBiCSON
• "TFA_303133" : TFA 30.3133

- Temperatur-/Luftffeuchtigkeitssensoren:

• "THGR228N": Oregon-Scientific THGN122/123, THGN132, THGR122/228/238/268
  

  THGR228N
• "THGR810": Oregon-Scientific THGR810
• "RTGR328": Oregon-Scientific RTGR328
• "THGR328": Oregon-Scientific THGR328
• "WTGR800_T": Oregon-Scientific WTGR800
• "THGR918": Oregon-Scientific THGR918, THGRN228, THGN500
• "TFATS34C": TFA TS34C (Kat. Nr. 30.3150)
• "WT450H": UPM WT450H
• "TX3_T": LaCrosse TX3, TX4, TX17

TX3TH

• Nicht unterstützt werden von der RFXCOM-Firmware: TFA 30.3166

- Temperatur-/Luftffeuchtigkeits-/Luftdrucksensoren:

• "BTHR918": Oregon-Scientific BTHR918
• "BTHR918N": Oregon-Scientific/Huger BTHR918N, BTHR968
  

  BTHR918N

- Regensensoren:

• "RGR918": Oregon-Scientific RGR126/682/918
• "PCR800": Oregon-Scientific PCR800
• "TFA_RAIN": TFA-Regensensor (Kat. Nr. 30.3148)
• "RG700": UPM RG700

- Windsensoren:

• "WTGR800_A": Oregon-Scientific WTGR800
• "WGR800_A": Oregon-Scientific WGR800
• "WGR918": Oregon-Scientific STR918, WGR918
• "TFA_WIND": TFA-Windsensor (Kat. Nr. 30.3149)
• "WDS500" : UPM WDS500

- UV-Sensoren:

• "UVN128": Oregon UVN128, UV138
• "UVN800": Oregon UVN800
• "TFA_UV": TFA_UV-Sensor

- Waagen:

• "BWR101": Oregon Scientific BWR101
• "GR101": Oregon Scientific GR101

- Energiesensoren:

• "CM160": OWL CM119 und CM160
• "CM180": OWL CM180

Der Autor des Module setzt derzeit folgende Sensoren ein:

• Oregon Scientific: BTHR918, BTHR918N, PCR800, RGR918, THGR228N, THR128, THWR288A, WTGR800, WGR918

Von Nutzern wurde die Funktion folgender weiterer Sensoren gemeldet:

• Oregon Scientific GR101
• Oregon Scientific RTGR-328 (T/H)
• Honeywell TF-ATS34C (T/H)
• TFA Regensender 433 MHz, Kat. Nr. 30.3148, siehe TFA
• TFA Windsender 433 MHz, Kat. Nr. 30.3149, siehe TFA
• TFA T/H-Sender 433 MHz, Kat. Nr. 30.3150, siehe TFA
• OWL CM160

FAQ: Wie bringe ich FHEM dazu nicht alle paar Sekunden den Zustand der Sensoren zu loggen?

Den ein oder anderen hat es schon genervt, dass die Oregon-Sensoren sehr gesprächig sind und damit das Filelog sehr groß wird.

Abhilfe: Hierzu kann man event-min-interval verwenden, um festzulegen, dass Events nur alle x Minuten generiert werden. event-on-change-reading kann man verwenden, dass Änderungen trotzdem sofort bemerkt werden.

Nachfolgend wird ein Oregon-Sensor BTHR918 so konfiguriert, dass er nur alle 10 Minuten loggt, aber beim State die Änderungen sofort geloggt werden.

define Alte_Garage TRX_WEATHER BTHR918
attr Alte_Garage event-min-interval state:600
attr Alte_Garage event-on-change-reading state
attr Alte_Garage event-on-update-reading .*

Damit man nicht alles loggt, kann man das Logging auf die Zeilen beschränken, die mit T: beginnen:

define FileLog_Alte_Garage FileLog /var/log/fhem/Alte_Garage-%Y.log Alte_Garage:T\x3a.*
attr FileLog_Alte_Garage logtype temp4press8:Temp/Press,temp4hum6dew10:Temp/Hum,text

Damit hat man dann folgendes im Log:

2013-08-27_12:21:29 Alte_Garage T: 19.9 H: 69 P: 1005 BAT: low
2013-08-27_12:31:37 Alte_Garage T: 19.9 H: 69 P: 1005 BAT: low
2013-08-27_12:41:45 Alte_Garage T: 19.9 H: 69 P: 1005 BAT: low
2013-08-27_12:47:27 Alte_Garage T: 20 H: 68 P: 1005 D: BAT: low
2013-08-27_12:57:35 Alte_Garage T: 20 H: 68 P: 1005 D: BAT: low

Wie man sieht, wird normalerweise alle 10 Minuten geloggt. Um 12:47:27 hat sich die Temperatur verändert und damit wurde ausserhalb der Reihe sofort ein Event generiert.

Ja, stimmt, ich muss noch die Batterie des Sensors wechseln (BAT: low) ;-)

FHEM-Modul: TRX_SECURITY

Empfängt Security-Sensoren der Protokolle X10-Security, KD101 und Visonic.

KD101 kompatible Rauchmelder Es wurden folgende KD101-Versionen gemeldet, die mit RXFtrx433 empfangen werden können:

• KD101LD
• KD101LA
• Flamingo FA20RF
• Elro RM150RF
• Unitec 46779

Die Rauchmelder KD101 (KD101LD, KD101LA, Flamingo FA20RF, Elro RM150RF) haben folgendes Verhalten:

• Wenn der KD101 selbst Rauch feststellt, kann man diesen Alarm über Funk nicht stoppen. Er sendet "alert" über Funk.
• Wenn man "alarm" über Funk an einen Rauchmelder sendet, dauert der Alarm nur wenige Sekunden. Für einen dauerhaften Alarm muss man also "alert" immer wieder senden.
• Wenn man die KD101 pairt, bekommen alle gepairten KD101 dieselbe ID.
• Wenn einer Rauch erkennt, triggert er alle KD101 mit derselben ID (also die gepairten).
• Nach Drücken der Taste "Test" am Rauchmelder sendet dieser "alert". Dadurch wird per autocreate der Rauchmelder angelegt.
• Ein KD101 sendet kein Keepalive-Signal. Man kann also nur testen, ob ein Rauchmelder noch funktioniert, indem man die Test-Taste drückt.

Mittels RFXtrx433 kann man die Befehle "alert" und "pair" an einen Rauchmelder senden.

Beispiel:

• set TRX_KD101_a5ca00 alert

Dies sendet den panic-Befehl an den Rauchmelder. Damit hört man ca. 3 Sekunden lang den nervigen Ton des Rauchmelders. Wer diesen länger haben will, muss das set nach ca. 3 Sekunden erneut auslösen. Wer man also ein "set DEVICE alert" an einen Rauchmelder schickt, der mit anderen gepairt ist, dann wird der Alarm bei allen gepairten Rauchmeldern ausgelöst.

X10-Security-Sensoren Folgende X10-Security-Sensoren werden erfolgreich eingesetzt:

• Türsensoren:
  • X10 Türsensor Powerhouse DS10A (Umbau auf 433 Mhz)
  • Marmitek Türsensor DS90
• Bewegungssensoren:
  • X10 Bewegungssensor Powerhouse MS10A (Umbau auf 433 Mhz)
    

    MS10A
    

    MS90
  • Marmitek Bewegungssensor MS10E/BNL (kompatibel mit X10 MS10)
  • Marmitek Bewegungssensor MS90
• Rauchmelder:
  • Marmitek Rauchmelder SD90

Die oben genannten Sensoren können auch parallel zum RFXtrx433 mit der Marmitek-Alarmanlage SC9000 eingesetzt werden.

• Fernbedienungen:
  • Marmitek KR21E
    

    KR21E
    

    SH624
  • Marmitek SH624

X10-Security-Sensoren senden etwa jede Stunde ein Keepalive-Paket, welches auch Informationen über den Batterieladestand enthält.

• Bewegungsmelder
  • Oregon MSR939 (benötigt den RFXtrx433e), theoretisch 32 Adressen möglich, 5 Stück erfolgreich eingebunden (mehr Sensoren hatte ich nicht zur Hand)

FHEM-Modul: TRX_LIGHT.pm

Empfängt die Protokolle X10, ARC, ELRO AB400D, Waveman, Chacon EMW200, IMPULS, RisingSun, Philips SBC, AC, HomeEasy EU sowie ANSLUT lighting devices (switches and remote control).

ARC ist ein a Protokoll, welches von Geräten HomeEasy, KlikAanKlikUit, ByeByeStandBy, Intertechno, ELRO, AB600, Duewi, DomiaLite und COCO genutzt wird. Typisch ist, dass diese Geräte einen Drehschalter haben, um die Protkolladresse einzustellen.

Das ARC-Protokoll kennt keinen Dim-Befehl. Daher hat die Firmware vom RFXtrx433 und auch das FHEM-Modul TRX_LIGHT keinen solchen Befehl. Die verkauften Dimmer mit ARC-Protokoll starten gemäß meiner Information das Hoch-Dimmen nach Empfang zweier ON-Kommandos. Sobald dann das nächste ON oder OFF Kommando empfangen wird, wird das Dimmen beendet. Das ganze ist also zeitabhängig und eigentlich nicht für die Hausautomatisierung gedacht, sondern für den Menschen, der sieht, ob der Dim-Level ok ist. Automatisiert bekommt man keine exakte prozentuale Dimmung hin, da man Dimmen nur über Timing erreichen kann. Da FHEM nicht sehen kann wie weit gedimmt wurde, ist das allerdings nicht wirklich praktikabel und auch vom Gerät abhängig. Unterschiedliche Geräte auch unterschiedliches Zeitverhalten.

AC ist ein Protokoll, welches verschiedene Hersteller nutzen, die die Adresse über einen LEARN-Button lernen: KlikAanKlikUit, NEXA, CHACON, HomeEasy UK.

Achtung:Es sollte beachtet werden, dass Tür- und Bewegungssensoren des AC-Protokolls (HomeEasy alt, Chacon, KlikAanKlikUit, NEXA...) teilweise für 3-5 Sekunden etwa 50 Funkpakete generieren, was zu Kollisionen mit anderen Paketen führen kann. Siehe Hinweis zur Nutzung von Bewegungssensoren. Ich rate daher vom Einsatz von Bewegungssensoren mit dem AC-Protokoll ab.

Der Autor des Moduls setzt derzeit folgende Geräte ein:

• Eagle EyeMS14a Bewegungssensor (Umbau auf 433 Mhz)
• Elro AB600 Funksender und Steckdosen

Nutzer haben die Funktion folgender Geräte gemeldet:

• KAKU AWST-6000 (Bewegungsmelder, sendet on/off)
• KAKU AMST-606 (Tür-/Fenster-Kontakt, sendet all_level/off)
• KAKU AWMT-230 (Unterputzsender, sendet on/off)
• KAKU APA3-1500R (Schalter & Handsender, nur on/off/all_off)
• KAKU CDB-6500AC (Türklingel, sendet nur chime)

PT2262 empfangen und senden mit TRX_LIGHT.pm

WARNUNG:PT2262-Codes sollten nur verwendet werden, wenn unbedingt erforderlich. Normalerweise reicht die Nutzung der von RFXCOM vordefinierten Dekodierungen wie das ARC-Protokoll aus. Bei manchen Geräten mit dem Chip PT2262 kann dies evtl. nicht ausreichen. Sinnvollerweise sollte man prüfen, ob das Gerät wirklich einen Funk-Encoder-IC PT2262 oder SC2262 enthält.

ACHTUNG: Es können nur PT2262-Codes empfangen werden, wenn das Pulse-Timung 350 usec ist (Siehe Kapitel 8 im RFXtrx User Guide). Gemäß Seite 6 im Dokument http://www.escol.com.my/Datasheets_specs/pt2262_1.pdf‎ sollte für den Oszillator normalerweise ein 3,3 Mega-Ohm-Widerstand eingebaut sein.

PT2262-Format empfangen

Das Funk-Encoder-IC PT2262 der Firma PTC Taiwan (siehe http://pdf.dzsc.com/88889/21967.pdf) wird häufig in Fernbedienungen von Funksteckdosen und auch anderen Funkgeräten im 433-Mhz-Bereich verwendet. Es gibt viele PIN kompatible ICs wie z.B. der SC2262.

Es werden hierbei 12 Zeichen im Tristate-Format (0, 1, 2 bzw. f) übertragen. Der erste Teil der Zeichen stellt die Adresse und die darauffolgenden Zeichen die Datenbits (Zeichen 0 oder 1) dar. Die verwendeten Fernbedienungen haben häufig Dip-Schalter mit drei Zuständen (also 0,1,2), mit denen sich die Adressen einstellen lassen.

Das Protokoll ist vom Aufbau ähnlich zum ARC-Protokoll.

Dabei lassen sich die ersten 6-12 Zeichen als Adressen (A0 bis A11) und die letzten 0-6 Zeichen (D5-D0) als Datenbits nutzen. Es sind damit insgesamt folgende Kombinationen der Bits möglich:

A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 A10 A11
A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 A10 D0 
A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 D1 D0
A0 A1 A2 A3 A4 A5 A6 A7 A8 D2 D1 D0
A0 A1 A2 A3 A4 A5 A6 A7 D3 D2 D1 D0 
A0 A1 A2 A3 A4 A5 A6 D4 D3 D2 D1 D0 
A0 A1 A2 A3 A4 A5 D5 D4 D3 D2 D1 D0

Damit lassen sich also maximal 6-Bit-Daten übertragen. Dies reicht für einfache Schaltaufgaben, aber nicht für Anwendungen wie beispielsweise Thermometer.

RFXtrx433 läßt sich über RFXmngr so konfigurieren, dass die 12-Zeichen-Datagramme des PT2262-Formats als 24-Bit-Nutzdaten bzw. 3 Bytes empfangen werden können. Dazu kann man in RFXmngr das Protokoll Lighting4 einschalten, wodurch gleichzeitig die Verarbeitung des ARC-Protokolls ausgeschaltet wird. Hinweise zur Nutzung sind in http://www.rfxcom.com/Documents/RFXtrx%20User%20Guide.pdf (Kapitel "8. Transmit undecoded ARC commands") zu finden.

Das FHEM-Modul TRX_LIGHT erlaubt die Verarbeitung des PT2262-Formates.

Sobald Lighting4 eingeschaltet wird, werden die einzelnen Bits dem Gerät TRX_PT2262 zugeordnet. Sofern dieses noch nicht vorhanden ist, wird diesen per Autocreate definiert und ein entsprechendes Filelog angelegt.

Wenn beispielsweise ein Nutzer einen Taster einer ELRO AB600 Fernbedienung drückt, werden je nach Codierung der Adresse folgende Codes im Filelog generiert:

• Drücken der Taste "on":

2012-12-30_21:40:42 TRX_PT2262 111101110111

• Drücken von "off":

2012-12-30_21:40:47 TRX_PT2262 111101110110

Auf diese Weise kann ein Nutzer sehen, welche PT2262-Codes von RFXtrx433 empfangen werden.

Der Nutzer muss danach selbst entscheiden, welche Zeichen Adressen und welche Daten darstellen und was die Daten bedeuten. Im oben genannten Beispiel ist dies relativ einfach. Man sieht, dass sich nur das letzte Bit ändern und die Zustände 0 und 1 annimmt. Es ist daher anzunehmen, dass die ersten 11 Zeichen die Adresse repräsentieren.

TRX_LIGHT bietet die Möglichkeit den Adressprefix, die sogenannte deviceid selbst in einem define-Statement festzulegen. Die Konvention ist dabei, dass die einzelnen Zeichen der Base4-Codierung angegeben werden müssen:

define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]

In commandcodes gibt man optional an wie die Ziffern Strings wie beispielsweise "on" oder "off" zugeordnet werden sollen. Dabei können über Komma getrennt wie die Ziffern den einzelnen Strings zugeordnet werden sollen. Jede einzelne Zuordnung wird über : angegeben. Zusätzlich sollte ein entsprechendes FileLog definiert werden.

Beispiel:

define TRX_MYREMOTE1 TRX_LIGHT PT2262 11110111011 light 0:off,1:on

define FileLog_TRX_MYREMOTE1 FileLog /var/log/fhem/TRX_MYREMOTE1-%Y.log TRX_MYREMOTE1

In diesem Fall wird die Ziffer 0 "off" und die Ziffer 1 "on" zugeordnet.

Damit werden nach Drücken der Tasten on und off folgende Einträge im Filelog wie folgt generiert:

  ==> TRX_MYREMOTE1-2012.log <==
  2012-12-30_21:54:56 TRX_MYREMOTE1 light: on
  2012-12-30_21:54:56 TRX_MYREMOTE1 on

  ==> TRX_MYREMOTE1-2012.log <==
  2012-12-30_21:54:59 TRX_MYREMOTE1 light: off
  2012-12-30_21:54:59 TRX_MYREMOTE1 off

PT2262-Format senden

Mit dem Funk-Decoder-IC PT2272 lassen sich Signale von PT2262-Sendern empfangen. RFXtrx433 ist in der Lage Funksignale im PT2262-Format zu senden, die dann mit Geräten empfangen werden können, die über den Funk-Decoder-IC PT2272 verfügen. Dazu ist es nicht erforderlich in RFXmngr das Protokoll Lighting4 einzuschalten.

PT2262-Codes können über ein set-Kommando des vorher zu definierenden PT2262-Devices gesendet werden. Die Definition wurde auch schon bei "PT2262-Format empfangen" beschrieben.

define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]

Beispiel:

define TRX_MYREMOTE1 TRX_LIGHT PT2262 11110111011 light 0:off,1:on

Sobald das Device definiert wurde, kann der Code mittels set gesendet werden. Dabei kann man entweder der Base4-Code direkt angegeben werden oder der String der in <commandcodes> definiert wurde.

Beispiele (senden von 1):

set TRX_MYREMOTE1 1

set TRX_MYREMOTE1 on set TRX_MYREMOTE1 off Damit ein PT2262 Code gesendet werden kann, muss der Base4-Code bestehend aus <deviceid> und den Daten genau 12 Base4-Zeichen haben.

Die mittels <commandcodes> definierten Strings werden in der Auswahlliste von set in der Weboberfläche von FHEM berücksichtigt.

Fragen und Antworten (FAQ)

Warum wird mein RFXtrx433 nicht erkannt?

Das Gerät hat einen FTDI-FT232R-USB-Interface-Chip installiert. Um RFXtrx433 nutzen zu können, muss das Betriebssystem einen entsprechenden Treiber für diesen Chip haben. Dies ist normalerweise bei Linux oder Fritzbox 7390 der Fall. Bei Windows muss ein entsprechender Treiber installiert werden. Siehe auch http://www.rfxcom.com/Documents/RFXtrx%20User%20Guide.pdf .

Bei Fritzbox 7270 und 7170 werden vom Hersteller AVM mit der Firmware keine Treiber für den FTDI-FT232R-USB-Interface-Chip mitgeliefert.

Warum werden die Tasten meiner Fernbedienung nicht alle erkannt?

Ist geklärt, dass die Fernbedienung von der Firmware supportet wird? Gerade beim ARC-Protokoll ist es häufig so, dass die Hersteller unterschiedliche Codierungen verwenden.

Es wurde berichtet, dass die Tasten folgende Fernbedienungen von der Firnware des RFXtrx433 nicht alle richtig erkannt werden:

• ELRO AB440RA

Bei folgende Fernbedienungen wurden berichtet, dass diese richtig erkannt werden:

• ELRO AB600RA

Bitte weitere Fernbedienungen melden!