Premise [download] W800RF32 Driver for Premise! Supports all X10 RF devices (standard and security).

Motorola Premise

etc6849

Senior Member
index.php
File Name: W800RF32 Driver for Premise! Supports all X10 RF devices (standard and security).
File Submitter: etc6849
File Submitted: 01 May 2010
File Updated: 19 Jul 2011
File Category: Premise
Author: etc6849
Contact: Please use the support forum...
Version: 1.5

Introduction
This is a module for the WGL W800RF32 or W800RF32A. The WGL is capable of receiving all X10 RF signals including X10 Security RF signals.

Improvements over the native X10 MR26a driver
Completely opensource and fully Premise compliant.

Much more responsive communications with increased range.

The Remote class inherits from the KeyPadDevice class.
This means you can initialize a new keypad from home to bind with the X10 HR12A PalmPad. Now you can do literally anything you want with a PalmPad's buttons by creating scripts attached to the bound keypad's buttons under Home. Other supported Remotes include: a custom remote with any number of even buttons (up to 18), the KR19A keychain remote and the UR81A media remote.

Supports X10 Security Devices and includes battery monitoring (MS10A and DS10A).
An event is set if the battery needs replaced to alert a user. This is based on periodic status from the X10 Security device not being received.

Note that the module also includes battery low property, but only for the DS10A. Unlike the replace battery property, the battery low property does not set an event, but lets you know the DS10A senses low battery voltage. The battery low property relies on the DS10A setting the battery low bit when sending a status packet. As it turns out, the DS10A battery low bit is not forgiving enough for NiMH rechargeable batteries, which do have a lower voltage than alkaline; this is why the property is not used to set an event.

Includes a Premise compliant LightSensor class for the MS12A, MS13A, MS14A and MS16A motion sensors.
Sets Light value to 0 or 100 (not variable); can be bound with a LightSensor home object (found under HVAC). Also suports standard motion sensors with no light sensor capability.

A quick example on using X10 Security devices...
You can now use a DS10A (X10 Security window/door switch) with Premise! The DS10A is very cheap (~$4) and there are literally thousands of uses for it. Version 1.2 and on of the module makes the DS10A generic by inheriting from the DigitalInput class and setting the State property.

To add a DS10A:
1. Install the module using Premise Builder under Modules by right clicking Modules and left clicking Import. Next create a W800RF32 device under devices. Be sure to tell the device driver what COM port the W800RF32 is connected to.
2. Go to W800RF32.Devices.Sensors.X10Security. The X10Security container will automatically be created.
3. Right click on the X10Security Container to add a DS10A, left click detect address and immediately change the state of the DS10A to learn (register) the code. Pay attention the DetectStatus during this process. Typical messages include "Address Detected" or "WARNING: Duplicate Address Detected."
If you receive the warning message, the DS10A you are trying to add matches that of an existing DS10A device. Try removing the batteries, wait a few minutes and then put the batteries back in.
4. An MS10A X10 Security motion sensor can be added in a similar manner.

X10 Security Notes
No X10 Security console is required to register the DS10A with the W800RF32 and use of WGLDesigns demo program is not required! All you need is to set up everything is Premise + W800RF32 + DS10A.

Multiple W800RF32’s can be added!
This means if you ever have dead spots, just add another W800RF32 along with a wireless serial port server (such as the Lantronix WiBox).

The DS10A and all X10 Security devices change their code upon battery removal.
You need to perform the process above each time you change the batteries.

The DS10A toggles the battery low bit when the DS10A thinks the battery is low, but no event is set in Premise.

The MS10A does not set the battery low bit. Luckily, the MS10A and DS10A both give a 1-2 hour update of its current status. This status is used to reset a battery timeout for both types of X10 Security devices. If the update is not received or no commands are received for 9000 seconds from a security device, the ReplaceBattery property will be set to true and an event will be created to alert the user.

A quick Example on adding a custom remote...
1. Follow step 1 from above.
2. Go to W800RF32.Devices.Remotes and right click to add a Generic remote.
3. Set the number of buttons (including the brt/dim buttons) using the NumButtons property. For example, a HR12A PalmPad would have 18 buttons.
4. Set the base house code for the remote (default is “Aâ€).
5. Set the base unit code for the remote. The base unit code is the unit code of the first button. For an HR12A, this is limited to 1 or 9. However, some keypads such as the KR19A, this can be assigned to be any number.
6. Go to Home and right click Home. Go to New->Keypads->Keypad.
7. After Keypad creation navigate to it. Using InitFromDevice, browse to the desired X10 remote found under Devices.W800RF32.Devices.Remotes.
8. All buttons are automatically created under the new home keypad and you can now add scripts or macros to the buttons.

Remote Notes
InitFromDevice will not overwrite your scripts if you want to bind with a different X10 remote.

The X10 remote buttons are Premise compliant. Note that three states are supported for each remote button: Release, Press and Hold. This means each button can have a different task assigned for the Hold state. Double click is not supported and wasn't in the native MR26A driver either so you're not missing much.

Documentation
Search google for X10 RF Codes RFXCOM for protocol details of the W800. Excel file is also included that decodes the classic X10 house and unit codes (requires Excel's Analysis ToolPak add-in).

Updated in V1.4
HoldCount will now continue to increment as the button is held down greater than 2 seconds (e.g. through the Press and Hold states). Previously, HoldCount would reset during the transition from Press to Hold states.

Updated in V1.5
Added an outer if statement to onchangenewdata. The if statement ensures we wait until 4 bytes are received before doing further processing. This may seem strange, but this is necessary for slower network based serial port servers such as the Lantronix Wibox. If you don't do this, the serial port server could send only a byte or two to sys initially, and this messes things up as the for loop processes 4 bytes at a time. The driver actually worked fine for almost a year on a usb Digi Edgeport 8.

Click here to download this file
 
etc6849,
Great work! Although I don't own a W800RF32, you're driver does an excellent job of modeling the physical device.

I have one question and it concerns how you've modeled the DS10A. You've chosen to base it on either the WindowSensor or DoorSensor classes. May I suggest that you base it on the DigitalInput class.

A DS10A is basically a wireless, digital input. From the driver's perspective, a DS10A can be used for several things so it should be portrayed in a device-neutral manner (i.e. a generic digital input). A DS10A's actual purpose is defined in Premise Home when it is bound to a WindowSensor or DoorSensor object.

For an example of this design philosophy, have a look at Premise's alarm panel drivers. Alarm panels have many digital inputs that can be connected to contact sensors (wired and wireless) in order to monitor doors, windows, garage doors, skylights, etc. The Ademco and CADDX drivers model their inputs ("Zones") using Premise's SecurityZone class whereas the HAI driver uses the DigitalInput class. The driver treat Zones as generic inputs and do not specifiy if they are intended to be for doors, windows, etc.

I've attached a revised version that uses a single DS10A class. Have a look at it and see if it makes sense to you.
 

Attachments

  • WGLDesigns_V1.1.zip
    28.6 KB · Views: 23
Excellent observation! I guess I didn't realize home properties could bind with device properties that have different names?!? (see attached image)

Your changes look good; however, the ProcessCommand scripting needs updated too look for the new device type DS10A and not the door and window sensor types... (see: sys://Schema/Modules/WGLDesigns/Classes/Sensors/ProcessCommand).

Similarly, code needs changed here: sys://Schema/Modules/WGLDesigns/Classes/Devices/SetDetectAddress

I'll give this change a test this week and update the download section. Here's an updated beta version with the changes above.
 

Attachments

  • binding.JPG
    binding.JPG
    28.7 KB · Views: 32
  • WGLDesigns_V1.2.zip
    28.5 KB · Views: 21
I have KR32A's, SH624's, and some other security key fobs. How do I define them? I have been trying to test their use, but cannot find how.
 
Back
Top