Frustrated with home automation software

[Dean Roddey]

You can always load multiple instances of a driver in CQC, each one talking to a separate VRCOP. CQC wouldn't care one way or another. And of course since CQC is fully networked, you could have one driver running on one end of the house and another on the other.

 

[Deane Johnson]

NeverDie, I need to be clear, I'm only running 12 nodes.  However, my comparison on speed is with the same number of nodes with both Elve and CQC.  How CQC compares with the other software you mentioned is something I have no experience with.
 
I don't have any idea why or where the difference in speed occured.  Since the VRC0P is a serial device, it wouldn't be in the network.  I'm suspecting the speed is in the HA software since the entire list of event executes fast, including the IR which is from the GC-100 which is network based.
 
John Hughes, creator of Elve is a superb programmer as is Dean Roddey.  That's why I'm sort of surprised at how much better CQC is performing for me.  Since I'm using the same peripherals and the same network, I keep going back to the software being the difference.

 

[Frunple]

NeverDie, I need to be clear, I'm only running 12 nodes.  However, my comparison on speed is with the same number of nodes with both Elve and CQC.  How CQC compares with the other software you mentioned is something I have no experience with.
 
I don't have any idea why or where the difference in speed occured.  Since the VRC0P is a serial device, it wouldn't be in the network.  I'm suspecting the speed is in the HA software since the entire list of event executes fast, including the IR which is from the GC-100 which is network based.
 
John Hughes, creator of Elve is a superb programmer as is Dean Roddey.  That's why I'm sort of surprised at how much better CQC is performing for me.  Since I'm using the same peripherals and the same network, I keep going back to the software being the difference.

You obviously have something set wrong. there's no delay at all in my set up.

 

[Deane Johnson]

You obviously have something set wrong. there's no delay at all in my set up.

 
That is certainly possible.  I don't know the reason for the difference.  My IR is much faster also with CQC, virtually instantaneous via the network.
 
With Elve, sometimes a single command was very fast, other times it lagged a second or so.  I always blamed the network for the delay, but with CQC, I'm using the same network with no changes.

 

[Dean Roddey]

To be fair, CQC is the product of almost 50 man years of effort (over the last 20'ish years real time), built on a completely custom, general purpose object oriented infrastructure that was a decade in the making before CQC was even begun, and has been expanded dramatically since then. So it's lean, compact, and very well developed, and in C++ which is a very efficient language. That's a huge advantage that most folks won't have, so they will have to work at a higher level, using more black box third party code and these days likely a much higher level, less efficient language. When you are talking about a hugely multi-process/thread, networked system, it makes a difference.

 

[ChrisCicc]

Speed, and what kind of hardware it takes to get it, really is important because high latency implies low WAF.  What sort of hardware is required for CQC to be nearly instantaneous?  In looking at reviews of home automation software, speed is rarely mentioned.  
 
Are HCA and CastleOS nearly instantaneous too?  I started with Vera almost two years ago, but I had to abandon it fairly quickly because I found it pathetically slow with anything but a small numer of z-wave nodes.  I'm currently running about 60 nodes, but I'll be closer to 80+ nodes when I'm finished.  I wouldn't call HomeSeer fast in absolute terms, but it is fast in comparison to Vera if it's running on a fast PC.  Ideally I would just try all the home automation software packages, but there are just too many, and it would take too much time to vet them all, so I need a good short list to work from.  I agree that this thread probably has some good leads, especially for software I hadn't heard of before.
 
Aside from being speedier than Vera, the thing that originally sold me on HomeSeer software is that it can get better z-wave robustness by running multiple z-trollers to get better z-wave coverage and with fewer hops (and fewer hops also helps reduce perceived lag time).  Can CQC do that?  HCA?  CastleOS?  Elve?  Anything else?  Even Vera had something similar, which worked using UDP over ethernet.  Without some kind of multiple, distributed z-wave interfaces, I'm convinced that z-wave just doesn't have the required reliability that I need.  I've tried it both ways, and so I'm pretty confident of that.

 
 
I can only speak for CastleOS, but yes it's instantaneous. The time from when you press the button on the app and when the command is sent to the relay (for mesh networks) or device (for IP devices) is measured in milliseconds. As CastleOS is not cloud-based, when using the app over the home WiFi there is no discernible delay.
 
Where you can run into delays is with the protocols themselves. Neither Z-Wave nor Insteon are particularly fast, and when cycling through several devices it can take a few seconds. (For the record, Z-Wave is faster than INSTEON.) It's also possible for some systems to have more efficient queuing than others, which can cause delays on some controllers but not others. 

 

[jlegault]

I'm really tempted to move to CQC after my brief encounter with HS3 (and 8 years of HomeSeer). Can someone comment on how robust a very large (50-70 nodes) zwave system would be? In the early days of zwave, networks seemed to benefit from routine optimizations, which is now core to HomeSeer's zwave management - I guess for that reason. My network is so messed up at this point with HS3 and my ztroller, I'll have to purge and set it up again - and I might as well try something new. I'd also be integrating it with an ELK (thermostats and core rules that control sprinklers, scene lighting, and temperature run on it) and roomie remote. At one point I attempted to make the ELK the zwave system of record, but it's not really setup for success in that department. Thoughts appreciated. 

 

[pete_c]

Here still using Homeseer.  Though its primarily Homeseer 2 production.  Production Homeseer 2 has some 20 plus serial / upb devices plugged into it.  There is no Wintel automation software that I know of today that will talk to all of the stuff that I have connected today to Homeseer 2.  I doubt too that there will be in the near future. 
 
I am testing Homeseer 3 and only on LInux today.  I am mostly in a wired mode and prefer not to utilize wireless for anything in my automation.  That is me.  While I believe that wireless is convenient to use and many times the only practical solution; it is not for me.
 
While the HSTouch designer and clients are very flexible (running on Wintel, Android, Linux and iOS) over the years it got too fat.  The GUI is very flexible and looks nice if you don't touch it.  I always broke mine trying to put too many variables on the screens.  I also pushed HSTouch with some 20 or more clients connected to it trying to break it.  That said thinking HST is moving towards a clean up of the designer and interfaces which would be a nice thing.
 
I purchased Z-Wave for Homeseer and do have the Z-Troller and Aeon stick plugged into Homeseer but never jumped on the Z-Wave bandwagon for my primary lighting automation which is UPB today. 
 
I am playing today also with Zigbee light/appliance switches and wireless trinkets following the same path as Z-Wave.
 
I don't think there will be a "winner" of the two aforementioned wireless protocols. 
 
That said though most likely you will see a whole home wireless Z-Wave / Zigbee "kits" for less than $100 sometime soon.  Maybe Insteon too.
 
I initially migrated  my in wall light switches from X-10 to Insteon and now UPB. 
 
I have no problems with my UPB light switches and never pay attention anymore to them.
 
I did test and play with Z-Wave light switches at one time.  (still have Z-Wave stuff going though).
 
I never did or do look at the Z-Wave connected to the Leviton HAI OPII panel as it just worked fine for me. (that is me though).
 
The above noted I do still utilize X10, Insteon, UPB, Z-Wave and now Zigbee.  (some play and some production). 
 
No "production" security or automation is wireless today.

 

[Dean Roddey]

I'm really tempted to move to CQC after my brief encounter with HS3 (and 8 years of HomeSeer). Can someone comment on how robust a very large (50-70 nodes) zwave system would be? In the early days of zwave, networks seemed to benefit from routine optimizations, which is now core to HomeSeer's zwave management - I guess for that reason. My network is so messed up at this point with HS3 and my ztroller, I'll have to purge and set it up again - and I might as well try something new. I'd also be integrating it with an ELK (thermostats and core rules that control sprinklers, scene lighting, and temperature run on it) and roomie remote. At one point I attempted to make the ELK the zwave system of record, but it's not really setup for success in that department. Thoughts appreciated. 

 
It'll be a LOT better if those nodes support associations. Attempting to poll that size a network would be sub-optimal at the least. Those that don't support associations can always be used in a write-only fashion so that CQC doesn't have to try to track their status. However that will prevent those from being used in the auto-generated user interfaces, which require that lights be read/write. Our old (V1) Z-Wave driver polled, but it's just not worth doing once you have more than a fairly small number of units. If it takes, on average, half a second to poll each unit (and still have time to let the Z-Wave network have some recovery time and to allow outgoing commands to be processed and such), 70 units would mean 35 seconds worst case between the time you changed a light at the switch and the automation system seeing that change. That's pretty useless.
 
So our V2 driver just requires associations if you want two way control. It will 'poll' some stuff that only needs sparse polling, like battery level which can be done on the order of hours apart, but for actual current status, it requires that the units be able to report their status asynchronously when changed at the module. And it'll do a once in a while poll as a test of whether a unit is alive if nothing has been reported asynchronously in some time. But that's it.
 
I know that sort of sucks, but it's really a limitation of Z-Wave. It's not fast enough to poll at high enough speed to keep the latency low enough to be useful when you have a large number of units. And most folks tend to have some number of units that are iffy on the mesh network and those will take longer to respond, which can slow it a lot more. An association based network is likely to be more stable because it's not being beaten to death constantly trying to poll it and being pushed to its limits.
 
Of course you could always let the Elk talk to Z-Wave and let CQC talk to the Z-Wave units indirectly via the Elk. CQC wouldn't know or care. As long as you are happy with the Elk's keeping up with the status of the units, you can use CQC to do all the logic stuff.

 

[jwilleke]

I'm enjoying this topic as well. Deane I would add on the Insteon topic that if by-and-large you're not having a problem with X10, you won't have a problem with Insteon. I have been in the Insteon camp since the beginning and while there were some growing pains at first with the quality of the gear coming out of Smartlabs, I haven't had a single problem in years, quite literally. I too had a house that was X10 friendly, and rarely would have a dropped X10 signal which made the transition to Insteon much easier. I have since moved and now have a large mix (about 45-50 devices) of devices now and it all just works.
 
Not trying to talk you into switching, just offering a different point of view. 
 
Also, WRT Elve - even though it's changing, why are you considering switching? If everything is working and you're not looking to expand into hardware not currently covered with Elve's feature-set, why move at all? You might be able to ride the wave a while longer until it's either open-sourced or a more suitable replacement comes along.
 
Terry

"..you won't have a problem with Insteon.."
 
When it first came out I jumped on the Insteon bandwagon.
I already was using a lot of smarthome products in X-10. The advertising and specs sold me on the protocol.
Then I find out that the devices really did NOT do Powerline And Radio as the specification and advertising said they would. 
(They only recently, in the last couple of years started shipping the dual mode devices).
Spent more than $1,000.00 and now it all sits in a box with a lot of other Home Automation pieces.
 
Insteon has a huge issue if you have backup power supplies. Never had issues with X-10 (well at least on the power line side of things)
 
-jim

 

[jwilleke]

And continuing the main topic, I agree. The interoperability AND usability of the product is terrible.
 
You basically have three choices: (or some combination of the three)

• You buy it all from One Vendor 
• You hack and cuss your way through multiple vendors.
• You hack and cuss your way through open source.

I have OmniPro II with

• 50+ Z-Wave Devices which are almost entirely Leviton.
• Another 20+ Wireless HAI Devices
• Another 20+ Hard-Wired Devices
• Another 15+ Home Grown Relays and sensors

The OmniPro was great. But it has not had any real updates in more than 10 years. Yes, they added EEProms so you would not have to buy and replace the chip on the board.
And they added two more serial ports, so now you have 5 serial ports. (I have not updated the board as HAI wanted $900 to upgrade the board)
But, My Cell phone has a lot more memory and cpu than the OmniPro and many more modern methods to communicate.
 
Then there is Z-Wave. 
I see adds that it is simple. Well there is NOTHING simple about it. The protocol is complex and the interoperability is ridiculous.
And they want you to type in names and labels and setup associations on a 2" (if you are lucky) screen on some BATTERY powered remote that you can not backup your Z-Wave network if the remote or some other device destroys your network.
 
Needles to say the OmniPro is not suitable to be a Primary Controller as you can not take it with you to add a new device.
Tried Vera 2. It was pretty good but you really want me to take it down off the wall and walk around to add a new device. And it was mostly a hacker thing.
Been using Leviton's USB Stick and there Installer Software. So now I need to lug a Windows laptop (I am really more of a OS X guy) around and update controllers and add a new device.
Leviton's software nor OmniPro want to talk to my Z-Wave Thermostat or not well.
Also have a Aspire Battery remote that seems to do ok. But a 2" screen with no backup. And it will not read the location infor from the Leviton device.
It is a secondary though so I can not add any new devices. I would make it a primary, but no idea if it will work with the Leviton devices.
 
So I am still looking for a Primary controller that works. Personally, I think the whole premise of Z_Wave is flawed. Lot of limitations like distance and number of associations.
And no one is consistent on the Z-Wave terminology.
Can anyone provide a real explanation of Areas, Groups Associations, Scenes along with a comparison and when you should use one vs the other? None of the vendor products seem to agree.
 
Tried a couple of the open source like OpenRemote and OpenHab. Way too much Geek time required for me.
 
Anyone have any serious advice on how to make this stuff cooperate?
-jim

 

[Frunple]

Well, I can tell you that you don't need to carry around a laptop to add zwave devices. There's no reason the device has to be "in place" to add, zwave networks will determine the neighbors as part of the mesh. 
So add the devices to the installer tool right at a desk, then go put them in place, then "rediscover" the network and it's fine. That's how I've always done zwave networks and they always report the proper neighbors.

 

[jwilleke]

Thanks for the tip and feedback.
"So add the devices to the installer tool right at a desk, then go put them in place," So you think I should wire a device upto 110V and then move it into position?
 
This is not what we should expect from todays home automation systems. We have all kinds of protocols to perform dynamic discovery. When you can buy an Arduino type device for ~$25, no one can make a light switch for $100 that can be dynamically discovered or included from anywhere in the network? 
 
There was at one time roles for SUC (Static Update Controller) and a SIC (Static ID Controller) available in the Z-Wave protocol that was supposed to do this, But my understanding was that it was removed in the latest versions and I could never find any controller that performed this functions that did not declare themselves as the primary which would be both roles on the same device.
 
Home Automation should be something my adorable wife should be able to do. We should be able to swap out one home automation controller for another without disrupting the network or walking around all over the place.
 
And why do (almost all) Home Automation systems use proprietary scripting ?  Did they not see that ECMA/JavaScript Script won this war several years ago ?.
 
And as too all the discussions of speed. With todays powerful CPUs and GOBs of memory available the processing on a controller can not be an issue (well ok if it is really poor programing or design I guess it could be) regardless of whether it was written in C or C++ or Java or .NET or PHP or ....
 
-jim

 

[Dean Roddey]

Thanks for the tip and feedback.
"So add the devices to the installer tool right at a desk, then go put them in place," So you think I should wire a device upto 110V and then move it into position?
 
This is not what we should expect from todays home automation systems. We have all kinds of protocols to perform dynamic discovery. When you can buy an Arduino type device for ~$25, no one can make a light switch for $100 that can be dynamically discovered or included from anywhere in the network? 

 
Well, to be fair, the one is based on the technology created by a market that moves hundreds of millions of units a year, so massive economies of scale. It's not quite fair to compare that to a market that moves units at a fraction of that bulk, and which has much more stringent expectations of just working out of the box.
 
BTW, I'm not sure we have 'all kinds' of discovery protocols, not in the sense that they are ubiquitously supported. Of course Z-Wave could have used a proprietary one, and they do. But for security reasons they chose to require low power transmission for enrollment, to make it harder for someone from the outside to get themselves into your network. At the time that all of this was done, there was no support for encryption in Z-Wave modules, and of course that means that most modules that exist don't have it. Without that, network wide, long range auto-enrollment would be sort of dangerous.
 

And why do (almost all) Home Automation systems use proprietary scripting ?  Did they not see that ECMA/JavaScript Script won this war several years ago ?.

 
Because these system have to be supported. If you want to hack away, you can do that and there are 'you are on your own' type products out there I'm sure that will allow it. But if someone is selling you a product, and they are going to be the ones getting yelled at if it isn't working right, then the less such open ended, uncontrolled entry points to the system the better. JavaScript is a horrendously loose language, which would let people shoot themselves in the foot before they even got it out of the holster for the most part. It's one of the last things I'd want anyone writing critical logic in.
 
I always point to Homeseer as an example, and the tremendous pains they've gone through to bring their product forward. I'm sure that a lot of that was due to the fact that they allowed general purpose languages to be used for drivers and customization. That means they have zero control over what those things are doing and when and how. So it becomes almost impossible to move forward without breaking a lot of stuff and/or spending enormous amounts of time supporting the old system plus creating a new one (and thus ending up with a system not really any safer, more complex, and more difficult to support.)
 
We, OTOH, have our own language, and except for a couple of small exceptions, every driver and user action (logic) ever written is still viable today without any of the above issues. We could move them forward easily as the product evolved by leaps and bounds, because we control what can be done and how. It makes a huge difference in the long term stability of the system.

 

[picta]

Personally, I think the whole premise of Z_Wave is flawed. Lot of limitations like distance and number of associations.

You nailed it, so don't use z-wave if you want a reliable whole house automation. z-wave is a protocol, not a product, so no z-wave devices are created equal. I only use these as a supplemental extension of my HA, if it goes bad, it's not a big deal. Wireless devices will always perform sub-par compare to wired alternatives, but when it comes to lighting, there is not much of a choice. IMO, the best bang for the buck are zigbee based centralite switches, my friends and family use these successfully for over 5 years now. The next best choice, but much more expensive, is RadioRA2. Both products are very robust, and come with extensive RS232 command interface, so you can integrate them with almost any controller.