User Error, or poor Elk->VRCOP & zwave design?

I'm hoping i'm seeing User Error right now as opposed to a bad design, but I just hooked up my VRCOP to the Elk. I have 16 lights in the network.

Problem #1: Commands don't really work, but show that they are.

For some lights, controlling lights via the Elk (M1XEP control via IE) works just fine. But for others, the slider works, tells me the light is on, but it's not actually on. It's as if it says "yep, i sent the lighting command" as opposed to "yep, I sent the lighting command and confirmed that it worked."

All I really did was teach the VRCOP the devices, update the M1XSP firmware to the one suitable for Vizia, and add the lighting under the Automation.Lighting tab with all fields with *Serial Expander, and dimmer or on-off based on what they were.

Problem #2: No polling to determine manual changes.

I'm also not seeing manual changes to light switches reflected. Granted i'm using Intermatic HA06 lightswitches, but isn't the whole point of zWave to be manufacturer independent?

Hopefully I didn't just piss away $200...

IVB said:

Hopefully I didn't just piss away $200...

Click to expand...

I'm hoping the same thing because I have the same equipment here ready to install. :lol:

I hope so too IVB! I am in the same position & was just blogging about it the other day,
http://www.cocoontech.com/forums/index.php...mp;showentry=99

Hopefully someone can shed some good light on your situation...

Well, CQC has a beta RZCOP driver, which I tried, but it's reporting "Wait for Connect". Might be a wiring mistake, so i'll check that out first before complaining. Hopefully that's a viable plan B, as I do like this RS232 controller better than the Intermatic USB one.

so this is how my driver works for the rzc0p. you can infer what you want for the other drivers from there.

the driver allows for 2 way feedback of acknowledgment of a command to the rzcop and that it received as well as another acknowledgment that it processed the command properly neither of which actually tell you if the device actually switched. to do this you have to poll the device status or look for an instant update from the device and report that as the status update. what is probably happening is that the first 2 acknowledgments are being used to confirm that the module changed status instead of polling it to actually make sure...i could be wrong on how the others are doing it but that is how i had to wind up doing it.

Very interesting, thanks. What I'll infer from that is that it's very easy, potentially even probable, to create an utterly useless rzcop/vrcop integration unless you're diligent about it, and putting yourself in your users shoes.

Boy I hope Elk was as diligent as you.

well one would think that both of the acknowledgments would be good enough but double checking never hurts. in my app manual start at 15, j, iv
here you will see i use regular iphone/itouch UI changes for rzcop confirmations and a green check mark for polling confirmations. that is the double check. after the double check i will use a graphic UI change like white light bulb changing to yellow when light is polled as on, hvac icon turning red after polled that indeed it is in heat mode, etc.

I haven't noticed any problems with ELK M1 control, lights activated by rules seem to work fine. I have noticed with zwave and other lighting technologies that the ELK m1 does not poll for confirmation, but thankfully some network troubleshooting ensured that things work 99.9% of the time.

I have noticed inconsistencies with manual changes and the ELK m1 lighting status. For my zWave, radioRA and x10 devices manual changes are often missed. Sometimes it is worse than others, can't find a pattern to it. I sniffed the serial data a while back that the radioRA interface was sending the status updates, but the ELK was not processing them. There was a short thread on the elk website about it, but I don't think anything meaningful came from it. This was pretty easy and common to see in my setup so I assume it is a known bug and I have been hoping ELK will fix it.

what zwave stuff do you use?

IVB said:

what zwave stuff do you use?

Click to expand...

When I have some time I will investigate the zwave failures. I have a rzcop with a few vizia loads. I don't think the zwave status is nearly as bad as the radioRA status, it is only being tested now so I only saw a few failures in testing. The radioRA failures seem to be unique to radioRA(processing local zone events fine, but not the zone maps associated with master control buttons), so I would guess any status issues are going to be unique to the zwave situation. I'll have to look harder to narrow down what is causing zwave failures and then dig through the rs232 protocol. Truth is that I don't care so much about status, just control, and with careful positioning of the loads it seems pretty reliable when a command is sent.

IVB said:

I'm hoping i'm seeing User Error right now as opposed to a bad design, but I just hooked up my VRCOP to the Elk. I have 16 lights in the network.

Problem #1: Commands don't really work, but show that they are.

For some lights, controlling lights via the Elk (M1XEP control via IE) works just fine. But for others, the slider works, tells me the light is on, but it's not actually on. It's as if it says "yep, i sent the lighting command" as opposed to "yep, I sent the lighting command and confirmed that it worked."

All I really did was teach the VRCOP the devices, update the M1XSP firmware to the one suitable for Vizia, and add the lighting under the Automation.Lighting tab with all fields with *Serial Expander, and dimmer or on-off based on what they were.

Problem #2: No polling to determine manual changes.

I'm also not seeing manual changes to light switches reflected. Granted i'm using Intermatic HA06 lightswitches, but isn't the whole point of zWave to be manufacturer independent?

Hopefully I didn't just piss away $200...

Click to expand...

IVB,

From my experience, and what we tell our customers, is that if you want to make sure you get 2-way feedback, then you need to use the Leviton ViziaRF switches with the Leviton Serial interface. Then after enrolling each switch, make sure you setup associations. (Associations are basically telling "Node X, when your status changes, report to Node Y").

Z-Wave is supposed to be interoperable, and it is, to an extent...but it seems that at some point, manufacturers end up having to do things slightly different for various reasons, and this was one of them. I played around with the intermatic switches (a while back, so my memory might be foggy), and it seems to me that manual changes at the switch weren't reported.

Aaron

aard3 said:

IVB said:

I'm hoping i'm seeing User Error right now as opposed to a bad design, but I just hooked up my VRCOP to the Elk. I have 16 lights in the network.

Problem #1: Commands don't really work, but show that they are.

Problem #2: No polling to determine manual changes.

Click to expand...

IVB,

From my experience, and what we tell our customers, is that if you want to make sure you get 2-way feedback, then you need to use the Leviton ViziaRF switches with the Leviton Serial interface. Then after enrolling each switch, make sure you setup associations. (Associations are basically telling "Node X, when your status changes, report to Node Y").

Z-Wave is supposed to be interoperable, and it is, to an extent...but it seems that at some point, manufacturers end up having to do things slightly different for various reasons, and this was one of them. I played around with the intermatic switches (a while back, so my memory might be foggy), and it seems to me that manual changes at the switch weren't reported.

Aaron

Click to expand...

Thanks for the response. I can see that as a legitimate response to #2, but certainly not for #1. I'm issuing a "light off" command, Elk reports that the light is now off, but in reality it isn't. If there's no guarantee that a given command worked because you used a different vendor, the integration is useless.

This is *not* how the CQC zWave driver works, indeed I get craptons of "send error" responses if it doesn't confirm that my "light on" or "light off" worked.

I'm still hoping this is user error, because if it isn't, then this is the final proof that I need to demonstrate to Steve/etc that best practice for integration is to use a PC for as much HA integration as possible, as it's easy to upgrade those drivers when you have problems. It'll take Elk months to modify the M1XSP/whatever firmware to fix this problem, and there's no chance I can have an unpredictable lighting system for that period of time.

IVB said:

aard3 said:

IVB said:

I'm hoping i'm seeing User Error right now as opposed to a bad design, but I just hooked up my VRCOP to the Elk. I have 16 lights in the network.

Problem #1: Commands don't really work, but show that they are.

Problem #2: No polling to determine manual changes.

Click to expand...

IVB,

From my experience, and what we tell our customers, is that if you want to make sure you get 2-way feedback, then you need to use the Leviton ViziaRF switches with the Leviton Serial interface. Then after enrolling each switch, make sure you setup associations. (Associations are basically telling "Node X, when your status changes, report to Node Y").

Z-Wave is supposed to be interoperable, and it is, to an extent...but it seems that at some point, manufacturers end up having to do things slightly different for various reasons, and this was one of them. I played around with the intermatic switches (a while back, so my memory might be foggy), and it seems to me that manual changes at the switch weren't reported.

Aaron

Click to expand...

Thanks for the response. I can see that as a legitimate response to #2, but certainly not for #1. I'm issuing a "light off" command, Elk reports that the light is now off, but in reality it isn't. If there's no guarantee that a given command worked because you used a different vendor, the integration is useless.

This is *not* how the CQC zWave driver works, indeed I get craptons of "send error" responses if it doesn't confirm that my "light on" or "light off" worked.

I'm still hoping this is user error, because if it isn't, then this is the final proof that I need to demonstrate to Steve/etc that best practice for integration is to use a PC for as much HA integration as possible, as it's easy to upgrade those drivers when you have problems. It'll take Elk months to modify the M1XSP/whatever firmware to fix this problem, and there's no chance I can have an unpredictable lighting system for that period of time.

Click to expand...

IVB,

I was just commented on the Leviton/Intermatic portion... I have no idea what the Elk/QCQ is doing/not doing! I was just trying to get you some insight on #2.

Good luck!

Aaron

IVB said:

I'm still hoping this is user error, because if it isn't, then this is the final proof that I need to demonstrate to Steve/etc that best practice for integration is to use a PC for as much HA integration as possible, as it's easy to upgrade those drivers when you have problems. It'll take Elk months to modify the M1XSP/whatever firmware to fix this problem, and there's no chance I can have an unpredictable lighting system for that period of time.

Click to expand...

You talking about me? If so,

1. You have nothing to prove to me!!!
2. That wouldn't change my opinion.My belief still is to use a hardware controller for lighting and this would not even come close to changing my mind. If the manufacturer has complete support for the technology then it should be rock solid. If the mfg has a bug in their implementation that is causing problem, I would suspect they would fix that rather quickly - days or weeks, not months. But if the problem is some sort of incompatibility or interoperability of components, that's a whole different problem. If it ss simple as the mfg does not support functionality, like they don't support full 2 way status while the protocol does, then I would say the mfg does not have complete support for that protocol and I would base my lighting choice partly on that. But to say that you should use a pc over a panel because you can rewrite a driver faster doesn't fly with me, it's just indicative of a deeper problem.

Anyway, that's just my opinion and I hope you get your stuff all sorted out.

From the Original Post:



Problem #1: Commands don't really work, but show that they are.

For some lights, controlling lights via the Elk (M1XEP control via IE) works just fine. But for others, the slider works, tells me the light is on, but it's not actually on. It's as if it says "yep, i sent the lighting command" as opposed to "yep, I sent the lighting command and confirmed that it worked."

All I really did was teach the VRCOP the devices, update the M1XSP firmware to the one suitable for Vizia, and add the lighting under the Automation.Lighting tab with all fields with *Serial Expander, and dimmer or on-off based on what they were.


Reply:
The M1XEP Virtual Keypad should be able to control all of the Zwave lighting devices that are including in the Zwave network. I haven’t heard of any reports from other users that it hasn’t. Has the customer gone through the Hand Held Programmer steps for updating the RZC0P Controller and the step called “RS-232 Setup� Also, in the lighting menu of ELK-RP make sure that the “OPT’ box is unchecked for each Zwave type lighting device.



Problem #2: No polling to determine manual changes.

I'm also not seeing manual changes to light switches reflected. Granted i'm using Intermatic HA06 lightswitches, but isn't the whole point of zWave to be manufacturer independent?


Reply:
The M1XSP doesn’t poll the lighting devices. If the light switch doesn’t send the change of status when manually pressed then the M1XSP will not know. The Leviton ViziaRF light switches do send the status; some of the other brands do not.



Don