mirror of
https://github.com/fhem/fhem-mirror.git
synced 2025-03-13 17:26:34 +00:00
New module RFXmeter. Added descriptions of RFXmeter and OREGON defines
git-svn-id: https://svn.fhem.de/fhem/trunk@793 2b470e98-0d58-463d-a4d8-8e2adae1ed80
This commit is contained in:
parent
ebeb3c72a7
commit
1a5343bb2f
@ -98,9 +98,11 @@
|
||||
<a href="#M232">M232</a>
|
||||
<a href="#M232Counter">M232Counter</a>
|
||||
<a href="#M232Voltage">M232Voltage</a>
|
||||
<a href="#OREGON">OREGON</a>
|
||||
<a href="#OWFS">OWFS</a>
|
||||
<a href="#OWTEMP">OWTEMP</a>
|
||||
<a href="#RFXCOM">RFXCOM</a>
|
||||
<a href="#RFXMETER">RFXMETER</a>
|
||||
<a href="#SCIVT">SCIVT</a>
|
||||
<a href="#SISPM">SISPM</a>
|
||||
<a href="#SIS_PMS">SIS_PMS</a>
|
||||
@ -3891,6 +3893,38 @@ audio</pre>
|
||||
<br>
|
||||
</ul>
|
||||
|
||||
<a name="OREGON"></a>
|
||||
<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>.
|
||||
|
||||
<br><br>
|
||||
|
||||
<a name="OREGONdefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> OREGON <deviceid></code> <br>
|
||||
<br>
|
||||
<deviceid> 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>
|
||||
<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="OWFS"></a>
|
||||
<h3>OWFS</h3>
|
||||
<ul>
|
||||
@ -4151,46 +4185,94 @@ audio</pre>
|
||||
<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 support many Oregon Scientific weather sensors. <br>
|
||||
for a variety of protocols. The 433.92MHz receivers supports many Oregon Scientific weather sensors and RFXMeter devices. <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>).
|
||||
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>
|
||||
<br>
|
||||
Currently one parser module (41_Oregon.pm) is implemented to parse and process messages for
|
||||
Oregon Scientific weather sensors. If you need to process other devices that are supported
|
||||
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>
|
||||
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.
|
||||
Please note that not all sensors are currently implemented in the parser module right now.
|
||||
The parsing module ist based on the <a href="http://www.xpl-perl.org.uk/">Perl xPL</a>
|
||||
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>
|
||||
<br>
|
||||
Until now the following Oregon Scientific weather sensors have been tested: BTHR918N, THGR810, THR128, THWR288A, WTGR800. <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>
|
||||
<ul>
|
||||
<code>define <name> RFXCOM <device> </code><br>
|
||||
<code>define <name> RFXCOM <device> [noinit] </code><br>
|
||||
</ul>
|
||||
<br>
|
||||
USB-connected (80002):<br><ul>
|
||||
<device> specifies the USB port to communicate with the RFXCOM receiver.
|
||||
Normally on Linux the device will be named /dev/ttyUSBx, where x is a number.
|
||||
For example /dev/ttyUSB0.<br><br>
|
||||
For example /dev/ttyUSB0.<br>
|
||||
<br>
|
||||
Example: <br>
|
||||
<code>define RFXCOMUSB RFXCOM /dev/ttyUSB0</code>
|
||||
<br>
|
||||
</ul>
|
||||
<br>
|
||||
Network-connected devices:<br><ul>
|
||||
<br>
|
||||
Network-connected devices:
|
||||
<br><ul>
|
||||
<device> specifies the host:port of the device. E.g.
|
||||
192.168.1.5:10001
|
||||
</ul>
|
||||
<ul>
|
||||
noninit is optional and issues that the RFXCOM device should not be initialized. This is useful if you share a RFXCOM device. It is also useful for testing to simulate a RFXCOM receiver via netcat.
|
||||
<br>
|
||||
<br>
|
||||
Example: <br>
|
||||
<code>define RFXCOMTCP RFXCOM 192.168.1.5:10001
|
||||
<br>
|
||||
<code>define RFXCOMTCP2 RFXCOM 192.168.1.121:10001 noinit
|
||||
<br>
|
||||
</ul>
|
||||
<br>
|
||||
</table>
|
||||
</ul>
|
||||
|
||||
<a name="RFXMETER"></a>
|
||||
<h3>RFXMETER</h3>
|
||||
<ul>
|
||||
The RFXMETER module interprets RFXCOM RFXMeter messages received by a RFXCOM receiver. You need to define an RFXCOM receiver first.
|
||||
See the <a href="#RFXCOM">RFXCOM</a>.
|
||||
|
||||
<br><br>
|
||||
|
||||
<a name="RFXMETERdefine"></a>
|
||||
<b>Define</b>
|
||||
<ul>
|
||||
<code>define <name> RFXMETER <deviceid> [<scalefactor>] [<unitname>]</code> <br>
|
||||
<br>
|
||||
<deviceid> is the device identifier of the RFXMeter sensor and is a one byte hexstring (00-ff).
|
||||
<br>
|
||||
<scalefactor> is an optional scaling factor. It is multiplied to the value that is received from the RFXmeter sensor.
|
||||
<br>
|
||||
<unitname> is an optional string that describes the value units. It is added to the Reading generated to describe the values.
|
||||
<br><br>
|
||||
Example: <br>
|
||||
<code>define RFXWater RFXMETER 00 0.5 ltr</code>
|
||||
<br>
|
||||
<code>define RFXPower RFXMETER 01 0.001 kwh</code>
|
||||
<br>
|
||||
<code>define RFXGas RFXMETER 02 0.01 cu_m</code>
|
||||
<br>
|
||||
</ul>
|
||||
<br>
|
||||
|
||||
<a name="RFXMETERset"></a>
|
||||
<b>Set</b> <ul>N/A</ul><br>
|
||||
|
||||
<a name="RFXMETERget"></a>
|
||||
<b>Get</b> <ul>N/A</ul><br>
|
||||
</ul>
|
||||
|
||||
<a name="structure"></a>
|
||||
<h3>structure</h3>
|
||||
<ul>
|
||||
|
Loading…
x
Reference in New Issue
Block a user