X10 DS10A, size: 25 KB
X10 Wireless Door / Window Sensor Don't be caught napping when it matters most! When a door or window is opened, this expert Sensor wirelessly signals any X10 Home Security System's Base Receiver about the intrusion. Self-checking for professional reliability Greater range & battery life than the DW534 Purchase the X10 Wireless Door / Window Sensor (XXTDS10A) and you are guaranteed to save.
Brand: Protector Plus
Part Numbers: DS10A, DS10A PDS01
UPC: 0099081419108, 099081331080, 099081419108, 99081419108
[ Report abuse or wrong photo | Share your X10 DS10A photo ]
User reviews and opinions
|Edmund Winks||4:14am on Thursday, July 22nd, 2010|
|We have used these for 7 years now We use the door/window sensors for our X10 alarm that we bought 7 years ago.|
Comments posted on www.ps2netdrivers.net are solely the views and opinions of the people posting them and do not necessarily reflect the views or opinions of us.
Door/Window Sensor, Model DS10A Set Up and Operating Instructions
Installing the Door/Window Sensor
Attach the Door/Window Sensor to the wall using the mounting screws provided. Fit the Door/Window Sensor as high as possible at the top of the door/window. Make sure the arrows on the magnetic switch halves are facing each other and that they separate cleanly when the door or wind ow is opened. Set the DELAY slide switch to MIN to always trigger the alarm instantly (for windows), or to MAX to trigger the alarm after a preset entry delay when the system is armed in DELAY mode (for doors).
When the security system is NOT armed and the Console is set to RUN2, the Console chimes when you open a door or window protected by the DS10A. The red indicator light for that zone on the Console also lights up. In RUN1 mode there are no chimes. When the security system IS armed, opening a door or window trips the alarm. If the DS10A is set to MIN the alarm trips instantly. If the DS10A is set to MAX there is a 30 second delay be fore the alarm trips after you open the door or window.
Open the battery compartment and replace the batteries with two AA alkaline type. After replacing the batteries, the following steps are necessary to determine that the Console still recognizes the DS10A.
Two windows (requires accessory magnetic switch pair)
Place the Consoles slide switch to RUN2. P res s TEST on the DS10A. If the Console chimes, it recognizes the DS10A and no further action is necessary.
If the Console did not chime:
Place the C no further action is necessary. the DS10A. The Console beeps and logs in the DS10A to the next available zone. To make sure the Console logs the DS10A back into the same zone it was allocated to before you changed the bateries, wait 4 hours after removing the old batteries before reinstalling (until the zone indicator on the Console starts flashing).
Registering the Door/Window Sensor with the Security Console
Fit two AA Alkaline batteries in the battery compartment. P ress and hold the TEST button for about a second. The LED flashes twice when you release it. This confirms it has generated a new security code. Set the slide switch on the Security Console to INSTALL. Press th e TEST button on the Door/Window Sensor. The console beeps once to confirm and the next available zone LED lights. Return the console slide switch to the RUN1 or RUN2 position.
Testing the Door/Window Sensor
Set the slide switch on the Security Console to RUN2. Open the door or window with the sensor attached. The console beeps to a c knowledge and the zone LED lights. *Note: you can install a total of 16 zones in the Console. This can be a combination of Door/Window Sensors and Motion Detectors. E.G. 8 Door/Window Sensors AND 8 Motion Detectors. See your Security System Owners Manual for more information.
Smarthome.com, Inc. (800) SMART-HOME (949) 221-9200 http://smarthome.com
x10aux - Auxiliary input to Heyu via RF
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.
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.
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 rst 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.) Describe for Heyu the port and receiver being used with the following directive in the Heyu conguration le: TTY_AUX <serial port> <receiver device> Example: TTY_AUX /dev/ttyS1 W800RF32A The conguration 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 conguration le, 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 ag 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 specied 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). 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 signicant bytes of code at each button-press or sensor action. The rst of these is an identication 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 signicant bytes of code. The rst 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.
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.
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 and attached receiver device must be specied in the Heyu conguration le with the TTY_AUX directive. The syntax for this directive is: TTY_AUX <serial port> <receiver device> where <receiver device> is W800RF32A, MR26A, or RFXCOM. Example: TTY_AUX /dev/ttyS1 W800RF32A RFXCOM defaults to the variable length packet mode model, RFXCOMVL. The 32 bit W800 emulation mode RFXCOM32 may be specied 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 conguration 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 specic 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 dened 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 dene 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 sensors "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 identies signals transceived by heyu_aux as having the source SNDA. Signals forwarded to heyu_engine are identied 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 identication, the transmitting device must be mapped to a Housecode and Unit in an ALIAS conguration 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 identies 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 identication 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" prex. 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 conguration le 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 doesnt change. It is built into the model and isnt specied 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 Heyus global security ags ("armed", "disarmed", "armpending", "home", and "away") the same as if the corresponding heyu arm. or heyu disarm. commands were entered from the keyboard. (Global ags may be tested in the launch conditions for any script.) Signals from security remotes and sensors also set local ags for the actual or implied switches on the devices: "swmin", "swmax", "swhome", "swaway", and nally "lobat" for a sensor low-battery ag. (Local ags may only be tested in a launch condition based on a signal received from the particular device which set that ag.) 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 ags "armed" and "disarmed", and dont confuse the local ags "swhome" and "swaway" with the global ags "home" and "away".
The TTY_AUX, TRANSCEIVE, RFFORWARD, and ALIAS directives are described earlier in this document. TRANS_DIMLEVEL directive This directive species 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 rst 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 rst response will be issued. Otherwise, setting the value of <REPEAT> too low can result in overruns - RF signals will accumulate in the systems 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 theres a break in the ood, 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 ood of RF bursts, e.g., from a stuck button on a remote. Once theres an interruption in the ood, the counting reverts back to <MIN>. Heyu can be congured to launch a "-rfood" script when it receives a RF Flood Started or Ended signal. Most users wont need to change the defaults for this directive. Example: AUX_REPCOUNTS 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 rmware 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 le 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 le 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 le and monitor will be cluttered with between about 16 to 24 superuous (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 le 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 le 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 congured a large number of sensors using the 8-bit IDs, until they have a chance to recongure them. SECURID_PARITY directive Some security sensors appear to have a rmware bug whereby a parity bit for the upper byte of a 16-bit ID isnt set properly. With the default value of YES for this directive, the signal will be classied 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 "tamper". Other special functions which can launch scripts are described in the Heyu man pages for RFXSensors, RFXMeters, Digimax, and Oregon sensors. Dont forget to include the source keyword(s) in the launch conditions. The keywords and ags which can be tested in the launch conditions for a script in addition to the usual keyword "changed" and the common ags 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 "-rfood" will launch a script when an RF Flood signal is received. The ags that can be tested in the launch conditions for this launcher are the special ags "started" or "ended", the common ags 1-16, and the security ags "armed", "armpending", "disarmed", "home", and "away". Example: SCRIPT -rfood started armed away :: heyu on siren SCRIPT -rfood 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 ag, 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 ag. (The tamper ag 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 congured 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 ags 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 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 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 ag. 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
--------- -----0xC0 Disabled (Factory setting) 0xC1 0xD1 0xC2 0xD2 0xC3 0xD3 0xC4 0xD4 0xC5 0xD5 0xC6 0xD6 0xC7 0xD7 0xC8 0xD8 0xC9 0xD9 0xCA 0xDA 0xCB 0xDB 0xCC 0xDC 0xCD 0xDD 0xCE 0xDE Disabled 0xDF
Each installed SD90 Smoke Detector unit should be set to its own unique addresses. Its 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, theres 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 theres 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. Briey 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. Briey press the Test button the number of times for the Sensor address. Then wait. After a delay of about 3 seconds, the LED will ash the Emergency address and after another few seconds will ash the Sensor address. If the Sensor address is anything other than 1, the LED will then ash 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 ash 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 ag, 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 rst of these transmissions will always have the changed ag set, even if the weight is identical to the previous weight measurement. Subsequent retransmissions will have this ag unset. The weight units slider switch on the scale controls only the unit displayed on the scales LCD; the transmitted native units are always kilograms, to 0.1 kg precision. The conguration directive ORE_WGTSCALE is used to convert the native units to the users preferred units. Example: ORE_WGTSCALE Lbs 2.200
Charles W. Sullivan (email@example.com)
http://www.heyu.org heyu(1), x10cong(5), x10sched(5), x10scripts(5), x10cm17a(5), x10rfxsensors(5), x10rfxmeters(5), x10digimax(5), x10oregon(5)
Automate AM9 CD-R55 UE46C6500 HT-TP75 18-2 G23 DPF-1030 MG102C Triax 50LX ML-1740 7208AG Gz-mg505 Kiel CD35 9960G WF-T1201TP BDV-F500 UX-67 STR-SE391 Suunto D4 ZWG6145 Aspire 7320 DSC-W170 R EW842F KLV-32U2530 HVL-FDH3 KEH-3900RDS Contour-2000 Officejet 9100 HK690I VPC-E6 1100L KAC-7251 Coolpix L5 KE770 6265I A35-S159 F09AHJ-n65 AVR-1603 C316BEE GSM7224 Ubtv-20C MP170 5806B Sitebuilder Finereader 8 UR 12 CCD-TRV128 AT-141 360 SCS200 5 Roomba 500 LW050V2 A E SGH-P300 Necchi 544 St200 Xv-dv252 550WP PW50-2003 HCD-CP11 Sibelius G7 DC-10R PD-M423 ZEN Xtra Justy FW730C-37 Schematic Magnet 4000 Stylus T21 PZ1710 LV979 Xdvd8182 KLV-30XBR900 Aastra M910 Adapter Headset Star Wars Alesis QS6 PX-777 Centralis IB DVP3005K 78 AQ24F AJL308-37B Nokia 5140 Practica T50 Sportback VP-D301 Aficio 2015 XV250TC IP 300 ZWF1026 Quattro Ultra HD DX650 28DG21U RM-AV2100 Ixus 430 DSR-500 KX-FC243RU Dslr-A550L LA32B650 HL650U
manuel d'instructions, Guide de l'utilisateur | Manual de instrucciones, Instrucciones de uso | Bedienungsanleitung, Bedienungsanleitung | Manual de Instruções, guia do usuário | инструкция | návod na použitie, Užívateľská príručka, návod k použití | bruksanvisningen | instrukcja, podręcznik użytkownika | kullanım kılavuzu, Kullanım | kézikönyv, használati útmutató | manuale di istruzioni, istruzioni d'uso | handleiding, gebruikershandleiding
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101