FHEMWiki - Benutzerbeiträge [de]

SIGNALduino

2016-02-13T21:44:56Z

Wherzig: Kleine Korrektur. set fehlte bei flash

{{Infobox Modul
|ModPurpose=Unterstützung für CUL-Klon auf Arduino-Basis
|ModType=d
|ModFTopic=38402
|ModCmdRef=SIGNALduino
|ModForumArea=Sonstige Systeme
|ModTechName=00_SIGNALduino.pm
|ModOwner=Sidey ({{Link2FU|8018|Forum}}/[[Benutzer Diskussion:Sidey|Wiki]])
}}

Das Modul [[SIGNALduino]] unterstützt den gleichnamigen Low-Cost Empfänger für digitale Signale, ähnlich einem [[CUL]]. Der SIGNALduino (Hardware) basiert auf einem Arduino. Hauptsächlich wurde er für den [http://arduino.cc/de/Main/ArduinoBoardNano Arduino Nano] entwickelt. Es stehen jedoch auch für den [https://www.arduino.cc/en/Main/arduinoBoardUno UNO] und [https://www.arduino.cc/en/Main/ArduinoBoardProMini PRO Mini] Firmware Dateien zur Verfügung. Die ausgelieferte Firmware läuft nur auf Mikrocontrollern mit 16 Mhz. Wer einen Mikrocontroller mit 8 Mhz verwenden möchte, muss die Firmware selbst compilieren.

Er wird derzeit über den USB Port angeschlossen. Die Schaltung entspricht der des [[FHEMduino]].

# Das Modul ist nicht fertig und kann als frühes Release bezeichnet werden.
# Das Modul gibt bei Bedarf sehr viele Meldungen ins Logfile, in den Normaleinstellungen verhält es sich aber relativ ruhig.

== Was macht dieser SIGNALduino? ==
[[Datei:Fhemduino_schematic.png|200px|thumb|right|SIGNAL(FHEM)duino Schaltplan]]
Digitale Signale anhand von Mustern erkennen und zum Auswerten an FHEM weitergeben, dort können die Daten dann dekodiert werden.
Zwischenzeitlich gibt der Arduino alle erkannten Signale an FHEM weiter, dies hilft um vor allem Signale zu finden, die noch nicht bekannt sind.

Beispiel:
Arduino mit 433 Mhz Empfänger an einen Fhem Server anschließen und IT Steckdosen empfangen / schalten

Das System ist jedoch nicht auf 433 Mhz beschränkt. Es funktioniert auch mit anderen Frequenzen oder Medien, z.B. auch mit Infrarot oder direkt angebunden via Draht.

== Worin liegt der Vorteil zu einem CUL oder FHEMduino? ==
Erst mal gibt es noch keinen richtigen Vorteil. Der ergibt sich erst, wenn man in FHEM die Signaldaten entsprechend verarbeitet. Für einige wenige Dinge ist das bereits implementiert, z.B. lassen sich Wettersensoren oder Funksteckdosen damit empfangen.
Wer Lust hat weitere Protokolle zu dekodieren, braucht dazu nur ein passendes FHEM Modul entwickeln. Änderungen am Arduino Code sind "eigentlich" nicht notwendig, dadurch skaliert das System gut.

Andere Möglichkeit: wer einen Wettersensor dekodieren möchte, muss ja erst mal feststellen, was der Sensor sendet. Dazu kann man den SIGNALduino auch an den Sendeausgang des Sensors anbinden und empfängt die digitalen Signale. Bitte achtet aber auf die passenden Spannungen, bevor ihr eine solche Schaltung vornehmt. Ein Arduino Nano verträgt 5V.

== Unterstützte Geräte ==
Für die folgenden Geräte gibt es derzeit eine Unterstützung für den Betrieb mit Fhem. Die Geräte werden [[autocreate|automatisch erkannt]] und in der Konfiguration eingetragen wenn der SIGNALduino mal läuft.
{|class="wikitable"
! style="text-align:left;"| Produkt
! (E)mpfangen<br />(S)enden
! Hinweise
! Verwendetes Modul
! Protokoll ID
|-
|TCM Wetterstation (97001 und 21xxx Serie)||E|| || CUL_TCM97001 || 0
|-
|ABS Wetterstation (ABS 700)||E|| || CUL_TCM97001 || 0
|-
|Prologue Wetterstation ||E|| ||CUL_TCM97001 || 0
|-
|Rubicson Wetterstation ||E|| ||CUL_TCM97001 ||0
|-
|NC_WS Wetterstation ||E|| ||CUL_TCM97001 || 0
|-
|[http://www.gt-support.de/ GT-WT-02 Wetterstation]||E|| ||CUL_TCM97001 || 0
|-
|AURIOL Wetterstation ||E|| ||CUL_TCM97001 || 0
|-
|Mebus Wetterstation ||E|| ||CUL_TCM97001 || 0
|-
|Intertechno Funkschalter||E S|| ||IT || 3,4,5,17
|-
|<strike>Conrad RSL Funkschalter</strike>||E S|| Funktioniert aktuell nicht || SIGNALduino_RSL ||
|-
|[http://global.oregonscientific.com/product_view.php?id=5 Oregon Scientific Wettersensoren]||E || Protokoll V2 & V3 implementiert || OREGON || 10
|-
|Bresser Temp/Hydro Sensor||E || || Hideki || 12
|-
|[https://de.hama.com/00104985/hama-aussensensor-ts33c-fuer-wetterstation Hama TS33C]||E || || Hideki || 12
|-
|TFA Temp/Hydro Sensor||E || || Hideki || 12
|-
|Lacrosse TX2/TX3 Sensoren||E || || CUL_TX || 8
|-
|TFA 30320902||E || || SD_WS07 || 7
|-
|Eurochon eas800z||E || || SD_WS07 || 7
|-
|Technoline WS6750/TX70DTH||E || || SD_WS07 || 7
|-
|FreeTec Außenmodul NC-7344||E || || SD_WS07 || 7
|-
|CTW600||E || || SD_WS09 || 9
|-
|WH1080||E || || SD_WS09 || 9
|-
|Visivon remote pt4450||E || || none || 24
|-
|Einhel HS 434/6||E || || none || 21
|-
|FA21RF||E || || none || 13
|-
|mumbi m-FS300||E || || none || 26,27
|-
|TFA 30.3200||E || || none || 33
|-
|Livolo||E|| || none || 20

|}

== Hardware ==
Wie muss der Arduino verkabelt werden?
Die Verkabelung ist Identisch zum [[FHEMduino]]

== Einbinden in FHEM ==
Die SIGNALduino Module werden über das FHEM [[update]] verteilt.

Die in der Entwicklung befindliche Version kann auch geladen werden. Dazu folgenden Befehl in Fhem ausführen:
:<code>update all <nowiki>https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r32/controls_signalduino.txt</nowiki></code>

Durch das Update wird auch die Firmware geladen. Im Log File seht ihr, wo diese hinkopiert wurden: z.B. nach FHEM/firmware/SIGNALduino_nano328.hex

Danach kann das Gerät wie folgt definiert werden (die Spezifikation des USB Anschlusses muss natürlich an die aktuellen Gegebenheiten angepasst werden):
:<code>define sduino SIGNALduino /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600</code>

Nach dem Einbinden wird der SIGNALduino, falls er erkannt wird, im Status "Opened" angezeigt. Erst wenn die richtige Firmware auf dem Arduino ist, wird der Status "Initialized" angezeigt

== Flashen des Ardunio mit der SIGNALduino Firmware ==
Falls avrdude noch nicht vorhanden ist, kann es mit folgendem Befehl installiert werden:
:<code>sudo apt-get install avrdude</code>

In Fhem ist der SIGNALduino ja bereits mit dem Status "Open" vorhanden. Jetzt müssen wir FHEM noch mitteilen, welche Hardware wir angeschlossen haben. Über das Attribut ''hardware'' lässt sich zwischen den mitgelieferten Firmware Dateien wechseln.

Beispiel:
:<code>attr sduino hardware nano328</code>

Anschließend kann der ''flash'' Befehl abgesetzt werden:
:<code>set sduino flash </code>
Dadurch wird der Arduino mit der gewählten Firmware geflasht. Das Ergebnis wird im Webinterface direkt angezeigt.

Alternativ kann auch der Flash-Befehl mit einem Dateinamen aufgerufen werden. Diese Möglichkeit sollte jedoch nur verwendet werden, wenn die SIGNALduino Firmware selbst compiliert wurde und eine andere Hardware verwendet wird. Der Flash-Befehl wird wie folgt aufgerufen:
:<code>set sduino flash FHEM/firmware/SIGNALduino_mega2560.hex</code>
(je nachdem wo und unter welchem Namen die .hex Datei abgelegt wurde).

Wenn alle vorherigen Schritte erfolgreich waren und die Details des SIGNALduino angezeigt werden, steht der Status nicht mehr auf ''open'' sondern auf ''initialized''.

== Daten aus dem Logfile erklärt ==
Im Logfile ab [[Verbose]] 4 tauchen diverse Meldungen auf, deren Bedeutung kurz erläutert wird:

Unknown Code, so oder ähnlich bedeutet, dass der SIGNALduino Signaldaten empfangen und diese binär interpretiert hat. Diese Meldung soll uns nun aber mitteilen, dass es dann nicht weiter verarbeitet werden kann, da kein Modul existiert, welches diese Daten jetzt in ihre Bedeutung umwandeln kann.
:
<code>sduino: Unknown code u1FFFFF0, help me!</code>

MS - Nachricht mit Sync Puls: Es wurde eine Signal empfangen. P0-P6 sind die Signalpegel (Dauer und positiv/negativ). Hinter D= befindet sich die Abfolge der Signale. 15 Bedeutet es wurde ein Signalpegel (1) 395 Mikrosekundenhigh und Anschließend (5) 8916 Mikrosekunden low gemessen. CP=1 ist die Referenz auf den Takt des Signales. Getaktet wird in diesem Fall mit ~395 Mikrosekunden. SP=5 gibt die Referenz zum Syncpuls an. Welche Signalfolge nun eine binäre 1 bzw. 0 bedeutet, wird im SIGNALduino über die integrierte Protokoll Liste realisiert.
:
<code>MS;P0=-108;P1=395;P2=-1033;P3=-547;P4=-19932;P5=-8916;P6=1368;D=151313131312131313131313131313131312121212121313131313131312131212132;CP=1;SP=5;</code>

MC - Nachricht vom Typ Manchester: Manchester Kodierte Signale, können bereits sehr einfach im Arduino in eine Binärform umgewandelt werden. Es wird hier nach IEEE 802.3 umgewandelt. In Manchester Signalen gibt es lange und kurze Pulse. Deren Durchschnittswert wird mit LL (long low), LH (long high), SL (short low) und SH (short high) übermittelt. Zusätzlich, um das Protokoll schneller erkennen zu können, wird die Taktfrequenz mit übermittelt (C=429 Mikrosekunden). Die Daten befinden sich hinter D= und werden in HEX Form übergeben.
:
<code>MC;LL=-1066;LH=904;SL=-562;SH=385;D=332B4B4D54D5554B552CD2D554B2B5354A;C=429;</code>

MU - Message unsynced: Diese Art von Nachrichten, sind nicht nach Manchester codiert und haben auch keinen erkennbaren Sync / Clock Signalpegel am Start der Nachricht.
Bei diesen Nachrichtentypen ist es, im Vergleich zu den anderen, am wahrscheinlichsten, dass das übermittelte Signal unvollständig oder überhaupt kein Signal ist.
Wie bei MS sind P0-P6 die Signalpegel und in D= wird die Abfolge der Signalpegel referenziert. CP=2 gibt auch hier die Referenz zum Takt an, allerdings muss dieser nicht korrekt erkannt worden sein.
:
<code>MU;P0=1372;P1=-580;P2=362;P3=-1047;D=01212321212321212121212121212123212123212321232121212121212321;CP=2;</code>

== Mein Gerät wird in FHEM nicht erkannt ==
1. Prüfen, ob vom Sensor die Signaldaten (verbose >=4) erkannt werden. Sobald ihr die empfangenen Signaldaten im Logfile zuordnen könnt, geht es weiter mit:

2. Eröffnet ein Thema unter [https://github.com/RFD-FHEM/RFFHEM/issues github] nach folgendem Muster:
:''Thema : Protokoll für <Das verwendete Gerät>
:Inhalt: Eure Hardware z.B. Arduino Nano mit XYZ Empfänger, oder Arduino Nano direkt an Gerät x
Auszug aus dem Logfile, welches zum Gerät gehört.
:''Alles was ihr sonst noch über das Gerät und die übertragenen Daten wisst.

Alternativ könnt ihr auch im Forum posten. Um einzelne Erweiterungen besser im Überblick zu behalten, eignet sich das github jedoch besser.

== Es wird ein Protokoll erkannt, Autocreate legt aber kein device an ==
Im SIGNALduino sind >30 Protokolle implementiert. Jedoch gibt es nur wenige Module, welche diese Protokolle verarbeiten.
Teilweise ist das auch nicht zwingend Notwendig um seine Anforderungen zu erfüllen.

Insbesondere für Schalter bzw. Sensoren die nur zwei Zustände kennen geht es meist ohne Modul und automatisch angelegtem Gerät.

Nehmen wir an, wir haben einen Schalter. Dieser kann einen oder zwei Zustände senden
Im FHEM Log tauchen Meldungen ähnlich dieser auf

<code>
2015.11.15 15:52:23 4: SIGNALduino_unknown incomming msg: u85#FF8081
</code>

Wir können mit Hilfe des Modules DOIF auf diese Nachricht eine Aktion ausführen:

<code>
define mydoif DOIF ([sduino:&DMSG] =~ "u85#FF8081") (set Lamp on)
attr mydoif do always
</code>

Der Teil u85#FF8081 muss individuell angepasst werden.

== Wie kann ich etwas Senden ==
Der SIGNALduino kann etwas senden, indem ihm das SIGNAL so übermittelt wird, wie er es moduliert.
Genannt "raw senden".

Um in der FHEM Kommandozeile etwas zu senden muss der Befehl wie folgt eingegeben werden:

<code>
set sduino raw SR;;R=3;;P0=4742;;P1=-1554;;P2=286;;P3=-786;;P4=649;;P5=-420;;D=0123234545234545452323232323454523234523454523232345454523232323452345234523452345;;
</code>

R=3 bedeutet das Signal wird 3x gesendet.
Die Übertragung besteht aus den in D angegeben Pulsen, welche in P0-P5 definiert werden.
Die Daten kann man aus einer empfangenen MS oder MU Nachricht extrahieren.

Alternativ kann ab Version 3.2 auch eine vereinfachte Form eingegeben werden.
<code>
set sduino sendMsg P3#00111010#R4
</code>

Moduliert die Bitfolge 00111010 mittels Protokoll #3 und wiederholt die Nachricht 4x.

== Es erscheinen viele Logmeldungen für Geräte die ich nicht habe ==
Es erscheinen viele Meldungen dieser Art:

<pre>
Fingerprint for MU Protocol id xxxx -> yyy matches, trying to demodulate
sduino: Starting demodulation at Position 1
Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate
sduino: Starting demodulation at Position 1
Fingerprint for MU Protocol id 29 -> HT12e remote matches, trying to demodulate
</pre>

Viele dieser Logmeldungen können durch Setzen des ''verbose'' Levels auf den Wert ''3'' unterdrückt werden.

Dennoch kommt es gehäuft zu Logmeldungen und auch Events in ähnlicher Form:
:<code>SIGNALduino_unknown incomming msg: u85#FF8081</code>

Das Attribut ''whitelistIDs'' erlaubt es, anzugeben, welche Protokolle vom FHEM Modul berücksichtigt werden. Für Protokolle, die nicht berücksichtigt werden, gibt es weder Logeinträge noch Events. Diese werden im Programmablauf nicht berücksichtigt. Das spart zum einen Ressourcen und trägt auch zur Übersichtlichkeit bei. Die Angabe erfolgt durch Komma getrennt: z.B.:
:<code>1,2,5,10</code>

== Externe Links ==
* {{Link2Forum|Topic=38402|LinkText=Forenthread - Ankündigung}}
* {{Link2Forum|Topic=38831|LinkText=Forumsdiskussion zur Weiterentwicklung}}

[[Kategorie:Interfaces]]
[[Kategorie:Arduino]]

RFXtrx

2016-01-30T22:53:09Z

Wherzig:

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

== Übersicht ==
[[File:Rfxtrx433.png|500px|right]]

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 [http://www.rfxcom.com/Downloads RFXflash] aktualisiert werden kann. Die neueste Firmware ist unter [http://www.rfxcom.com/Downloads http://www.rfxcom.com/Downloads] zu finden.

Weitere Informationen zu den von diesem Transceiver verfügbaren Protokolle beim Hersteller unter [http://www.rfxcom.com 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 [http://forum.fhem.de/ 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 [http://www.rfxcom.com/oregon.htm 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 [[File:Thgr228n.png|92px|right|thumb|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
[[File:TX3TH.jpg|92px|right|thumb|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 [[File:Bthr918n.png|96px|right|thumb|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 [http://tfa-dostmann.de/index.php?id=57 TFA]
* TFA Windsender 433 MHz, Kat. Nr. 30.3149, 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

=== 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 ([http://www.domotica.famschenk.eu/DS10A_op_433Mhz.html Umbau auf 433 Mhz])
** Marmitek Türsensor DS90
* Bewegungssensoren:
** X10 Bewegungssensor Powerhouse MS10A ([http://www.domotica.famschenk.eu/MS10A-433.html Umbau auf 433 Mhz])[[File:Ms10a.png|70px|right|thumb|MS10A]]<div class="tright" style="clear:none">[[File:Ms90.png|82px|mini|ohne|MS90]]</div>
** 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 [[File:Kr21e.png|60px|right|thumb|KR21E]]<div class="tright" style="clear:none">[[File:Sh624.png|75px|mini|ohne|SH624]]</div>
** 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 [http://www.domoticaforum.eu/viewtopic.php?f=7&t=7276 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 ([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.

'''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 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:

<nowiki>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</nowiki>
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 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":
<nowiki>2012-12-30_21:40:42 TRX_PT2262 111101110111</nowiki>
* Drücken von "off":
<nowiki>2012-12-30_21:40:47 TRX_PT2262 111101110110</nowiki>
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:

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
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.

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
Beispiel:

<nowiki>define TRX_MYREMOTE1 TRX_LIGHT PT2262 11110111011 light 0:off,1:on</nowiki>
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):

<nowiki>set TRX_MYREMOTE1 1</nowiki>
<nowiki>set TRX_MYREMOTE1 on</nowiki>
<nowiki>set TRX_MYREMOTE1 off</nowiki>
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!
[[Kategorie:Interfaces]]
[[Kategorie:Temperatursensoren]]
[[Kategorie:Bewegungs- und Anwesenheitsmelder]]
[[Kategorie:Rauchmelder]]
[[Kategorie:Luftdrucksensor]]
[[Kategorie:Regensensor]]
[[Kategorie:Wetterstationen]]
[[Kategorie:Dimmer]]
[[Kategorie:Feuchtesensoren]]
[[Kategorie:Other_Components]]
[[Kategorie:Waagen]]
[[Kategorie:UV-Sensoren]]
[[Kategorie:Energiesensoren]]

RFXtrx

2016-01-30T22:50:40Z

Wherzig:

RFXtrx

2016-01-30T22:48:34Z

Wherzig:

RFXtrx

2016-01-30T22:47:06Z

Wherzig:

RFXtrx

2016-01-30T22:46:17Z

Wherzig:

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

== Übersicht ==
[[File:Rfxtrx433.png|500px|right]]

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 [http://www.rfxcom.com/Downloads RFXflash] aktualisiert werden kann. Die neueste Firmware ist unter [http://www.rfxcom.com/Downloads http://www.rfxcom.com/Downloads] zu finden.

Weitere Informationen zu den von diesem Transceiver verfügbaren Protokolle beim Hersteller unter [http://www.rfxcom.com 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 [http://forum.fhem.de/ 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 [http://www.rfxcom.com/oregon.htm 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 [[File:Thgr228n.png|92px|right|thumb|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
[[File:TX3TH.jpg|92px|right|thumb|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 [[File:Bthr918n.png|96px|right|thumb|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 [http://tfa-dostmann.de/index.php?id=57 TFA]
* TFA Windsender 433 MHz, Kat. Nr. 30.3149, 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

=== 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 ([http://www.domotica.famschenk.eu/DS10A_op_433Mhz.html Umbau auf 433 Mhz])
** Marmitek Türsensor DS90
* Bewegungssensoren:
** X10 Bewegungssensor Powerhouse MS10A ([http://www.domotica.famschenk.eu/MS10A-433.html Umbau auf 433 Mhz])[[File:Ms10a.png|70px|right|thumb|MS10A]]<div class="tright" style="clear:none">[[File:Ms90.png|82px|mini|ohne|MS90]]</div>
** 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 [[File:Kr21e.png|60px|right|thumb|KR21E]]<div class="tright" style="clear:none">[[File:Sh624.png|75px|mini|ohne|SH624]]</div>
** 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 [http://www.domoticaforum.eu/viewtopic.php?f=7&t=7276 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 ([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.

'''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 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:

<nowiki>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</nowiki>
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 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":
<nowiki>2012-12-30_21:40:42 TRX_PT2262 111101110111</nowiki>
* Drücken von "off":
<nowiki>2012-12-30_21:40:47 TRX_PT2262 111101110110</nowiki>
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:

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
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.

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
Beispiel:

<nowiki>define TRX_MYREMOTE1 TRX_LIGHT PT2262 11110111011 light 0:off,1:on</nowiki>
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):

<nowiki>set TRX_MYREMOTE1 1</nowiki>
<nowiki>set TRX_MYREMOTE1 on</nowiki>
<nowiki>set TRX_MYREMOTE1 off</nowiki>
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!

[[Kategorie:Hardware]]
[[Kategorie:Interfaces]]
[[Kategorie:Temperatursensoren]]
[[Kategorie:Bewegungs- und Anwesenheitsmelder]]
[[Kategorie:Rauchmelder]]
[[Kategorie:Luftdrucksensor]]
[[Kategorie:Regensensor]]
[[Kategorie:Wetterstationen]]
[[Kategorie:Dimmer]]
[[Kategorie:Feuchtesensoren]]

RFXtrx

2016-01-30T22:45:36Z

Wherzig:

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

== Übersicht ==
[[File:Rfxtrx433.png|500px|right]]

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 [http://www.rfxcom.com/Downloads RFXflash] aktualisiert werden kann. Die neueste Firmware ist unter [http://www.rfxcom.com/Downloads http://www.rfxcom.com/Downloads] zu finden.

Weitere Informationen zu den von diesem Transceiver verfügbaren Protokolle beim Hersteller unter [http://www.rfxcom.com 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 [http://forum.fhem.de/ 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 [http://www.rfxcom.com/oregon.htm 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 [[File:Thgr228n.png|92px|right|thumb|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
[[File:TX3TH.jpg|92px|right|thumb|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 [[File:Bthr918n.png|96px|right|thumb|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 [http://tfa-dostmann.de/index.php?id=57 TFA]
* TFA Windsender 433 MHz, Kat. Nr. 30.3149, 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

=== 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 ([http://www.domotica.famschenk.eu/DS10A_op_433Mhz.html Umbau auf 433 Mhz])
** Marmitek Türsensor DS90
* Bewegungssensoren:
** X10 Bewegungssensor Powerhouse MS10A ([http://www.domotica.famschenk.eu/MS10A-433.html Umbau auf 433 Mhz])[[File:Ms10a.png|70px|right|thumb|MS10A]]<div class="tright" style="clear:none">[[File:Ms90.png|82px|mini|ohne|MS90]]</div>
** 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 [[File:Kr21e.png|60px|right|thumb|KR21E]]<div class="tright" style="clear:none">[[File:Sh624.png|75px|mini|ohne|SH624]]</div>
** 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 [http://www.domoticaforum.eu/viewtopic.php?f=7&t=7276 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 ([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.

'''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 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:

<nowiki>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</nowiki>
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 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":
<nowiki>2012-12-30_21:40:42 TRX_PT2262 111101110111</nowiki>
* Drücken von "off":
<nowiki>2012-12-30_21:40:47 TRX_PT2262 111101110110</nowiki>
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:

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
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.

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
Beispiel:

<nowiki>define TRX_MYREMOTE1 TRX_LIGHT PT2262 11110111011 light 0:off,1:on</nowiki>
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):

<nowiki>set TRX_MYREMOTE1 1</nowiki>
<nowiki>set TRX_MYREMOTE1 on</nowiki>
<nowiki>set TRX_MYREMOTE1 off</nowiki>
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!
[[Kategorie:Hardware]]
[[Kategorie:Interfaces]]
[[Kategorie:Temperatursensoren]]
[[Kategorie:Bewegungs- und Anwesenheitsmelder]]
[[Kategorie:Rauchmelder]]
[[Kategorie:Luftdrucksensor]]
[[Kategorie:Regensensor]]
[[Kategorie:Wetterstationen]]
[[Kategorie:Dimmer]]
[[Kategorie:Feuchtesensoren]]

RFXtrx

2016-01-30T22:44:22Z

Wherzig:

RFXtrx

2016-01-30T22:43:40Z

Wherzig:

RFXtrx

2016-01-30T22:42:55Z

Wherzig:

RFXtrx

2016-01-30T22:42:14Z

Wherzig:

RFXtrx

2016-01-30T22:41:37Z

Wherzig:

RFXtrx

2016-01-30T22:40:22Z

Wherzig:

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

== Übersicht ==
[[File:Rfxtrx433.png|500px|right]]

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 [http://www.rfxcom.com/Downloads RFXflash] aktualisiert werden kann. Die neueste Firmware ist unter [http://www.rfxcom.com/Downloads http://www.rfxcom.com/Downloads] zu finden.

Weitere Informationen zu den von diesem Transceiver verfügbaren Protokolle beim Hersteller unter [http://www.rfxcom.com 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 [http://forum.fhem.de/ 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 [http://www.rfxcom.com/oregon.htm 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 [[File:Thgr228n.png|92px|right|thumb|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
[[File:TX3TH.jpg|92px|right|thumb|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 [[File:Bthr918n.png|96px|right|thumb|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 [http://tfa-dostmann.de/index.php?id=57 TFA]
* TFA Windsender 433 MHz, Kat. Nr. 30.3149, 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

=== 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.

[[Kategorie:Rauchmelder]]

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

* Türsensoren:
** X10 Türsensor Powerhouse DS10A ([http://www.domotica.famschenk.eu/DS10A_op_433Mhz.html Umbau auf 433 Mhz])
** Marmitek Türsensor DS90
* Bewegungssensoren:
** X10 Bewegungssensor Powerhouse MS10A ([http://www.domotica.famschenk.eu/MS10A-433.html Umbau auf 433 Mhz])[[File:Ms10a.png|70px|right|thumb|MS10A]]<div class="tright" style="clear:none">[[File:Ms90.png|82px|mini|ohne|MS90]]</div>
** 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 [[File:Kr21e.png|60px|right|thumb|KR21E]]<div class="tright" style="clear:none">[[File:Sh624.png|75px|mini|ohne|SH624]]</div>
** 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 [http://www.domoticaforum.eu/viewtopic.php?f=7&t=7276 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 ([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.

'''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 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:

<nowiki>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</nowiki>
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 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":
<nowiki>2012-12-30_21:40:42 TRX_PT2262 111101110111</nowiki>
* Drücken von "off":
<nowiki>2012-12-30_21:40:47 TRX_PT2262 111101110110</nowiki>
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:

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
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.

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
Beispiel:

<nowiki>define TRX_MYREMOTE1 TRX_LIGHT PT2262 11110111011 light 0:off,1:on</nowiki>
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):

<nowiki>set TRX_MYREMOTE1 1</nowiki>
<nowiki>set TRX_MYREMOTE1 on</nowiki>
<nowiki>set TRX_MYREMOTE1 off</nowiki>
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!
[[Kategorie:Interfaces]]
[[Kategorie:Temperatursensoren]]
[[Kategorie:Bewegungs- und Anwesenheitsmelder]]

RFXtrx

2016-01-30T22:38:52Z

Wherzig:

RFXtrx

2016-01-30T22:37:42Z

Wherzig:

RFXtrx

2013-12-13T19:47:08Z

Wherzig: /* PT2262 empfangen und senden mit TRX_LIGHT.pm */

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

== Übersicht ==
[[File:Rfxtrx433.png|500px|right]]

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 [http://www.rfxcom.com/Downloads RFXflash] aktualisiert werden kann. Die neueste Firmware ist unter [http://www.rfxcom.com/Downloads http://www.rfxcom.com/Downloads] zu finden.

Weitere Informationen zu den von diesem Transceiver verfügbaren Protokolle beim Hersteller unter [http://www.rfxcom.com 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 [http://forum.fhem.de/ 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 [http://www.rfxcom.com/oregon.htm 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 [[File:Thgr228n.png|92px|right|thumb|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
[[File:TX3TH.jpg|92px|right|thumb|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 [[File:Bthr918n.png|96px|right|thumb|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 [http://tfa-dostmann.de/index.php?id=57 TFA]
* TFA Windsender 433 MHz, Kat. Nr. 30.3149, 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

=== 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 ([http://www.domotica.famschenk.eu/DS10A_op_433Mhz.html Umbau auf 433 Mhz])
** Marmitek Türsensor DS90
* Bewegungssensoren:
** X10 Bewegungssensor Powerhouse MS10A ([http://www.domotica.famschenk.eu/MS10A-433.html Umbau auf 433 Mhz])[[File:Ms10a.png|70px|right|thumb|MS10A]]<div class="tright" style="clear:none">[[File:Ms90.png|82px|mini|ohne|MS90]]</div>
** 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 [[File:Kr21e.png|60px|right|thumb|KR21E]]<div class="tright" style="clear:none">[[File:Sh624.png|75px|mini|ohne|SH624]]</div>
** 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.

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 [http://www.domoticaforum.eu/viewtopic.php?f=7&t=7276 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 ([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.

'''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 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:

<nowiki>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</nowiki>
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 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":
<nowiki>2012-12-30_21:40:42 TRX_PT2262 111101110111</nowiki>
* Drücken von "off":
<nowiki>2012-12-30_21:40:47 TRX_PT2262 111101110110</nowiki>
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:

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
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.

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
Beispiel:

<nowiki>define TRX_MYREMOTE1 TRX_LIGHT PT2262 11110111011 light 0:off,1:on</nowiki>
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):

<nowiki>set TRX_MYREMOTE1 1</nowiki>
<nowiki>set TRX_MYREMOTE1 on</nowiki>
<nowiki>set TRX_MYREMOTE1 off</nowiki>
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!
[[Kategorie:Interface]]

RFXtrx

2013-12-01T17:41:25Z

Wherzig: /* Fragen und Antworten (FAQ) */

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

== Übersicht ==
[[File:Rfxtrx433.png|500px|right]]

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 [http://www.rfxcom.com/Downloads RFXflash] aktualisiert werden kann. Die neueste Firmware ist unter [http://www.rfxcom.com/Downloads http://www.rfxcom.com/Downloads] zu finden.

Weitere Informationen zu den von diesem Transceiver verfügbaren Protokolle beim Hersteller unter [http://www.rfxcom.com 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 [http://forum.fhem.de/ 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 [http://www.rfxcom.com/oregon.htm 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 [[File:Thgr228n.png|92px|right|thumb|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
[[File:TX3TH.jpg|92px|right|thumb|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 [[File:Bthr918n.png|96px|right|thumb|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 [http://tfa-dostmann.de/index.php?id=57 TFA]
* TFA Windsender 433 MHz, Kat. Nr. 30.3149, 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

=== 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 ([http://www.domotica.famschenk.eu/DS10A_op_433Mhz.html Umbau auf 433 Mhz])
** Marmitek Türsensor DS90
* Bewegungssensoren:
** X10 Bewegungssensor Powerhouse MS10A ([http://www.domotica.famschenk.eu/MS10A-433.html Umbau auf 433 Mhz])[[File:Ms10a.png|70px|right|thumb|MS10A]]<div class="tright" style="clear:none">[[File:Ms90.png|82px|mini|ohne|MS90]]</div>
** 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 [[File:Kr21e.png|60px|right|thumb|KR21E]]<div class="tright" style="clear:none">[[File:Sh624.png|75px|mini|ohne|SH624]]</div>
** 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.

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 [http://www.domoticaforum.eu/viewtopic.php?f=7&t=7276 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 ([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 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:

<nowiki>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</nowiki>
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 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":
<nowiki>2012-12-30_21:40:42 TRX_PT2262 111101110111</nowiki>
* Drücken von "off":
<nowiki>2012-12-30_21:40:47 TRX_PT2262 111101110110</nowiki>
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:

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
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.

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
Beispiel:

<nowiki>define TRX_MYREMOTE1 TRX_LIGHT PT2262 11110111011 light 0:off,1:on</nowiki>
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):

<nowiki>set TRX_MYREMOTE1 1</nowiki>
<nowiki>set TRX_MYREMOTE1 on</nowiki>
<nowiki>set TRX_MYREMOTE1 off</nowiki>
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!
[[Kategorie:Interface]]

RFXtrx

2013-12-01T17:41:09Z

Wherzig: /* Fragen und Antworten (FAQ) */

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

== Übersicht ==
[[File:Rfxtrx433.png|500px|right]]

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 [http://www.rfxcom.com/Downloads RFXflash] aktualisiert werden kann. Die neueste Firmware ist unter [http://www.rfxcom.com/Downloads http://www.rfxcom.com/Downloads] zu finden.

Weitere Informationen zu den von diesem Transceiver verfügbaren Protokolle beim Hersteller unter [http://www.rfxcom.com 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 [http://forum.fhem.de/ 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 [http://www.rfxcom.com/oregon.htm 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 [[File:Thgr228n.png|92px|right|thumb|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
[[File:TX3TH.jpg|92px|right|thumb|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 [[File:Bthr918n.png|96px|right|thumb|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 [http://tfa-dostmann.de/index.php?id=57 TFA]
* TFA Windsender 433 MHz, Kat. Nr. 30.3149, 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

=== 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 ([http://www.domotica.famschenk.eu/DS10A_op_433Mhz.html Umbau auf 433 Mhz])
** Marmitek Türsensor DS90
* Bewegungssensoren:
** X10 Bewegungssensor Powerhouse MS10A ([http://www.domotica.famschenk.eu/MS10A-433.html Umbau auf 433 Mhz])[[File:Ms10a.png|70px|right|thumb|MS10A]]<div class="tright" style="clear:none">[[File:Ms90.png|82px|mini|ohne|MS90]]</div>
** 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 [[File:Kr21e.png|60px|right|thumb|KR21E]]<div class="tright" style="clear:none">[[File:Sh624.png|75px|mini|ohne|SH624]]</div>
** 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.

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 [http://www.domoticaforum.eu/viewtopic.php?f=7&t=7276 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 ([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 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:

<nowiki>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</nowiki>
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 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":
<nowiki>2012-12-30_21:40:42 TRX_PT2262 111101110111</nowiki>
* Drücken von "off":
<nowiki>2012-12-30_21:40:47 TRX_PT2262 111101110110</nowiki>
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:

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
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.

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
Beispiel:

<nowiki>define TRX_MYREMOTE1 TRX_LIGHT PT2262 11110111011 light 0:off,1:on</nowiki>
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):

<nowiki>set TRX_MYREMOTE1 1</nowiki>
<nowiki>set TRX_MYREMOTE1 on</nowiki>
<nowiki>set TRX_MYREMOTE1 off</nowiki>
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? ===a

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!
[[Kategorie:Interface]]

RFXtrx

2013-12-01T17:40:08Z

Wherzig: /* Warum werden die Tasten meiner Fernbedienung nicht alle erkannt? */

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

== Übersicht ==
[[File:Rfxtrx433.png|500px|right]]

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 [http://www.rfxcom.com/Downloads RFXflash] aktualisiert werden kann. Die neueste Firmware ist unter [http://www.rfxcom.com/Downloads http://www.rfxcom.com/Downloads] zu finden.

Weitere Informationen zu den von diesem Transceiver verfügbaren Protokolle beim Hersteller unter [http://www.rfxcom.com 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 [http://forum.fhem.de/ 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 [http://www.rfxcom.com/oregon.htm 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 [[File:Thgr228n.png|92px|right|thumb|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
[[File:TX3TH.jpg|92px|right|thumb|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 [[File:Bthr918n.png|96px|right|thumb|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 [http://tfa-dostmann.de/index.php?id=57 TFA]
* TFA Windsender 433 MHz, Kat. Nr. 30.3149, 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

=== 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 ([http://www.domotica.famschenk.eu/DS10A_op_433Mhz.html Umbau auf 433 Mhz])
** Marmitek Türsensor DS90
* Bewegungssensoren:
** X10 Bewegungssensor Powerhouse MS10A ([http://www.domotica.famschenk.eu/MS10A-433.html Umbau auf 433 Mhz])[[File:Ms10a.png|70px|right|thumb|MS10A]]<div class="tright" style="clear:none">[[File:Ms90.png|82px|mini|ohne|MS90]]</div>
** 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 [[File:Kr21e.png|60px|right|thumb|KR21E]]<div class="tright" style="clear:none">[[File:Sh624.png|75px|mini|ohne|SH624]]</div>
** 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.

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 [http://www.domoticaforum.eu/viewtopic.php?f=7&t=7276 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 ([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 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:

<nowiki>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</nowiki>
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 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":
<nowiki>2012-12-30_21:40:42 TRX_PT2262 111101110111</nowiki>
* Drücken von "off":
<nowiki>2012-12-30_21:40:47 TRX_PT2262 111101110110</nowiki>
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:

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
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.

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
Beispiel:

<nowiki>define TRX_MYREMOTE1 TRX_LIGHT PT2262 11110111011 light 0:off,1:on</nowiki>
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):

<nowiki>set TRX_MYREMOTE1 1</nowiki>
<nowiki>set TRX_MYREMOTE1 on</nowiki>
<nowiki>set TRX_MYREMOTE1 off</nowiki>
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? ===a

=== 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!
[[Kategorie:Interface]]

RFXtrx

2013-12-01T17:39:55Z

Wherzig: /* Fragen und Antworten (FAQ) */

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

== Übersicht ==
[[File:Rfxtrx433.png|500px|right]]

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 [http://www.rfxcom.com/Downloads RFXflash] aktualisiert werden kann. Die neueste Firmware ist unter [http://www.rfxcom.com/Downloads http://www.rfxcom.com/Downloads] zu finden.

Weitere Informationen zu den von diesem Transceiver verfügbaren Protokolle beim Hersteller unter [http://www.rfxcom.com 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 [http://forum.fhem.de/ 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 [http://www.rfxcom.com/oregon.htm 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 [[File:Thgr228n.png|92px|right|thumb|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
[[File:TX3TH.jpg|92px|right|thumb|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 [[File:Bthr918n.png|96px|right|thumb|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 [http://tfa-dostmann.de/index.php?id=57 TFA]
* TFA Windsender 433 MHz, Kat. Nr. 30.3149, 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

=== 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 ([http://www.domotica.famschenk.eu/DS10A_op_433Mhz.html Umbau auf 433 Mhz])
** Marmitek Türsensor DS90
* Bewegungssensoren:
** X10 Bewegungssensor Powerhouse MS10A ([http://www.domotica.famschenk.eu/MS10A-433.html Umbau auf 433 Mhz])[[File:Ms10a.png|70px|right|thumb|MS10A]]<div class="tright" style="clear:none">[[File:Ms90.png|82px|mini|ohne|MS90]]</div>
** 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 [[File:Kr21e.png|60px|right|thumb|KR21E]]<div class="tright" style="clear:none">[[File:Sh624.png|75px|mini|ohne|SH624]]</div>
** 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.

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 [http://www.domoticaforum.eu/viewtopic.php?f=7&t=7276 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 ([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 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:

<nowiki>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</nowiki>
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 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":
<nowiki>2012-12-30_21:40:42 TRX_PT2262 111101110111</nowiki>
* Drücken von "off":
<nowiki>2012-12-30_21:40:47 TRX_PT2262 111101110110</nowiki>
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:

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
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.

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
Beispiel:

<nowiki>define TRX_MYREMOTE1 TRX_LIGHT PT2262 11110111011 light 0:off,1:on</nowiki>
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):

<nowiki>set TRX_MYREMOTE1 1</nowiki>
<nowiki>set TRX_MYREMOTE1 on</nowiki>
<nowiki>set TRX_MYREMOTE1 off</nowiki>
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? ===a

=== 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!
[[Kategorie:Interface]]

RFXtrx

2013-11-08T18:33:11Z

Wherzig: /* FHEM-Modul: TRX_LIGHT.pm */

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

== Übersicht ==
[[File:Rfxtrx433.png|500px|right]]

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 [http://www.rfxcom.com/Downloads RFXflash] aktualisiert werden kann. Die neueste Firmware ist unter [http://www.rfxcom.com/Downloads http://www.rfxcom.com/Downloads] zu finden.

Weitere Informationen zu den von diesem Transceiver verfügbaren Protokolle beim Hersteller unter [http://www.rfxcom.com 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 [http://forum.fhem.de/ 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 [http://www.rfxcom.com/oregon.htm 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 [[File:Thgr228n.png|92px|right|thumb|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
[[File:TX3TH.jpg|92px|right|thumb|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 [[File:Bthr918n.png|96px|right|thumb|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 [http://tfa-dostmann.de/index.php?id=57 TFA]
* TFA Windsender 433 MHz, Kat. Nr. 30.3149, 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

=== 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 ([http://www.domotica.famschenk.eu/DS10A_op_433Mhz.html Umbau auf 433 Mhz])
** Marmitek Türsensor DS90
* Bewegungssensoren:
** X10 Bewegungssensor Powerhouse MS10A ([http://www.domotica.famschenk.eu/MS10A-433.html Umbau auf 433 Mhz])[[File:Ms10a.png|70px|right|thumb|MS10A]]<div class="tright" style="clear:none">[[File:Ms90.png|82px|mini|ohne|MS90]]</div>
** 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 [[File:Kr21e.png|60px|right|thumb|KR21E]]<div class="tright" style="clear:none">[[File:Sh624.png|75px|mini|ohne|SH624]]</div>
** 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.

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 [http://www.domoticaforum.eu/viewtopic.php?f=7&t=7276 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 ([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 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:

<nowiki>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</nowiki>
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 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":
<nowiki>2012-12-30_21:40:42 TRX_PT2262 111101110111</nowiki>
* Drücken von "off":
<nowiki>2012-12-30_21:40:47 TRX_PT2262 111101110110</nowiki>
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:

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
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.

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
Beispiel:

<nowiki>define TRX_MYREMOTE1 TRX_LIGHT PT2262 11110111011 light 0:off,1:on</nowiki>
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):

<nowiki>set TRX_MYREMOTE1 1</nowiki>
<nowiki>set TRX_MYREMOTE1 on</nowiki>
<nowiki>set TRX_MYREMOTE1 off</nowiki>
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.

[[Kategorie:Interface]]

RFXtrx

2013-11-01T09:26:01Z

Wherzig: /* Übersicht */

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

== Übersicht ==
[[File:Rfxtrx433.png|500px|right]]

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 [http://www.rfxcom.com/Downloads RFXflash] aktualisiert werden kann. Die neueste Firmware ist unter [http://www.rfxcom.com/Downloads http://www.rfxcom.com/Downloads] zu finden.

Weitere Informationen zu den von diesem Transceiver verfügbaren Protokolle beim Hersteller unter [http://www.rfxcom.com 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 [http://forum.fhem.de/ 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 [http://www.rfxcom.com/oregon.htm 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 [[File:Thgr228n.png|92px|right|thumb|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
[[File:TX3TH.jpg|92px|right|thumb|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 [[File:Bthr918n.png|96px|right|thumb|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 [http://tfa-dostmann.de/index.php?id=57 TFA]
* TFA Windsender 433 MHz, Kat. Nr. 30.3149, 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

=== 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 ([http://www.domotica.famschenk.eu/DS10A_op_433Mhz.html Umbau auf 433 Mhz])
** Marmitek Türsensor DS90
* Bewegungssensoren:
** X10 Bewegungssensor Powerhouse MS10A ([http://www.domotica.famschenk.eu/MS10A-433.html Umbau auf 433 Mhz])[[File:Ms10a.png|70px|right|thumb|MS10A]]<div class="tright" style="clear:none">[[File:Ms90.png|82px|mini|ohne|MS90]]</div>
** 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 [[File:Kr21e.png|60px|right|thumb|KR21E]]<div class="tright" style="clear:none">[[File:Sh624.png|75px|mini|ohne|SH624]]</div>
** 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 [http://www.domoticaforum.eu/viewtopic.php?f=7&t=7276 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 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:

<nowiki>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</nowiki>
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 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":
<nowiki>2012-12-30_21:40:42 TRX_PT2262 111101110111</nowiki>
* Drücken von "off":
<nowiki>2012-12-30_21:40:47 TRX_PT2262 111101110110</nowiki>
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:

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
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.

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
Beispiel:

<nowiki>define TRX_MYREMOTE1 TRX_LIGHT PT2262 11110111011 light 0:off,1:on</nowiki>
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):

<nowiki>set TRX_MYREMOTE1 1</nowiki>
<nowiki>set TRX_MYREMOTE1 on</nowiki>
<nowiki>set TRX_MYREMOTE1 off</nowiki>
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.

[[Kategorie:Interface]]

RFXtrx

2013-11-01T09:24:05Z

Wherzig:

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

== Übersicht ==
[[File:Rfxtrx433.png|500px|right]]

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, muß 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 [http://www.rfxcom.com/Downloads RFXflash] aktualisiert werden kann. Die neueste Firmware ist unter [http://www.rfxcom.com/Downloads http://www.rfxcom.com/Downloads] zu finden.

Weitere Informationen zu den von diesem Transceiver verfügbaren Protokolle beim Hersteller unter [http://www.rfxcom.com 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 [http://forum.fhem.de/ 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 [http://www.rfxcom.com/oregon.htm 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 [[File:Thgr228n.png|92px|right|thumb|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
[[File:TX3TH.jpg|92px|right|thumb|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 [[File:Bthr918n.png|96px|right|thumb|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 [http://tfa-dostmann.de/index.php?id=57 TFA]
* TFA Windsender 433 MHz, Kat. Nr. 30.3149, 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

=== 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 ([http://www.domotica.famschenk.eu/DS10A_op_433Mhz.html Umbau auf 433 Mhz])
** Marmitek Türsensor DS90
* Bewegungssensoren:
** X10 Bewegungssensor Powerhouse MS10A ([http://www.domotica.famschenk.eu/MS10A-433.html Umbau auf 433 Mhz])[[File:Ms10a.png|70px|right|thumb|MS10A]]<div class="tright" style="clear:none">[[File:Ms90.png|82px|mini|ohne|MS90]]</div>
** 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 [[File:Kr21e.png|60px|right|thumb|KR21E]]<div class="tright" style="clear:none">[[File:Sh624.png|75px|mini|ohne|SH624]]</div>
** 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 [http://www.domoticaforum.eu/viewtopic.php?f=7&t=7276 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 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:

<nowiki>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</nowiki>
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 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":
<nowiki>2012-12-30_21:40:42 TRX_PT2262 111101110111</nowiki>
* Drücken von "off":
<nowiki>2012-12-30_21:40:47 TRX_PT2262 111101110110</nowiki>
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:

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
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.

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
Beispiel:

<nowiki>define TRX_MYREMOTE1 TRX_LIGHT PT2262 11110111011 light 0:off,1:on</nowiki>
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):

<nowiki>set TRX_MYREMOTE1 1</nowiki>
<nowiki>set TRX_MYREMOTE1 on</nowiki>
<nowiki>set TRX_MYREMOTE1 off</nowiki>
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.

[[Kategorie:Interface]]

RFXtrx

2013-11-01T09:18:15Z

Wherzig: /* Übersicht */

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

== Übersicht ==
[[File:Rfxtrx433.png|500px|right]]

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, muß 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 [http://www.rfxcom.com/Downloads RFXflash] aktualisiert werden kann. Die neueste Firmware ist unter [http://www.rfxcom.com/Downloads http://www.rfxcom.com/Downloads] zu finden.

Weitere Informationen zu den von diesem Transceiver verfügbaren Protokolle beim Hersteller unter [http://www.rfxcom.com 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 [http://forum.fhem.de/ 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 [http://www.rfxcom.com/oregon.htm 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 [[File:Thgr228n.png|92px|right|thumb|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
[[File:TX3TH.jpg|92px|right|thumb|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 [[File:Bthr918n.png|96px|right|thumb|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 [http://tfa-dostmann.de/index.php?id=57 TFA]
* TFA Windsender 433 MHz, Kat. Nr. 30.3149, 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

=== 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 ([http://www.domotica.famschenk.eu/DS10A_op_433Mhz.html Umbau auf 433 Mhz])
** Marmitek Türsensor DS90
* Bewegungssensoren:
** X10 Bewegungssensor Powerhouse MS10A ([http://www.domotica.famschenk.eu/MS10A-433.html Umbau auf 433 Mhz])[[File:Ms10a.png|70px|right|thumb|MS10A]]<div class="tright" style="clear:none">[[File:Ms90.png|82px|mini|ohne|MS90]]</div>
** 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 [[File:Kr21e.png|60px|right|thumb|KR21E]]<div class="tright" style="clear:none">[[File:Sh624.png|75px|mini|ohne|SH624]]</div>
** 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 [http://www.domoticaforum.eu/viewtopic.php?f=7&t=7276 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 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:

<nowiki>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</nowiki>
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 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":
<nowiki>2012-12-30_21:40:42 TRX_PT2262 111101110111</nowiki>
* Drücken von "off":
<nowiki>2012-12-30_21:40:47 TRX_PT2262 111101110110</nowiki>
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:

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
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.

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
Beispiel:

<nowiki>define TRX_MYREMOTE1 TRX_LIGHT PT2262 11110111011 light 0:off,1:on</nowiki>
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):

<nowiki>set TRX_MYREMOTE1 1</nowiki>
<nowiki>set TRX_MYREMOTE1 on</nowiki>
<nowiki>set TRX_MYREMOTE1 off</nowiki>
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.

[[Kategorie:Interface]]

RFXtrx

2013-11-01T09:14:30Z

Wherzig: /* Übersicht */

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

== Übersicht ==
[[File:Rfxtrx433.png|500px|right]]

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, muß das Betriebssystem einen entsprechenden Treiber für diesen Chip haben. Genutzt wird RFXt433 von Anwendern unter 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 [http://www.rfxcom.com/Downloads RFXflash] aktualisiert werden kann. Die neueste Firmware ist unter [http://www.rfxcom.com/Downloads http://www.rfxcom.com/Downloads] zu finden.

Weitere Informationen zu den von diesem Transceiver verfügbaren Protokolle beim Hersteller unter [http://www.rfxcom.com 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 [http://forum.fhem.de/ 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 [http://www.rfxcom.com/oregon.htm 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 [[File:Thgr228n.png|92px|right|thumb|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
[[File:TX3TH.jpg|92px|right|thumb|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 [[File:Bthr918n.png|96px|right|thumb|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 [http://tfa-dostmann.de/index.php?id=57 TFA]
* TFA Windsender 433 MHz, Kat. Nr. 30.3149, 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

=== 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 ([http://www.domotica.famschenk.eu/DS10A_op_433Mhz.html Umbau auf 433 Mhz])
** Marmitek Türsensor DS90
* Bewegungssensoren:
** X10 Bewegungssensor Powerhouse MS10A ([http://www.domotica.famschenk.eu/MS10A-433.html Umbau auf 433 Mhz])[[File:Ms10a.png|70px|right|thumb|MS10A]]<div class="tright" style="clear:none">[[File:Ms90.png|82px|mini|ohne|MS90]]</div>
** 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 [[File:Kr21e.png|60px|right|thumb|KR21E]]<div class="tright" style="clear:none">[[File:Sh624.png|75px|mini|ohne|SH624]]</div>
** 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 [http://www.domoticaforum.eu/viewtopic.php?f=7&t=7276 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 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:

<nowiki>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</nowiki>
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 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":
<nowiki>2012-12-30_21:40:42 TRX_PT2262 111101110111</nowiki>
* Drücken von "off":
<nowiki>2012-12-30_21:40:47 TRX_PT2262 111101110110</nowiki>
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:

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
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.

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
Beispiel:

<nowiki>define TRX_MYREMOTE1 TRX_LIGHT PT2262 11110111011 light 0:off,1:on</nowiki>
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):

<nowiki>set TRX_MYREMOTE1 1</nowiki>
<nowiki>set TRX_MYREMOTE1 on</nowiki>
<nowiki>set TRX_MYREMOTE1 off</nowiki>
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.

[[Kategorie:Interface]]

RFXtrx

2013-11-01T09:14:16Z

Wherzig: /* Übersicht */

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

== Übersicht ==
[[File:Rfxtrx433.png|500px|right]]

RFXtrx433 ist ein Transceiver ([[Interface]] / 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, muß das Betriebssystem einen entsprechenden Treiber für diesen Chip haben. Genutzt wird RFXt433 von Anwendern unter 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 [http://www.rfxcom.com/Downloads RFXflash] aktualisiert werden kann. Die neueste Firmware ist unter [http://www.rfxcom.com/Downloads http://www.rfxcom.com/Downloads] zu finden.

Weitere Informationen zu den von diesem Transceiver verfügbaren Protokolle beim Hersteller unter [http://www.rfxcom.com 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 [http://forum.fhem.de/ 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 [http://www.rfxcom.com/oregon.htm 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 [[File:Thgr228n.png|92px|right|thumb|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
[[File:TX3TH.jpg|92px|right|thumb|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 [[File:Bthr918n.png|96px|right|thumb|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 [http://tfa-dostmann.de/index.php?id=57 TFA]
* TFA Windsender 433 MHz, Kat. Nr. 30.3149, 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

=== 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 ([http://www.domotica.famschenk.eu/DS10A_op_433Mhz.html Umbau auf 433 Mhz])
** Marmitek Türsensor DS90
* Bewegungssensoren:
** X10 Bewegungssensor Powerhouse MS10A ([http://www.domotica.famschenk.eu/MS10A-433.html Umbau auf 433 Mhz])[[File:Ms10a.png|70px|right|thumb|MS10A]]<div class="tright" style="clear:none">[[File:Ms90.png|82px|mini|ohne|MS90]]</div>
** 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 [[File:Kr21e.png|60px|right|thumb|KR21E]]<div class="tright" style="clear:none">[[File:Sh624.png|75px|mini|ohne|SH624]]</div>
** 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 [http://www.domoticaforum.eu/viewtopic.php?f=7&t=7276 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 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:

<nowiki>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</nowiki>
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 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":
<nowiki>2012-12-30_21:40:42 TRX_PT2262 111101110111</nowiki>
* Drücken von "off":
<nowiki>2012-12-30_21:40:47 TRX_PT2262 111101110110</nowiki>
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:

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
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.

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
Beispiel:

<nowiki>define TRX_MYREMOTE1 TRX_LIGHT PT2262 11110111011 light 0:off,1:on</nowiki>
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):

<nowiki>set TRX_MYREMOTE1 1</nowiki>
<nowiki>set TRX_MYREMOTE1 on</nowiki>
<nowiki>set TRX_MYREMOTE1 off</nowiki>
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.

[[Kategorie:Interface]]

RFXtrx

2013-10-07T12:53:44Z

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

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

== Übersicht ==
[[File:Rfxtrx433.png|500px|right]]

RFXtrx433 ist ein Transceiver ([[Interface]] / 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 [http://www.rfxcom.com/Downloads RFXflash] aktualisiert werden kann. Die neueste Firmware ist unter [http://www.rfxcom.com/Downloads http://www.rfxcom.com/Downloads] zu finden.

Weitere Informationen zu den von diesem Transceiver verfügbaren Protokolle beim Hersteller unter [http://www.rfxcom.com 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 [http://forum.fhem.de/ 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 [http://www.rfxcom.com/oregon.htm 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 [[File:Thgr228n.png|92px|right|thumb|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
[[File:TX3TH.jpg|92px|right|thumb|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 [[File:Bthr918n.png|96px|right|thumb|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 [http://tfa-dostmann.de/index.php?id=57 TFA]
* TFA Windsender 433 MHz, Kat. Nr. 30.3149, 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

=== 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 ([http://www.domotica.famschenk.eu/DS10A_op_433Mhz.html Umbau auf 433 Mhz])
** Marmitek Türsensor DS90
* Bewegungssensoren:
** X10 Bewegungssensor Powerhouse MS10A ([http://www.domotica.famschenk.eu/MS10A-433.html Umbau auf 433 Mhz])[[File:Ms10a.png|70px|right|thumb|MS10A]]<div class="tright" style="clear:none">[[File:Ms90.png|82px|mini|ohne|MS90]]</div>
** 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 [[File:Kr21e.png|60px|right|thumb|KR21E]]<div class="tright" style="clear:none">[[File:Sh624.png|75px|mini|ohne|SH624]]</div>
** 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 [http://www.domoticaforum.eu/viewtopic.php?f=7&t=7276 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 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:

<nowiki>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</nowiki>
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 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":
<nowiki>2012-12-30_21:40:42 TRX_PT2262 111101110111</nowiki>
* Drücken von "off":
<nowiki>2012-12-30_21:40:47 TRX_PT2262 111101110110</nowiki>
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:

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
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.

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
Beispiel:

<nowiki>define TRX_MYREMOTE1 TRX_LIGHT PT2262 11110111011 light 0:off,1:on</nowiki>
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):

<nowiki>set TRX_MYREMOTE1 1</nowiki>
<nowiki>set TRX_MYREMOTE1 on</nowiki>
<nowiki>set TRX_MYREMOTE1 off</nowiki>
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.

[[Kategorie:Interface]]

RFXtrx

2013-08-27T12:45:56Z

Wherzig:

'''RFXtrx'''
FHEM unterstützt viele durch einen RFXtrx433 Transceiver erreichbare Geräte durch eigene Module.
== Übersicht ==
[[File:Rfxtrx433.png|500px|right]]

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 [http://www.rfxcom.com/Downloads RFXflash] aktualisiert werden kann. Die neueste Firmware ist unter [http://www.rfxcom.com/Downloads http://www.rfxcom.com/Downloads] zu finden.

Weitere Informationen zu den von diesem Transceiver verfügbaren Protokolle beim Hersteller unter [http://www.rfxcom.com 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 [http://forum.fhem.de/ 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 [http://www.rfxcom.com/oregon.htm 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 [[File:Thgr228n.png|92px|right|thumb|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
[[File:TX3TH.jpg|92px|right|thumb|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 [[File:Bthr918n.png|96px|right|thumb|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 [http://tfa-dostmann.de/index.php?id=57 TFA]
* TFA Windsender 433 MHz, Kat. Nr. 30.3149, 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

=== 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 ([http://www.domotica.famschenk.eu/DS10A_op_433Mhz.html Umbau auf 433 Mhz])
** Marmitek Türsensor DS90
* Bewegungssensoren:
** X10 Bewegungssensor Powerhouse MS10A ([http://www.domotica.famschenk.eu/MS10A-433.html Umbau auf 433 Mhz])[[File:Ms10a.png|70px|right|thumb|MS10A]]<div class="tright" style="clear:none">[[File:Ms90.png|82px|mini|ohne|MS90]]</div>
** 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 [[File:Kr21e.png|60px|right|thumb|KR21E]]<div class="tright" style="clear:none">[[File:Sh624.png|75px|mini|ohne|SH624]]</div>
** 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 [http://www.domoticaforum.eu/viewtopic.php?f=7&t=7276 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 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:

<nowiki>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</nowiki>
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 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":
<nowiki>2012-12-30_21:40:42 TRX_PT2262 111101110111</nowiki>
* Drücken von "off":
<nowiki>2012-12-30_21:40:47 TRX_PT2262 111101110110</nowiki>
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:

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
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.

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
Beispiel:

<nowiki>define TRX_MYREMOTE1 TRX_LIGHT PT2262 11110111011 light 0:off,1:on</nowiki>
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):

<nowiki>set TRX_MYREMOTE1 1</nowiki>
<nowiki>set TRX_MYREMOTE1 on</nowiki>
<nowiki>set TRX_MYREMOTE1 off</nowiki>
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.

[[Kategorie:Hardware]]
[[Kategorie:Other Components]]
[[Kategorie:Glossary]]

RFXtrx

2013-08-27T12:23:37Z

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

'''RFXtrx'''
Fhem unterstützt viele durch einen RFXtrx433 Transceiver erreichbare Geräte durch eigene Module.
== Übersicht ==
[[File:Rfxtrx433.png|500px|right]]

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 [http://www.rfxcom.com/Downloads RFXflash] aktualisiert werden kann. Die neueste Firmware ist unter [http://www.rfxcom.com/Downloads http://www.rfxcom.com/Downloads] zu finden.

Weitere Informationen zu den von diesem Transceiver verfügbaren Protokolle beim Hersteller unter [http://www.rfxcom.com 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 [http://forum.fhem.de/ 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 [http://www.rfxcom.com/oregon.htm 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 [[File:Thgr228n.png|92px|right|thumb|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
[[File:TX3TH.jpg|92px|right|thumb|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 [[File:Bthr918n.png|96px|right|thumb|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 [http://tfa-dostmann.de/index.php?id=57 TFA]
* TFA Windsender 433 MHz, Kat. Nr. 30.3149, 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

=== 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 ([http://www.domotica.famschenk.eu/DS10A_op_433Mhz.html Umbau auf 433 Mhz])
** Marmitek Türsensor DS90
* Bewegungssensoren:
** X10 Bewegungssensor Powerhouse MS10A ([http://www.domotica.famschenk.eu/MS10A-433.html Umbau auf 433 Mhz])[[File:Ms10a.png|70px|right|thumb|MS10A]]<div class="tright" style="clear:none">[[File:Ms90.png|82px|mini|ohne|MS90]]</div>
** 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 [[File:Kr21e.png|60px|right|thumb|KR21E]]<div class="tright" style="clear:none">[[File:Sh624.png|75px|mini|ohne|SH624]]</div>
** 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 [http://www.domoticaforum.eu/viewtopic.php?f=7&t=7276 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 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:

<nowiki>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</nowiki>
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 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":
<nowiki>2012-12-30_21:40:42 TRX_PT2262 111101110111</nowiki>
* Drücken von "off":
<nowiki>2012-12-30_21:40:47 TRX_PT2262 111101110110</nowiki>
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:

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
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.

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
Beispiel:

<nowiki>define TRX_MYREMOTE1 TRX_LIGHT PT2262 11110111011 light 0:off,1:on</nowiki>
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):

<nowiki>set TRX_MYREMOTE1 1</nowiki>
<nowiki>set TRX_MYREMOTE1 on</nowiki>
<nowiki>set TRX_MYREMOTE1 off</nowiki>
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.

[[Kategorie:Hardware]]
[[Kategorie:Other Components]]
[[Kategorie:Glossary]]

RFXtrx

2013-08-27T12:23:05Z

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

'''RFXtrx'''
Fhem unterstützt viele durch einen RFXtrx433 Transceiver erreichbare Geräte durch eigene Module.
== Übersicht ==
[[File:Rfxtrx433.png|500px|right]]

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 [http://www.rfxcom.com/Downloads RFXflash] aktualisiert werden kann. Die neueste Firmware ist unter [http://www.rfxcom.com/Downloads http://www.rfxcom.com/Downloads] zu finden.

Weitere Informationen zu den von diesem Transceiver verfügbaren Protokolle beim Hersteller unter [http://www.rfxcom.com 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 [http://forum.fhem.de/ 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 [http://www.rfxcom.com/oregon.htm 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 [[File:Thgr228n.png|92px|right|thumb|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
[[File:TX3TH.jpg|92px|right|thumb|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 [[File:Bthr918n.png|96px|right|thumb|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 [http://tfa-dostmann.de/index.php?id=57 TFA]
* TFA Windsender 433 MHz, Kat. Nr. 30.3149, 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

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

== 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 ([http://www.domotica.famschenk.eu/DS10A_op_433Mhz.html Umbau auf 433 Mhz])
** Marmitek Türsensor DS90
* Bewegungssensoren:
** X10 Bewegungssensor Powerhouse MS10A ([http://www.domotica.famschenk.eu/MS10A-433.html Umbau auf 433 Mhz])[[File:Ms10a.png|70px|right|thumb|MS10A]]<div class="tright" style="clear:none">[[File:Ms90.png|82px|mini|ohne|MS90]]</div>
** 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 [[File:Kr21e.png|60px|right|thumb|KR21E]]<div class="tright" style="clear:none">[[File:Sh624.png|75px|mini|ohne|SH624]]</div>
** 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 [http://www.domoticaforum.eu/viewtopic.php?f=7&t=7276 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 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:

<nowiki>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</nowiki>
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 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":
<nowiki>2012-12-30_21:40:42 TRX_PT2262 111101110111</nowiki>
* Drücken von "off":
<nowiki>2012-12-30_21:40:47 TRX_PT2262 111101110110</nowiki>
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:

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
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.

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
Beispiel:

<nowiki>define TRX_MYREMOTE1 TRX_LIGHT PT2262 11110111011 light 0:off,1:on</nowiki>
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):

<nowiki>set TRX_MYREMOTE1 1</nowiki>
<nowiki>set TRX_MYREMOTE1 on</nowiki>
<nowiki>set TRX_MYREMOTE1 off</nowiki>
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.

[[Kategorie:Hardware]]
[[Kategorie:Other Components]]
[[Kategorie:Glossary]]

RFXtrx

2013-08-27T12:22:06Z

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

'''RFXtrx'''
Fhem unterstützt viele durch einen RFXtrx433 Transceiver erreichbare Geräte durch eigene Module.
== Übersicht ==
[[File:Rfxtrx433.png|500px|right]]

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 [http://www.rfxcom.com/Downloads RFXflash] aktualisiert werden kann. Die neueste Firmware ist unter [http://www.rfxcom.com/Downloads http://www.rfxcom.com/Downloads] zu finden.

Weitere Informationen zu den von diesem Transceiver verfügbaren Protokolle beim Hersteller unter [http://www.rfxcom.com 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 [http://forum.fhem.de/ 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 [http://www.rfxcom.com/oregon.htm 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 [[File:Thgr228n.png|92px|right|thumb|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
[[File:TX3TH.jpg|92px|right|thumb|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 [[File:Bthr918n.png|96px|right|thumb|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 [http://tfa-dostmann.de/index.php?id=57 TFA]
* TFA Windsender 433 MHz, Kat. Nr. 30.3149, 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

=== 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 D: 14.0 BAT: low
2013-08-27_12:31:37 Alte_Garage T: 19.9 H: 69 P: 1005 D: 14.0 BAT: low
2013-08-27_12:41:45 Alte_Garage T: 19.9 H: 69 P: 1005 D: 14.0 BAT: low
2013-08-27_12:47:27 Alte_Garage T: 20 H: 68 P: 1005 D: 13.9 BAT: low
2013-08-27_12:57:35 Alte_Garage T: 20 H: 68 P: 1005 D: 13.9 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.

== 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 ([http://www.domotica.famschenk.eu/DS10A_op_433Mhz.html Umbau auf 433 Mhz])
** Marmitek Türsensor DS90
* Bewegungssensoren:
** X10 Bewegungssensor Powerhouse MS10A ([http://www.domotica.famschenk.eu/MS10A-433.html Umbau auf 433 Mhz])[[File:Ms10a.png|70px|right|thumb|MS10A]]<div class="tright" style="clear:none">[[File:Ms90.png|82px|mini|ohne|MS90]]</div>
** 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 [[File:Kr21e.png|60px|right|thumb|KR21E]]<div class="tright" style="clear:none">[[File:Sh624.png|75px|mini|ohne|SH624]]</div>
** 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 [http://www.domoticaforum.eu/viewtopic.php?f=7&t=7276 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 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:

<nowiki>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</nowiki>
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 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":
<nowiki>2012-12-30_21:40:42 TRX_PT2262 111101110111</nowiki>
* Drücken von "off":
<nowiki>2012-12-30_21:40:47 TRX_PT2262 111101110110</nowiki>
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:

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
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.

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
Beispiel:

<nowiki>define TRX_MYREMOTE1 TRX_LIGHT PT2262 11110111011 light 0:off,1:on</nowiki>
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):

<nowiki>set TRX_MYREMOTE1 1</nowiki>
<nowiki>set TRX_MYREMOTE1 on</nowiki>
<nowiki>set TRX_MYREMOTE1 off</nowiki>
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.

[[Kategorie:Hardware]]
[[Kategorie:Other Components]]
[[Kategorie:Glossary]]

RFXtrx

2013-08-27T12:19:38Z

Wherzig: /* FAQ: Wie bringe ich FFHEM dazu nicht alle paar Sekunden den Zustand der Sensoren zu loggen? */

'''RFXtrx'''
Fhem unterstützt viele durch einen RFXtrx433 Transceiver erreichbare Geräte durch eigene Module.
== Übersicht ==
[[File:Rfxtrx433.png|500px|right]]

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 [http://www.rfxcom.com/Downloads RFXflash] aktualisiert werden kann. Die neueste Firmware ist unter [http://www.rfxcom.com/Downloads http://www.rfxcom.com/Downloads] zu finden.

Weitere Informationen zu den von diesem Transceiver verfügbaren Protokolle beim Hersteller unter [http://www.rfxcom.com 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 [http://forum.fhem.de/ 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 [http://www.rfxcom.com/oregon.htm 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 [[File:Thgr228n.png|92px|right|thumb|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
[[File:TX3TH.jpg|92px|right|thumb|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 [[File:Bthr918n.png|96px|right|thumb|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 [http://tfa-dostmann.de/index.php?id=57 TFA]
* TFA Windsender 433 MHz, Kat. Nr. 30.3149, 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

=== 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 D: 14.0 BAT: low RSSI: 5
2013-08-27_12:31:37 Alte_Garage T: 19.9 H: 69 P: 1005 D: 14.0 BAT: low RSSI: 5
2013-08-27_12:41:45 Alte_Garage T: 19.9 H: 69 P: 1005 D: 14.0 BAT: low RSSI: 5
2013-08-27_12:47:27 Alte_Garage T: 20 H: 68 P: 1005 D: 13.9 BAT: low RSSI: 5
2013-08-27_12:57:35 Alte_Garage T: 20 H: 68 P: 1005 D: 13.9 BAT: low RSSI: 5

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.

== 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 ([http://www.domotica.famschenk.eu/DS10A_op_433Mhz.html Umbau auf 433 Mhz])
** Marmitek Türsensor DS90
* Bewegungssensoren:
** X10 Bewegungssensor Powerhouse MS10A ([http://www.domotica.famschenk.eu/MS10A-433.html Umbau auf 433 Mhz])[[File:Ms10a.png|70px|right|thumb|MS10A]]<div class="tright" style="clear:none">[[File:Ms90.png|82px|mini|ohne|MS90]]</div>
** 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 [[File:Kr21e.png|60px|right|thumb|KR21E]]<div class="tright" style="clear:none">[[File:Sh624.png|75px|mini|ohne|SH624]]</div>
** 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 [http://www.domoticaforum.eu/viewtopic.php?f=7&t=7276 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 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:

<nowiki>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</nowiki>
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 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":
<nowiki>2012-12-30_21:40:42 TRX_PT2262 111101110111</nowiki>
* Drücken von "off":
<nowiki>2012-12-30_21:40:47 TRX_PT2262 111101110110</nowiki>
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:

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
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.

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
Beispiel:

<nowiki>define TRX_MYREMOTE1 TRX_LIGHT PT2262 11110111011 light 0:off,1:on</nowiki>
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):

<nowiki>set TRX_MYREMOTE1 1</nowiki>
<nowiki>set TRX_MYREMOTE1 on</nowiki>
<nowiki>set TRX_MYREMOTE1 off</nowiki>
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.

[[Kategorie:Hardware]]
[[Kategorie:Other Components]]
[[Kategorie:Glossary]]

RFXtrx

2013-08-27T12:18:27Z

Wherzig: /* FAQ: Wie bringe ich FFHEM dazu nicht alle paar Sekunden den Zustand der Sensoren zu loggen? */

'''RFXtrx'''
Fhem unterstützt viele durch einen RFXtrx433 Transceiver erreichbare Geräte durch eigene Module.
== Übersicht ==
[[File:Rfxtrx433.png|500px|right]]

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 [http://www.rfxcom.com/Downloads RFXflash] aktualisiert werden kann. Die neueste Firmware ist unter [http://www.rfxcom.com/Downloads http://www.rfxcom.com/Downloads] zu finden.

Weitere Informationen zu den von diesem Transceiver verfügbaren Protokolle beim Hersteller unter [http://www.rfxcom.com 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 [http://forum.fhem.de/ 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 [http://www.rfxcom.com/oregon.htm 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 [[File:Thgr228n.png|92px|right|thumb|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
[[File:TX3TH.jpg|92px|right|thumb|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 [[File:Bthr918n.png|96px|right|thumb|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 [http://tfa-dostmann.de/index.php?id=57 TFA]
* TFA Windsender 433 MHz, Kat. Nr. 30.3149, 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

=== FAQ: Wie bringe ich FFHEM 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 D: 14.0 BAT: low RSSI: 5
2013-08-27_12:31:37 Alte_Garage T: 19.9 H: 69 P: 1005 D: 14.0 BAT: low RSSI: 5
2013-08-27_12:41:45 Alte_Garage T: 19.9 H: 69 P: 1005 D: 14.0 BAT: low RSSI: 5
2013-08-27_12:47:27 Alte_Garage T: 20 H: 68 P: 1005 D: 13.9 BAT: low RSSI: 5
2013-08-27_12:57:35 Alte_Garage T: 20 H: 68 P: 1005 D: 13.9 BAT: low RSSI: 5

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.

== 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 ([http://www.domotica.famschenk.eu/DS10A_op_433Mhz.html Umbau auf 433 Mhz])
** Marmitek Türsensor DS90
* Bewegungssensoren:
** X10 Bewegungssensor Powerhouse MS10A ([http://www.domotica.famschenk.eu/MS10A-433.html Umbau auf 433 Mhz])[[File:Ms10a.png|70px|right|thumb|MS10A]]<div class="tright" style="clear:none">[[File:Ms90.png|82px|mini|ohne|MS90]]</div>
** 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 [[File:Kr21e.png|60px|right|thumb|KR21E]]<div class="tright" style="clear:none">[[File:Sh624.png|75px|mini|ohne|SH624]]</div>
** 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 [http://www.domoticaforum.eu/viewtopic.php?f=7&t=7276 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 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:

<nowiki>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</nowiki>
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 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":
<nowiki>2012-12-30_21:40:42 TRX_PT2262 111101110111</nowiki>
* Drücken von "off":
<nowiki>2012-12-30_21:40:47 TRX_PT2262 111101110110</nowiki>
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:

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
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.

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
Beispiel:

<nowiki>define TRX_MYREMOTE1 TRX_LIGHT PT2262 11110111011 light 0:off,1:on</nowiki>
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):

<nowiki>set TRX_MYREMOTE1 1</nowiki>
<nowiki>set TRX_MYREMOTE1 on</nowiki>
<nowiki>set TRX_MYREMOTE1 off</nowiki>
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.

[[Kategorie:Hardware]]
[[Kategorie:Other Components]]
[[Kategorie:Glossary]]

RFXtrx

2013-08-27T12:12:28Z

Wherzig: /* FHEM-Modul: TRX_WEATHER */

'''RFXtrx'''
Fhem unterstützt viele durch einen RFXtrx433 Transceiver erreichbare Geräte durch eigene Module.
== Übersicht ==
[[File:Rfxtrx433.png|500px|right]]

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 [http://www.rfxcom.com/Downloads RFXflash] aktualisiert werden kann. Die neueste Firmware ist unter [http://www.rfxcom.com/Downloads http://www.rfxcom.com/Downloads] zu finden.

Weitere Informationen zu den von diesem Transceiver verfügbaren Protokolle beim Hersteller unter [http://www.rfxcom.com 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 [http://forum.fhem.de/ 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 [http://www.rfxcom.com/oregon.htm 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 [[File:Thgr228n.png|92px|right|thumb|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
[[File:TX3TH.jpg|92px|right|thumb|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 [[File:Bthr918n.png|96px|right|thumb|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 [http://tfa-dostmann.de/index.php?id=57 TFA]
* TFA Windsender 433 MHz, Kat. Nr. 30.3149, 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

=== FAQ: Wie bringe ich FFHEM 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.

Abhlfe: 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 D: 14.0 BAT: low RSSI: 5
2013-08-27_12:31:37 Alte_Garage T: 19.9 H: 69 P: 1005 D: 14.0 BAT: low RSSI: 5
2013-08-27_12:41:45 Alte_Garage T: 19.9 H: 69 P: 1005 D: 14.0 BAT: low RSSI: 5
2013-08-27_12:47:27 Alte_Garage T: 20 H: 68 P: 1005 D: 13.9 BAT: low RSSI: 5
2013-08-27_12:57:35 Alte_Garage T: 20 H: 68 P: 1005 D: 13.9 BAT: low RSSI: 5

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.

== 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 ([http://www.domotica.famschenk.eu/DS10A_op_433Mhz.html Umbau auf 433 Mhz])
** Marmitek Türsensor DS90
* Bewegungssensoren:
** X10 Bewegungssensor Powerhouse MS10A ([http://www.domotica.famschenk.eu/MS10A-433.html Umbau auf 433 Mhz])[[File:Ms10a.png|70px|right|thumb|MS10A]]<div class="tright" style="clear:none">[[File:Ms90.png|82px|mini|ohne|MS90]]</div>
** 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 [[File:Kr21e.png|60px|right|thumb|KR21E]]<div class="tright" style="clear:none">[[File:Sh624.png|75px|mini|ohne|SH624]]</div>
** 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 [http://www.domoticaforum.eu/viewtopic.php?f=7&t=7276 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 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:

<nowiki>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</nowiki>
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 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":
<nowiki>2012-12-30_21:40:42 TRX_PT2262 111101110111</nowiki>
* Drücken von "off":
<nowiki>2012-12-30_21:40:47 TRX_PT2262 111101110110</nowiki>
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:

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
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.

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
Beispiel:

<nowiki>define TRX_MYREMOTE1 TRX_LIGHT PT2262 11110111011 light 0:off,1:on</nowiki>
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):

<nowiki>set TRX_MYREMOTE1 1</nowiki>
<nowiki>set TRX_MYREMOTE1 on</nowiki>
<nowiki>set TRX_MYREMOTE1 off</nowiki>
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.

[[Kategorie:Hardware]]
[[Kategorie:Other Components]]
[[Kategorie:Glossary]]

RFXtrx

2013-08-22T11:58:58Z

Wherzig: /* FHEM-Modul: TRX_WEATHER */

'''RFXtrx'''
Fhem unterstützt viele durch einen RFXtrx433 Transceiver erreichbare Geräte durch eigene Module.
== Übersicht ==
[[File:Rfxtrx433.png|500px|right]]

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 [http://www.rfxcom.com/Downloads RFXflash] aktualisiert werden kann. Die neueste Firmware ist unter [http://www.rfxcom.com/Downloads http://www.rfxcom.com/Downloads] zu finden.

Weitere Informationen zu den von diesem Transceiver verfügbaren Protokolle beim Hersteller unter [http://www.rfxcom.com 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 [http://forum.fhem.de/ 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 [http://www.rfxcom.com/oregon.htm 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 [[File:Thgr228n.png|92px|right|thumb|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
[[File:TX3TH.jpg|92px|right|thumb|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 [[File:Bthr918n.png|96px|right|thumb|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 [http://tfa-dostmann.de/index.php?id=57 TFA]
* TFA Windsender 433 MHz, Kat. Nr. 30.3149, 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

== 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 ([http://www.domotica.famschenk.eu/DS10A_op_433Mhz.html Umbau auf 433 Mhz])
** Marmitek Türsensor DS90
* Bewegungssensoren:
** X10 Bewegungssensor Powerhouse MS10A ([http://www.domotica.famschenk.eu/MS10A-433.html Umbau auf 433 Mhz])[[File:Ms10a.png|70px|right|thumb|MS10A]]<div class="tright" style="clear:none">[[File:Ms90.png|82px|mini|ohne|MS90]]</div>
** 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 [[File:Kr21e.png|60px|right|thumb|KR21E]]<div class="tright" style="clear:none">[[File:Sh624.png|75px|mini|ohne|SH624]]</div>
** 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 [http://www.domoticaforum.eu/viewtopic.php?f=7&t=7276 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 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:

<nowiki>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</nowiki>
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 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":
<nowiki>2012-12-30_21:40:42 TRX_PT2262 111101110111</nowiki>
* Drücken von "off":
<nowiki>2012-12-30_21:40:47 TRX_PT2262 111101110110</nowiki>
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:

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
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.

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
Beispiel:

<nowiki>define TRX_MYREMOTE1 TRX_LIGHT PT2262 11110111011 light 0:off,1:on</nowiki>
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):

<nowiki>set TRX_MYREMOTE1 1</nowiki>
<nowiki>set TRX_MYREMOTE1 on</nowiki>
<nowiki>set TRX_MYREMOTE1 off</nowiki>
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.

[[Kategorie:Hardware]]
[[Kategorie:Other Components]]
[[Kategorie:Glossary]]

RFXtrx

2013-07-12T19:17:23Z

Wherzig:

'''RFXtrx'''
Fhem unterstützt viele durch einen RFXtrx433 Transceiver erreichbare Geräte durch eigene Module.
== Übersicht ==
[[File:Rfxtrx433.png|500px|right]]

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 [http://www.rfxcom.com/Downloads RFXflash] aktualisiert werden kann. Die neueste Firmware ist unter [http://www.rfxcom.com/Downloads http://www.rfxcom.com/Downloads] zu finden.

Weitere Informationen zu den von diesem Transceiver verfügbaren Protokolle beim Hersteller unter [http://www.rfxcom.com 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 [http://forum.fhem.de/ 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 [http://www.rfxcom.com/oregon.htm 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 [[File:Thgr228n.png|92px|right|thumb|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
[[File:TX3TH.jpg|92px|right|thumb|TX3TH]]

- '''Temperatur-/Luftffeuchtigkeits-/Luftdrucksensoren''':

* "BTHR918": Oregon-Scientific BTHR918
* "BTHR918N": Oregon-Scientific/Huger BTHR918N, BTHR968 [[File:Bthr918n.png|96px|right|thumb|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 [http://tfa-dostmann.de/index.php?id=57 TFA]
* TFA Windsender 433 MHz, Kat. Nr. 30.3149, 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

== 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 ([http://www.domotica.famschenk.eu/DS10A_op_433Mhz.html Umbau auf 433 Mhz])
** Marmitek Türsensor DS90
* Bewegungssensoren:
** X10 Bewegungssensor Powerhouse MS10A ([http://www.domotica.famschenk.eu/MS10A-433.html Umbau auf 433 Mhz])[[File:Ms10a.png|70px|right|thumb|MS10A]]<div class="tright" style="clear:none">[[File:Ms90.png|82px|mini|ohne|MS90]]</div>
** 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 [[File:Kr21e.png|60px|right|thumb|KR21E]]<div class="tright" style="clear:none">[[File:Sh624.png|75px|mini|ohne|SH624]]</div>
** 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 [http://www.domoticaforum.eu/viewtopic.php?f=7&t=7276 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 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:

<nowiki>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</nowiki>
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 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":
<nowiki>2012-12-30_21:40:42 TRX_PT2262 111101110111</nowiki>
* Drücken von "off":
<nowiki>2012-12-30_21:40:47 TRX_PT2262 111101110110</nowiki>
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:

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
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.

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
Beispiel:

<nowiki>define TRX_MYREMOTE1 TRX_LIGHT PT2262 11110111011 light 0:off,1:on</nowiki>
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):

<nowiki>set TRX_MYREMOTE1 1</nowiki>
<nowiki>set TRX_MYREMOTE1 on</nowiki>
<nowiki>set TRX_MYREMOTE1 off</nowiki>
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.

[[Kategorie:Hardware]]
[[Kategorie:Other Components]]
[[Kategorie:Glossary]]

RFXtrx

2013-07-12T19:16:01Z

Wherzig:

[[Kategorie:Hardware]]
'''RFXtrx'''
Fhem unterstützt viele durch einen RFXtrx433 Transceiver erreichbare Geräte durch eigene Module.
== Übersicht ==
[[File:Rfxtrx433.png|500px|right]]

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 [http://www.rfxcom.com/Downloads RFXflash] aktualisiert werden kann. Die neueste Firmware ist unter [http://www.rfxcom.com/Downloads http://www.rfxcom.com/Downloads] zu finden.

Weitere Informationen zu den von diesem Transceiver verfügbaren Protokolle beim Hersteller unter [http://www.rfxcom.com 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 [http://forum.fhem.de/ 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 [http://www.rfxcom.com/oregon.htm 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 [[File:Thgr228n.png|92px|right|thumb|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
[[File:TX3TH.jpg|92px|right|thumb|TX3TH]]

- '''Temperatur-/Luftffeuchtigkeits-/Luftdrucksensoren''':

* "BTHR918": Oregon-Scientific BTHR918
* "BTHR918N": Oregon-Scientific/Huger BTHR918N, BTHR968 [[File:Bthr918n.png|96px|right|thumb|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 [http://tfa-dostmann.de/index.php?id=57 TFA]
* TFA Windsender 433 MHz, Kat. Nr. 30.3149, 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

== 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 ([http://www.domotica.famschenk.eu/DS10A_op_433Mhz.html Umbau auf 433 Mhz])
** Marmitek Türsensor DS90
* Bewegungssensoren:
** X10 Bewegungssensor Powerhouse MS10A ([http://www.domotica.famschenk.eu/MS10A-433.html Umbau auf 433 Mhz])[[File:Ms10a.png|70px|right|thumb|MS10A]]<div class="tright" style="clear:none">[[File:Ms90.png|82px|mini|ohne|MS90]]</div>
** 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 [[File:Kr21e.png|60px|right|thumb|KR21E]]<div class="tright" style="clear:none">[[File:Sh624.png|75px|mini|ohne|SH624]]</div>
** 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 [http://www.domoticaforum.eu/viewtopic.php?f=7&t=7276 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 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:

<nowiki>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</nowiki>
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 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":
<nowiki>2012-12-30_21:40:42 TRX_PT2262 111101110111</nowiki>
* Drücken von "off":
<nowiki>2012-12-30_21:40:47 TRX_PT2262 111101110110</nowiki>
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:

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
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.

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
Beispiel:

<nowiki>define TRX_MYREMOTE1 TRX_LIGHT PT2262 11110111011 light 0:off,1:on</nowiki>
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):

<nowiki>set TRX_MYREMOTE1 1</nowiki>
<nowiki>set TRX_MYREMOTE1 on</nowiki>
<nowiki>set TRX_MYREMOTE1 off</nowiki>
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.

[[Kategorie:Other Components]]
[[Kategorie:Glossary]]

RFXtrx

2013-07-12T19:14:35Z

Wherzig:

'''RFXtrx'''
Fhem unterstützt viele durch einen RFXtrx433 Transceiver erreichbare Geräte durch eigene Module.
== Übersicht ==
[[File:Rfxtrx433.png|500px|right]]

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 [http://www.rfxcom.com/Downloads RFXflash] aktualisiert werden kann. Die neueste Firmware ist unter [http://www.rfxcom.com/Downloads http://www.rfxcom.com/Downloads] zu finden.

Weitere Informationen zu den von diesem Transceiver verfügbaren Protokolle beim Hersteller unter [http://www.rfxcom.com 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 [http://forum.fhem.de/ 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 [http://www.rfxcom.com/oregon.htm 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 [[File:Thgr228n.png|92px|right|thumb|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
[[File:TX3TH.jpg|92px|right|thumb|TX3TH]]

- '''Temperatur-/Luftffeuchtigkeits-/Luftdrucksensoren''':

* "BTHR918": Oregon-Scientific BTHR918
* "BTHR918N": Oregon-Scientific/Huger BTHR918N, BTHR968 [[File:Bthr918n.png|96px|right|thumb|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 [http://tfa-dostmann.de/index.php?id=57 TFA]
* TFA Windsender 433 MHz, Kat. Nr. 30.3149, 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

== 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 ([http://www.domotica.famschenk.eu/DS10A_op_433Mhz.html Umbau auf 433 Mhz])
** Marmitek Türsensor DS90
* Bewegungssensoren:
** X10 Bewegungssensor Powerhouse MS10A ([http://www.domotica.famschenk.eu/MS10A-433.html Umbau auf 433 Mhz])[[File:Ms10a.png|70px|right|thumb|MS10A]]<div class="tright" style="clear:none">[[File:Ms90.png|82px|mini|ohne|MS90]]</div>
** 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 [[File:Kr21e.png|60px|right|thumb|KR21E]]<div class="tright" style="clear:none">[[File:Sh624.png|75px|mini|ohne|SH624]]</div>
** 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 [http://www.domoticaforum.eu/viewtopic.php?f=7&t=7276 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 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:

<nowiki>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</nowiki>
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 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":
<nowiki>2012-12-30_21:40:42 TRX_PT2262 111101110111</nowiki>
* Drücken von "off":
<nowiki>2012-12-30_21:40:47 TRX_PT2262 111101110110</nowiki>
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:

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
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.

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
Beispiel:

<nowiki>define TRX_MYREMOTE1 TRX_LIGHT PT2262 11110111011 light 0:off,1:on</nowiki>
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):

<nowiki>set TRX_MYREMOTE1 1</nowiki>
<nowiki>set TRX_MYREMOTE1 on</nowiki>
<nowiki>set TRX_MYREMOTE1 off</nowiki>
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.

[[Kategorie:Other Components]]
[[Kategorie:Hardware]]
[[Kategorie:Glossary]]

RFXtrx

2013-07-12T19:05:26Z

Wherzig: /* FHEM-Modul: TRX_WEATHER */

'''RFXtrx'''
Fhem unterstützt viele durch einen RFXtrx433 Transceiver erreichbare Geräte durch eigene Module.
== Übersicht ==
[[File:Rfxtrx433.png|500px|right]]

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 [http://www.rfxcom.com/Downloads RFXflash] aktualisiert werden kann. Die neueste Firmware ist unter [http://www.rfxcom.com/Downloads http://www.rfxcom.com/Downloads] zu finden.

Weitere Informationen zu den von diesem Transceiver verfügbaren Protokolle beim Hersteller unter [http://www.rfxcom.com 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 [http://forum.fhem.de/ 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 [http://www.rfxcom.com/oregon.htm 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 [[File:Thgr228n.png|92px|right|thumb|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
[[File:TX3TH.jpg|92px|right|thumb|TX3TH]]

- '''Temperatur-/Luftffeuchtigkeits-/Luftdrucksensoren''':

* "BTHR918": Oregon-Scientific BTHR918
* "BTHR918N": Oregon-Scientific/Huger BTHR918N, BTHR968 [[File:Bthr918n.png|96px|right|thumb|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 [http://tfa-dostmann.de/index.php?id=57 TFA]
* TFA Windsender 433 MHz, Kat. Nr. 30.3149, 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

== 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 ([http://www.domotica.famschenk.eu/DS10A_op_433Mhz.html Umbau auf 433 Mhz])
** Marmitek Türsensor DS90
* Bewegungssensoren:
** X10 Bewegungssensor Powerhouse MS10A ([http://www.domotica.famschenk.eu/MS10A-433.html Umbau auf 433 Mhz])[[File:Ms10a.png|70px|right|thumb|MS10A]]<div class="tright" style="clear:none">[[File:Ms90.png|82px|mini|ohne|MS90]]</div>
** 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 [[File:Kr21e.png|60px|right|thumb|KR21E]]<div class="tright" style="clear:none">[[File:Sh624.png|75px|mini|ohne|SH624]]</div>
** 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 [http://www.domoticaforum.eu/viewtopic.php?f=7&t=7276 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 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:

<nowiki>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</nowiki>
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 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":
<nowiki>2012-12-30_21:40:42 TRX_PT2262 111101110111</nowiki>
* Drücken von "off":
<nowiki>2012-12-30_21:40:47 TRX_PT2262 111101110110</nowiki>
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:

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
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.

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
Beispiel:

<nowiki>define TRX_MYREMOTE1 TRX_LIGHT PT2262 11110111011 light 0:off,1:on</nowiki>
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):

<nowiki>set TRX_MYREMOTE1 1</nowiki>
<nowiki>set TRX_MYREMOTE1 on</nowiki>
<nowiki>set TRX_MYREMOTE1 off</nowiki>
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.

[[Kategorie:Other Components]]
[[Kategorie:Glossary]]

RFXtrx

2013-07-12T19:04:10Z

Wherzig: /* FHEM-Modul: TRX_WEATHER */

'''RFXtrx'''
Fhem unterstützt viele durch einen RFXtrx433 Transceiver erreichbare Geräte durch eigene Module.
== Übersicht ==
[[File:Rfxtrx433.png|500px|right]]

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 [http://www.rfxcom.com/Downloads RFXflash] aktualisiert werden kann. Die neueste Firmware ist unter [http://www.rfxcom.com/Downloads http://www.rfxcom.com/Downloads] zu finden.

Weitere Informationen zu den von diesem Transceiver verfügbaren Protokolle beim Hersteller unter [http://www.rfxcom.com 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 [http://forum.fhem.de/ 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 [http://www.rfxcom.com/oregon.htm Wetter-Sensoren] finden Sie eine vollständige Liste der aktuell von RFXtrx433 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 [[File:Thgr228n.png|92px|right|thumb|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
[[File:TX3TH.jpg|92px|right|thumb|TX3TH]]

- '''Temperatur-/Luftffeuchtigkeits-/Luftdrucksensoren''':

* "BTHR918": Oregon-Scientific BTHR918
* "BTHR918N": Oregon-Scientific/Huger BTHR918N, BTHR968 [[File:Bthr918n.png|96px|right|thumb|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 [http://tfa-dostmann.de/index.php?id=57 TFA]
* TFA Windsender 433 MHz, Kat. Nr. 30.3149, 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

== 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 ([http://www.domotica.famschenk.eu/DS10A_op_433Mhz.html Umbau auf 433 Mhz])
** Marmitek Türsensor DS90
* Bewegungssensoren:
** X10 Bewegungssensor Powerhouse MS10A ([http://www.domotica.famschenk.eu/MS10A-433.html Umbau auf 433 Mhz])[[File:Ms10a.png|70px|right|thumb|MS10A]]<div class="tright" style="clear:none">[[File:Ms90.png|82px|mini|ohne|MS90]]</div>
** 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 [[File:Kr21e.png|60px|right|thumb|KR21E]]<div class="tright" style="clear:none">[[File:Sh624.png|75px|mini|ohne|SH624]]</div>
** 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 [http://www.domoticaforum.eu/viewtopic.php?f=7&t=7276 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 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:

<nowiki>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</nowiki>
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 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":
<nowiki>2012-12-30_21:40:42 TRX_PT2262 111101110111</nowiki>
* Drücken von "off":
<nowiki>2012-12-30_21:40:47 TRX_PT2262 111101110110</nowiki>
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:

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
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.

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
Beispiel:

<nowiki>define TRX_MYREMOTE1 TRX_LIGHT PT2262 11110111011 light 0:off,1:on</nowiki>
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):

<nowiki>set TRX_MYREMOTE1 1</nowiki>
<nowiki>set TRX_MYREMOTE1 on</nowiki>
<nowiki>set TRX_MYREMOTE1 off</nowiki>
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.

[[Kategorie:Other Components]]
[[Kategorie:Glossary]]