RFXCOM sells RF receivers and transmitters
- for a variety of protocols. The 433.92MHz receivers supports many Oregon Scientific weather sensors and RFXMeter devices.
+ 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.
- This module supports receiving messages for the USB attached receivers (Order code: 80002, see http://www.rfxcom.com/receivers.htm).
+ This module supports receiving messages for the USB attached receivers (see http://www.rfxcom.com/receivers.htm).
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.
+ the code for LAN access is not fault tolerant. I recommend to use the USB attached receiver.
- 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.
+ Currently the following parser modules are implemented:
+
+ - 41_OREGON.pm (see device OREGON): Process messages Oregon Scientific weather sensors.
See http://www.rfxcom.com/oregon.htm of
- Oregon Scientific weather sensors that could be received by the RFXCOM receivers. See http://www.rfxcom.com/sensors.htm 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 Perl xPL
- project parsing modules. Thanks to Mark Hindess from the xPL project for writing this code.
+ Oregon Scientific weather sensors that could be received by the RFXCOM receivers. See http://www.rfxcom.com/sensors.htm.
+ 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.
+
+ - 42_RFXMETER.pm (see device RFXMETER): Process RFXCOM RFXMeter devices.
+ - 43_RFXX10REC.pm (see device RFXX10REC): Process X10 security and X10 lightning devices.
+ - 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.
+
- 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.
Define
@@ -4655,6 +4658,76 @@ The one byte hex string is generated by the Oregon sensor when is it powered on.
Get
+
+RFXX10REC
+
+ 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 RFXCOM.
+
+
+
+
+ Define
+
+ define <name> RFXX10REC <type> <deviceid> <devicelog> [<deviceid> <devicelog>]
+
+ <type>
+
+ specifies the type of the X10 device:
+ X10 security devices:
+
+ -
ds10a (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].)
+ -
ms10a (X10 security ms10a motion sensor. This device type reports the status of motion sensor [normal|alert] and battery status [ok|low].))
+ -
sd90 (Marmitek sd90 smoke detector. This device type reports the status of the smoke detector [normal|alert] and battery status [ok|low].)
+ -
kr18 (X10 security remote control. Report the Reading "Security" with values [Arm|Disarm], "ButtonA" and "ButtonB" with values [on|off] )
+
+ X10 lightning devices:
+
+ -
ms14a (X10 motion sensor. Reports [normal|alert] on the first deviceid (motion sensor) and [on|off] for the second deviceid (light sensor))
+ -
x10 (All other x10 devices. Report [on|off] on both deviceids.)
+
+
+
+ <deviceid>
+
+ 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").
+
+
+ <devicelog>
+
+ is the name of the Reading used to report. Suggested: "Window" or "Door" for ds10a, "motion" for motion sensors, "Smoke" for sd90.
+
+
+ <deviceid2>
+
+ 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.
+
+
+ <devicelog2>
+
+ is optional for the name used for the Reading of <deviceid2>.
+
+
+ Example:
+ define livingroom_window RFXX10REC ds10a 72cd Window
+
+ define motion_sensor1 RFXX10REC ms10a 55c6 motion
+
+ define smoke_sensor1 RFXX10REC sd90 54d3 Smoke 54d3 Smoketest
+
+ define motion_sensor2 RFXX10REC ms14a A1 motion A2 light
+
+
+
+
+
+ Set
+
+
+ Get
+
+
structure
|