What is wrong with CQC?

That's one of those "can't reproduce" ones. If we'd gotten the port forward set up, I could have figured out the issue quickly and updated the driver to deal with that variation (now that we knew it existed.)
 
BTW, we now have a V2 compatible 'universal' Yamaha A/V receiver driver, which supports those modules that implement Yamaha's YNC protocol. It allows us to just figure out the available options by asking the receiver, so we don't have to hard code such things into the driver itself. It's been texted on two models so far and adapts to them perfectly. Those models allow you to name zones and inputs, and we pick up that stuff as well so that we can automatically name zone and input fields to match.
 
My thoughts, many yrs ago I purchased CQC, installed it and tried a few things, but never got it up fully running.  Plan was to use to control my home theater equipment.  I didn’t spend enough time trying to get it working and kids, wife, and house got in the way.  I continued to pay the yearly fee for a few years despite not using it and then stopped paying it.  Enough yrs have lapsed that the pricing has change and I can’t stomach the amount I’ve paid vs what little I used CQC, not Dean’s fault but my own.
 
We recently moved, I setup the home theater equipment started getting into more home automation and I’ve been happy trying out Roomie Remote the last few months.  I run it on an Ipad mini and use it to control my home theater equipment, RadiorRA2 lights, Philips Hue, Kodi on an HTPC and raspberry PI.  It is not very customizable, has very little documentation, but is very easy to setup and make changes.  As I add more home automation equipment I’ll probably find it lacking but for now it works for me.
 
You could easily auto-generate some nice user interfaces for RA2 and Hue now with CQC. The price change didn't affect existing users, who were grandfathered in at the highest tier.
 
Well we put out 4.7, so that we could get out the not huge but nice collection of improvements that we had and which we had gotten stabilized nicely. We wanted to get those out there before we took off into the wild blue yonder for 5.0, in which we will address the bulk of complaints expressed here, at least wrt to the UI. A fair bit of work had already been done on the side while waiting for users to vet the 4.7 release. Assuming I don't die of a stress induced heart attack from the strain of effectively recreating the entire product UI, it should be a hugely improved system. The underlying system will remain the same, and have all of the same power, the UI will just be much easier to understand, more helpful, and more standardized.
 
You got much fire in you Dean; and I see that here with your posts.
 
You are amoung friends here that support your efforts; well like family.
 
I have been on this forum a long time and this thread is probably the longest most read thread on Cocoontech today.
 
You did that.
 
364 replies
6484 views
 
Dean is unique in that not only is he a world class programmer, he listens to input and think seriously about suggestions.  His openness with his constituency  is unique in today's product world.  It gives him a massive amount of credibility.
 
I just tried out the latest version so I could tryout the autogen stuff, looks ugly to me but maybe others will like it.
 
There's no way to make everyone happy in terms of creating an interface, at least without supporting a lot of different looks. If you choose something, some people will like it, some won't.
 
I may change it to something else at some point, though that could be an issue if folks have done their own customization in the style that is currently supported.
 
I can make my own graphics so I am not worried, I would not change it if others like it, maybe offer an option to generate a couple of different options instead of just one style in the future if you get enough demand and you don't have other things you need to work on.
 
First, I just want to say that I admire Dean for throwing himself to the wolves. That takes guts.
 
Second, a little bit of background before getting into CQC:
I have been tinkering with HA for about 9 years now (off and on). I've had two ISYs and returned them both because of the proprietary nature and the lack of something as simple as creating a recurring program that does not require a year in the schedule. What I loved about the ISY was it's fairly simple interface (never mind all the Java junk and having to disable anti-virus software). My point is that it was the easiest way to manage my Insteon network. The key phrase here is that it was easy to start with.
 
I was also using MisterHouse to fill the gaps left by my Elk M1G and the ISY. Since getting rid of the ISYs, I now use MH as my only method of Insteon management. MH has come along way with Insteon support over the years so I no long miss my ISY at all. MH is free and although the learning curve was (and still is) somewhat steep, it can do just about anything I want. If a driver doesn't exist, just create one yourself using Perl, not some complicated proprietary language.
 
I've also spent some time with Elve. It was great at first, but creating drivers was incredibly complicated. I loved the ease of deployment and initial config. But again, moving beyond the basics or adding new drivers was tough.
 
I have tried CQC, but from the onset there was a huge list of turn offs:
 - The website required Silverlight. This was shocking and says, "All who enter prepare for anything but open standards". That alone forced me to think twice.
 - The price is really high and the pricing structure is complicated.
 - The system looks very complicated. There was no way of "just starting out simple and migrating to more complex". It was just complex from the word start.
 - It requires Windows.
 - I can't just run install, have an app on my tablet that interfaces with it, and start coding in a simple language after getting beyond the basics.
 - Limited drivers.
 
Suggestions (I know these aren't easy, but these would make me look at CQC again):
 - Lower the price
 - Remove all proprietary bits. IT has been full of proprietary systems that have all died. No one person or company can ever give a community all that it wants or needs. This is why open source thrives.
 - Create an easier way of allowing users to add their own drivers and contribute them back to the community. You can't possibly support every bit of hardware that exists and then support it yourself. So you are limiting your target audience.
 - Enable it to run on something like a Raspberry Pi.
 
I apologize for the ramble, but I think the overall message is there. Just my $.02, and thanks for opening yourself up to comments and criticism.
 
 
 
 
 
The Silverlight web site is gone. At the time we originally did it, HTM5 was far from fully baked, and Silveright was actually very nice. It still makes the baked version of HTM5 look like a high school kid's experiment really..
 
 
If you are using devices that are supported by our new V2 driver architecture it is a lot easier to get started, since we can auto-generate some nice touch screen interfaces for you based on some room configuration. The ISY is one of those devices, and it's actually a nice choice because you don't have to provide any other configuration info, we can get all we need from the ISY.
 
http://www.charmedquark.com/Web2/Downloads/Video%20Tutorials/Version4_6/Tutorials/AutoGen_1.wmv
 
 
As to coding, there isn't any, unless you just particular want to. If it required coding, it would appeal to almost no one. It's all point and click.
 
 
It's already easy for third parties to write drivers and contribute them back. What's hard is writing high quality drivers. CQC isn't a simple program that can get away with simplistic, one way, send and pray type drivers. It needs high quality, two way drivers, and that's seldom easy. And you just don't want to be using drivers that are written by people who aren't qualified to do that kind of work. Unstable drivers make the whole product look bad. And of course the problem with user contributed drivers is that they may contribute them, but they often don't stay around to support them. Then the burden of maintaining them falls onto us, and often they aren't written optimally and need to be considerably rewritten. So anyway, it's a lot more complex issue than it seems.
 
Dean Roddey said:
CQC isn't a simple program that can get away with simplistic, one way, send and pray type drivers. It needs high quality, two way drivers, and that's seldom easy
 
Could you elaborate on that a bit.
 
My current system (Elan g!) is, with one or two exceptions, controlling all of the A/V gear (4 rooms, 16 devices) with one-way IR or serial "drivers". 
 
And it all works just fine.
 
Yes the two-way stuff is nice in that any changes to the device itself are picked up by the system but such changes to the device are very, very rare.
 
For A/V gear you can get away with it better than some, but it limits how slick you can make it. For instance, a lot of projectors have long warm up and cool down times. If you can't know that the projector is already on, all you can do is blindly send it a power on and wait the whole warmup time because otherwise it's not going to be ready before you start doing other stuff. If you have two way control, you can know if it's already on and not bother to wait. Similarly for many media players these days, which have long power on times. You can't do things like automatically lower/raise the lights based on playback starting and stopping. You can't really do things like automatically play trailers because you need to know when they complete in order to know when to start the movie playback. Certain options in A/V receivers aren't valid in certain modes, but you have to know what mode you are in to know what options to present to the user. And there are various others I'm probably just not remembering.
 
In other areas such as lights, security, HVAC, sprinklers, weather info/alerts, sensors of various types, and various other stuff, two way is very much an important part of creating a smart home type of result.
 
BTW, if you do want to create one way drivers, it ain't hard, since it can be done with our PDL language. Here is an example, and this one is a it more tricky than most since it's a binary protocol and the values sent by the user aren't just single values so it has to pull out multiple tokens from the written values, in order to create the msg to send to the device. Some would have more fields, but they wouldn't be any more complicated, just a bit more grunt work.
 
Code:
[CQCProto Version="2.0" Encoding="ISO-8859-1"]

// ----------------------------------------------------------------------------
//  Protocol for the Fibaro Wifi370 RGB LED controller. It's one way only.
// ----------------------------------------------------------------------------

// ----------------------------------------------------------------------------
//  Overall protocol information
// ----------------------------------------------------------------------------
ProtocolInfo=
    ProtocolType="OneWay";
EndProtocolInfo;


// ----------------------------------------------------------------------------
//  Mappings
// ----------------------------------------------------------------------------
Maps=

    Map=PowerMap
        Type=Card1;
        Items=
           Item="Off"   , 0x24;
           Item="On"    , 0x23;
           Item="Run"   , 0x21;
           Item="Pause" , 0x20;
        EndItems;
    EndMap;

EndMaps;



// ----------------------------------------------------------------------------
//  Driver Fields
// ----------------------------------------------------------------------------
Fields=

    // Put the project into and out of standby
    Field=SetBuiltIn
        Type=String;
        Access=Write;
    EndField;

    // Set the power state
    Field=SetPower
        Type=String;
        Access=Write;
        Limits="Enum: Off, On, Run, Pause";
    EndField;

    // Set a static color
    Field=SetStatic
        Type=String;
        Access=Write;
    EndField;

EndFields;


// ----------------------------------------------------------------------------
//  Write Commands
// ----------------------------------------------------------------------------
WriteCmds=

    //
    //  The write command for a built in mode. It is a string in the form:
    //  "mode,speed" where mode is one of the mode numbers and speed is from
    //  0 to 15. As with the static color command below, we have to extract the
    //  whole buffer as a string, get a token, and convert that to a number,
    //  for both values.
    //
    WriteCmd=SetBuiltIn
        Send=
            ToCard1(0xBB);
            ToCard1(ExtractToken(&WriteVal, 0, ",", True));
            ToCard1(ExtractToken(&WriteVal, 1, ",", True));
            ToCard1(0x44);
        EndSend;
    EndWriteCmd;

    // The write command for the power state
    WriteCmd=SetPower
        Send=
            ToCard1(0xCC);
            MapTo(PowerMap, &WriteVal);
            ToCard1(0x33);
        EndSend;
    EndWriteCmd;

    //
    //  The write command for a static color. It's a string in the form:
    //  RR,GG,BB, where each value is a 0 to 255 value for red, green, and
    //  blue. For each one we have to extract the whole buffer as a string,
    //  then pull out the correct comma separated token, and then convert that
    //  to a number. That's kind of piggy, but this is just done in response to
    //  outgoing commands.
    //
    WriteCmd=SetStatic
        Send=
            ToCard1(0x56);
            ToCard1(ExtractToken(&WriteVal, 0, ",", True));
            ToCard1(ExtractToken(&WriteVal, 1, ",", True));
            ToCard1(ExtractToken(&WriteVal, 2, ",", True));
            ToCard1(0xAA);
        EndSend;
    EndWriteCmd;

EndWriteCmds;
 
Just some friendly observations:
 - Open up as much as you can to the community.
 - Place videos on youtube. In 2015, one should not have to click a hyperlink to download a video that requires a player to be installed. A side benefit to youtube is that folks unfamiliar to CQC may stumble on some of the videos and get curious, thus expanding your potential audience. Honestly, I can't be bothered to give the video you provided above a chance because I can't just click and move on. There's that ease of use thing again.
 - Try understanding what folks want instead of defending what you offer. Doing say may make for less to defend. ;)
 
On another note - Indigo seems to have a pretty good model, just a shame it requires a MAC. They offer a low entry price, simple pricing model, ease of use out of the box, but still offer the ability to script in well known languages if one desires to do so. I would be all over Indigo if not for the MAC aspect.
 
Back
Top