From d5fd5cef3da4bb7ddee0c12e5b0067f7bdd5cb1c Mon Sep 17 00:00:00 2001
From: wherzig <wherzig@2b470e98-0d58-463d-a4d8-8e2adae1ed80>
Date: Fri, 24 Feb 2012 17:56:06 +0000
Subject: [PATCH] new module TRX added

git-svn-id: https://fhem.svn.sourceforge.net/svnroot/fhem/trunk/fhem@1280 2b470e98-0d58-463d-a4d8-8e2adae1ed80
---
 docs/commandref.html | 300 ++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 285 insertions(+), 15 deletions(-)

diff --git a/docs/commandref.html b/docs/commandref.html
index a18ff92ce..57fcd1934 100644
--- a/docs/commandref.html
+++ b/docs/commandref.html
@@ -117,6 +117,10 @@
       <a href="#SIS_PMS">SIS_PMS</a> &nbsp;
       <a href="#TCM">TCM</a> &nbsp;
       <a href="#TellStick">TellStick</a> &nbsp;
+      <a href="#TRX">TRX</a> &nbsp;
+      <a href="#TRX_LIGHT">TRX_LIGHT</a> &nbsp;
+      <a href="#TRX_SECURITY">TRX_SECURITY</a> &nbsp;
+      <a href="#TRX_WEATHER">TRX_WEATHER</a> &nbsp;
       <a href="#TUL">TUL</a> &nbsp;
       <a href="#USF1000">USF1000</a> &nbsp;
       <a href="#USBWX">USBWX</a> &nbsp;
@@ -5650,7 +5654,6 @@ audio</pre>
     &lt;deviceid&gt; is the device identifier of the Oregon sensor. It consists of the sensors name and a one byte hex string (00-ff) that identifies the sensor. The define statement with the deviceid is generated automatically by autocreate. The following sensor names are used:
 BTHR918, BTHR918N, PCR800 RGR918, RTGR328N, THN132N, THGR228N, THGR328N, THGR918, THR128, THWR288A, THGR810, UV138, UVN800, WGR918, WGR800, WTGR800_A, WTGR800_T.
     <br>
-The one byte hex string is generated by the Oregon sensor when is it powered on. The value seems to be randomly generated. This has the advantage that you may use more than one Oregon sensor of the same type even if it has no switch to set a sensor id. For exampple the author uses three BTHR918 sensors at the same time. All have different deviceids. The drawback is that the deviceid changes after changing batteries.
     <br><br>
       Example: <br>
     <code>define Kaminzimmer OREGON BTHR918N_ab</code>
@@ -5925,22 +5928,17 @@ The one byte hex string is generated by the Oregon sensor when is it powered on.
 <ul>
   <table>
   <tr><td>
-  <a href="http://www.rfxcom.com">RFXCOM</a> sells RF receivers and transmitters
-  for a variety of protocols. The 433.92MHz receivers supports many protocols like Oregon Scientific weather sensors, RFXMeter devices, X10 security and lightning devices adn others. <br>
-  <br>
-  This module supports receiving messages for the USB attached receivers (see <a href="http://www.rfxcom.com/receivers.htm">http://www.rfxcom.com/receivers.htm</a>).
-  For testing purposes you may also use the LAN based receivers. However
-  the code for LAN access is not fault tolerant. I recommend to use the USB attached receiver.<br>
-  <br>
+  This module is for the old <a href="http://www.rfxcom.com">RFXCOM</a> USB or LAN based 433 Mhz RF receivers and transmitters (order order code 80002 and others). It does not support the new RFXtrx433 transmitter because it uses a different protocol. See <a href="#RFXTRX">RFXTRX</a> for support of the RFXtrx433 transmitter.<br>
+These receivers supports many protocols like Oregon Scientific weather sensors, RFXMeter devices, X10 security and lighting devices and others. <br>
   Currently the following parser modules are implemented: <br>
     <ul>
     <li> 41_OREGON.pm (see device <a href="#OREGON">OREGON</a>): Process messages Oregon Scientific weather sensors.
   See <a href="http://www.rfxcom.com/oregon.htm">http://www.rfxcom.com/oregon.htm</a> of
-  Oregon Scientific weather sensors that could be received by the RFXCOM receivers. See <a href="http://www.rfxcom.com/sensors.htm">http://www.rfxcom.com/sensors.htm</a>.
-  Until now the following Oregon Scientific weather sensors have been tested successfully: BTHR918N, THGR810, THR128, THWR288A, PCR800, WTGR800. It will probably work with many other Oregon sensors supported by RFXCOM receivers. Please give feedback if you use other sensors.<br>
+  Oregon Scientific weather sensors that could be received by the RFXCOM receivers. 
+  Until now the following Oregon Scientific weather sensors have been tested successfully: BTHR918, BTHR918N, PCR800, RGR918, THGR228N, THGR810, THR128, THWR288A, WTGR800, WGR918. It will probably work with many other Oregon sensors supported by RFXCOM receivers. Please give feedback if you use other sensors.<br>
     </li>
-    <li> 42_RFXMETER.pm (see device <a href="#RFXMETER">RFXMETER</a>): Process RFXCOM RFXMeter devices. </li>
-    <li> 43_RFXX10REC.pm (see device <a href="#RFXX10REC">RFXX10REC</a>): Process X10 security and X10 lightning devices. </li>
+    <li> 42_RFXMETER.pm (see device <a href="#RFXMETER">RFXMETER</a>): Process RFXCOM RFXMeter devices. See <a href="http://www.rfxcom.com/sensors.htm">http://www.rfxcom.com/sensors.htm</a>.</li>
+    <li> 43_RFXX10REC.pm (see device <a href="#RFXX10REC">RFXX10REC</a>): Process X10 security and X10 lighting devices. </li>
     <li> 44_RFXELSE.pm: Process and display all other messages. This module shows you messages that could not be handled by the other modules. It is useful to see RF receiption problems.</li>
     </ul>
   <br>
@@ -6021,7 +6019,7 @@ The one byte hex string is generated by the Oregon sensor when is it powered on.
 <a name="RFXX10REC"></a>
 <h3>RFXX10REC</h3>
 <ul>
-  The RFXX10REC module interprets X10 security and X10 lightning messages received by a RFXCOM RF receiver. Reported also to work with KlikAanKlikUit. You need to define an RFXCOM receiver first.
+  The RFXX10REC module interprets X10 security and X10 lighting messages received by a RFXCOM RF receiver. Reported also to work with KlikAanKlikUit. You need to define an RFXCOM receiver first.
   See <a href="#RFXCOM">RFXCOM</a>.
 
   <br><br>
@@ -6041,7 +6039,7 @@ The one byte hex string is generated by the Oregon sensor when is it powered on.
           <li> <code>sd90</code> (Marmitek sd90 smoke detector. This device type reports the status of the smoke detector [normal|alert] and battery status [ok|low].)</li>
           <li> <code>kr18</code> (X10 security remote control. Report the Reading "Security" with values [Arm|Disarm], "ButtonA" and "ButtonB" with values [on|off] )</li>
         </ul>
-    X10 lightning devices:
+    X10 lighting devices:
         <ul>
           <li> <code>ms14a</code> (X10 motion sensor. Reports [normal|alert] on the first deviceid (motion sensor) and [on|off] for the second deviceid (light sensor)) </li>
           <li> <code>x10</code> (All other x10 devices. Report [on|off] on both deviceids.)</li>
@@ -6051,7 +6049,7 @@ The one byte hex string is generated by the Oregon sensor when is it powered on.
     <code>&lt;deviceid&gt;</code>
     <ul>
     specifies the first device id of the device. X10 security have a a 16-Bit device id which has to be written as a hex-string (example "5a54").
-    A X10 lightning device has a house code A..P followed by a unitcode 1..16 (example "B1").
+    A X10 lighting device has a house code A..P followed by a unitcode 1..16 (example "B1").
     </ul>
     <br>
     <code>&lt;devicelog&gt;</code>
@@ -6916,6 +6914,278 @@ href="http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=29870">U
   <br>
 </ul>
 
+<a name="TRX"></a>
+<h3>TRX</h3>
+<ul>
+  <table>
+  <tr><td>
+  This module is for the <a href="http://www.rfxcom.com">RFXCOM</a> RFXtrx433 USB based 433 Mhz RF transmitters. 
+This USB based transmitter is able to receive and transmit many protocols like Oregon Scientific weather sensors, X10 security and lighting devices, ARC ((address code wheels) HomeEasy, KlikAanKlikUit, ByeByeStandBy, Intertechno, ELRO,
+AB600, Duewi, DomiaLite, COCO) and others. <br>
+  Currently the following parser modules are implemented: <br>
+    <ul>
+    <li> 46_TRX_WEATHER.pm (see device <a href="#TRX">TRX</a>): Process messages Oregon Scientific weather sensors.
+  See <a href="http://www.rfxcom.com/oregon.htm">http://www.rfxcom.com/oregon.htm</a> for a list of
+  Oregon Scientific weather sensors that could be received by the RFXtrx433 tranmitter. 
+  Until now the following Oregon Scientific weather sensors have been tested successfully: BTHR918, BTHR918N, PCR800, RGR918, THGR228N, THGR810, THR128, THWR288A, WTGR800, WGR918. It will also work with many other Oregon sensors supported by RFXtrx433. Please give feedback if you use other sensors.<br>
+    </li>
+    <li> 46_TRX_SECURITY.pm (see device <a href="#TRX_SECURITY">TRX_SECURITY</a>): Receive X10, KD101 and Visonic security sensors.</li>
+    <li> 46_TRX_LIGHT.pm (see device <a href="#RFXX10REC">RFXX10REC</a>): Process X10, ARC, ELRO AB400D, Waveman, Chacon EMW200 and IMPULS lighting devices (switches and remote control). ARC is a protocol used by devices from HomeEasy, KlikAanKlikUit, ByeByeStandBy, Intertechno, ELRO, AB600, Duewi, DomiaLite and COCO with address code wheels. </li>
+    <li> 46_TRX_ELSE.pm: Process and display all other messages. This module shows you messages that could not be handled by the other modules. It is useful to see RF receiption problems.</li>
+    </ul>
+  <br>
+  Note: this module requires the Device::SerialPort or Win32::SerialPort module
+  if the devices is connected via USB or a serial port.
+  <br><br>
+ <a name="TRXdefine"></a>
+  <b>Define</b>
+  <ul>
+    <code>define &lt;name&gt; TRX &lt;device&gt; [noinit] </code><br>
+  </ul>
+    <br>
+    USB-connected:<br><ul>
+      &lt;device&gt; specifies the USB port to communicate with the RFXtrx433 receiver.
+      Normally on Linux the device will be named /dev/ttyUSBx, where x is a number.
+      For example /dev/ttyUSB0.<br>
+      <br>
+      Example: <br>
+    <code>define RFXTRXUSB TRX /dev/ttyUSB0</code>
+      <br>
+     </ul>
+    <br>
+    Network-connected devices:
+    <br><ul>
+    &lt;device&gt; specifies the host:port of the device. E.g.
+    192.168.1.5:10001
+    </ul>
+    <ul>
+    noninit is optional and issues that the RFXtrx433 device should not be initialized. This is useful if you share a RFXtrx433 device via LAN. It is also useful for testing to simulate a RFXtrx433 receiver via netcat.
+      <br>
+      <br>
+      Example: <br>
+    <code>define RFXTRXTCP TRX 192.168.1.5:10001
+    <br>
+    <code>define RFXTRXTCP2 TRX 192.168.1.121:10001 noinit
+      <br>
+    </ul>
+    <br>
+  </table>
+
+  <a name="TRXattr"></a>
+  <b>Attributes</b>
+  <ul>
+    <li><a href="#attrdummy">dummy</a></li><br>
+    <li>longids<br>
+        Comma separates list of device-types for TRX_WEATHER that should be handles using long ids. This additional ID is a one byte hex string and is generated by the Oregon sensor when is it powered on. The value seems to be randomly generated. This has the advantage that you may use more than one Oregon sensor of the same type even if it has no switch to set a sensor id. For example the author uses two BTHR918N sensors at the same time. All have different deviceids. The drawback is that the deviceid changes after changing batteries.
+      <br>
+      Example: <br>
+      <code>attr RFXTRXUSB longids BTHR918N</code>
+    </li><br>
+  </ul>
+
+  <br>
+</ul>
+
+<a name="TRX_SECURITY"></a>
+<h3>TRX_SECURITY</h3>
+<ul>
+  The TRX_SECURITY module interprets X10, KD101 and Visonic security sensors received by a RFXCOM RFXtrx433 RF receiver. You need to define an RFXtrx433 receiver first. See <a href="#TRX">TRX</a>.
+
+  <br><br>
+
+  <a name="TRX_SECURITYdefine"></a>
+  <b>Define</b>
+  <ul>
+    <code>define &lt;name&gt; TRX_SECURITY &lt;type&gt; &lt;deviceid&gt; &lt;devicelog&gt; [&lt;deviceid&gt; &lt;devicelog&gt;] </code> <br>
+    <br>
+    <code>&lt;type&gt;</code>
+    <ul>
+      specifies one of the following security devices:
+        <ul>
+          <li> <code>DS10A</code> (X10 security ds10a Door/Window Sensor or compatible devices. This device type reports the status of the switch [Open/Closed], status of the delay switch [min|max]], and battery status [ok|low].)</li>
+          <li> <code>MS10A</code> (X10 security ms10a motion sensor. This device type reports the status of motion sensor  [normal|alert] and battery status [ok|low].))</li>
+          <li> <code>SD90</code> (Marmitek sd90 smoke detector. This device type reports the status of the smoke detector [normal|alert] and battery status [ok|low].)</li>
+          <li> <code>KR18</code> (X10 security remote control. Report the Reading "Security" with values [Arm|Disarm], "ButtonA" and "ButtonB" with values [on|off] )</li>
+          <li> <code>KD101</code> (KD101 smoke sensor. Report the Reading "smoke" with values [normal|alert])</li>
+          <li> <code>VISONIC_WINDOW</code> (VISONIC security Door/Window Sensor or compatible devices. This device type reports the status of the switch [Open/Closed] and battery status [ok|low].)</li>
+          <li> <code>VISONIC_MOTION</code> (VISONIC security motion sensor. This device type reports the status of motion sensor  [normal|alert] and battery status [ok|low].))</li>
+        </ul>
+    </ul>
+    <br>
+    <code>&lt;deviceid&gt;</code>
+    <ul>
+    specifies the first device id of the device. X10 security (DS10A, MS10A) and SD90 have a a 16 bit device id which has to be written as a hex-string (example "5a54"). All other devices have a 24 bit device id.
+    </ul>
+    <br>
+    <code>&lt;devicelog&gt;</code>
+    <ul>
+    is the name of the Reading used to report. Suggested: "Window" or "Door" for ds10a, "motion" for motion sensors, "smoke" for sd90.
+    </ul>
+    <br>
+    <code>&lt;deviceid2&gt;</code>
+    <ul>
+    is optional and specifies the second device id of the device if it exists. For example sd90 smoke sensors can be configured to report two device ids. 
+    </ul>
+    <br>
+    <code>&lt;devicelog2&gt;</code>
+    <ul>
+    is optional for the name used for the Reading of <code>&lt;deviceid2&gt;</code>.
+    </ul>
+    <br>
+      Example: <br>
+    <code>define livingroom_window TRX_SECURITY ds10a 72cd Window</code>
+      <br>
+    <code>define motion_sensor1 TRX_SECURITY ms10a 55c6 motion</code>
+      <br>
+    <code>define smoke_sensor1 TRX_SECURITY sd90 54d3 Smoke 54d3 Smoketest</code>
+      <br>
+  </ul>
+  <br>
+
+  <a name="TRX_SECURITYset"></a>
+  <b>Set</b> <ul>N/A</ul><br>
+
+  <a name="TRX_SECURITYget"></a>
+  <b>Get</b> <ul>N/A</ul><br>
+</ul>
+
+<a name="TRX_LIGHT"></a>
+<h3>TRX_LIGHT</h3>
+<ul>
+  The TRX_LIGHT module receives and sends X10, ARC, ELRO AB400D, Waveman, Chacon EMW200 and IMPULS lighting messages by a RFXtrx433 RF transceiver. ARC is a protocol used by devices from HomeEasy, KlikAanKlikUit, ByeByeStandBy, Intertechno, ELRO, AB600, Duewi, DomiaLite and COCO with address code wheels. <br> You need to define an RFXtrx433 transceiver receiver first.
+  See <a href="#TRX">TRX</a>.
+
+  <br><br>
+
+  <a name="TRX_LIGHTdefine"></a>
+  <b>Define</b>
+  <ul>
+    <code>define &lt;name&gt; TRX_LIGHT &lt;type&gt; &lt;deviceid&gt; &lt;devicelog&gt; [&lt;deviceid&gt; &lt;devicelog&gt;] </code> <br>
+    <br>
+    <code>&lt;type&gt;</code>
+    <ul>
+      specifies the type of the device: <br>
+    X10 lighting devices:
+        <ul>
+          <li> <code>MS14A</code> (X10 motion sensor. Reports [normal|alert] on the first deviceid (motion sensor) and [on|off] for the second deviceid (light sensor)) </li>
+          <li> <code>X10</code> (All other x10 devices. Report [on|off] on both deviceids.)</li>
+          <li> <code>ARC</code> (ARC devices. ARC is a protocol used by devices from HomeEasy, KlikAanKlikUit, ByeByeStandBy, Intertechno, ELRO, AB600, Duewi, DomiaLite and COCO with address code wheels. Report [on|off] on both deviceids.)</li>
+          <li> <code>AB400D</code> (ELRO AB400D devices. Report [on|off] on both deviceids.)</li>
+          <li> <code>WAVEMAN</code> (Waveman devices. Report [on|off] on both deviceids.)</li>
+          <li> <code>EMW200</code> (Chacon EMW200 devices. Report [on|off] on both deviceids.)</li>
+          <li> <code>IMPULS</code> (IMPULS devices. Report [on|off] on both deviceids.)</li>
+        </ul>
+    </ul>
+    <br>
+    <code>&lt;deviceid&gt;</code>
+    <ul>
+    specifies the first device id of the device. 
+    A lighting device has a house code A..P followed by a unitcode 1..16 (example "B1").
+    </ul>
+    <br>
+    <code>&lt;devicelog&gt;</code>
+    <ul>
+    is the name of the Reading used to report. Suggested: "motion" for motion sensors.
+    </ul>
+    <br>
+    <code>&lt;deviceid2&gt;</code>
+    <ul>
+    is optional and specifies the second device id of the device if it exists. For example ms14a motion sensors report motion status on the first deviceid and the status of the light sensor on the second deviceid.
+    </ul>
+    <br>
+    <code>&lt;devicelog2&gt;</code>
+    <ul>
+    is optional for the name used for the Reading of <code>&lt;deviceid2&gt;</code>.
+    </ul>
+    <br>
+      Example: <br>
+    	<code>define motion_sensor2 TRX_LIGHT MS14A A1 motion A2 light</code>
+	<br>
+    	<code>define Steckdose TRX_LIGHT ARC G2 light</code>
+      <br>
+  </ul>
+  <br>
+
+  <a name="TRX_LIGHTset"></a>
+  <b>Set </b>
+  <ul>
+    <code>set &lt;name&gt; &lt;value&gt;</code>
+    <br><br>
+    where <code>value</code> is one of:<br>
+    <pre>
+    off
+    on                 
+    dim                # only for X10
+    bright             # only for X10
+    all_off            # only for X10, ARC, EMW200
+    all_on             # only for X10, ARC, EMW200
+    chime              # only for ARC
+    </pre>
+      Example: <br>
+    	<code>set Steckdose on</code>
+      <br>
+  </ul><br>
+
+  <a name="TRX_LIGHTget"></a>
+  <b>Get</b> <ul>N/A</ul><br>
+</ul>
+
+<a name="TRX_WEATHER"></a>
+<h3>TRX_WEATHER</h3>
+<ul>
+  The TRX_WEATHER module interprets weather sensor messages received by a RTXtrx receiver. See <a href="http://www.rfxcom.com/oregon.htm">http://www.rfxcom.com/oregon.htm</a> for a list of
+  Oregon Scientific weather sensors that could be received by the RFXtrx433 tranmitter. You need to define a RFXtrx433 receiver first. See 
+  See <a href="#TRX">TRX</a>.
+
+  <br><br>
+
+  <a name="TRX_WEATHERdefine"></a>
+  <b>Define</b>
+  <ul>
+    <code>define &lt;name&gt; OREGON &lt;deviceid&gt;</code> <br>
+    <br>
+    &lt;deviceid&gt; is the device identifier of the Oregon sensor. It consists of the sensors name and (only if the attribute longids is set of the RFXtrx433) an a one byte hex string (00-ff) that identifies the sensor. If an sensor uses an switch to set an additional is then this is also added. The define statement with the deviceid is generated automatically by autocreate. The following sensor names are used: <br>
+	"THR128" (for THR128/138, THC138),<br>
+	"THGR132N" (for THC238/268,THN132,THWR288,THRN122,THN122,AW129/131),<br>
+	"THWR800", <br>
+	"RTHN318", <br>
+	"TX3_T" (for LaCrosse TX3, TX4, TX17),<br>
+	"THGR228N" (for THGN122/123, THGN132, THGR122/228/238/268),<br>
+	"THGR810",<br>
+	"RTGR328",<br>
+	"THGR328",<br>
+	"WTGR800_T" (for temperature of WTGR800),<br> 
+	"THGR918" (for THGR918, THGRN228, THGN500),<br>
+	"TFATS34C" (for TFA TS34C),<br>
+	"BTHR918",<br>
+	"BTHR918N (for BTHR918N, BTHR968),<br>
+	"RGR918" (for RGR126/682/918),<br>
+	"PCR800",<br>
+	"TFA_RAIN" (for TFA rain sensor),<br>
+	"WTGR800_A" (for wind sensor of WTGR800),<br>
+	"WGR800_A" (for wind sensor of WGR800),<br>
+	"WGR918_A" (for wind sensor of STR918 and WGR918),<br>
+	"TFA_WIND" (for TFA wind sensor)
+    <br>
+    <br><br>
+      Example: <br>
+    <code>define Tempsensor TRX_WEATHER TX3_T</code><br>
+    <code>define Tempsensor3 TRX_WEATHER THR128_3</code><br>
+    <code>define Windsensor TRX_WEATHER WGR918_A</code><br>
+    <code>define Regensensor TRX_WEATHER RGR918</code><br>
+  </ul>
+  <br>
+
+  <a name="OREGONset"></a>
+  <b>Set</b> <ul>N/A</ul><br>
+
+  <a name="OREGONget"></a>
+  <b>Get</b> <ul>N/A</ul><br>
+  <br>
+</ul>
+
+
+
 <a name="TUL"></a>
 <h3>TUL</h3>
 <ul>