Upgrade Vizia to Vizia RF+

politics123

Active Member
Hi all --
 
Have an ELK M1 GOLD that uses a XSP that communicates to a RZCOP serial controller, a bunch of Vizia RF legacy devices (including my master controller, a RZCPG) Old school, I know. But it works... I'm able to automate basic rules with lighting, even if I don't have polling or triggers.
 
I'm starting to think about a refresh and interested in everyone's opinions. I'm thinking about adding locks, which I understand I can't do with what I have today.
 
I'd need to destroy my zwave network and start-over again with a Vizia RF+ primary controller. If I wanted the ELK to communciate with ZWAVE locks, I'd need to purchase a new serial controller and an SLZW. 
 
So, my questions:
1. I am a programmer, have several Raspberry PIs around the house to monitor and automate other tasks, and I'm wondering how beneficial it is for the ELK to be involved, vs just getting a z-stick and having one of my raspberry pis manage the automation.
2. The above is a more "open" solution, and as long as I could figure out some what for the RPi and ELK to communicate, (repurpose the XSP?) is it good enough?
 
Certainly saves a couple hundred dollars... I'd need to buy the zstick (new master controller) anyway, but I could do without the SLZW and new serial controller. Heck, the ELK could still use the XSP/RZCOP to do some basic lighting activities, just not locks.
 
Thanks for your thoughts.
 
Michael
 
politics123 said:
So, my questions:
1. I am a programmer, have several Raspberry PIs around the house to monitor and automate other tasks, and I'm wondering how beneficial it is for the ELK to be involved, vs just getting a z-stick and having one of my raspberry pis manage the automation.
2. The above is a more "open" solution, and as long as I could figure out some what for the RPi and ELK to communicate, (repurpose the XSP?) is it good enough?
Not sure what the best course of action is.
 
I have an elk/vrc0p combo for some lights,  thermos and locks. The bulk of my lighting is RRa2.
 
I am rather semi-satisfied with the elk+vrc0p. Not fully satisfied because I discovered that it was elk itself that  occasionally lost lighting/thermostat commands and not the zwave network as I suspected at first and almost hoped it would be the culprit given how awful the protocol is.  As recently as today, my flood lights failed to switch off with elk thinking that the command was sent and vrc0p never receiving the command on its serial port.  It happens not very frequently, about once a month, but when it happens it's quite annoying.
 
Now, with an RPI soution, you'll most likely rely on the openzwave library.  There's an implementation oddity in the library such that each command is followed by reading the device status which effectively doubles zwave traffic and latency.  Not sure why they did it this way.  Other than that, you may or may not have a better luck with a zwave stick and some application based on the OZW library than with the elk/vrc0p approach depending on how well a specific free/non-free automation system you are considering is implemented.
 
vc1234 said:
Not sure what the best course of action is.
 
I have an elk/vrc0p combo for some lights,  thermos and locks. The bulk of my lighting is RRa2.
 
I am rather semi-satisfied with the elk+vrc0p. Not fully satisfied because I discovered that it was elk itself that  occasionally lost lighting/thermostat commands and not the zwave network as I suspected at first and almost hoped it would be the culprit given how awful the protocol is.  As recently as today, my flood lights failed to switch off with elk thinking that the command was sent and vrc0p never receiving the command on its serial port.  It happens not very frequently, about once a month, but when it happens it's quite annoying.
 
Now, with an RPI soution, you'll most likely rely on the openzwave library.  There's an implementation oddity in the library such that each command is followed by reading the device status which effectively doubles zwave traffic and latency.  Not sure why they did it this way.  Other than that, you may or may not have a better luck with a zwave stick and some application based on the OZW library than with the elk/vrc0p approach depending on how well a specific free/non-free automation system you are considering is implemented.
That's pretty interesting. I don't think I can ever recall a time that one of my scheduled rules didn't work as expected. The only time I would see similar occurrences would be something like when I had a light triggered off a door opening. MOST of the time they would work fine, but I too would maybe get a monthly or bi-monthly occurrence of either a delayed light turning on (e.g. 2-4 seconds after door opened) or worse case - not coming on at all. It was fairly rare, but it did happen. Same as you mentioned - certainly annoying when it happened.
 
drvnbysound said:
That's pretty interesting. I don't think I can ever recall a time that one of my scheduled rules didn't work as expected. The only time I would see similar occurrences would be something like when I had a light triggered off a door opening. MOST of the time they would work fine, but I too would maybe get a monthly or bi-monthly occurrence of either a delayed light turning on (e.g. 2-4 seconds after door opened) or worse case - not coming on at all. It was fairly rare, but it did happen. Same as you mentioned - certainly annoying when it happened.
A while ago, I complained about my thermostats not getting a new setpoint.  I suspected everything from the thermo itself to the zwave network.  Finally, I found time to connect a serial port tap  between the elk and the vrc0p module.  I also have a zwave sniffer, but seeing activity on the serial port turned out to be quite enough.
 
So, one of the rules is that when the garage door is open, turn on flood lights for 1m30s and the garage lights for 1 minute. Here's what I saw yesterday:
 
-- Elk messages generated by a perl script connected to XEP:
Feb 28 18:08:19 ha01 perl[27412]: 2017-02-28 18:08:19 PLCChangeUpdate: house=A, unit=9, status=1
Feb 28 18:08:19 ha01 perl[27412]: 2017-02-28 18:08:19 Submitting: PLCChangeUpdate: house=A, unit=9, status=1 Flood on

Feb 28 18:08:20 ha01 perl[27412]: 2017-02-28 18:08:20 PLCChangeUpdate: house=A, unit=14, status=1
Feb 28 18:08:20 ha01 perl[27412]: 2017-02-28 18:08:20 Submitting: PLCChangeUpdate: house=A, unit=14, status=1 Garage on

Feb 28 18:09:20 ha01 perl[27412]: 2017-02-28 18:09:20 PLCChangeUpdate: house=A, unit=14, status=0
Feb 28 18:09:20 ha01 perl[27412]: 2017-02-28 18:09:20 Submitting: PLCChangeUpdate: house=A, unit=14, status=0 Garage off after a minute

Feb 28 18:09:34 ha01 perl[27412]: 2017-02-28 18:09:34 PLCChangeUpdate: house=A, unit=9, status=0
Feb 28 18:09:34 ha01 perl[27412]: 2017-02-28 18:09:34 Submitting: PLCChangeUpdate: house=A, unit=9, status=0 Flood off after a minute and a half, but not really


-- VRC0P serial port messages:
>N009ON 2017-02-28T18:08:20.321203 Flood  on
>N014ON 2017-02-28T18:08:22.821259 Garage on
>N014OF 2017-02-28T18:09:20.040728 Garage off
-- No message for flood off
 
 
After about 15 min I noticed that the flood lights were still on and turned them on/off manually:
--  Elk:
Feb 28 18:22:44 ha01 perl[27412]: 2017-02-28 18:22:44 PLCChangeUpdate: house=A, unit=9, status=1
Feb 28 18:22:44 ha01 perl[27412]: 2017-02-28 18:22:44 Submitting: PLCChangeUpdate: house=A, unit=9, status=1 Flood on
Feb 28 18:22:46 ha01 perl[27412]: 2017-02-28 18:22:46 PLCChangeUpdate: house=A, unit=9, status=0
Feb 28 18:22:46 ha01 perl[27412]: 2017-02-28 18:22:46 Submitting: PLCChangeUpdate: house=A, unit=9, status=0 Flood off
 
--VRC0P:
>N009ON 2017-02-28T18:22:44.549157 On
>N009OF 2017-02-28T18:22:46.831215 Off
 
The message is  emitted by Elk but does not make it through to VRC0P, who knows where it's lost.  My thermo failed to change its setpoint once this season so far, also in the same way despite my sending the setpoint message twice in the rule -- both messages were lost!
 
First, thank you for your thoughtful comments. This was exactly what I was hoping for... a frank conversion about an ELK-based solution.
 
I should have mentioned that I don't have too many ZWAVE devices. About 10 lights, a couple of switches (to automate the Solar PV and backup heater in the DHW tank). The latency in the ZWAVE piece has always annoyed me... scene controllers that take just a hair too long to drive changes, etc.
 
For OZW, is it a device-specific read, or a general poll of every device on the network? (ouch!)
 
Odd that a command would get lose through a serial connection. I guess you could brute-force/load-test it (hook it up to a computer. run it through 100-or 1000-commands, and see if you can trigger the same issue) --- would at least determine if its leviton's fault or ELKs.
 
politics123 said:
First, thank you for your thoughtful comments. This was exactly what I was hoping for... a frank conversion about an ELK-based solution.
 
I should have mentioned that I don't have too many ZWAVE devices. About 10 lights, a couple of switches (to automate the Solar PV and backup heater in the DHW tank). The latency in the ZWAVE piece has always annoyed me... scene controllers that take just a hair too long to drive changes, etc.
 
For OZW, is it a device-specific read, or a general poll of every device on the network? (ouch!)
 
Odd that a command would get lose through a serial connection. I guess you could brute-force/load-test it (hook it up to a computer. run it through 100-or 1000-commands, and see if you can trigger the same issue) --- would at least determine if its leviton's fault or ELKs.
re. ozw, it's a specific device get, as in (observe consecutive set/get):
 

2016-02-10 04:14:03.940 Detail, Node013, Queuing (Send) SwitchMultilevelCmd_Set (Node=13): 0x01, 0x0a, 0x00, 0x13, 0x0d, 0x03, 0x26, 0x01, 0x63, 0x25, 0x7a, 0xf3
2016-02-10 04:14:03.941 Detail, Node013, Queuing (Send) SwitchMultilevelCmd_Get (Node=13): 0x01, 0x09, 0x00, 0x13, 0x0d, 0x02, 0x26, 0x02, 0x25, 0x7b, 0x90

 
There was a discussion a while ago as to why they do that I do not find particularly convincing.
 
Re. lost messages, it is clearly elk's fault because I do not see the incoming message on the vrc0p serial port. Whether it's lost on the bus or inside XLSZW is anybody's guess. I do not feel motivated to dig any deeper because I would not be able to fix it anyway.
 
vc1234 said:
re. ozw, it's a specific device get, as in (observe consecutive set/get):
 

2016-02-10 04:14:03.940 Detail, Node013, Queuing (Send) SwitchMultilevelCmd_Set (Node=13): 0x01, 0x0a, 0x00, 0x13, 0x0d, 0x03, 0x26, 0x01, 0x63, 0x25, 0x7a, 0xf3
2016-02-10 04:14:03.941 Detail, Node013, Queuing (Send) SwitchMultilevelCmd_Get (Node=13): 0x01, 0x09, 0x00, 0x13, 0x0d, 0x02, 0x26, 0x02, 0x25, 0x7b, 0x90

 
There was a discussion a while ago as to why they do that I do not find particularly convincing.
 
Re. lost messages, it is clearly elk's fault because I do not see the incoming message on the vrc0p serial port. Whether it's lost on the bus or inside XLSZW is anybody's guess. I do not feel motivated to dig any deeper because I would not be able to fix it anyway.
 
Just confirming that I'm reading this correctly. 
 
You're saying, for a given instance, you are observing that Elk never sends a command to control a specified device. Is that correct? 

So, as in the case I mentioned above where I would have a rule written to trigger a light to turn on when it became unsecure. Elk would obviously observe the unsecure door, but never send the command to turn on the light? I understand that you have now way to observe data from my network, but just want to see if I'm understanding you correctly. 
 
drvnbysound said:
Just confirming that I'm reading this correctly. 
 
You're saying, for a given instance, you are observing that Elk never sends a command to control a specified device. Is that correct? 

So, as in the case I mentioned above where I would have a rule written to trigger a light to turn on when it became unsecure. Elk would obviously observe the unsecure door, but never send the command to turn on the light? I understand that you have now way to observe data from my network, but just want to see if I'm understanding you correctly. 
Yes, that's correct, in the example above, I do not see the message on the XSZW serial port  output (or the VRC0P serial port input which is the same pair of wires) although Elk claims that it has sent the command out (as shown by the Perl trace).
 
Any thoughts on an elk M1 to Raspberry Pi interface? Seems to me the options are: XSP, XEP, and using the Raspberry PI's GPIO ports to control Elk ZONES.
 
  • Found this guy who used the XEP: and some python code: System Setup   |  code
  • If I wanted to unplug my XEP, I could have the RPI talk directly to the serial port.
  • I can't find any documentation on the XSP. That seems like the painfully slow option of "configure as some XXX device and sniff the serial traffic/reverse engineer?"
  • GPIO/Elk zone route ???
 
The last one is somewhat intriguing. How would one connect an Elk zone output to one of the Pi's GPIO ports? (too early in the morning for me to think clearly)
 
politics123 said:
Any thoughts on an elk M1 to Raspberry Pi interface? Seems to me the options are: XSP, XEP, and using the Raspberry PI's GPIO ports to control Elk ZONES.
 
  • Found this guy who used the XEP: and some python code: System Setup   |  code
  • If I wanted to unplug my XEP, I could have the RPI talk directly to the serial port.
  • I can't find any documentation on the XSP. That seems like the painfully slow option of "configure as some XXX device and sniff the serial traffic/reverse engineer?"
  • GPIO/Elk zone route ???
 
The last one is somewhat intriguing. How would one connect an Elk zone output to one of the Pi's GPIO ports? (too early in the morning for me to think clearly)
The options for what exactly? Are you referring to the options ONLY for M1 to the RPi interface? 
 
The reason I stated the above, is that Elk supports Zwave integration with their own M1XSLZW interface

The reason I went that route was because it is Elk supported. Elk has posted webinars on YouTube regarding setup, configuration, etc and would provide phone support to me in the event that something wasn't working as expected. They aren't going to provide much, if any support for the roll-your-own integration. 
 
Yes, ELK to RPI. I'm assuming that I'd offload most ZWAVE automation to the RPI... but that there may need to be some cross-over integration between the ELK and RPI.
 
I wish Elk would update the M1SXLZW to eliminate the VRC0P+3 and create a fully integrated Z-Wave gateway – similar to UPB version. The M1SXLZW 2.0 would eliminate the triple DTE (RS-485 > RS-232 > RS-232) round trips and high probability of character loss. Also, it would be nice if 2.0 version support Z-Wave+.
 
I played around with the VRC0P+3 GR update command and noticed that it generated a large number of switch responses (as it should). The Elk light status is typically not correct in M12GO when a group/zone command is executed. I think the M1SXLZW doesn’t have a huge amount of buffering or serial processing port power.
 
Maybe Elk will at least acknowledge problem if supporting evidence is submitted. The description of problem and analysis is good enough on surface to avoid the who's the blame game.
 
d.dennerline said:
I wish Elk would update the M1SXLZW to eliminate the VRC0P+3 and create a fully integrated Z-Wave gateway – similar to UPB version. The M1SXLZW 2.0 would eliminate the triple DTE (RS-485 > RS-232 > RS-232) round trips and high probability of character loss. Also, it would be nice if 2.0 version support Z-Wave+.
 
I played around with the VRC0P+3 GR update command and noticed that it generated a large number of switch responses (as it should). The Elk light status is typically not correct in M12GO when a group/zone command is executed. I think the M1SXLZW doesn’t have a huge amount of buffering or serial processing port power.
 .
Eliminating vrc0p does not seem to be a simple endeavor. Locks require the controller participation to establish secure communication. Right now, secure enrollment is done by vrc0p, I do not think elk m1 has enough processing power/functionality to do it on its own, so we are likely to be doomed to use vrc0p forever.

If it were not for locks, it might have been possible.
 
Long before there was a VRC0P+3, Elk sold a secondary Z-Wave controller that used the RS-485 bus. This controller wasn’t very robust as compared to VRC0P+3, and didn’t have integrated primary controller either.  Elk retired that device ones the first VRC0P was created.
 
I am not sure I understand the why locks couldn’t be securely enrolled. The RFIT/VRUSB does the secure enrollment. Elk could create a Razberry PI like controller with a RS-485 backend. The problem with currently solution (M1XSLZW) as you suggested is data loss and lack of support for wide variety of ZWave devices. I really would love to be able to use a temp/humidity sensor.
 
The current challenge with using any other primary controller seems to be ability to correctly replicate to VC0P+3 including zones/scenes/associations. A few people mentioned they got partial functionality working with SmartThings or ISY.
 
For now, I am very satisfied with Leviton Vizia+. The switches seems to be very reliable and sturdy. I can instantly turn all (or some) lights on/off. Leviton recently replaced one of my switches under warranty without any huge hassle.
 
VC1234 - Since you did so much work to find the source of problem, I really think that you should share your research and tools with Elk technical support. Granted, probably no action will be taken. On other hand, Elk will know for certain the current M1XSLZW solution is not very robust.
 
Back
Top