FHEM/fhem-mirror
2
0
Fork 0
mirror of https://github.com/fhem/fhem-mirror.git synced 2025-05-05 02:19:31 +00:00
Code Issues Releases Wiki Activity

Added description for new module RFXX10REC: RFXCOM X10 security and light receiving support

Browse Source 
git-svn-id: https://svn.fhem.de/fhem/trunk@832 2b470e98-0d58-463d-a4d8-8e2adae1ed80
This commit is contained in:
wherzig 2011-02-05 20:48:46 +00:00
parent 3a35d0b320
commit dfb5376ed1
1 changed files with 85 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

97
fhem/docs/commandref.html
View File

@ -106,6 +106,7 @@
<a href="#OWTEMP">OWTEMP</a> &nbsp;
<a href="#RFXCOM">RFXCOM</a> &nbsp;
<a href="#RFXMETER">RFXMETER</a> &nbsp;
<a href="#RFXX10REC">RFXX10REC</a> &nbsp;
<a href="#SCIVT">SCIVT</a> &nbsp;
<a href="#SISPM">SISPM</a> &nbsp;
<a href="#SIS_PMS">SIS_PMS</a> &nbsp;
@ -4279,7 +4280,7 @@ audio</pre>
<h3>OREGON</h3>
<ul>
The OREGON module interprets Oregon sensor messages received by a RFXCOM receiver. You need to define a RFXCOM receiver first.
See the <a href="#RFXCOM">RFXCOM</a>.
See <a href="#RFXCOM">RFXCOM</a>.
<br><br>
@ -4567,22 +4568,24 @@ The one byte hex string is generated by the Oregon sensor when is it powered on.
<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 Oregon Scientific weather sensors and RFXMeter devices. <br>
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 (Order code: 80002, see <a href="http://www.rfxcom.com/receivers.htm">http://www.rfxcom.com/receivers.htm</a>).
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 still in beta stage and not fault tolerant. Therefore you should use the USB attached receiver.<br>
the code for LAN access is not fault tolerant. I recommend to use the USB attached receiver.<br>
<br>
Currently two parser modules (41_OREGON.pm and 42_RFXMETER.pm) are implemented to parse and process messages for
Oregon Scientific weather sensors and RFXCOM RFXMeter devices. If you need to process other devices that are supported
by RFXCOM, you have to implement a new parsing module.<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> for RFXMeter device.
Please note that not all Oregon sensors are currently implemented in the parser module right now.
The parsing modules are based on the <a href="http://www.xpl-perl.org.uk/">Perl xPL</a>
project parsing modules. Thanks to Mark Hindess from the xPL project for writing this code. <br>
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>
</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> 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>
Until now the following Oregon Scientific weather sensors have been tested successfully: BTHR918N, THGR810, THR128, THWR288A, PCR800, WTGR800. Please give feedback if you use other sensors.<br>
<br>
<a name="RFXCOMdefine"></a>
<b>Define</b>
@ -4655,6 +4658,76 @@ The one byte hex string is generated by the Oregon sensor when is it powered on.
<b>Get</b> <ul>N/A</ul><br>
</ul>
<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.
See <a href="#RFXCOM">RFXCOM</a>.
<br><br>
<a name="RFXX10RECdefine"></a>
<b>Define</b>
<ul>
<code>define &lt;name&gt; RFXX10REC &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 X10 device: <br>
X10 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>
</ul>
X10 lightning 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>
</ul>
</ul>
<br>
<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").
</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. 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 livingroom_window RFXX10REC ds10a 72cd Window</code>
<br>
<code>define motion_sensor1 RFXX10REC ms10a 55c6 motion</code>
<br>
<code>define smoke_sensor1 RFXX10REC sd90 54d3 Smoke 54d3 Smoketest</code>
<br>
<code>define motion_sensor2 RFXX10REC ms14a A1 motion A2 light</code>
<br>
</ul>
<br>
<a name="RFXX10RECset"></a>
<b>Set</b> <ul>N/A</ul><br>
<a name="RFXX10RECget"></a>
<b>Get</b> <ul>N/A</ul><br>
</ul>
<a name="structure"></a>
<h3>structure</h3>
<ul>