What is wrong with CQC?

[ano]

I don't want my response to be taken in this context as I'm not the poster boy for CQC issues.  I had a problem with one driver, and like Dean said, one line of code.  Unfortunately, that was the driver that I bought CQC for and had intermittent problems.  The issue has been fixed.  Unfortunately, everything has its time and my time to do home automation has waned.  I hope I can find the time and recapture the passion to make that happen again.

I think the driver problem is one that wasn't talked about here. I found CQC very stable in operation, and I rarely had a problem with that code. but I relied on two drivers for 95% of what I did; the UPB driver and the HAI driver. Everyone has different important driver, but these were the ones I really needed to work well.  In 10 years of using CQC, they never did. The UPB driver was written by a third party who is long gone. What this means is I had a better chance of getting hit by lightning then getting bugs or new features added to that drive. The HAI driver was written by Dean, and although it was stable and worked fine, new features were never added when HAI added new features. Again, a driver stuck in time. 
 
Of course if I go to the driver page on the CQC site, everything looks great. The HAI and UPB drivers are so you assume they are up-to-date.  WRONG. 
 
I think Dean needs to go through EVERY driver listed on the CQC site, and give each some love. Ask customers about bugs and features wanted, and within reason, make them happen. If a driver is NOT updated, then clearly mark it UNSUPPORTED or remove it from the site.  Drivers ARE important.

 

[jkmonroe]

Yes.  Since we brought this back around to the the original topic, this is definitely what is 'wrong' with CQC.  I said it in one of my posts long ago in this thread, but I think that the codebase needs to be locked for a cycle or two and 100% of focus put into updating and developing drivers.
 
Making certain drivers official like Nest, Ecobee, and XBMC, updating the Tivo driver to the latest protocol, getting a driver out there for Plex, and making a repo for both Plex and XBMC, get a driver written for the Denon, Pioneer, and Onkyo lines of receivers (all IP, and I think one was just done for Yamaha), go on Amazon and find the most popular two or three projectors and get drivers written, get some stuff done for the IP controlled TVs like the Sony W series (controls power via IP), and CCTV items like Dropcam and BlueIris.
 
It is also worth considering, although unlikely, updating drivers for some of the base devices to newer gizmos.  The VRC0P hasn't been updated by Leviton in 3 years, so explore the Z-Stick 2.  Everyone likes the ISY, but explore the official Insteon API and their hub.  Really get in and expose everything for Hue and explore the options for hooking into the Harmony Hubs.
 
Take a look here: http://www.roomieremote.com/device-compatibility/
 
If it is on that list, then it will have solid two-way IP support.  This is what I use when buying equipment since I know that it would be possible to get total control.  That list encompasses just about every device someone would want to integrate in their home.
 
Look at how cool it would be if there was official support for Insteon.  You could use their hub and do this:
 
http://www.insteon.com/applewatch

 

[NeverDie]

Does anyone here think I actually don't want to fix anything that could be wrong with the product? Obviously I do. The ones that get quickly fixed are ones that are repeatable, by me I mean. If I can repeat it, I can figure out what the problem is easily. It's a lot harder to fix problems that only occur on customer sites, and equally hard to fix things that only happen after some period of time. When it's both, it's extremely hard. We can't bring our entire debugging apparatus to bear on a customer's system, so it's trickier to deal with. We do try to provide plenty of logging to help, but of course you can't log everything, so it doesn't always work.
 
But ultimately we would of course like it to be completely flawless, since that would mean the most sales combined with the least support. It would be the ultimate outcome. And I'm sure every other software company feels the same. But, for anything pretty complex, I don't think anyone actually really achieves that, not for all potential users anyway.

Makes total sense to me.  It's reality, and so denying it is unproductive.
 
If you haven't already, I strongly suggest you publish the details of your most heavily vetted, least buggy configurations that you have in your test lab.  That way, if someone hasn't yet bought hardware, or wants to upgrade from an older system, they can buy the exact same configuration.  Then, if someone encountered a probable bug, they could send you an image at the same time they filed a bug report, and you'd have it instantly in front of you.  Especially now that people are using VM's, that would make it perfectly feasible, wouldn't it?  Furthermore, a standardized, optimal setup could be as easy as downloading a VM.  Then, anybody who wants to be can on the exact same page as you are.  If that means getting faster resolutions, sounds like a win-win to me.
 
When I wanted to learn something about  ESXi as a total beginner, I bought the most popular, highly rated platform (motherboard, CPU, and even memory) for that purpose, because I just didn't want to get snagged on some detail that would become a major distraction from that purpose.

 

[fcwilt]

Given the good quality tools built-in to CQC for writing drivers it would seem that folks should join together, decide what needs doing and assign projects to teams of two for developing these drivers. 
 
While Dean can do it all it might go faster, given skilled coders, if top notch drivers were developed by CQC supporters.

 

[ano]

Given the good quality tools built-in to CQC for writing drivers it would seem that folks should join together, decide what needs doing and assign projects to teams of two for developing these drivers. 
 
While Dean can do it all it might go faster, given skilled coders, if top notch drivers were developed by CQC supporters.

In theory that works, but the problem is many times some third party submitted a driver, and at the time it worked great, but then this person is now gone, and the driver never gets touched.  Community maintenance sounds good, but this isn't always possible with many drivers.
 
I think the real issue for me is not so much maintaining driver, but that is very important. The issue is that many drivers are listed on the web site as supported when they haven't been looked at in years. As many have mentioned, just jumping into CQC is a big commitment in time, and its really unfair for these people to think their hardware is supported when in fact it might not be.  As others have also said, people may only need one or two drivers, but if that driver doesn't work, then it really doesn't matter how great the other drivers are.  I know Dean will come back with that you can see what the driver supports, but a new person may not fully understand this.  Also, take the UPB driver.  It is on the CQC site, and it lists all different great things it does. But what it doesn't do is work when more than two or three commands are sent in a row.  It also doesn't work at all unless you use this third-party program that takes your UPStart device list and converts it to a file it can understand. This converter program hasn't been around in years. I could go on, but you get the idea. If UPB is NOT really supported by CQC, remove that entry from the site.

 

[Dean Roddey]

You guys are really missing the point on the issue of drivers supporting every single aspect of a really complex device. That is something that makes a difference to a tiny fraction of users. The thing that makes a difference, is whether the core features of devices are available in a way that's easy to implement. 99% of users would take basic support that they don't have to be experts in order to make use of, than 100% support that they can only get to by doing heavy customization work (something that we've already established time and again in this thread is not viable for the vast majority of users.)
 
So, we spent the last year do exactly what is required to address that. Instead of spending time taking every driver to the Nth degree, we created a completely new way of doing drivers that allows us to auto-generate a lot of stuff (and more in the future) and in reworking a lot of drivers to fit within that paradigm. That was a huge amount of work just to do that. And it's paid of very nicely, and will reap a lot more benefits moving forward.
 
As I said before in this thread, you can't have it both ways. If we need to make the product more accessible, you can't blame us for spending our time working on that.
 
As for the UPB driver, the problem is that it can't just be updated, it needs to be reworked to be V2 compatible, and it will need almost a complete rewrite since the original author wasn't a highly skilled driver writer, and it needs to take advantage of new CQC architectural features as well. And I know nothing at all about UPB so I'd have to do a complete spin up on the whole thing. There just wasn't time to do it. We already took on Z-Wave, ISY, Elk, DSC, Omni, and Radio RA2 during the last cycle, and that was an enormous amount of work. But you can now auto-generate nice user interfaces for all of those devices now, plus a lot more (smaller ones) that were V2'd as well. That's clearly work towards addressing the primary concern expressed on this thread.
 
In the next release we'll address them much more, but all of that V2 driver/auto-gen stuff will be a big part of making the product more useable by more people.

 

[Dean Roddey]

Why not? If it means fixes. BRING IT ON!

 
It would require you having the full development system and the source code on your machine so that we could debug locally there on your system. That's just not possible.
 
Visual C++ does support a remote debug scenario, but for whatever reason it only works on the local subnet. Maybe because it's a gigantic security risk to expose a full debugging interface on your machine to the outside world and they didn't want to deal with that, I dunno.

 

[bbrendon]

My original issue was the core CQC code but I can also see the driver frustration. My offer still stands for Dean to run whatever he wants to improve the code on my system. I've been thinking about this and I think CQC is not for IT people . IT people know how to leverage the "IT system" in powerful ways and I really think CQC has some network level issues that are broken/buggy. If the network isn't 0 packet loss and 1ms latency, CQC is not happy. On real networks, that is not the case. To make CQC happy, I moved it from dynamic interfaces to static, but there is still latency and normal packetloss (like < 0.5%). But CQC still does weird things even though it only runs on one computer, so I dunno.
 
Anyway, on to the driver thing... I used the DSC and UPB driver. I had some issues getting the DSC driver working because it was for older firmware. I think the issue was fixed in upstream after this issue was figured out. 
 
UPB, yea. I thought it would be smooth sailing, which it was until I started really getting into it. Once I got heavy into UPB, I starting finding weird bugs in the UPB driver. Things that are beyond my skillset to figure out in a reasonable amount of time.
 
I've been thinking about upgrading my CQC system from ESXi on a Dell R900 to an HP Steam 7 5700ng! http://www.notebookcheck.net/HP-Stream-7-5700ng-Tablet-Review.134411.0.html
 
....you know, take some of the enterprise IT out of it. dumb it down.
-BB
 

 
 
 
 
 

 

[bbrendon]

It would require you having the full development system and the source code on your machine so that we could debug locally there on your system. That's just not possible.
 
Visual C++ does support a remote debug scenario, but for whatever reason it only works on the local subnet. Maybe because it's a gigantic security risk to expose a full debugging interface on your machine to the outside world and they didn't want to deal with that, I dunno.

How does Microsoft deal with these issues? Better logging, debug output? We could still do the remote debugging, just setup some VPNs or whatever is required.
 
I could see you not wanting to put source code on remote systems. Putting your crown jewels out isn't exactly comforting.

 

[Dean Roddey]

My original issue was the core CQC code but I can also see the driver frustration. My offer still stands for Dean to run whatever he wants to improve the code on my system. I've been thinking about this and I think CQC is not for IT people . IT people know how to leverage the "IT system" in powerful ways and I really think CQC has some network level issues that are broken/buggy. If the network isn't 0 packet loss and 1ms latency, CQC is not happy. On real networks, that is not the case. To make CQC happy, I moved it from dynamic interfaces to static, but there is still latency and normal packetloss (like < 0.5%). But CQC still does weird things even though it only runs on one computer, so I dunno.

 
I doubt that could have anything to do with it. With the one exception of sending out event triggers, CQC purely uses TCP level communications. TCP deals with packet loss and retransmission, and the application never knows about such things. So any failure due to that sort of stuff would have to be below CQC's level, and it's probably not too likely.
 
On the static vs. dynamic address thing... I think that the simplest thing to do is to just enable IPV6 on all of your machines. Assuming you aren't getting IPV6 addresses from your ISP (and probably few of us are), then you just set up IPV6 to automatically choose an address, which means it just creates a known unique address based on each machine's MAC address, so it doesn't depend on DHCP even. Each machine just gets a unique IPV6 address without question.
 
As long as your router's DNS correctly returns IPV6 addresses for those machines that have enabled it, then CQC will get that IPV6 address (since it never requests a particular IPV6/IPV4 format when taking to another CQC process, it just asks for an address and uses what the DNS gives it.) If you have V6 enabled everywhere, I think that the router's DNS will return those over the IPV4 addresses, right? It always seems to in my experience.
 
That way you get the benefits of a static address without any DHCP overhead or DHCP caching weirdness and the like.

 

[jdk972003]

All these discussion points come back to the business model.  More users means more testers means bugs are determined faster and solved sooner. But more dealer users is not the same as more DIY users necessarily.  Dealers use the same equipment over and over.  If your driver works for them, it always works for them.  DIY is different almost every instance.
 
If you were aiming for dealers you could focus on drivers required by your dealers and list those as your 1st tier officially supported and constantly updated drivers.  These would always work, and stay updated (weekly?).  All other drivers could be labeled something different, 2nd tier?, and they are updated annually/biannual/whatever works for your business model.  Then you could have a third tier for anything else which you have a driver, but no guaranteed update schedule.  This would provide your users some guidance on expectations for driver capabilities.  Maybe instead of tiers you can grade them A+, A, A-, B+, etc etc.  You get the picture.
 
This gives your DIY a core equipment support list as well as what may work but may not do EVERYTHING the component is capable of.  It would also allow you to schedule your own time between system/drivers/support and track how much is going to what.  At some point your going to require additional help if you want to grow and this would tell what type of help will be needed.
 
Just food for thought.

 

[dgage]

This reminds me of a game system...it isn't the system, it's the games.  As proved by the Wii at one point, it was the least capable machine among Xbox 360, Playstation 3, and the Wii.  But the game play was so good that it overcame the system's lack of power and graphics capability...until the competition caught up with similar interactive systems. 

 

[jkmonroe]

A hypothetical:
 
Denon X1100 HTR $350, Sony W600B 48" $520, HEOS (sticking with Denon) for BR $300 or Sonos for $200, Nest Thermo $250, Roku $100, Caseta Hub $150, Harmony Hub $100, Plex Repo $0
 
Throw in 2 Winbook TW700 tablets for $120 total and CQC Bronze at $200 (give them 2 clients).
 
You could *easily* automate a 2BR condo or apartment for $2,500 depending on how many switches/outlets/sensors are used.  Full, two-way control of every primary component in your home including media, that is easy to retrofit.
 
But only Nest, Roku, and Sonos have CQC drivers, and Nest is third party.  Just think about the volume you could sell with something like that.
 
To make it more CQC friendly you could replace the Caseta with Hue and Hue Tap, but that's it.  No one in the above scenario is buying a VRC0P or ISY.  If the Insteon Hub were supported, I could see that being used, though.  

 

[Dean Roddey]

That's generally going to be true for any particular list of devices you choose, with any automation system you choose. No one can support everything. In the A/V receiver world, they grow like weeds. Whatever you support this week will be out of date in a few months probably, and there's no way we can afford to buy all of these devices in order to support them. So we have to wait till someone asks for support and can make the device available to do the driver against.
 
On the Caseta, I contacted Lutron twice, in two different ways, and got nothing back from them.
 
On the Nest we'll get to that one. It was only recently that the means to support it well was in place (i.e. they published an official API, and we got the ability to do async HTTP into CML that seems to be necessary to support it in a reasonable way, though that also complicates things a lot as well.) I haven't looked into it, but I guess the issue is that it's very slow to respond, so the driver can't block and will have to queue up commands and handle them asynchronously. And of course that sucks because then you don't get confirmation on the client that commands worked.

 

[brathnach]

   Just reading through all the posts in this forum with great interest. I have to say I do see value in jkmonroe's idea of locking CQC development at certain intervals to focus on driver support for a period.  Obviously driver development would have to be prioritised in order of user requirement but the last thing any new user wants is driver related issues as I found learning the core CQC software tasking enough in itself. Driver related issues just kill the passion that gets you to delve into home automation software in the first place. 
 
  I also am a happy CQC user and on evaluating the software was delighted that it had drivers that supported the majority of my equipment. However, when setting up some driver issues came to fore. Namely, I could not get the Yamaha RX-V driver to play right with the receiver. Dean was his typical committed self and we attempted a remote port set-up but my broadband was so terrible it proved unworkable. I ended up writing my own PDL driver which gave me sufficient control. It was a great time later that I realised that the reason the driver would not work was because of Yamaha having US and European versions of the receiver and so slightly different functionality. In my case it was something like XM Radio IIRC that goosed the original driver. Again it was a case of 1 line of code, but you can imagine the investigations it requires to get to that point. 
 
   So in my semi-newbie state with regards to CQC, I have to say that the last thing you would want is any fresh users having to delve down to anything to deal with drivers not working as expected. I know this is a gigantic workload and even with that not completely obtainable. However, I could not genuinely blame Dean that a driver he had advertised as working wouldn't work for my equipment, as to do so would expect him to be able to cater for not only different equipment but different versions of the same equipment.
 
   I think that CQC has a strong following as regards extensive functionality and customisation. However, it will always be driver support (and reliability of same) that would really set it apart from any competition. CQC is tasking enough to spin up on. Minimise exposing average Joe users to driver level frustrations and customer satisfaction would soar.
 
Jim