RFXtrx: Unterschied zwischen den Versionen
C2j2 (Diskussion | Beiträge) (Beispiel-Anleitung für die Konfiguration von Brennenstuhl Funksteckdosen) |
C2j2 (Diskussion | Beiträge) |
||
Zeile 352: | Zeile 352: | ||
EIN=10111 11101 01, AUS=10111 11101 11 (Steckdose 4)</nowiki> | EIN=10111 11101 01, AUS=10111 11101 11 (Steckdose 4)</nowiki> | ||
Also sind die nächsten 5 Zahlen die Zuordnung der Steckdosen. Jede Stelle beschreibt den Zustand des passenden DIP-Switches "A" bis "E", wie üblich "0" ist "ON", "1" ist "OFF". Ob die Steckdosen mit mehr als einem auf OFF gelegten "A" bis "E"-Switch funktionieren, habe ich nicht getestet, aber es erscheint logisch, man könnte dann bis zu 32 Steckdosen auf den gleichen Systemcode legen | Also sind die nächsten 5 Zahlen die Zuordnung der Steckdosen. Jede Stelle beschreibt den Zustand des passenden DIP-Switches "A" bis "E", wie üblich "0" ist "ON", "1" ist "OFF". Ob die Steckdosen mit mehr als einem auf OFF gelegten "A" bis "E"-Switch funktionieren, habe ich nicht getestet, aber es erscheint logisch, man könnte dann bis zu 32 Steckdosen auf den gleichen Systemcode legen, und ein Nachbar mit Fernbedienung kann nichts Böses anrichten! FHEM kann es egal sein, man kann ja verschiedene Systemcodes angeben, das geht bei der Fernbedienung nicht. Die ausserdem auch nur einen der "A" bis "D"-Switches adressiert. | ||
===== Ein/Aus-Kommando ===== | ===== Ein/Aus-Kommando ===== |
Version vom 1. Dezember 2016, 18:32 Uhr
Fhem unterstützt viele durch einen RFXtrx433 Transceiver erreichbare Geräte durch eigene Module.
Übersicht
RFXtrx433 ist ein Transceiver (Funkempfänger und Funksender) mit USB-Anschluss für den Frenzbereich 433,92 MHz. Die Stromversorgung erfolgt über USB. Das Gerät hat einen FTDI-FT232R-USB-Interface-Chip installiert. Um RFXtrx433 nutzen zu können, muss das Betriebssystem einen entsprechenden Treiber für diesen Chip haben. Genutzt wird RFXtrx433 von Anwendern mit FHEM unter Linux, Fritzbox 7390 oder Windows.
Mit der mitgelieferten Firmware können viele Funksensoren in diesem Frequenzbereich empfangen werden und es ist möglich bestimmte Protokolle auch zu senden. Die unterstützten Protokolle sind von der installierten Firmware abhängig, die über das Windows-Programm RFXflash aktualisiert werden kann. Die neueste Firmware ist unter http://www.rfxcom.com/Downloads zu finden.
Weitere Informationen zu den von diesem Transceiver verfügbaren Protokolle beim Hersteller unter www.rfxcom.com. Da der Hersteller die Anzahl der Geräte ständig aktualisiert und die FHEM-Treiber in der Freizeit des Autors geschrieben werden, sind in den FHEM-Treibern nur eine Untermenge implementiert. Sollte ein Gerät/Protokoll fehlen, das die Firma RFXCOM unterstützt, können Sie im FHEM-Forum in der Untergruppe RFXTRX nachfragen, ob dieses implementiert werden kann.
TRXtrx433 wird derzeit von FHEM mit den Modulen TRX, TRX_LIGHT, TRX-SECURITY und TRX_WEATHER für eine Reihe von Protokollen unterstützt.
Nachfolgend werden nur Geräte aufgezeigt, die bei der Erstellung dieses WIKI-Eintrages eingepflegt werden.
FHEM-Modul: TRX_WEATHER
Dieses Modul unterstützt Wettersensoren, insbesondere Sensoren des Herstellers Oregon-Scientific. Unter Wetter-Sensoren finden Sie eine Liste der von der RFXtrx433-Firmware unterstützten Wetter-Sensoren (Oregon-Scientific, Cresta, La Crosse, TFA, UPM, ...). Das FHEM-Modul TRX_WEATHER implementiert derzeit den Empfang folgender Sensorentypen und Sensoren:
- Temperatursensoren:
- "THR128": Oregon-Scientific THR128/138, THC138
- "THGR132N": Oregon-Scientific THC238/268,THN132,THWR288,THRN122,THN122,AW129/131
- "THWR800": Oregon-Scientific THWR800
- "RTHN318": Oregon-Scientific RTHN318
- "TS15C": TS15C
- "VIKING_02811" : Viking 02811
- "WS2300" : La Crosse WS2300
- "RUBICSON" : RUBiCSON
- "TFA_303133" : TFA 30.3133
- Temperatur-/Luftffeuchtigkeitssensoren:
- "THGR228N": Oregon-Scientific THGN122/123, THGN132, THGR122/228/238/268
- "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
- Nicht unterstützt werden von der RFXCOM-Firmware: TFA 30.3166
- Temperatur-/Luftffeuchtigkeits-/Luftdrucksensoren:
- "BTHR918": Oregon-Scientific BTHR918
- "BTHR918N": Oregon-Scientific/Huger BTHR918N, BTHR968
- Regensensoren:
- "RGR918": Oregon-Scientific RGR126/682/918
- "PCR800": Oregon-Scientific PCR800
- "TFA_RAIN": TFA-Regensensor (Kat. Nr. 30.3148)
- "RG700": UPM RG700
- Windsensoren:
- "WTGR800_A": Oregon-Scientific WTGR800
- "WGR800_A": Oregon-Scientific WGR800
- "WGR918": Oregon-Scientific STR918, WGR918
- "TFA_WIND": TFA-Windsensor (Kat. Nr. 30.3149)
- "WDS500" : UPM WDS500
- UV-Sensoren:
- "UVN128": Oregon UVN128, UV138
- "UVN800": Oregon UVN800
- "TFA_UV": TFA_UV-Sensor
- Waagen:
- "BWR101": Oregon Scientific BWR101
- "GR101": Oregon Scientific GR101
- Energiesensoren:
- "CM160": OWL CM119 und CM160
- "CM180": OWL CM180
Der Autor des Module setzt derzeit folgende Sensoren ein:
- Oregon Scientific: BTHR918, BTHR918N, PCR800, RGR918, THGR228N, THR128, THWR288A, WTGR800, WGR918
Von Nutzern wurde die Funktion folgender weiterer Sensoren gemeldet:
- Oregon Scientific GR101
- Oregon Scientific RTGR-328 (T/H)
- Honeywell TF-ATS34C (T/H)
- TFA Regensender 433 MHz, Kat. Nr. 30.3148, siehe TFA
- TFA Windsender 433 MHz, Kat. Nr. 30.3149, siehe TFA
- TFA T/H-Sender 433 MHz, Kat. Nr. 30.3150, siehe TFA
- OWL CM160
FAQ: Wie bringe ich FHEM dazu nicht alle paar Sekunden den Zustand der Sensoren zu loggen?
Den ein oder anderen hat es schon genervt, dass die Oregon-Sensoren sehr gesprächig sind und damit das Filelog sehr groß wird.
Abhilfe: Hierzu kann man event-min-interval verwenden, um festzulegen, dass Events nur alle x Minuten generiert werden. event-on-change-reading kann man verwenden, dass Änderungen trotzdem sofort bemerkt werden.
Nachfolgend wird ein Oregon-Sensor BTHR918 so konfiguriert, dass er nur alle 10 Minuten loggt, aber beim State die Änderungen sofort geloggt werden.
define Alte_Garage TRX_WEATHER BTHR918 attr Alte_Garage event-min-interval state:600 attr Alte_Garage event-on-change-reading state attr Alte_Garage event-on-update-reading .*
Damit man nicht alles loggt, kann man das Logging auf die Zeilen beschränken, die mit T: beginnen:
define FileLog_Alte_Garage FileLog /var/log/fhem/Alte_Garage-%Y.log Alte_Garage:T\x3a.* attr FileLog_Alte_Garage logtype temp4press8:Temp/Press,temp4hum6dew10:Temp/Hum,text
Damit hat man dann folgendes im Log:
2013-08-27_12:21:29 Alte_Garage T: 19.9 H: 69 P: 1005 BAT: low 2013-08-27_12:31:37 Alte_Garage T: 19.9 H: 69 P: 1005 BAT: low 2013-08-27_12:41:45 Alte_Garage T: 19.9 H: 69 P: 1005 BAT: low 2013-08-27_12:47:27 Alte_Garage T: 20 H: 68 P: 1005 D: BAT: low 2013-08-27_12:57:35 Alte_Garage T: 20 H: 68 P: 1005 D: BAT: low
Wie man sieht, wird normalerweise alle 10 Minuten geloggt. Um 12:47:27 hat sich die Temperatur verändert und damit wurde ausserhalb der Reihe sofort ein Event generiert.
Ja, stimmt, ich muss noch die Batterie des Sensors wechseln (BAT: low) ;-)
FHEM-Modul: TRX_SECURITY
Empfängt Security-Sensoren der Protokolle X10-Security, KD101 und Visonic.
KD101 kompatible Rauchmelder Es wurden folgende KD101-Versionen gemeldet, die mit RXFtrx433 empfangen werden können:
- KD101LD
- KD101LA
- Flamingo FA20RF
- Elro RM150RF
- Unitec 46779
Die Rauchmelder KD101 (KD101LD, KD101LA, Flamingo FA20RF, Elro RM150RF) haben folgendes Verhalten:
- Wenn der KD101 selbst Rauch feststellt, kann man diesen Alarm über Funk nicht stoppen. Er sendet "alert" über Funk.
- Wenn man "alarm" über Funk an einen Rauchmelder sendet, dauert der Alarm nur wenige Sekunden. Für einen dauerhaften Alarm muss man also "alert" immer wieder senden.
- Wenn man die KD101 pairt, bekommen alle gepairten KD101 dieselbe ID.
- Wenn einer Rauch erkennt, triggert er alle KD101 mit derselben ID (also die gepairten).
- Nach Drücken der Taste "Test" am Rauchmelder sendet dieser "alert". Dadurch wird per autocreate der Rauchmelder angelegt.
- Ein KD101 sendet kein Keepalive-Signal. Man kann also nur testen, ob ein Rauchmelder noch funktioniert, indem man die Test-Taste drückt.
Mittels RFXtrx433 kann man die Befehle "alert" und "pair" an einen Rauchmelder senden.
Beispiel:
- set TRX_KD101_a5ca00 alert
Dies sendet den panic-Befehl an den Rauchmelder. Damit hört man ca. 3 Sekunden lang den nervigen Ton des Rauchmelders. Wer diesen länger haben will, muss das set nach ca. 3 Sekunden erneut auslösen. Wer man also ein "set DEVICE alert" an einen Rauchmelder schickt, der mit anderen gepairt ist, dann wird der Alarm bei allen gepairten Rauchmeldern ausgelöst.
X10-Security-Sensoren
Folgende X10-Security-Sensoren werden erfolgreich eingesetzt:
- Türsensoren:
- X10 Türsensor Powerhouse DS10A (Umbau auf 433 Mhz)
- Marmitek Türsensor DS90
- Bewegungssensoren:
- X10 Bewegungssensor Powerhouse MS10A (Umbau auf 433 Mhz)
- 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
- Marmitek SH624
X10-Security-Sensoren senden etwa jede Stunde ein Keepalive-Paket, welches auch Informationen über den Batterieladestand enthält.
- Bewegungsmelder
- Oregon MSR939 (benötigt den RFXtrx433e), theoretisch 32 Adressen möglich, 5 Stück erfolgreich eingebunden (mehr Sensoren hatte ich nicht zur Hand)
FHEM-Modul: TRX_LIGHT.pm
Empfängt die Protokolle X10, ARC, ELRO AB400D, Waveman, Chacon EMW200, IMPULS, RisingSun, Philips SBC, AC, HomeEasy EU sowie ANSLUT lighting devices (switches and remote control).
ARC ist ein a Protokoll, welches von Geräten HomeEasy, KlikAanKlikUit, ByeByeStandBy, Intertechno, ELRO, AB600, Duewi, DomiaLite und COCO genutzt wird. Typisch ist, dass diese Geräte einen Drehschalter haben, um die Protkolladresse einzustellen.
Das ARC-Protokoll kennt keinen Dim-Befehl. Daher hat die Firmware vom RFXtrx433 und auch das FHEM-Modul TRX_LIGHT keinen solchen Befehl. Die verkauften Dimmer mit ARC-Protokoll starten gemäß meiner Information das Hoch-Dimmen nach Empfang zweier ON-Kommandos. Sobald dann das nächste ON oder OFF Kommando empfangen wird, wird das Dimmen beendet. Das ganze ist also zeitabhängig und eigentlich nicht für die Hausautomatisierung gedacht, sondern für den Menschen, der sieht, ob der Dim-Level ok ist. Automatisiert bekommt man keine exakte prozentuale Dimmung hin, da man Dimmen nur über Timing erreichen kann. Da FHEM nicht sehen kann wie weit gedimmt wurde, ist das allerdings nicht wirklich praktikabel und auch vom Gerät abhängig. Unterschiedliche Geräte auch unterschiedliches Zeitverhalten.
AC ist ein Protokoll, welches verschiedene Hersteller nutzen, die die Adresse über einen LEARN-Button lernen: KlikAanKlikUit, NEXA, CHACON, HomeEasy UK.
Achtung:Es sollte beachtet werden, dass Tür- und Bewegungssensoren des AC-Protokolls (HomeEasy alt, Chacon, KlikAanKlikUit, NEXA...) teilweise für 3-5 Sekunden etwa 50 Funkpakete generieren, was zu Kollisionen mit anderen Paketen führen kann. Siehe Hinweis zur Nutzung von Bewegungssensoren. Ich rate daher vom Einsatz von Bewegungssensoren mit dem AC-Protokoll ab.
Der Autor des Moduls setzt derzeit folgende Geräte ein:
- Eagle EyeMS14a Bewegungssensor (Umbau auf 433 Mhz)
- Elro AB600 Funksender und Steckdosen
Nutzer haben die Funktion folgender Geräte gemeldet:
- KAKU AWST-6000 (Bewegungsmelder, sendet on/off)
- KAKU AMST-606 (Tür-/Fenster-Kontakt, sendet all_level/off)
- KAKU AWMT-230 (Unterputzsender, sendet on/off)
- KAKU APA3-1500R (Schalter & Handsender, nur on/off/all_off)
- KAKU CDB-6500AC (Türklingel, sendet nur chime)
PT2262 empfangen und senden mit TRX_LIGHT.pm
WARNUNG:PT2262-Codes sollten nur verwendet werden, wenn unbedingt erforderlich. Normalerweise reicht die Nutzung der von RFXCOM vordefinierten Dekodierungen wie das ARC-Protokoll aus. Bei manchen Geräten mit dem Chip PT2262 kann dies evtl. nicht ausreichen. Sinnvollerweise sollte man prüfen, ob das Gerät wirklich einen Funk-Encoder-IC PT2262 oder SC2262 enthält.
ACHTUNG: Es können nur PT2262-Codes empfangen werden, wenn das Pulse-Timung 350 usec ist (Siehe Kapitel 8 im RFXtrx User Guide). Gemäß Seite 6 im Dokument http://www.escol.com.my/Datasheets_specs/pt2262_1.pdf sollte für den Oszillator normalerweise ein 3,3 Mega-Ohm-Widerstand eingebaut sein.
PT2262-Format empfangen
Das Funk-Encoder-IC PT2262 der Firma PTC Taiwan (siehe http://pdf.dzsc.com/88889/21967.pdf) wird häufig in Fernbedienungen von Funksteckdosen und auch anderen Funkgeräten im 433-Mhz-Bereich verwendet. Es gibt viele PIN kompatible ICs wie z.B. der SC2262.
Es werden hierbei 12 Zeichen im Tristate-Format (0, 1, 2 bzw. f) übertragen. Der erste Teil der Zeichen stellt die Adresse und die darauffolgenden Zeichen die Datenbits (Zeichen 0 oder 1) dar. Die verwendeten Fernbedienungen haben häufig Dip-Schalter mit drei Zuständen (also 0,1,2), mit denen sich die Adressen einstellen lassen.
Das Protokoll ist vom Aufbau ähnlich zum ARC-Protokoll.
Dabei lassen sich die ersten 6-12 Zeichen als Adressen (A0 bis A11) und die letzten 0-6 Zeichen (D5-D0) als Datenbits nutzen. Es sind damit insgesamt folgende Kombinationen der Bits möglich:
A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 A10 A11 A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 A10 D0 A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 D1 D0 A0 A1 A2 A3 A4 A5 A6 A7 A8 D2 D1 D0 A0 A1 A2 A3 A4 A5 A6 A7 D3 D2 D1 D0 A0 A1 A2 A3 A4 A5 A6 D4 D3 D2 D1 D0 A0 A1 A2 A3 A4 A5 D5 D4 D3 D2 D1 D0
Damit lassen sich also maximal 6-Bit-Daten übertragen. Dies reicht für einfache Schaltaufgaben, aber nicht für Anwendungen wie beispielsweise Thermometer.
RFXtrx433 läßt sich über RFXmngr so konfigurieren, dass die 12-Zeichen-Datagramme des PT2262-Formats als 24-Bit-Nutzdaten bzw. 3 Bytes empfangen werden können. Dazu kann man in RFXmngr das Protokoll Lighting4 einschalten. Hinweise zur Nutzung sind in RFXtrx User Guide (Kapitel "15. Transmit undecoded ARC commands") zu finden.
Das FHEM-Modul TRX_LIGHT erlaubt die Verarbeitung des PT2262-Formates.
Sobald Lighting4 eingeschaltet wird, werden die einzelnen Bits dem Gerät TRX_PT2262 zugeordnet. Sofern dieses noch nicht vorhanden ist, wird diesen per Autocreate definiert und ein entsprechendes Filelog angelegt.
Wenn beispielsweise ein Nutzer einen Taster einer ELRO AB600 Fernbedienung drückt, werden je nach Codierung der Adresse folgende Codes im Filelog generiert:
- Drücken der Taste "on":
2012-12-30_21:40:42 TRX_PT2262 111101110111
- Drücken von "off":
2012-12-30_21:40:47 TRX_PT2262 111101110110
Auf diese Weise kann ein Nutzer sehen, welche PT2262-Codes von RFXtrx433 empfangen werden.
Der Nutzer muss danach selbst entscheiden, welche Zeichen Adressen und welche Daten darstellen und was die Daten bedeuten. Im oben genannten Beispiel ist dies relativ einfach. Man sieht, dass sich nur das letzte Bit ändern und die Zustände 0 und 1 annimmt. Es ist daher anzunehmen, dass die ersten 11 Zeichen die Adresse repräsentieren.
TRX_LIGHT bietet die Möglichkeit den Adressprefix, die sogenannte deviceid selbst in einem define-Statement festzulegen. Die Konvention ist dabei, dass die einzelnen Zeichen der Base4-Codierung angegeben werden müssen:
define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]
In commandcodes gibt man optional an wie die Ziffern Strings wie beispielsweise "on" oder "off" zugeordnet werden sollen. Dabei können über Komma getrennt wie die Ziffern den einzelnen Strings zugeordnet werden sollen. Jede einzelne Zuordnung wird über : angegeben. Zusätzlich sollte ein entsprechendes FileLog definiert werden.
Beispiel:
define TRX_MYREMOTE1 TRX_LIGHT PT2262 11110111011 light 0:off,1:on
define FileLog_TRX_MYREMOTE1 FileLog /var/log/fhem/TRX_MYREMOTE1-%Y.log TRX_MYREMOTE1
In diesem Fall wird die Ziffer 0 "off" und die Ziffer 1 "on" zugeordnet.
Damit werden nach Drücken der Tasten on und off folgende Einträge im Filelog wie folgt generiert:
==> TRX_MYREMOTE1-2012.log <== 2012-12-30_21:54:56 TRX_MYREMOTE1 light: on 2012-12-30_21:54:56 TRX_MYREMOTE1 on
==> TRX_MYREMOTE1-2012.log <== 2012-12-30_21:54:59 TRX_MYREMOTE1 light: off 2012-12-30_21:54:59 TRX_MYREMOTE1 off
PT2262-Format senden
Mit dem Funk-Decoder-IC PT2272 lassen sich Signale von PT2262-Sendern empfangen. RFXtrx433 ist in der Lage Funksignale im PT2262-Format zu senden, die dann mit Geräten empfangen werden können, die über den Funk-Decoder-IC PT2272 verfügen. Dazu ist es nicht erforderlich in RFXmngr das Protokoll Lighting4 einzuschalten.
PT2262-Codes können über ein set-Kommando des vorher zu definierenden PT2262-Devices gesendet werden. Die Definition wurde auch schon bei "PT2262-Format empfangen" beschrieben.
define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]
Beispiel:
define TRX_MYREMOTE1 TRX_LIGHT PT2262 11110111011 light 0:off,1:on
Sobald das Device definiert wurde, kann der Code mittels set gesendet werden. Dabei kann man entweder der Base4-Code direkt angegeben werden oder der String der in <commandcodes> definiert wurde.
Beispiele (senden von 1):
set TRX_MYREMOTE1 1
set TRX_MYREMOTE1 on set TRX_MYREMOTE1 off Damit ein PT2262 Code gesendet werden kann, muss der Base4-Code bestehend aus <deviceid> und den Daten genau 12 Base4-Zeichen haben.
Die mittels <commandcodes> definierten Strings werden in der Auswahlliste von set in der Weboberfläche von FHEM berücksichtigt.
PT2262-Format am Beispiel der Brennenstuhl (RCS 2044 N) Steckdosen
Etwas verwirrend ist die Base-4-Codierung in FHEM und die Binärcodierung im RFXtrx, und weil mich das ein paar Minuten beschäftigt hat, beschreibe ich mal die Vorgehensweise exemplarisch mit dem o.a. Funk-Schaltdosensystem.
Vorbereitung (Hardware einstellen)
Zuallererst muss man sicherstellen, dass der "System-"Code aller Geräte, sprich des Senders und jedes Empfängers gleich ist, das sind die DIP-Switches (aka "Mäuseklavier") 1-5. "ON" ist eine 0, "OFF" eine 1. Dieser Konfiguration werden wir gleich noch begegnen. Stellen Sie also mal gleich alle Geräte auf eine andere Konfiguration als die ausgelieferte (sonst schalten Sie möglicherweise die Steckdosen des netten Nachbars), aber alle Geräte auf die gleiche Konfiguration.
Wer will, teste nun alle Steckdosen, ob sie mit der Fernbedienung schaltbar sind, ob also die Switches alle passen.
Konfiguration für FHEM
Nun zu FHEM: Erst einmal probiert man ja verschiedene Protokolle im RfxMgr. Also den Empfänger an den PC anschließen und im RfxMgr die Verbindung aufbauen. Im User Guide steht, dass das nötige Protokoll Lighting4 ist, also ankreuzen und Set Mode anklicken. Wenn man nun eine Taste der Fernbedienung drückt, kommt so was wie
Packettype = Lighting4 subtype = PT2262 Sequence nbr = 6 Code = 455451 decimal:4543569 S1- S24 = 0100 0101 0101 0100 0101 0001 Pulse = 325 usec Signal level = 7 -64dBm ------------------------------------------------ ------------------------------------------------ Packettype = Lighting4 subtype = PT2262 Sequence nbr = 7 Code = 45555F decimal:4543839 S1- S24 = 0100 0101 0101 0101 0101 1111 Pulse = 324 usec Signal level = 7 -64dBm
Hier kommen meist 2 Meldungen, zuerst das Kommando. Die zweite Meldung kann uns egal sein, sie kommt nicht immer und hat denselben Wert, egal ob eine Steckdose geschaltet wird oder nicht (also kein Fehlerstatus), und egal ob sie ein- oder ausgeschaltet ist.
Decodierung des Systemcodes
Nun steht überall hier im Artikel "12 Base4-Zeichen". Wir haben 24 Binärzeichen. Das läßt sich übersetzen, indem man immer 2 Binärzeichen zu einem Base4-Zeichen zusammenfasst:
0100 0101 0101 0100 0101 0001 1 0 1 1 1 1 1 0 1 1 0 1
nach dem Prinzip: 00 = 0, 01 = 1, 10 = 2, 11 = 3
Und wenn man sich die DIP-Switches anschaut, und den Wert oben (hier "101111101101" durchgeht, fällt einem auf: die ersten 5 Zahlen sind genau die Stellungen der DIP-Switches: 10111 = OFF ON OFF OFF OFF
Und tatsächlich sind diese 5 Zahlen bei allen Tasten gleich: die Decodierung der ersten 5 Zahlen ist geschafft.
Decodierung der Steckdosen-Zuordnung
Dann geht man die verschiedenen Steckdosen-IDs durch, jeweils der "EIN"-Schalter, ergibt (suggestiv formatiert):
EIN=10111 01111 01, AUS=10111 01111 11 (Steckdose 1) EIN=10111 10111 01, AUS=10111 10111 11 (Steckdose 2) EIN=10111 11011 01, AUS=10111 11011 11 (Steckdose 3) EIN=10111 11101 01, AUS=10111 11101 11 (Steckdose 4)
Also sind die nächsten 5 Zahlen die Zuordnung der Steckdosen. Jede Stelle beschreibt den Zustand des passenden DIP-Switches "A" bis "E", wie üblich "0" ist "ON", "1" ist "OFF". Ob die Steckdosen mit mehr als einem auf OFF gelegten "A" bis "E"-Switch funktionieren, habe ich nicht getestet, aber es erscheint logisch, man könnte dann bis zu 32 Steckdosen auf den gleichen Systemcode legen, und ein Nachbar mit Fernbedienung kann nichts Böses anrichten! FHEM kann es egal sein, man kann ja verschiedene Systemcodes angeben, das geht bei der Fernbedienung nicht. Die ausserdem auch nur einen der "A" bis "D"-Switches adressiert.
Ein/Aus-Kommando
Bleiben noch 2 Zahlen. Wenn man auf den "AN"-Taster drückt, ist der Wert "01", bei "AUS" "11". Da hier wieder alles invertiert ist, steht zu vermuten, dass davon nur die erste Zahl den gewünschten Schaltzustand beschreibt, "01" -> "0" -> "EIN". "11" -> "1" -> "AUS". Was die letzte Stelle ist: keine Ahnung.
Geschafft: jetzt ist die Fernbedienung in FHEM folgendermassen zu konfigurieren:
defmod Steckdose_brennenstuhl_aussen TRX_LIGHT PT2262 1011101111 light 01:on,10:off defmod Steckdose_brennenstuhl_1 TRX_LIGHT PT2262 1011110111 light 01:on,10:off defmod Steckdose_brennenstuhl_2 TRX_LIGHT PT2262 1011111011 light 01:on,10:off defmod Steckdose_brennenstuhl_3 TRX_LIGHT PT2262 1011111101 light 01:on,10:off attr Steckdose_brennenstuhl_.* Funksteckdosen,RFXcom
(Natürlich sind die ersten 5 Zahlen bei Ihrem System anders als meine, insbesondere wenn Sie direkt neben mir wohnen, bitte ;))
Hinweis: Man kann natürlich auch bei jeder Steckdose die ersten 5 Switches anders einstellen, also alle 10 Stellen, aber dann kann man die Fernbedienung nicht mehr verwenden, um mehrere zu schalten.
Adventsbeleuchtung gefällig?
define di_adventsbeleuchtung DOIF ([{sunset(-1800)}-24:00]) (set Steckdose_brennenstuhl_aussen on) DOELSE (set Steckdose_brennenstuhl_aussen off) define di_adventsbeleuchtung_2 DOIF ([05:45-{sunrise(+1800)}]) (set Steckdose_brennenstuhl_aussen on) DOELSE (set Steckdose_brennenstuhl_aussen off) define di_adventsbeleuchtung_3 DOIF ([{sunset(-1800)}-01:00]) (set Steckdose_brennenstuhl_1 on) DOELSE (set Steckdose_brennenstuhl_1 off) define di_adventsbeleuchtung_4 DOIF ([05:35-{sunrise(+1800)}]) (set Steckdose_brennenstuhl_1 on) DOELSE (set Steckdose_brennenstuhl_1 off)
Fragen und Antworten (FAQ)
Warum wird mein RFXtrx433 nicht erkannt?
Das Gerät hat einen FTDI-FT232R-USB-Interface-Chip installiert. Um RFXtrx433 nutzen zu können, muss das Betriebssystem einen entsprechenden Treiber für diesen Chip haben. Dies ist normalerweise bei Linux oder Fritzbox 7390 der Fall. Bei 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!