RFXtrx: Unterschied zwischen den Versionen

Aus FHEMWiki
Zeile 23: Zeile 23:
* "THWR800": Oregon-Scientific THWR800
* "THWR800": Oregon-Scientific THWR800
* "RTHN318": Oregon-Scientific RTHN318
* "RTHN318": Oregon-Scientific RTHN318
* "TX3_T": LaCrosse TX3, TX4, TX17
* "TS15C": TS15C
* "TS15C": TS15C
* "VIKING_02811" : Viking 02811
* "VIKING_02811" : Viking 02811
Zeile 40: Zeile 39:
* "TFATS34C": TFA TS34C (Kat. Nr. 30.3150)
* "TFATS34C": TFA TS34C (Kat. Nr. 30.3150)
* "WT450H": UPM WT450H
* "WT450H": UPM WT450H
* "TX3_T": LaCrosse TX3, TX4, TX17
[[File:TX3TH.jpg|92px|right|thumb|TX3TH]]


- '''Temperatur-/Luftffeuchtigkeits-/Luftdrucksensoren''':
- '''Temperatur-/Luftffeuchtigkeits-/Luftdrucksensoren''':
Zeile 90: Zeile 91:
* TFA T/H-Sender 433 MHz, Kat. Nr. 30.3150, siehe [http://tfa-dostmann.de/index.php?id=57 TFA]
* TFA T/H-Sender 433 MHz, Kat. Nr. 30.3150, siehe [http://tfa-dostmann.de/index.php?id=57 TFA]
* OWL CM160
* OWL CM160
== FHEM-Modul: TRX_SECURITY ==
== FHEM-Modul: TRX_SECURITY ==
Empfängt Security-Sensoren der Protokolle X10-Security, KD101 und Visonic.  
Empfängt Security-Sensoren der Protokolle X10-Security, KD101 und Visonic.  

Version vom 14. Mai 2013, 09:24 Uhr

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

Übersicht

Rfxtrx433.png

RFXtrx433 ist ein Transceiver (Funkempfänger und Funksender) mit USB-Anschluss für den Frenzbereich 433,92 MHz. Die Stromversorgung erfolgt über USB.

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 Oregon-Sensoren finden Sie eine vollständige Liste der aktuell von RFXtrx433 unterstützten Oregon Scientific Sensoren. 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

- 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:
  • 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
    • Unitec 46771X (meldet sich als KR18, inkl Battery-Status)

Die oben genannten Sensoren können auch parallel zum RFXtrx433 mit der Marmitek-Alarmanlagfe 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.

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.

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

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

  • Eagle EyeMS14a Bewegungssensor ([http://www.domotica.famschenk.eu/MS14A_OP_433.92.html 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.

RFXtrx433 bietet die Möglichkeit diese Geräte zu empfangen, jedoch muss man dazu die Bits und Bytes der entsprechenden PT2262-Codierung sowie die Funktionsweise von PT2262 allgemein verstehen, bevor man dies nachfolgend realisieren kann.

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.