Premise Z-Wave Status using RZCOP/VRCOP help

Motorola Premise


Hey guys, I've recently started using Premise and have an VRCOP with a bunch of HA14C intermatic dimmers. These dimmers, unlike the super-expensive Vizia RF+ devices, do not update their status automatically and require polling.

Is anyone using the recently posted Zwave device driver for Premise with non Vizia RF/RF+? If so, has anyone figured out how to poll these devices for status?

Without being able to obtain the status of the dimmers, the automation software is relatively useless to me :(

Unfortunately, I'm an html/php/perl/bash guy so I can't program C worth a damn. I have the source code to the dll if that helps.

For those without these devices but with the ability to help, every bound zwave device (node) is assigned an address (numerical 1 to 255).
The VRCOP/RZCOP serial device accepts ascii commands and requires a command such as ">?Nx" (x being the node number 1-255)
The response that is issued is also in ascii and would be "NxxxLzz" (xxx being the node 001-255 and zz being the level 0-99 (off to full bright))

One would then require the "brightness" element under to be updated accordingly.

Preferably this would be a bindable object as not all of the dimmers/switches require polling unless they're used in a schedule/scene/whatever.

Any help would be greatly appreciated...

As you've indicated, the driver does not employ polling and was not designed for use with the type of zwave switches you are using. Given this situation, the best solution is to modify the zwave driver. Its author, Damon Dean, has provided the source-code so it is possible to amend it. However, the challenge requires software development skills with C++, an understanding of the architecture of a native Premise driver, and familiarity with the RXCOP's ASCII protocol. Another option would be to study the driver's construction and develop a new one implemented as a Module.

I suspect you weren't planning to do any of the above and would prefer a simpler solution. I suggest you try the following experiment:
The zwave driver has a DiscoverDevices property. What happens when you enable it? I suspect that the first time it is clicked it will create child objects representing the Switches and Dimmers it discovers in your home. Now what happens if you click it a second time? Does it:
  1. Wipe out all existing child objects and then replace them with identical new ones.
  2. Retain the existing child objects and append identical new ones.
  3. Update the status of the existing child objects.
  • The first result is unusable for our purpose because it will destroy existing objects and lose their bindings.
  • The second result is equally bad because we don't want duplicated objects (I doubt it works this way!).
  • The third result is useful.
If #3 is what happens, then all we need is a simple Timer object that periodically triggers the DiscoverDevices property. I have no idea how much overhead a discovery operation represents nor how long it takes to run. I suspect it must iterate through all 255 addresses so the Timer shouldn't run faster than, I dunno, maybe once a minute ... or two?

Give it a try and let us know what happens.
Thanks for the response 123. As far as I know, this driver was intended for the original (due to the driver's age) RZCOP and Vizia RF line of products which did not automatically update their status ("set hail"). It wasn't until the release of the RF+ and VRCOP device that this feature was enabled so I find it a little curious that this driver doesn't support polling.

That being said, it was extremely nice of Damon to upload these drivers and their source code for us. Unfortunately I'm just not proficient enough in C++ to do much with them :(

Regarding your suggestions, when using DiscoverDevices it adds all of the nodes by ID. When using DiscoverDevices it does not add duplicate nodes, BUT it does not poll the status of the devices. Apparently it only reads the list of nodes from the device as provided by the primary controller.

This just got me thinking.. let's just say that I had RF+ devices which do update their status. All they would be do is respond to each command or local dimming level with a "N002L99" automatically. This would still require some polling of Premise to read this data and update the appropriate dimmer levels. I see nowhere that this is being done.

I'm left to assume that this driver was originally intended for 1-way operation only which is kind of a bummer.

Darn :(
"Darn" is right. I was hoping the discovery process included determining a device's status. Apparently not.

Not too many options left at this point. Unless someone rolls up their sleeves and modifies Damon's driver, the only other option is to create a new one as a Module. Module-based drivers for serially-controlled devices are easier to write than native drivers. However, it is a daunting task if you've never written one before. My first driver was for the ELK M1 and it was a long journey.

I think you've reached a point where Premise may not be the best solution for you. You need to consider switching to an HA product with comprehensive support for zwave devices.
Thanks again 123. The terrible part is that I really LIKE premise; how it's laid out and how it operates. I only went out and purchased the switches, primary controller, and serial controller once damon posted the ZWAVE drivers. I went with zwave due to the sheer amount of devices available (thermostats, lock sets, motion detectors, switches, dimmers, et cetera) and hoped I could get it working.

Now that I've purchased it all I suppose I'm stuck with it.

I was contemplating buy an ELK M1 for security purposes. I wonder if it will help me in any way...
...I was contemplating buy an ELK M1 for security purposes. I wonder if it will help me in any way...
I did a little research and although the ELK M1 supports zwave, it appears that it does not employ polling. From what I've gathered, most zwave switches do not automatically report their status when they are controlled locally. Periodic polling is the only way to keep track of a typical zwave switch's true state. Leviton implemented automated status reporting in its ViziaRF line and would not require polling to keep track of their true state.

IVB went through this exercise, with the ELK M1, and it is all documented in this post and this one.

When researching alternatives to Premise, you'll need to confirm that the product's zwave driver can perform polling so that it can properly support your brand of zwave switches. There is an excellent post on CQC's forum where IVB & Co. make their case that CQC's zwave driver should be enhanced with polling.
Is there an easy way to expose an add-in's serial port and use it to send/receive data? Perhaps someone could make a class extension that adds the polling capability?

I too looked at the source code and C++ looks really different from any programming I have done before. I really wanted to add zwave thermostat control, but the source code is beyond my current programming skills at this point.

WRT zwave two way feedback: I too use the RZC0P and liked it a lot initially over the X10 stuff I was using before, but I have found I must use vizia rf+ exclusively else there are huge delays in receiving the feedback from a vizia rf+ switch. For example, I recently purchased a intermatic socket module for my garage light, only to find it severely delayed the two way feedback from neighboring leviton dimmers/switches (obviously I had no feedback from the intermatic module, but for $25 I didn't expect much). Once I excluded the intermatic switch, everything worked fine again! I would see a 10-30 second delay with the intermatic lamp switch included! Normally the two way feedback is received by the RZC0P in 1 second or so after the light is completely out. I verified this twice using port spy and did everything I could think of such as changing the rediscovery dB of the devices etc. I think I'm going to try one of those X10 lamp sockets in the garage, else I'll have to buy a $70 leviton RF+ switch.
Etc6849, with the Vizia RF switches that you're using, is premise updating the current dimmer level if someone changes the dim level locally (or via another piece of software)?

When sending a command via the VRCOP to a dimmer I should be able to request a return response (L50, UP) which SHOULD set the dimmer level to 50 and then get the switch to confirm that it truly IS at level 50. The weird thing is that I'm not getting these responses either.

I'm not sure if it's my gear or a configuration issue...

I use the following:
In wall Dimmers: VR106-1LX
In wall Switches: VR151LX
Plug in Lamp Module: Vizia RF and RF+ 300w lamp dimmers
Vizia RF+ handheld controller

Note that the switch needs 4 wires in total, including a common wire and a ground wire. The dimmer needs 3 wire in total including a ground wire.

When I manually change the brightness at the dimmer, it takes a total of ~2 seconds for the automation browser page to show the new brightness. Port spy shows the receipt of the command from the lamp dimmer.

When I use the handheld Vizia RF+ controller, the light gives the same response once action is completed and SYS updates automatically.

This appears to be pretty consistent until I include the z-wave intermattic light switch into the mesh network. For this reason, I've disconnecting the intermatic light switch permanently.

If you are having trouble with vizia rf devices:

If you are having trouble with vizia rf devices:
1. Exclude all intermatic devices.
2. Run network rediscovery from the handheld vizia rf+ controller.
3. Associate all the vizia rf+ and rf devices with the RZC0P from the handheld controller.
4. Set the device to hail the rs232 controller using the "set hail" command under the advanced menu of the handheld vizia rf+ controller.
5. Update the rs232 controller with the handheld vizia rf+ controller by standing within 3 feet of it.
So, I guess that answers my question: Premise does support 2-way with the Vizia RF line of products. Guess I'll have to go swap my 10 Homesettings with Vizia devices..

Anyone care to loan me a few hundred $$ ? :(

Thanks for your help guys.
As always, there are a few things you could do as an alternative:

1. Mimmick the X10 smart palm pad example found below to use X10 palm pads to turn the lights on/off, letting SYS keep track of the light's state. Also use X10 motion sensors to turn lights on/off. It goes without saying that you would not want to toggle the lamp switch manually if you let SYS keep track of the state.

2. Use the setValueForce method to force a powerstate change. For example, if motion is detected and you have previously turned off the lights manually, the lights will not come on when motion is detected! However, if you use setValueForce a state change will be forced and the lights would come on even though SYS still thinks they are on, a command will be sent.

3. Write a custom module (aka driver) using Premise Builder. I'm going to attempt this in a few months, so I'll post one if I'm successful (I may not be as I'm somewhat new to Premise and home automation).
Thanks etc and 123 for both your help. Do either of you happen to have the sdk and visual c++ installed? I'm just curious how Premise is updating the dimmer level using the Vizia RF line of products if it doesn't read from the serial port. A quick perusal of the SPLEVINTON's various .h and .cpp files shows the commands being sent to the serial port, but I can't see anywhere that it's being read.

The Vizia RF devices automatically send back their status to the serial device using the same ascii commands (lets say: N004L50 for Node 4 Level 50) I can emulate this behaviour with a big hack by sharing my com port (virtual serial port emulator) and having a timer setup within premise requesting each nodes status every x amount of seconds.

I just can't figure out how the driver is reading this data and supplying it/updating Premise.

Again, I really appreciate both of your help in this.
I think you've reached a point where Premise may not be the best solution for you. You need to consider switching to an HA product with comprehensive support for zwave devices.
Trying to tread lightly here... manxam, if you have a lot of the HA14's installed and you need instant status, we do handle this in our software. FYI.
... how Premise is updating the dimmer level ... I can't see anywhere that it's being read.
At the top of the VIZIARF.cpp file you'll find the following:
JumpTableEntry<MFP> arrJT[] = 
	{"<F", CVIZIARF::UpdateZones},
	{"<E", CVIZIARF::HandleAck},
	{"<X", CVIZIARF::HandleResponse},
	{"<N", CVIZIARF::HandleUpdate},
void CVIZIARF::ProcessLine(LPCSTR psz)
	if (m_spSite != NULL)
		MFP fp = LookupJumpPartialMatch(psz, arrJT);
		if (fp != NULL)
  • Premise buffers the data that arrives via the serial port.
  • The driver object's "ProcessLine" method is called when something arrives in the buffer.
  • It calls on the "Jump Table" to decide what should happen next.
The "Jump Table" is like a C++ switch/case statement and defines which method to call based on the received data. For example, if the incoming data starts with "<F", the driver will execute its "UpdateZones" method.

The HSDK (Software Development Kit for creating native drivers) contains a manual that describes how to build a driver. I've posted a neatly formatted version of the HSDK's Quick Start Guide in Premise Downloads. Page 51 (Section 13. Adding A Jump Table To Handle Responses From The Device) describes how a driver receives data and uses a Jump Table.
I too read the .cpp files and couldn't make too much sense of what is going on due to my lack of programming knowledge.

That being said, I have a simple driver I worked on last night that I'll share later this week. All you need to know is vbscript to follow it, but it does not deal with scenes or groups yet. It appears to be working, but I'm on travel so I can't test it in the real world. I'll post it after a few more tests/additions. I may add polling (not needed for my system), but polling would be very easy to add later too.