Premise WGL W800RF32 Premise Driver Beta

[etc6849]

I'm working on a W800RF32 module for Premise. My first objective is to get a palmpad (HR12a) working just like or better than the MR26a native Premise driver.

Attached is a working driver; however, it doesn't handle press, hold, release functionality yet. I'm hoping someone has an idea of how to add this. Everything else is working very well and I've checked most of the unit/house addresses against the X10 native driver. All of my addressing code seems correct.

To test the palm pad, import the module, then add a new W800RF32 device. Under the W800RF32 device, right click the devices container and click new HR12a.

One improvement over the native X10 MR26a driver thus far:
The driver's Remote class inherits from the keyPadDevice class. This means you can initialize a new keypad from home to bind with the X10 Palm Pad. This driver is also opensource so others can change it as they see fit.

The driver could also be used with an MR26a with a few small modifications.

Documentation
I have all of the protocol figured out and decoded from binary to hex and decimal, but it's in Excel format. However, the excel file has grown very large so I'll have to post it seperately.

 

[etc6849]

Documentation attached (Excel format).

Also see this link for more information:
http://www.wgldesigns.com/protocols/w800rf32_protocol.txt

 

[etc6849]

I'm still thinking about how to implement press, release and hold... I could use several timers to mimmick what the MR26a does.

However, I'm thinking it's much more reliable (but more complex) to build a rxJob class and look for patterns.

Each job would record the 2 byte address data in X10 format (housecode + unitcode), job creation time and have a press, release, hold multivalue property that process job will set.

A ProcessRxJob method would look at the job creation time and compare it to some maximum interval to determine if release should be set. If the release max time has not been met, it would then compare this job to the last job and increase a count if they match. If this count is above some threshold, hold is set.

It goes without saying then that there will be three basic types of X10 devices:

1. Remotes (that use press, release, hold)
2. Sensors (that use the classic house letter + unit number; I'm proposing these have a new property called address)
3. Security devices like the DS10 (don't have any of these; it's likely they'll have an address property)

The ProcessAddress under devices will be responsible for finding a devices with an address that matches a job and devices with a buttonstate property. There after it will also look for an address alone.

Note that normally, Sensors don't have an address property in the native X10 driver. However, I think it makes sense to give them one and use onchangescripts to call a devices method that will fill the address out.

This type of method would avoid timers altogether. Any thoughts on the job idea and how to best layout this driver?

 

[123]

Firstly, congrats on tackling this device. The W800RF32 will be a very useful addition to Premise.

I currently use several HR12A devices ("Palm Pads") with an MR12A. As you already know, the MR12A driver inherits from Premise's Button class which models four states: press, release, hold, and doubletap. Frankly, I've always used the "release" event, in my scripts, and never experimented with the other states.

To support "hold" and "doubletap", your driver will definitely need to use timers. I guess if you hold down a button for more than 1 second, that would constitute a "hold" event. "Doubletap" is trickier because, in practice, the time delay between two taps can be less that 1 second yet there are no sub-second timers available in Modules (there are if you were writing a native C++ driver or Minibroker driver).

 

[etc6849]

I'm not sure I know enough to program for a double tap button state. This is not something the current MR26a native driver supports; it only supports press, hold and release.

Currently, I use the hold state of the MR26a driver extensively. For example, if a user holds a button down, a fan comes on; if it's just a press a lamp comes on...

EDIT:
I had issues with deadspots before even with an external antenna on the MR26a; especially with a motion sensor two floors down in the garage. Not anymore and some motion sensors even seem more responsive when using the W800RF32. The instant I walk into the room the motion detectors now trigger the zwave lights. Before I could walk past them sometimes and the lights would turn on after I was half way into the room.

I'll post a new version tomorrow or tonight that includes the motion sensor class. I want to also get the buttonState working before I repost and clean up the code for the remote class.

 

[etc6849]

Improved version. Now supports non-security motion sensor (MS16, MS13 etc...) and includes ButtonState changes.

123, when you get some time, please take a look at: sys://Schema/Modules/WGLDesigns/Classes/RFButton/OnChangeButtonState and sys://Schema/Modules/WGLDesigns/Classes/Remotes/ProcessCommand

I'm getting spurious button releases even though the button is held down. The spurious release results in a new press and eventually a hold though. However, I'm confused why this is happening. Getting press, hold and release to work made my head hurt; I'm not a programmer so there is probably a much more reliable way to handle the timing...

The next goal is to add one of these: ftp://ftp.x10.com/pu...als/ur81-om.pdf

 

[etc6849]

I've rewritten the following code and cleaned it up significantly:

sys://Schema/Modules/WGLDesigns/Classes/Remotes/ProcessCommand

'process the address command

'find remotes by searching for items of RFButton type that match the address
for each oRFButton in this.GetObjectsByTypeAndPropertyValue(Schema.Modules.WGLDesigns.Classes.RFButton.Path, "Address", method.Address, true) 
	system.removeTimer "ReleaseTimer_" & oRFButton.ObjectID
	
	'don't force command because native X10 driver does not repeat Press and Hold 
	'unless button is physically released for one second (verified in debugview)
	if oRFButton.ButtonState = 0 then
		oRFButton.ButtonState = 1
	end if
	
	'get path in dot format
	oRFButtonPath = Right(oRFButton.Path,Len(oRFButton.Path) - 6)
	oRFButtonPath = Replace(oRFButtonPath, "/", ".")
	oRFButtonPath = Replace(oRFButtonPath, " ", "_")

	'set release if nothing received for this button in the next 1.5 seconds.
	'any shorter than 1.5 seconds and trigger time is unreliable (even for 1 second verified in debugview)
	system.addTimer 1.5, "on error resume next: " & oRFButtonPath & ".ButtonState = 0", 1, "ReleaseTimer_" & oRFButton.ObjectID
next
set oRFButton = nothing

sys://Schema/Modules/WGLDesigns/Classes/RFButton/OnChangeButtonState

if sysevent.newVal = 1 then
	'toggle status
	if this.Status = false then this.Status = true else this.Status = false

	'if hold timer doesn't exist, then add it, else let it expire
	set oTimers = modules.Default.Timers.GetObjectsByPropertySearch("Name", "HoldTimer_" & this.ObjectID)
	if oTimers.Count = 0 then
		system.addTimer 2, "on error resume next: if this.ButtonState = 1 then this.ButtonState = 2",1,"HoldTimer_" & this.ObjectID
	end if
	set oTimers = nothing
end if

Press, hold and release now work with 100% reliability. However, the sacrifice is a release is not set until 1.5 seconds after a given button's commands are nolonger received. This is kind of long, but comparable to how the native X10 driver behaves (I ran several debugview tests). Previously, the release timer was set to 1 second and it appears that SYS cannot handle timers reliably at this interval (see other post with debugview output); this was causing spurious releases that should not have occurred.

Previously, when a new command was received a buttonState change was forced; I've changed this so that a buttonstate change only occurs when there is actually a new button state. I checked the native X10 driver using debugview and this is how it behaves. The sensor class already behaved like this.

PS: I've also added a media remote (UR81A). This new type of remote inherits from a class called MediaRemote. This has the same buttons as a normal IR remote would, but uses special X10 hex codes.

At this point, I think the driver is 90% complete and this is the last release for a few weeks... I wish I had a DS10 to play with; I think I'll order one and add DS10 functionality before publishing the final version under downloads.

 

[etc6849]

I've rewritten the remote class to be much more efficient and completely dynamic. Now there is a generic remote class that allows a user to input the total number of buttons, the unit code for the first button and the house code dynamically. If you change your mind after creating a keypad, you can always change it later. Only the buttons outside of the new index will be deleted; this means that any bindings will stay!

For example, you can now easily create a keypad under devices for a KR19a keychain remote. Create new generic remote, set the button count to 6, set the unit code for the first button and set the housecode. The KR19a is a unique remote in that you can define any unit code for the first button versus an HR12a that limits the first button's unitcode to 1 or 9. The remote is very small and about the size of any car keychain remote.
ftp://ftp.x10.com/pu...ls/kr19a-is.pdf

PS: the same code is also used to create a HR12a so the code is much simpler and easier to follow.

Some other new ideas I've included:
A button hold property that keeps track of how long a button is held down. Using this under home would require extending this new property to the SYS Button class; however, it's been included under devices now for testing purposes. Upon release, the holdCount is set back to zero.

As it turns out, the addTimer with a zero iteration count can be used accurately for intervals less than one second. This has been used to improve the button release time. Thanks 123 for verfying this for me!

Still thinking about how to handle a watchdog. I haven't deleted the reset port code, but may in the near future after I call WGL to make sure the W800RF32 does not emit a keep alive string periodically.

I've ordered two DS10A's to try. If all goes well, the final version will incorporate them.

 

[etc6849]

My DS10A's came today. The DS10A appears to be a great device that's highly reliable. They are less than $5 shipping included on ebay.

It turns out there are thousands of uses for these things that you never think of until you have a few. I'm going to order more

I'm thinking about implementing: a tool box alarm, door ajar reminder, liquor cabinet alarm, rack door light (light comes on when rack door is open) and etc...

If only I had an intercom system to send zoned text to speech over... These DS10A's were totally worth upgrading from the MS26a for.

EDIT: I'll post the new driver in the next few days. I forgot to mention the 16 zone limitation of the X10 security console seems like it is non-existent with Premise and the W800RF32. I'm not sure what the device limit is for the number of unique DS10A's, but looking at the hex output, I'm assuming it's very very high.

 

[electron]

The DS10A's are some of the best home automation toys out there. Just search the how-to's and forums to find out what you can do with them.

 

[etc6849]

Thanks Dan.

I remember it being you who made the neat keychain holder using DS10A's?

PS: Another member was kind enough to send me some hard to find documentation that is no longer online on the X10 security protocol. The new driver will now support battery low events for the DS10A.

 

[electron]

That same protocol document is also hosted on CT

http://www.cocoontech.com/forums/index.php...&showfile=4

Since the DS10A also transmits a heartbeat, I would implement that as well (so you can discover when there are communication issues, etc.).

 

[etc6849]

There's other good protocol resources that were easier to follow... An RFXCOM protocol document that details the X10 security format. There's also the X10 firecracker protocol published by X10: ftp://ftp.x10.com/pub/manuals/ direct link: ftp://ftp.x10.com/pub/manuals/cm17a_protocol.txt

The RFXCOM protocol doc appears to be pulled from their site or I'd link to it. I'm not sure if I can post it here as it has a copyright.

However, if you google:
"X10 rf codes" rfxcom

You'll find a very well written and easy to use resource on the X10 protocol.

 

[etc6849]

I've added several new capabilities:

1. Now includes DS10A as well as a new container for X10 Security devices.
To use the DS10A, create a new window or door sensor under the X10 Security container. Then click detect address and actuate the DS10A sensor. No X10 Security Console required!

2. An event is set for X10 security devices with a low on battery upon initial ReplaceBattery state change.

3. Devices ProcessCommand method has been rewritten. Added a SetDetectAddress method to clean the code up.

4. MotionDetector now has a default address assigned.

5. A warning is now set if a device address is already in use.
The user can ignore the warning at their discretion as a duplicate address may be desired.

6. Modified two lines of code to allow multiple W800RF32a's to be used.

Screen shots will be posted shortly. XDO file is zipped and attached.

EDIT: Updated version Beta 11 to Beta 11a. Now attached. Small change: Forgot to inherit from BindingTarget for the door and window sensor classes. The bindingTarget class is what allows you to link the home layer to the device layer... Doh!

 

[etc6849]

Screenshots for Beta 11