RFXtrx

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

RFXtrx
RFXtrx433
Allgemein
Protokoll	diverse, vgl. Herstellerangaben
Typ	Sender / Empfänger
Kategorie	IT / RLS / SOMFY / HomeEasy / HomeComfort / Oregon / Lacrosse / ...
Technische Details
Kommunikation	433.92 MHz / 433.42 MHz
Kanäle
Betriebsspannung	5 V
Leistungsaufnahme	28 mA = 0.14 W (Empfang) / 45 mA = 0.23 W (Senden)
Versorgung	USB Input
Abmessungen	83 x 59 x 22 mm (130 mm mit Antenne)
Sonstiges
Modulname	TRX, TRX_ELSE, TRX_LIGHT, TRX_SECURITY, TRX_WEATHER
Ersteller	??
Hersteller	Bertronix RFXCOM

Übersicht

RFXtrx ist eine Gerätefamilie der Niederländischen Firma Bertronix RFXCOM, bestehend aus (2017/02):

• RFXtrx433 - Transceiver für 433.92 MHz
• RFXtrx433E - Transceiver für 433.92 MHz und 433.42 MHz (z. B. Somfy RTS)
• RFXrec433 - Receiver für Wettersensoren diverser Hersteller auf 433.92MHz
• RFX868X - (Prototyp, aktuell noch nicht im Verkauf) Transceiver für 433.92 MHz und 868 MHz
• RFXtrx315 und RFXtrx315E - Receiver für 315 oder 310 MHz Visonic Powercode Sensoren, PT2262 und protokollkompatible Geräte (vorrangig für USA-Markt)

Die E-Ausgaben sind dabei durch zusätzliche Hardware erweiterte Versionen.

Typischer Preis des RFXtrx433E: ca. 85 € (aufgearbeitetes gebrauchtes Gerät) ... ca. 110 € (Neuware).

RFXtrx433 bzw. RFXtrx433E 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. Genutzt wird RFXtrx433 von Anwendern mit FHEM unter Linux, Fritzbox 7390 oder Windows.

Der USB-Treiber emuliert ein serielles Interface (COM), über das die Kommunikation auf unterster Ebene läuft. Typisch ist dabei eine Baudrate von 38400.

Mit der mitgelieferten Firmware können viele Funksensoren in diesem Frequenzbereich empfangen werden und es ist möglich bestimmte Protokolle auch zu senden.

Ein englisches Benutzerhandbuch findet sich als PDF-Datei auf der Hersteller-Seite.

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.

Im FHEM-Forum werden weitere erfolgreich verbundene Geräte genannt.

Inbetriebnahme

Zusammenbau

Das Gerät wird fertig montiert geliefert. Antenne aufschrauben, USB-Kabel stecken - betriebsbereit.

USB-Devicetreiber

Um RFXtrx433 nutzen zu können, muss das Betriebssystem auf dem FHEM-Server, an dem der RFXtrx lokal am USB-Port steckt, einen Treiber für den Interface-Chip (FTDI-FT232R) haben. Zum Download und Nachinstallation finden sich diese für diverse Betriebssysteme bei Bedarf z. B. hier.

Die bisher verwendeten Hostsysteme (Windows 10, Ubuntu 16.10) erkannten des USB-Device in der Grundausstattung und legten die entsprechende serielle Schnittstelle (virtuelles COM-Device) an.

Firmware

Grundsätzlich unterstützte, aber im konkreten Einsatzfall nicht genutzte Empfangsprotokolle können deaktiviert (konfiguriert) werden, was eine Lastsenkung und Verbesserung der Empfangssicherheit zur Folge hat. Die unterstützten Protokolle sind von der installierten Firmware abhängig, die über das Windows-Programm (lauffähig unter Linux Mono) RFXflash (Beschreibung im Benutzerhandbuch) aktualisiert werden kann. Die neueste Firmware ist unter http://www.rfxcom.com/Downloads zu finden. Es gibt sie für den RFXtrx433 und RFXtrx433E in vier Varianten (Type1, Type2, Ext und Ext2).

Das Gerät wird meist mit einer relativ aktuellen Firmware ausgeliefert. Der Hersteller hat aber einen kurzen Release-Zyklus für die Firmware und beschreibt auf seinem Blog (auch als RSS-Feed beobachtbar) die neuen Feature (Geräteunterstützung) bzw. Fehlerbereinigungen. Es kann sich somit durchaus lohnen, bereits Initial die Firmware neu zu flashen.

Dem permanent aktualisierten englischen Benutzerhandbuch ist zu entnehmen, welcher Firmwaretyp welche Protokolle/Geräte unterstützt.

Empfohlen wird für

• den RFXtrx433E: Ext oder Ext2 (Type1 und Type2 sind möglich)
• den RFXtrx433: Type1 oder Type2

Hardware-Konfiguration

Zur Konfiguration (v.a. Protokolleinstellungen) und Testen der Geräte (Erkennen, Konfigurationsstatus sehen) sowie zum Analysieren empfangbarer Pakete und Versenden definierter Prokoll-Nachrichten gibt es das Windows-Programm (nicht lauffähig unter Linux Mono) RFXmngr (Beschreibung im englischen Benutzerhandbuch).

Einrichten des FHEM-Gerätes

Zur Verwendung des Transceivers ist ein FHEM-Gerät vom Typ TRX auf dem Server nötig, an dem der RFXtrx lokal am USB-Port steckt.

Bei aktiviertem autocreate sollte dies von FHEM selbst automatisch vorgenommen werden.

Die Verwendung eines Transceivers, der auf einem anderen Server lokal angesteckt ist, ist ebenso möglich, setzt allerdings dort ein lokal konfiguriertes TRX device voraus, das dann über IP und Port adressiert wird.

FHEM-Module

FHEM-Modul: TRX

Ein Gerät (device) vom Typ TRX ist die I/O-Schnittstelle zwischen FHEM und den Geräten, analog zu den CUL-devices.

Es wird bei den diversen TRX-Geräten dann als Schnittstellen-Gerät verwendet (IODev).

Das TRX-Gerät kann sich lokal (am USB-Port des Rechners, auf dem FHEM läuft) oder entfernt (network-connected) auf einem anderen FHEM-Server (dort lokal) befinden und angesprochen werden.

FHEM-Modul: TRX_ELSE

Empfängt der RFXtrx433 Nachrichten (Codes), die von keinem der folgenden TRX_...-Module bearbeitet wird (also z. B. ein neues device angelegt wird), wird ein device vom Typ RFX_ELSE angelegt. Dies ist dann ggf. zu deaktivieren/ignore (vielleicht, weil es vom Nachbarn stammt?!) oder eine Erweiterung der bestehenden RFX-Module (s. u.) bzw. die Erstellung eines weiteren in Angriff zu nehmen - am besten im Dialog mit dem Maintainer der TRX-Module.

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

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 Protokolladresse 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. Hinweise zur Nutzung sind im englischen User Guide (Kapitel "15. 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.

PT2262-Format am Beispiel der Brennenstuhl (RCS 2044 N) Steckdosen

Etwas verwirrend ist die Base-4-Codierung in FHEM und die Binärcodierung im RFXtrx, und weil mich das ein paar Minuten beschäftigt hat, beschreibe ich mal die Vorgehensweise exemplarisch mit dem o.a. Funk-Schaltdosensystem.

Vorbereitung (Hardware einstellen)

Zuallererst muss man sicherstellen, dass der "System-"Code aller Geräte, sprich des Senders und jedes Empfängers gleich ist, das sind die DIP-Switches (aka "Mäuseklavier") 1-5. "ON" ist eine 0, "OFF" eine 1. Dieser Konfiguration werden wir gleich noch begegnen. Stellen Sie also mal gleich alle Geräte auf eine andere Konfiguration als die ausgelieferte (sonst schalten Sie möglicherweise die Steckdosen des netten Nachbars), aber alle Geräte auf die gleiche Konfiguration.

Wer will, teste nun alle Steckdosen, ob sie mit der Fernbedienung schaltbar sind, ob also die Switches alle passen.

Konfiguration für FHEM

Nun zu FHEM: Erst einmal probiert man ja verschiedene Protokolle im RfxMgr. Also den Empfänger an den PC anschließen und im RfxMgr die Verbindung aufbauen. Im User Guide steht, dass das nötige Protokoll Lighting4 ist, also ankreuzen und Set Mode anklicken. Wenn man nun eine Taste der Fernbedienung drückt, kommt so was wie

Packettype    = Lighting4
 subtype       = PT2262
 Sequence nbr  = 6
 Code          = 455451 decimal:4543569
 S1- S24  = 0100 0101 0101 0100 0101 0001 
 Pulse         = 325 usec
 Signal level  = 7  -64dBm
 ------------------------------------------------
 ------------------------------------------------
 Packettype    = Lighting4
 subtype       = PT2262
 Sequence nbr  = 7
 Code          = 45555F decimal:4543839
 S1- S24  = 0100 0101 0101 0101 0101 1111 
 Pulse         = 324 usec
 Signal level  = 7  -64dBm

Hier kommen meist 2 Meldungen, zuerst das Kommando. Die zweite Meldung kann uns egal sein, sie kommt nicht immer und hat denselben Wert, egal ob eine Steckdose geschaltet wird oder nicht (also kein Fehlerstatus), und egal ob sie ein- oder ausgeschaltet ist.

Decodierung des Systemcodes

Nun steht überall hier im Artikel "12 Base4-Zeichen". Wir haben 24 Binärzeichen. Das läßt sich übersetzen, indem man immer 2 Binärzeichen zu einem Base4-Zeichen zusammenfasst:

0100 0101 0101 0100 0101 0001
 1 0  1 1  1 1  1 0  1 1  0 1

nach dem Prinzip: 00 = 0, 01 = 1, 10 = 2, 11 = 3

Und wenn man sich die DIP-Switches anschaut, und den Wert oben (hier "101111101101" durchgeht, fällt einem auf: die ersten 5 Zahlen sind genau die Stellungen der DIP-Switches: 10111 = OFF ON OFF OFF OFF

Und tatsächlich sind diese 5 Zahlen bei allen Tasten gleich: die Decodierung der ersten 5 Zahlen ist geschafft.

Decodierung der Steckdosen-Zuordnung

Dann geht man die verschiedenen Steckdosen-IDs durch, jeweils der "EIN"-Schalter, ergibt (suggestiv formatiert):

EIN=10111 01111 01, AUS=10111 01111 11 (Steckdose 1)
EIN=10111 10111 01, AUS=10111 10111 11 (Steckdose 2)
EIN=10111 11011 01, AUS=10111 11011 11 (Steckdose 3)
EIN=10111 11101 01, AUS=10111 11101 11 (Steckdose 4)

Also sind die nächsten 5 Zahlen die Zuordnung der Steckdosen. Jede Stelle beschreibt den Zustand des passenden DIP-Switches "A" bis "E", wie üblich "0" ist "ON", "1" ist "OFF". Ob die Steckdosen mit mehr als einem auf OFF gelegten "A" bis "E"-Switch funktionieren, habe ich nicht getestet, aber es erscheint logisch, man könnte dann bis zu 32 Steckdosen auf den gleichen Systemcode legen, und ein Nachbar mit Fernbedienung kann nichts Böses anrichten! FHEM kann es egal sein, man kann ja verschiedene Systemcodes angeben, das geht bei der Fernbedienung nicht. Die ausserdem auch nur einen der "A" bis "D"-Switches adressiert.

Ein/Aus-Kommando

Bleiben noch 2 Zahlen. Wenn man auf den "AN"-Taster drückt, ist der Wert "01", bei "AUS" "11". Da hier wieder alles invertiert ist, steht zu vermuten, dass davon nur die erste Zahl den gewünschten Schaltzustand beschreibt, "01" -> "0" -> "EIN". "11" -> "1" -> "AUS". Was die letzte Stelle ist: keine Ahnung.

Geschafft: jetzt ist die Fernbedienung in FHEM folgendermassen zu konfigurieren:

defmod Steckdose_brennenstuhl_aussen TRX_LIGHT PT2262 1011101111 light 01:on,10:off
defmod Steckdose_brennenstuhl_1 TRX_LIGHT PT2262      1011110111 light 01:on,10:off
defmod Steckdose_brennenstuhl_2 TRX_LIGHT PT2262      1011111011 light 01:on,10:off
defmod Steckdose_brennenstuhl_3 TRX_LIGHT PT2262      1011111101 light 01:on,10:off
attr Steckdose_brennenstuhl_.* Funksteckdosen,RFXcom

(Natürlich sind die ersten 5 Zahlen bei Ihrem System anders als meine, insbesondere wenn Sie direkt neben mir wohnen, bitte ;))

Hinweis: Man kann natürlich auch bei jeder Steckdose die ersten 5 Switches anders einstellen, also alle 10 Stellen, aber dann kann man die Fernbedienung nicht mehr verwenden, um mehrere zu schalten.

Adventsbeleuchtung gefällig?

define di_adventsbeleuchtung   DOIF ([{sunset(-1800)}-24:00])  (set Steckdose_brennenstuhl_aussen on) DOELSE (set Steckdose_brennenstuhl_aussen off)
define di_adventsbeleuchtung_2 DOIF ([05:45-{sunrise(+1800)}]) (set Steckdose_brennenstuhl_aussen on) DOELSE (set Steckdose_brennenstuhl_aussen off)
define di_adventsbeleuchtung_3 DOIF ([{sunset(-1800)}-01:00])  (set Steckdose_brennenstuhl_1 on) DOELSE (set Steckdose_brennenstuhl_1 off)
define di_adventsbeleuchtung_4 DOIF ([05:35-{sunrise(+1800)}]) (set Steckdose_brennenstuhl_1 on) DOELSE (set Steckdose_brennenstuhl_1 off)

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 (älteren) Windows muss ein entsprechender Treiber installiert werden. Siehe auch im englischen Benutzerhandbuch<ref name="BHB">.

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!

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) ;-)

---