Manual Reference Pages - X10AUX (5)
x10aux - Auxiliary input to Heyu via RF
Security Functions And Flags
Special Ds90/ds18-1 Setup
Special Sd90 Setup
Special Bwr102 Setup
Heyu is a program for controlling an X-10 "CM11A" home control device.
See the heyu(1) man page for usage information.
This page contains information about the capability of Heyu to receive
and process signals from RF remotes and sensors using a WGL W800RF32A, an
X-10 MR26A, or an RFXCOM X10 RF receiver connected to a second serial port,
or an RFXLAN network version of the RFXCOM connected to a local network.
The W800RF32A is manufactured by WGL & Associates (http://www.wgldesigns.com).
Two models are available - the US/Canada model operates at a frequency
of 310 MHz and the International model (W800RF32AE) at 433.92 MHz.
It is capable of receiving signals from standard X10 RF remotes and
sensors like the X-10 HR12A "PalmPad", from security X10 remotes and sensors
like the X-10 DS10A Door/Window Sensor, and from older entertainment X-10
remotes like the UR81A Universal Remote which are designed to be used
in conjunction with an X-10 MR26A Receiver. Its receiving range is
The X-10 MR26A is capable of receiving standard X10 and the older entertainment
X10 signals, but not the security X10 signals. Its receiving range is
somewhat limited, perhaps 20-30 feet.
The RFXCOM X10 receiver (http://www.rfxcom.com) is available in a US/Canada 310MHz
version, an International 433.92 MHz version, and a dual-frequency version.
All versions receive signals from standard, entertainment, and security RF
remotes and sensors (which transmit at their frequency). The 433.92 MHz and
dual-frequency versions can additionally receive signals from various other
sensors like Oregon Temperature/Humidity/Barometric Pressure sensors.
The RFXCOM X10 receiver is supported by Heyu in both variable length packet and
32 bit (W800 emulation) modes.
The RFXCOM is a USB device but has a built-in FTDI USB-to-Serial converter
and communication with it is the same as with a serial port (assuming your
OS supports the FTDI chipset, as does Linux).
All of these devices are strictly RF receivers and have no transmitting
The RFXLAN version of the RFXCOM receiver connects to a local network
and is accessible over a TCP socket. Its optional transmitter part, if present,
is not supported.
Stop Heyu (if already running) with the command heyu stop.
Plug a W800RF32A/AE or MR26A receiver into a serial port. Or plug an RFXCOM
receiver into a USB port and determine the serial device assigned by the
OS. (Under Linux, the first USB device plugged in will normally be assigned
to /dev/ttyUSB0, or possibly to /dev/usb/ttyUSB0, the second USB device to
/dev/ttyUSB1, etc.). Or connect an RFXLAN receiver to your local network and
configure of verify its network address and port it listens on.
Describe for Heyu the port and receiver being used with the following
directive in the Heyu configuration file:
TTY_AUX <serial_port or network_address:port> <receiver device>
TTY_AUX /dev/ttyS1 W800RF32A
TTY_AUX 10.10.10.10:10000 RFXCOM
The configuration directives TRANSCEIVE and RFFORWARD determine whether signals
from a Standard X10 transmitter (like the HR12A PalmPad) are directly transceived
to the powerline or are forwarded to the Heyu Engine for processing. The defaults
for these directives are "TRANSCEIVE ALL" and "RFFORWARD NONE".
Run 'heyu start', and in another xterm 'heyu monitor'. Verify that the RF
signals are being correctly received. Transceived signals will appear in the
monitor window with source "snda", indicating they were sent by the auxilliary
For transmissions from Security X10 sensors like the X10 DS10A Door/Window sensor
(with an RF receiver capable of receiving these transmissions) the Heyu monitor
will display an "RFdata" signal.
... rcva func RFdata : Type Sec ID 0x23 Data 0x04
Before Heyu can decode the signal data it has to know the type of sensor. This is
accomplished by mapping the sensor module type and its ID (0x23 in
this example) to an otherwise unused housecode|unit address with an ALIAS
directive in the configuration file, e.g.,
ALIAS Back_Door B2 DS10A 0x23
Then after running 'heyu restart', opening the door will result in a monitor
... rcva func Alert : hu B2 swMin (Back_Door)
where the flag swMin indicates the "Delay" slider switch on the DS10A is set to
the Min position. The "rcva" means the signal was received from the Heyu
Auxilliary daemon, heyu_aux. (This signal source will have to be specified in
the SCRIPT launch conditions if the alert signal is to launch a script.)
In addition to the various standard X10 remotes and sensors, Heyu currently
includes RF decoder modules for the following RF security and
entertainment remotes and sensors:
North American models:
SH624 Security Remote
KR10A Security Keychain Remote
DS10A Security Door/Window Sensor
MS10A Security Motion Sensor (See section MS10A WARNING).
UR81A Universal Remote (Entertainment).
Marmitek DS90 Security Door/Window Sensor (See section "SPECIAL DS90/DS18-1
SETUP" towards the bottom of this man page.)
ElekHomica DS18-1 Door/Window Sensor (2 channel. Equivalent to Marmitek DS90)
ElekHomica DS18 Door/Window Sensor (1 channel, 433.92 MHz version of DS10A)
Marmitek SD90 and SD10 Smoke Detectors (See section "SPECIAL SD90
SETUP" towards the bottom of this man page.)
Marmitek MS90 Security Motion Sensor
ElekHomica EH-CWSD10 Smoke Detector
ElekHomica EH-WD210 Water Detector
Marmitek GB10 Glass Break Detector
(Also sends a sDusk signal at dark)
Decoders are also included for RFXSensor and RFXMeter signals, and
signals from the DigiMax 210 Thermostat and Oregon sensors. Owners
of these devices should see man pages x10rfxsensors(5), x10rfxmeters(5),
x10digimax(5), and/or x10oregon(5).
Modules for other remotes and sensors will be added once the RF code
generated by each button-press or sensor action is known. (Heyu
displays this information.)
Security remote and sensor devices transmit two significant bytes of code
at each button-press or sensor action. The first of these is an
identification byte which is (nominally) unique for each individual
device; the second describes the function of the particular
button-press or sensor action.
Older entertainment remotes like the UR81A transmit two significant
bytes of code. The first of these is either constant or restricted
to a few values; the second describes the function of the button-press.
The way each of the bytes are encoded for RF transmission allows
distinguishing between standard, security, and entertainment codes.
The Alert/Clear action of security Door/Window sensors may be swapped
by including the keyword REVERSE as a parameter to the ALIAS directive
which maps the sensor ID to a Housecode|Unit address. With this option
the Alert signal is issued when the door/window is closed and the Clear
signal when it is opened. This option is currently supported by the
models DS10A and DS90 sensors. It was added so that these sensors can
be used with a N/O switch instead of the N/C magnetic switch supplied with
These keywords are currently supported only by the DS90 Security
Door/Window sensor. See the special setup instructions for this sensor
in the SPECIAL DS90 SETUP section toward the bottom of this man page.
In order to receive RF signals, Heyu relies on the heyu_aux
daemon, which is started either manually with the 'heyu aux'
command or automatically in the startup sequence with the
'heyu start' command. The serial port, or network address
in case of the RFXLAN network receiver, and attached receiver
device must be specified in the Heyu configuration file with
the TTY_AUX directive. The syntax for this directive is:
TTY_AUX <serial_port or network_address:port> <receiver device>
where <receiver device> is W800RF32A, MR26A, or RFXCOM. Examples:
TTY_AUX /dev/ttyS1 W800RF32A
TTY_AUX 10.10.10.10:10000 RFXCOM
RFXCOM defaults to the variable length packet mode model, RFXCOMVL.
The 32 bit W800 emulation mode RFXCOM32 may be specified if
There is no default for this directive.
Standard X10 RF signals received by heyu_aux may either be directly
transceived to X10 powerline code or may be forwarded to the heyu_engine
and used to launch scripts without the delay inherent in X10 powerline
communication. The alternatives are controlled by the two configuration
directives, TRANSCEIVE and RFFORWARD. The syntax for these directives
where <list> may be the keywords ALL or NONE, or may be a string of
housecode enclosed in square  brackets.
which will transceive RF signals on housecode B, F, and H, and forward
RF signals on housecode I, J, and K. RF signals on all other housecodes
will be ignored.
Either of these directives may also use the keyword ALLEXCEPT followed by
the square bracketed housecode list to include all housecodes except
those in the list.
RFFORWARD ALLEXCEPT [BFHLM]
In this example, housecodes B, F, and H will be transceived,
housecodes L and M will be ignored, and all others will be
Any given housecode may not be both transceived and forwarded.
The default for the TRANSCEIVE directive is ALL, and that for the
RFFORWARD directive is NONE.
Finer grained control is available from special module types
used in an ALIAS directive which can override the TRANSCEIVE
and RFFORWARD selections for specific units and functions
within a housecode. These module types are:
PALMPAD (or HR12A) - Controls RF On, Off, Dim, and Bright
KEYCHAIN (or KC624) - Controls RF On and Off
ONLYON - Controls RF On
ONLYOFF - Controls RF Off
MS12, MS13, MS14, MS16 - Controls RF On and Off.
The MSxx module types differ from the KEYCHAIN module type only
in that they are defined as "sensors" and will be listed in the
table displayed by 'heyu show sensors'.
Each of these special module types requires one of the parameters
TRANSCEIVE, RFFORWARD, or RFIGNORE to define its functionality.
ALIAS XMMS_Control D1-4 PALMPAD RFFORWARD
which would direct heyu_aux to forward On/Off/Dim/Bright signals
from an X-10 PalmPad (or any other RF remote) on housecode D,
units 1 through 4, regardless of the selections in TRANSCODE and
RFFORWARD (which will otherwise control other RF signals on this
ALIAS LightIgnore B2 KEYCHAIN RFIGNORE
would direct heyu_aux to ignore RF signals from the light sensor
on Address+1 of a (non-security) Motion Sensor, e.g., the X-10
MS14A, set to address B1 (which often causes collision problems
when the sensor's "motion" signal turns on a lamp within view
of the sensor).
If, for whatever reason, you have an external transceiver like
a TM751 or RR501 in operation, Heyu should usually not transceive
on the same housecode lest there be signal collisions on the
AC power line.
Note: Heyu identifies signals transceived by heyu_aux as having the
source SNDA. Signals forwarded to heyu_engine are identified as
having source RCVA. Remember this when using these signals to
launch a script.
Security and Entertainment X10 RF signals received by heyu_aux are
decoded and processed by the Heyu State Engine daemon, heyu_engine.
Since these types of signals contain no Housecode/Unit identification,
the transmitting device must be mapped to a Housecode and Unit in
an ALIAS configuration directive for the RF signal to be decoded by the
Heyu Engine. Once decoded, the signals can be used to launch scripts
or control various Heyu features like a home security system.
Heyu identifies security and entertainment signals from heyu_aux as originating
from source RCVA. Remember this when using these signals to launch a script.
For security devices, the identification of the individual device (or devices
if you have more than one of the same type) must be provided with the
ALIAS directive. The syntax is:
ALIAS <label> <housecode|unit> <device model> <ID> [<ID> [<ID>...]]
where <ID> represents the security ID of a device expressed as a hexadecimal
number, either with or without the "0x" prefix. Up to 16 security IDs can be
associated with a single housecode|unit address for security remotes.
Note: multiple device IDs are normally mapped to a single
housecode|unit address only for security remotes of the same model.
Security sensors must be mapped to different addresses so the signals
from each can be distinguished.
ALIAS my_sh624_remote D12 SH624 0x1c b2
ALIAS back_door C3 DS10A 0x65
To determine the security ID of a device, start Heyu normally and open
a Heyu Monitor window. Operate the device(s) in question by pressing a
button, opening the door, or whatever it takes to make it send an RF
signal. Heyu will display the raw RF signal in the monitor
window like this:
rcva func RFdata : Type Sec ID 0x65 Data 0x04
which provides the information that a signal was received by heyu_aux
(rcva) and that it is from a device of type Sec[urity] with ID 0x65.
Once we have added the ALIAS directive (in the back_door DS10A example
above) to the configuration file and restarted Heyu, the same signal
now interpreted by heyu_engine will be displayed in the monitor as:
rcva func Alert : hc C unit 3 swMin (back_door)
Indicating the door was opened and that the DS10A has its slider
switch set to the "min" position.
Most X10 Security devices actually send a 16-bit ID code, however the
upper byte is received only with an RFXCOM receiver in variable
length packet mode. The examples here illustrate only the 8-bit code
which would be received by a W800RF32A/AE receiver or RFXCOM in 32 bit
mode. In the ALIAS directive, use whatever ID code, 16-bit or 8-bit,
is reported by Heyu from your RF receiver.
For entertainment remotes like the UR81A, the ID doesn't change.
It is built into the model and isn't specified in the ALIAS.
So using the UR81A as an example, we could use the directive:
ALIAS my_ur81a B2 UR81A
The RF signals from entertainment remotes are currently decoded
by heyu_engine only as virtual data ('vdata') signals. Heyu scripts
can examine the data value (environment variable X10_Vdata) to
determine what action to take for a particular button-press. An
example script is UR81A_Action.sh found in the Utilities section
of the Heyu website (http://www.heyu.org).
SECURITY FUNCTIONS AND FLAGS
The "Arm" and "Disarm" RF signals from security remotes like the X-10
SH624 and KR10A correspond to functions "arm" and "disarm". They
control Heyu's global security flags ("armed", "disarmed", "armpending",
"home", and "away") the same as if the corresponding 'heyu arm ...' or
'heyu disarm ...' commands were entered from the keyboard. (Global
flags may be tested in the launch conditions for any script.)
Signals from security remotes and sensors also set local flags
for the actual or implied switches on the devices: "swmin", "swmax",
"swhome", "swaway", and finally "lobat" for a sensor low-battery flag.
(Local flags may only be tested in a launch condition based on a
signal received from the particular device which set that flag.)
Security sensors send the RF signals "Alert" or "Clear", corresponding
to functions "alert" and "clear". They periodically repeat the
current state of the device in a signal approximately every 60-90
minutes, just to let the host system (Heyu in this case) know they
are functioning normally.
Dont confuse the functions "arm" and "disarm" with the flags
"armed" and "disarmed", and dont confuse the local flags "swhome"
and "swaway" with the global flags "home" and "away".
The TTY_AUX, TRANSCEIVE, RFFORWARD, and ALIAS directives are
described earlier in this document.
This directive specifies the dim level for each RF Dim or Bright
signal transceived by heyu_aux. This is the same level as would
be sent with the 'heyu dim ...' or 'heyu bright ...' command
from the keyboard. The default value is 2, which produces a
change of about 6 percent in brightness. Setting the value
to 3 would produce a change of about 11 percent. The allowed range
for this directive is 1-22, the same as for commands sent from the
RF transmitters of all types generally repeat the transmission
in multiple bursts. For example the X-10 HR12A "PalmPad" transmits
a minimum of 6 bursts - more if button is held down; the X-10
security remotes and sensors typically transmit 5-7 bursts.
This directive instructs heyu_aux how to handle multiple bursts
in an uninterrupted sequence by providing 3 numbers:
AUX_REPCOUNTS <MIN> <REPEAT> <MAX>
<MIN> is the minimum number of identical RF bursts in a row
required for heyu_aux to issue its first response, i.e.,
transceive the signal or send the signal to heyu_engine.
(Default is 1 for the W800RF32A and RFXCOM, or 2 for the MR26A,
which is more susceptable to noise.)
<REPEAT> is the number of identical RF bursts in a row before
heyu_aux will issue additional responses. (Default 8)
If <REPEAT> is set to zero, no more than the first response
will be issued. Otherwise, setting the value of <REPEAT> too
low can result in overruns - RF signals will accumulate
in the system's serial driver buffer faster than they
can be transceived.
<MAX> is the number of bursts in a row without any break at which
point heyu_aux will stop issuing its normal responses and
instead issue a "RF Flood : Started" signal. (Default 200)
Once there's a break in the flood, heyu_aux will issue a
"RF Flood : Ended" signal.
If <MAX> is set to zero, heyu_aux will continue to send responses
without limit and there will be no "RF Flood" signals.
The purpose of the <MAX> count is to protect the
system from being overwhelmed by an accidental (or deliberate)
unbroken flood of RF bursts, e.g., from a stuck button on a
remote. Once theres an interruption in the flood, the counting
reverts back to <MIN>. Heyu can be configured to launch a
"-rfflood" script when it receives a RF Flood Started or
Most users wont need to change the defaults for this directive.
AUX_REPCOUNTS 1 8 200
will result in a signal being transceived or sent to the
heyu_engine on the 1st, 9th, 17th, ..., 193rd burst. Then
RF Flood messages will be sent on the 200th, 400th, 800th,
Older firmware versions of the RFXCOM receiver sent a special
signal when they detected RF jamming, however the system was
prone to many false positives and the feature was removed.
The options for this directive are YES or NO, with the default
being NO. With this default, jamming signals from the older
RFXCOM receivers are reported in the Heyu Monitor and Log file as
"RF Jamming : Started|Ended Main|Aux", where Main and Aux
refer to the RFXCOM Master and Slave receivers. If set to YES,
the jamming signals are treated as RF Noise.
This directive allows the display of signals in the Heyu Monitor
and log file to be suppressed if successive signals are unchanged,
for example the periodic "heatbeat" signals from security
sensors or temperature signals from temperature sensors.
With the default value of NO for this directive, the log file
and monitor will be cluttered with between about 16 to 24
superfluous (typically "Clear") signals daily for each security
sensor, or far more from sensors like Oregon temperature
sensors which transmit approximately every 30 to 90 seconds.
If the value of this directive is set to YES, then
the signal will be displayed in the monitor and log file
only when it represents a change from the previous state,
or if the signal launches a script. Only the display is
hidden - the processing by heyu_engine continues normally.
This directive instructs Heyu whether or not to display
the raw RF data bytes from the receiver device. The
choices are the default "NONE" to not display any raw
data, "NOISE" to display data which heyu_aux judges to be
RF noise, or "ALL" to display both noise and normal raw
The display of raw data is in addition to the normal
decoded data display. Displaying raw data requires writing
a _lot_ of data to the spool file which can interfere with
CM11A communications, so this directive should be left at
the default "NONE" (or "NOISE") except for testing and debugging (or
just to see what it looks like).
Note: Some versions of the W800RF32A are said to
receive 4-byte RF data from newer X10 entertainment remotes
like the CR14A "Pan n Tilt" remote and the UR89A "Lola"
remote. With the current absence of models for these remotes
in Heyu, heyu_aux is forced to classify RF data which might
be received from these remotes as RF noise.
Is used with the RFXCOM receiver in variable length mode to
instruct Heyu how to handle 16-bit Security IDs. The default
is YES, to use 16-bit IDs. If set to NO, Heyu will mask off
the upper byte and use only the lower byte, which corresponds
to the 8-bit ID used by the W800RF32 and RFXCOM receiver in 32
bit mode. This directive is provided primarily for those
who have configured a large number of sensors using the 8-bit
IDs, until they have a chance to reconfigure them.
Some security sensors appear to have a firmware bug whereby a
parity bit for the upper byte of a 16-bit ID isn't set properly.
With the default value of YES for this directive, the signal
will be classified as NOISE and ignored. Setting the value of
this directive to NO instructs Heyu to ignore this parity bit,
which is less risky than ignoring the signal.
In addition to the standard X10 functions transceived by
heyu_aux (with source SNDA), the following functions
received by heyu_engine (with source RCVA) from heyu_aux
are available for launching scripts: "arm", "disarm", "panic"
"alert", "clear", "slightson", "slightsoff", "vdata", "test", and
Other special functions which can launch scripts are described
in the Heyu man pages for RFXSensors, RFXMeters, Digimax, and
Don't forget to include the source keyword(s) in the launch
The keywords and flags which can be tested in the launch
conditions for a script in addition to the usual keyword
"changed" and the common flags 1-16 are: "armed", "armpending",
"disarmed", "home", "away", "swhome", "swaway", "swmin",
"swmax", "lobat", "tamper", "main", and "aux". (The last three
currently relate only to the DS90 Security Door/Window sensor.)
ALIAS side_window E7 DS10A 0x3d
SCRIPT side_window alert armed away rcva :: heyu turn siren on
The special launcher type "-rfflood" will launch a script
when an RF Flood signal is received. The flags that can be
tested in the launch conditions for this launcher are the
special flags "started" or "ended", the common flags 1-16,
and the security flags "armed", "armpending", "disarmed",
"home", and "away". Example:
SCRIPT -rfflood started armed away :: heyu on siren
SCRIPT -rfflood ended :: heyu off siren
When the total voltage of the four AA cells in the MS10A falls below
about 4.3 Volts, THE SENSOR WILL NO LONGER DETECT MOTION. Its
heartbeat signal then is always Alert with the LoBat flag, which
continues to be transmitted until the battery voltage is somewhat
lower. To avoid false alarms, Heyu scripts should always check
for the Alert/LoBat condition before checking for Alert alone, e.g.,
SCRIPT MyMS10A alert lobat rcva :: echo "Low battery" | mail
SCRIPT MyMS10A alert rcva :: call_police.sh
SPECIAL DS90/DS18-1 SETUP
The DS90 and DS18E Security Door/Window Sensors have two independent
circuits. In addition to the main circuit which is actuated by
the magnetic door/window switch, there is an auxiliary circuit
actuated by connecting a switch to a pair of internal contacts.
The DS90/DS18-1 also has a "tamper" switch actuated by removing the
cover from the unit which will issue a "Tamper" command and
set the Heyu tamper flag. (The tamper flag is sticky and must be
cleared by executing a 'heyu clrtamper' command.)
Each circuit has its own security ID. The security IDs are
related by the following formula, so given one the other can
(bit-reversed)AUX_ID = 1 + (bit-reversed) MAIN_ID.
This sensor can be configured in Heyu several different ways:
Map the main and aux circuits to different housecode|unit
addresses. Simply use the main ID in one ALIAS directive and the
aux ID in another ALIAS directive.
ALIAS kitchen_door C12 DS90 0x63
ALIAS kitchen_deadbolt C13 DS90 0xE3
Map both main and aux circuits to the same housecode|unit address
by including both security IDs in the one ALIAS directive. The
signals from each will be distinguished by flags MAIN or AUX.
ALIAS kitchen_entry C12 DS90 0x63 0xE3
Note: A potential hazard with mapping both circuits to the same
housecode|unit address is that they both use the same activity
timer. So the failure of one circuit wont be tagged as "inactive"
so long as the other circuit is still working.
If both circuits are mapped to the same address, the raw data from
the AUX sensor is stored in the "memory level" byte in the state
table and can be recovered with 'heyu rawmemlevel Hu'.
Use only one of the two circuits and ignore signals from the
other. To do this, include the security ID for whichever circuit
you want to use in the ALIAS directive. Tell Heyu which one it
is by adding the keyword either MAIN or AUX as a parameter to the
ALIAS kitchen_door C12 DS90 0x63 MAIN
In the above, Heyu will compute the AUX ID (0xE3) and ignore signals
received from it.
SPECIAL SD90 SETUP
The Marmitek SD90 Smoke Detector transmits signals at two independent
ID addresses, an "Emergency" or "Test" address and a "Sensor" address.
Marmitek security base stations apparently use only the signal at
the Emergency address, and with the factory default SD90 setting the
signals at the Sensor address are disabled. This is unfortunate
because the Sensor transmissions include two important features which are
absent in the Emergency transmissions: a periodic "heartbeat" signal and
a low battery flag.
The Emergency and Sensor addresses may individually be programmed to a
value 1 through 16. The following table displays the (8-bit) security
ID for each programmed address.
Note: An RFXCOM RF receiver in the default variable length mode will
display a 16-bit security ID with a high byte of 0x54 and a low byte
as shown in this table, e.g., 0x54C0 for Emergency address 1.
Address Emergency Sensor
------- --------- ------
1 0xC0 Disabled (Factory setting)
2 0xC1 0xD1
3 0xC2 0xD2
4 0xC3 0xD3
5 0xC4 0xD4
6 0xC5 0xD5
7 0xC6 0xD6
8 0xC7 0xD7
9 0xC8 0xD8
10 0xC9 0xD9
11 0xCA 0xDA
12 0xCB 0xDB
13 0xCC 0xDC
14 0xCD 0xDD
15 0xCE 0xDE
16 Disabled 0xDF
Each installed SD90 Smoke Detector unit should be set to its
own unique addresses. It's probably a good idea to check with
nearby neighbors who may have a SD90 within range of your RF
While the Emergency and Sensor addresses for a given SD90 can
be set to different values, there's no particular reason for
doing so and the full functionality of the SD90 can be achieved
by setting both Emergency and Sensor address to the same value
from 2 through 15.
Instructions for changing the Emergency and Sensor addresses
are provided in the Marmitek SD90 Advanced Use manual, which
at the time of this writing is available for download from URL:
however there's currently no reference to this anywhere on the
Marmitek website. The instructions are reproduced here.
Having decided on the Emergency and Sensor addresses to use,
perform the following steps:
1. Press and hold the Test button, and while doing so, press and
hold the Reset button until the yellow LED lights up. Then release
the Reset button.
2. Release the Test button and wait 3 seconds.
3. Briefly press the Test button the number of times for the Emergency
address, e.g., once for address 1, twice for address 2, etc. The LED
will blink for each press.
4. Wait until the LED lights up again, then wait another 3 seconds.
5. Briefly press the Test button the number of times for the Sensor
address. Then wait.
After a delay of about 3 seconds, the LED will flash the Emergency
address and after another few seconds will flash the Sensor address.
If the Sensor address is anything other than 1, the LED will then
flash rapidly a number of times to indicate the procedure has been
The programmed addresses can be recovered by pressing the Reset
button. The LED will flash the Emergency address, then after a
short delay the Sensor address.
The Heyu SD90 model allows the Emergency and Sensor signals
to be mapped to the same or different housecode|unit addresses,
depending on whether one or both IDs are supplied as a parameter
in the ALIAS directive.
ALIAS Both_ID F1 SD90 0xCA 0xDA
-- or --
ALIAS Emer_ID F1 SD90 0xCA
ALIAS Sens_ID F2 SD90 0xDA
(where 0x54CA and 0x54DA should be substituted for 0xCA and 0xDA
respectively in the above when using an RFXCOM receive).
The signal from the Emergency address appears in the Heyu
monitor as "Test" when either the Test button is pressed or
when the detector is actuated by smoke. (The SD90 makes no
distinction between the two.)
The signals from the Sensor address are "Alert" when the detector
is actuated by smoke, and "Clear" when the smoke dissipates and
also at the heartbeat intervals.
When the SD90 determines that a low battery condition exists,
it sends a single Sensor signal with the LoBat flag, then stops
sending the heartbeat signal. (The detector will start issuing
audible beeps at intervals.)
SPECIAL BWR102 SETUP
Mapping the BWR102 scale data to a housecode|unit address with
an ALIAS directive and module type ORE_WGT1 is similar to that
for other Oregon sensors.
For each weight measurement, the BWR102 retransmits the encoded
weight data at intervals of 10 or 11 seconds, up to 7 times or
until another weight measurement is started. The first of these
transmissions will always have the 'changed' flag set, even if
the weight is identical to the previous weight measurement.
Subsequent retransmissions will have this flag unset.
The weight units slider switch on the scale controls only the unit
displayed on the scale's LCD; the transmitted native units are
always kilograms, to 0.1 kg precision. The configuration directive
ORE_WGTSCALE is used to convert the native units to the user's
ORE_WGTSCALE Lbs 2.200
Charles W. Sullivan (firstname.lastname@example.org)
heyu(1), x10config(5), x10sched(5), x10scripts(5), x10cm17a(5), x10rfxsensors(5), x10rfxmeters(5), x10digimax(5), x10oregon(5)
Visit the GSP FreeBSD Man Page Interface.
Output converted with manServer 1.07.