To Protect and Conserve: Catch the Z-Wave - Page 2 - AVS Forum | Home Theater Discussions And Reviews
Forum Jump: 
Thread Tools
post #31 of 34 Old 06-18-2013, 04:52 PM
Advanced Member
etc6849's Avatar
Join Date: Dec 2006
Location: Irmo, SC
Posts: 878
Mentioned: 8 Post(s)
Tagged: 0 Thread(s)
Quoted: 176 Post(s)
Liked: 126
You can have advanced control over Z-Wave. I and a few guys developed an opensource z-wave driver for free a automation program called Motorola Premise, so I've had years of experience with Z-Wave and over all I like it. The Leviton VRC0P I use is basically just an RS232 bridge between the proprietary Zensys Z-Wave protocol used on the Z-Wave network and your PC, and of course, Leviton publishes most of the protocol you need to work with all kinds of Z-Wave devices. For the unpublished stuff, I usually scour the net looking at examples. Almost everything you need protocol wise can be "found"...

A few things I don't like about Z-Wave are all the different marketing terms each company uses, lack of clarity as to which z-wave classes are supported, and the fact that most dimmers lose power when the bulb burns out. This causes havoc on a mesh network. I'm assuming RadioRa2 and others have similar issues with dimmer power unless you rewire your house, so there you go...

Other than the above I'm happy and have seen less than 1/1000 commands fail (my software tracks failures and alerts the user). Not bad for any wireless lighting technology that's 100% DIY. Best of all though is since I'm using an opensource driver, I can add new types of devices very easily and don't have to wait for Vera or whoever to update things for me.

My packet failure rate is so low because I don't use battery powered devices on my main network, and I mostly stick with Leviton, using a VRC0P for control via RS232. I specifically put my locks and secure devices on their own separate Z-Wave network and VRC0Pv3 as they send too many encrypted packets which would delay my lights from responding in less than a few hundred milliseconds.

I've heard too horror stories about Crestron dealers holding programming code hostage so you can never switch to a new dealer. Further, what if your Crestron dealer goes under? You'll have to pay someone from scratch to code your system. Being a DIY'er who wants things heavily customized, I quickly realized my PC can do anything a Crestron or Control4 controller can do, and for a much lower price and in a much more versatile fashion.

Please be sure to update your post so advanced users can learn more. There is no reason Z-Wave can't be integrated into what you are calling an "in-depth" system with RS232 Z-Wave controllers like the VRC0P.
Originally Posted by VinnyS View Post

People who are more technical and wish to have more control over their system such as using RS232 protocols, I can understand Z-wave being a little more limited. Z-wave requires little-to-no programming because of it's simplicity. There are many solutions out there and I strongly recommend doing some research on the forum because their are many knowledgable people.
Originally Posted by VinnyS View Post

This was more of an introductory piece to show awareness of Z-wave and it's capabilities. Again, this is a more basic system at a cost effective solution. Anyone who wishes to do more in-depth programming and such, Lutron, Crestron, Control4 systems and more should be considered.

Premise, a FREE home automation program. Open-source Z-Wave Premise Module found here.
etc6849 is offline  
Sponsored Links
post #32 of 34 Old 09-30-2015, 07:02 PM
kmiller15211's Avatar
Join Date: Jan 2004
Location: Pittsburgh, PA
Posts: 50
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 30 Post(s)
Liked: 11
In case anyone was wondering, I was able to get my Z wave lighting controlled by my Harmony hub by going through the Smart Things hub. See my reply on this thread: Does Harmony Smart Control control Z-Wave switches?.
kmiller15211 is offline  
post #33 of 34 Old 10-01-2015, 10:24 AM
AVS Forum Addicted Member
Dean Roddey's Avatar
Join Date: Aug 1999
Posts: 18,978
Mentioned: 5 Post(s)
Tagged: 0 Thread(s)
Quoted: 410 Post(s)
Liked: 342
Z-Wave has a number of issues, some of which have been enumerated here to one degree or another.

1. Use of battery powered devices. This sounds nice, and for simplistic setups it's probably fine. But, in a real automation system, where the automation system needs to know the state of everything at all times, it becomes a problem. In order to save power, these types of devices often only wake up every couple hours or so. If you do any maintenance on the automation system, it could be a couple hours after starting it back up before it finally gets the status of all of the devices, which can be really annoying. It also means that these devices are send and pray, because the automation system cannot talk to them except for this very brief moment when they wake up. The automation system has no way to actively ping them to make sure it's staying in sync. You can often crank up the wakeup time, but if you set to anything very short you'll go through batteries fast.

'Beaming' is a relatively recent technology added to help with this. Devices wake up and go back to sleep rapidly, like a couple times a second, but very briefly so as to use minimal energy and just to listen. But, it means that outgoing messages have to be held on the network long enough to insure that the target device has woken up once during that interval in order to have seen it, and worst case it could be the full interval. This has to slow things down because another command can't be sent until the previous one completes. I don't know if they can cut short the interval if the response comes in (i.e. if they can correlate the response and know that they can drop the beam.) Even if so, the average time would be half of the interval, which would still be long compared to a non-beaming transmission. If not, then they would have to hold it 'in the air' for the full interval.

2. It's a semi-standard standard. There's too much leeway for the manufacturers as to how they use the various device classes. It's often the case that you can't support a particular module without having to explicitly code for it. There are way too many modules to get into that. We use a scheme where we have an XML file that describes a module, what classes it uses, what info it accepts and provides, what stuff is encrypted and what's not, etc... Even with a fairly convoluted set of such rules, it's still often difficult to support modules in this generic sort of way, and sometimes impossible because of vendors playing tricks or taking liberties.

Even when not taking liberties, it's still sort of a mess. I think there's something like 6 or more variations on how a lock can report it's lock status, for instance. Some are due to ongoing extensions of the device class interfaces (V2, V3, etc...) and sometimes it's because there's just multiple ways to do it and some vendors pick this and some vendors pick that. Some use generic device classes to send/receive some info and some use more device specific ones. Some depend on the interaction of two or more device classes in a way that you couldn't deal with generically and would almost have to support with custom code, which I just don't want to get into. Some use manufacturer propriety messages to do some things, which would certainly require it.

3. Without modules doing async reporting of status, it's pretty much a lost cause to try to have real two way control. The Z-Wave network isn't remotely fast enough to poll any significant number of modules at a rate that would keep latency to a useful minimum. If you open a window and it's not seen by the automation system until two minutes later, that's semi-useless. More and more devices are supporting this, BUT it means that a significant chunk of the actual configuration of the automation system isn't in the automation system, it's spread out all over the place in each module, because it requires setting up the async reporting (the interval, where to send them, and often what is set) in the modules themselves in many cases. You can of course record this in the automation system, but it's not practical to constantly re-push this information out to the modules. And the speed of the Z-Wave network would mean that fully pushing out all of this info every time the automation system (or driver) starts up could mean no control available for some time until it's all done. And it could somehow change any point after that without the automation system knowing it.

4. As mentioned by someone above, real control over the modules requires knowing detailed information about what device classes they implement and what versions of them and so forth. This is often a state secret of some sort that can be almost impossible to find.

5. Unlike technologies like Radio RA2, in which the automation system is completely insulated from the details of the underlying networking system, with Z-Wave you have to do with SO many details, it's stupid. Even using something like the VRCOP only helps somewhat since it's still a relatively like wrapper around a Z-Wave node. It requires an effort that's far out of balance with the benefits of supporting it for the most part. Yes, you can heavily concentrate on Z-Wave and get the best out of it it can provide, as some companies have. But there are a lot of other technologies out there as well that need to be supported as well, and time doesn't grow on trees. So, when one takes undue time and effort, it's probably not going to be integrated as well as those that take integration seriously and make it straightforward for the automation system manufacturer to deal with (and, importantly, which protect the system from the automation system as well, which is not the case at all in Z-Wave where the automation system is directly a node on the Z-Wave network.)

6. Reliability. This isn't a Z-Wave specific thing, it applies to all of the consumer level lighting systems. Some people do well with them, some do OK, and some end up giving up before they have a stress related heart attack. These systems aren't overbuilt like pro level systems are, so it's like they have 'just enough' to handle reasonably optimal circumstances then fall down to one degree or another, whereas higher end systems aren't on the edge like that.

Often the discussions on this front are apples and oranges comparisons, where one person is using the technology in a very simple way, mostly to just send outgoing commands to modules. In this case, the controller just sends out every command a few times, and it's likely they will arrive and it never over-stresses the Z-Wave system. Another person may be using it in a serious automation environment, in which robust two way control with minimal latency is a requirement, and so have a very different experience, because Z-Wave really wasn't ever designed to support that sort of thing.

Also some of our customers have reported limited success if they start mixing modules from different manufacturers, only being able to maintain a stable system if they stick strictly to Leviton devices.

7. You have to be pretty strict about how you physically handle modules, and some folks just aren't gong to be. Z-Wave isn't, as I understand it, and ongoing, self-healing mesh network (which maybe Zigbee is more of?) It finds neighboring (non-battery) nodes during network setup and uses them to pass along messages. You can't just yank out a module and move it without causing issues, and probably it happens often enough. Or, you change things around in the room and suddenly a previously good neighbor becomes a flaky neighbor due to interference and whatnot. Maybe this has gotten better in recent years, and maybe it's more self-healing, someone correct me if I'm wrong here. Any technology to target non-technical users probably needs to assume the absolute worst case and always be prepared to re-jigger itself for maximum performance on an ongoing basis.

Anyway, that's my view of it. I don't mean to sound overly critical. All systems to one degree or another have their issues. It's a complex real world out there and any time you try to deal with it from a piece of hardware or software it can get really wierd. But these are the concerns I see wrt to Z-Wave, and some of them are due to the design of Z-Wave itself and the lack of strict standards for module manufacturers, not due to the world being a dangerous place.

Dean Roddey
Chairman/CTO, Charmed Quark Systems, Ltd


Dean Roddey is offline  
post #34 of 34 Old 10-05-2015, 07:48 AM
AVS Forum Addicted Member
thebland's Avatar
Join Date: Jan 2001
Location: Detroit, Michigan USA
Posts: 25,750
Mentioned: 25 Post(s)
Tagged: 0 Thread(s)
Quoted: 1666 Post(s)
Liked: 1005
Big fan!

I have two full Z-Wave systems at my primary residence and vacation home. All are Honeywell Tuxedo Touch and Vista panels. I use Total Connect app for control on both.

House 1: 3 Z-wave Thermostats, 20-25 lights, Landscape lights, Lock, 1 Tuxedo Touch
House 2. 1 Zwave Thermostat, 10 lights, 1 Tuxedo Touch

The scenes are great. When I arm and its day time, all lights are shut off, if after sunset certain lights stay on and can rotate, voice control arms system, locks door, turns off int lights and turns on some ext lights. IF I say 'Wake up' alarm disarms (keypad requires code, however), certain lights turn on if priot to sunset so I can see my way through the house. All scenes or lights, or security faults can send texts and / or emails. IF my generator comes on, I get a text. If the power is out, I get notifications as well.

I am very pleased with the reliability and functionality. My only device that uses a battery is the Z=Wave Lock. 4 AA batteries seem to last 4-6 months.

I've had these systems for 2-3 years.

I may try Zwave Garage Door openers next. Good stuff!

Goodbye to a great audio and video genius and writer... JOHN GANNON. I enjoyed your friendship, wit and a nice long run we took around Indianapolis at CEDIA years back... and for buying my Runco 980 Ultra years back... you saved my ass! Rest in peace.
thebland is offline  
Sponsored Links
Reply Home Automation

Thread Tools
Show Printable Version Show Printable Version
Email this Page Email this Page

Forum Jump: 

Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off