NAME

x10aux - Auxiliary input to Heyu via RF

DESCRIPTION

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.

HARDWARE

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 excellent.

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 capability.

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.

QUICK START

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>
Examples:
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 daemon heyu_aux.

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.
Example:
... 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 display like:
... 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.)

RF TRANSMITTERS

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).

International models:
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.

MODULE OPTIONS

REVERSE keyword.
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 the unit.

MAIN keyword
AUX keyword
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.

BASIC OPERATION

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 necessary.

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 is:
TRANSCEIVE <list>
RFFORWARD <list>
where <list> may be the keywords ALL or NONE, or may be a string of housecode enclosed in square [] brackets.
Example:
TRANSCEIVE [BFH]
RFFORWARD [IJK]
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.
Example:
TRANSCEIVE [BFH]
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 forwarded.

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.
Example:
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 housecode).

Example:
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. Examples:
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.

Don't confuse the functions "arm" and "disarm" with the flags "armed" and "disarmed", and don't confuse the local flags "swhome" and "swaway" with the global flags "home" and "away".

CONFIGURATION DIRECTIVES

The TTY_AUX, TRANSCEIVE, RFFORWARD, and ALIAS directives are described earlier in this document.

TRANS_DIMLEVEL directive
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 keyboard. Example:
TRANS_DIMLEVEL 2

AUX_REPCOUNTS directive
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>
where:
<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 there's 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 Ended signal.

Most users won't need to change the defaults for this directive.
Example:
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, etc., burst.

SUPPRESS_RFXJAM directive
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.

HIDE_UNCHANGED directive
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.

DISPLAY_RAW_RF directive
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 RF data.

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.

SECURID_16 directive
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.

SECURID_PARITY directive
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.

LAUNCHING SCRIPTS

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 "tamper".

Other special functions which can launch scripts are described in the Heyu man pages for RFXSensors, RFXMeters, Digimax, and Oregon sensors.

Don´t forget to include the source keyword(s) in the launch conditions.

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.)
Example:
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

MS10A WARNING

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 be derived:
(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.
Example:
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.
Example:
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 won't 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 directive.
Example:
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 receiver.

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:
http://www.marmitek.com/nl/manual/9652_SD90_AdvancedUse.pdf
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 completed.

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.
Examples:
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 preferred units.
Example:
ORE_WGTSCALE Lbs 2.200

AUTHORS

Charles W. Sullivan (cwsulliv01@heyu.org)