What application to try next?

Nugget

New Member
I've had a few false starts, and before spending hours and hours on yet another unsuitable home automation application, I wanted to get some advice on what to do. I've tried three approaches so far, and none of them have worked the way they should right out of the box, and all have been incredibly difficult to get set up and running, requiring programmer-level knowledge. What options are out there that an average non-programmer can get up in running in a day or two?

I'm exclusively Z-wave, with Leviton switches, a ZRTSI shade controller, some IP cameras, and kwikset locks. So far I've tried:

1) Vera: but there's a bug and it can't properly operate my dimmer switches (the majority of my switches)

2) Premise: no support for the ZRTSI and awful interfaces

3) Elve: couldn't detect my switches, and my trial expired while Leviton was trying to figure out if it was my controller or the software causing the problem (I'm not buying anything else unless I know it works). In addition, no step-by-step instructions

Homeseer seems to be more mainstream, but it's so expensive - it'd set me back $500. CQC is expensive too, and looks like it'd require a programming backgroup.

Is there any software out there with step-by-step instructions, beitween $50 - $200, supports Zwave out of the box, and that I could get running in a day or two? I'm at a loss right now...
 
Bugs can be fixed if you otherwise like Vera - may not be overnight but with enough squeaking...

Also for Elve, John would probably give you an extension if you just drop him an email; I'm sure he'd understand.
 
Premise can be made to fully support the ZRTSI very easily (in vbscript), provided the commands are available on Leviton's VRC0P. If it can't work with the VRC0P, how is it going to work with Elk or any program that uses the VRC0P?

I guess you could wait until one of the other Premise users gets a ZRTSI or post your port spy data and some documentation on the ZRTSI. No offense, but considering you didn't even respond to my last post offering help on the subject (http://cocoontech.com/forums/topic/21982-gui-changes-a-zrtsi-shade-controller/), I really don't know what to tell you other than to hire someone or buy a program with tech support that you can call.

Homeseer does have a very knowledgeable engineer well versed in z-wave. HS doesn't use a VRC0P either, but instead interprets the raw z-wave data in its entirety using their own RS232 Z-Troller. This may be your best option. I would buy their professional version though as it's cheaper in the long run.
 
I've seen lots of posts of this type and it is really hard to provide an answer, mainly because what is difficult/cheap/versatile/etc... to one person, will not be so to another.

The best thing you can do, though it will take some time, is to download trials and play around with them.

IMO, HomeSeer and CQC are more costly than most as you mentioned, but they are more seasoned as well and worth the look.

I thought CQC strives to provide a basic starter setup on their latest version (just to get a new user setup on basic tasks with minimal time), but don't know this first hand.
 
Yes, Dean has auto-generation features in the latest version of CQC to get you up and running with an initial set of screens for common features with no scripting required. They have a trial version if you want to play around and see if it works with your ZWave devices.
 
And, just for the record, no programming is required in either case. It's all done through configuration. We have recently added a VRCOP based Z-Wave driver (to replace our native Z-Wave driver that we used before.) Z-Wave, though in theory standardized, isn't really. It's semi-standardized, so it can be tricky to interface to sometimes.
 
The Vera issue was showing up in May, and still doesn't appear to be fixed - so I'm not going to hold my breath on that. So far, the package that has worked the best straight out of the box has been Premise - I was pretty impressed that I was able to get it up and running quickly, and that the standard interfaces worked ok, though they leave a bit to be desired. But I don't know vbscript, so trying to write a ZRTSI driver was a nonstarter, and I put in about 40 hours trying to build a nice touchscreen interface for my ipads, only to become dismayed at my less than mediocre design abilities. I apologize if I offended you, etc6849, for not responding - at that point I had realized that writing drivers and doing design of touchscreen interfaces was beyond my abilities.

Elve didn't seem to be able to communicate with my VRC0P for some reason, and when I installed the package on a laptop (not my home automation server) just to try to keep testing it, I still had errors, even with the updated zwave primary controller. My VRC0P worked fine with Premise, I don't know why it doesn't seem to be able to play nice with Elve.

So maybe my options are A) Try to hire someone to write a vbscript driver for Premise, and build a new interface or B) I just noticed that the step up sale for CQC is this month, which actually puts it in my price range (I have 15 switches, ip cameras, 4 shades, and locks, so my device count is beyond the base level). Maybe I should see if I can get that working?
 
The Z-Wave driver is just one driver. It's not one per Z-Wave device. From CQC's perspective, the 'device' is whatever it's physically (or virtually in some cases) connected to, not other things that may in turn be connected to that. So the Elk is one driver, the Omni is one driver, Z-Wave controller is one, etc...
 
You don't need to write a ZRTSI driver for Premise. All that is need is added a few properties and defining a ZRTSI class within the existing VRC0P module's exposed source code in builder. The code is only 8 lines or so!

The issue here is that you need to answer key questions about the VRC0P and how it works with the ZRTSI. If you can't answer those questions, I definitely would not purchase ANY home automation program that uses the VRC0P.

I don't know if you know it or not but the VRC0P protocol is not the entire z-wave command class protocol. It's a simplified version that Leviton gives us as the real z-wave command class protocol is proprietary and kept secret from users. If you open the VRC0P up, you'll find that there's actually a microcontroller in between the zensys chip and the com port you're connected to. This microcontroller does the interpreting and is programmed by Leviton (that's why you use their protocol).

Some key thoughts:
1. What does the VRC0P see for the ZRTSI when it performs a discovery?
2. What zensys z-wave command classes are supported by the ZRTSI?
3. Are there some proprietary commands that can stop the blinds or define a set position? (I think that was your original issue with Premise)
4. If so, can the proprietary commands supported on the VRC0P?
5. What is returned for manufacturer/product type/product id during discovery?

I would also read various forums and find out the exact VRC0P commands and what they do. If not, I would use something that supports native zensys z-wave commands such as the z-troller. http://store.homeseer.com/store/HomeSeer-Z-Troller-Z-Wave-Controller-P214.aspx

There are commands that the VRC0P cannot perform such as controlling the led lights on Leviton's z-wave zone controllers. And yes, something like the z-troller or vera can do this and the VRC0P can't. Good luck trying to get Leviton to add a useful feature like that; I talked with two of their engineers and they still haven't done it. I was also surprised to find out that such a thing would not be possible without a firmware upgrade of the VRC0P.

What ever you find on the VRC0P and the ZRTSI compatibility, please post it hear to save others the same research... The z-wave technology is kind of a bust as information is not readily available on packaging for simple things like which command classes are supported. It seems manufacturers don't care to provide purchasers with commands to use their devices either.
 
There really isn't any single set of step by step instructions to build a DIY automation solution. Every one of them is different. The videos are arranged in order of how you would basically go through the configuration of the system. That's the best we can do. No matter what your solution you'll use those fundamental steps outlined in the videos, but you'll use them in very different ways depending on what you are trying to do. What you would do to set up a remote control driven home theater system is very different from what you'd do to set up a smart phone based security and lighting system.

On the other question, obviously about our Z-Wave driver, the problem is we can't tell you the answer. Z-Wave is not a product, it's a loose confederation of manuacturers making products around a 'standard', but that standard is pretty loose and has evolved quite a bit over time. We can't possibly have built in knowledge of all of the possible devices, and others are coming out all the time that we don't know about. Some are capable of reporting status asynchronously, but only if set up correctly to do so and how to do that is unit specific. Some can't at all and have to be polled, but we can't tell you how quickly to poll them. That would depend on the size of your Z-Wave network and how healthy it is, and whether some of the units are more important to you than others (and therefore you want to minimize current status latency on those.) Manufacturers are supposed to provide this type of info to users, but they often don't, or not in any way that's easy to find.

If you want to move up to something like Lutron, where it's all provided by one vendor, and tightly integrated, and all we have to know about is their controller and that's it, then it gets somewhat easier because we don't need you to tell us that sort of stuff.


That's not to say we couldn't potentially do some videos where we just set up a few small solutions of a particular type. But I kind of imagine you'd end up just as frustrated because we can't tell you about your hardware, or explain simply how to do what you want to do, given your particular situation. I wish we could, since we'd probably be rich, but I don't think it's possible. It would require us documenting all of the foibles of the possible hardware you might use, in all the configurations you might want to use them, i.e. how they might interact with any other harware you might have, since a primary function of a system like CQC is to tie them together in useful ways. That would be a document that would make the collection of US tax law look like a manga comic probably.
 
Back
Top