my CQC review

Squintz

Squintz

Senior Member
I just wanted to let you guys know that I have been playing with (CQC) Charmed Quark Controller and I have actually started liking it more than HS. It just seems to me that its a much better design. One thing that I like is that its a flat cost and you dont have to pay extra for plugins. The other thing that I like is that all the networking distribution bugs have been worked out already. This program has been around for a while but just has not caught on do to its lack of features. But I must say its not lacking very many features any more.

PROS:
Supports JRivers 11 XML
Supports an easy to use Graphical Designer Interface for making nice looking touch screens
Supports Z-wave (Indetical Copy of remote so groups are also carried over)
The current beta support Elk M1 Gold
USB-Uirt is supported and done very well.
and much more

The other thing that I have come to find out in my few weeks of trying CQC is that Dean (The pushy salesman) is actually a very nice guy who is simply pasionate about his work.

If you have devices that need drivers made so the CQC will support it dean will try his best to add the support himself. I have already asked him to add support for the NetCallerID which should be coming soon. I have asked for a special widget which he has agreed to. (A widget is like a button on a User Interface that has a special purpose)

I guess what I am trying to tell you guys is that if you don't atleast give other programs a shot (use the 30 day trials) then you are going to be traped in the HomeSeer niche. You may find HomeSeer to be better in you personal opinion which is ok but atleast try other applications so that you know there are other options.

Some of the cons of CQC are the macro (scripting) language is a little hard to get use to and you need to know a little about OOP to be able to use it. CQC is a program designed to be marketed to Professionals so its great for those of us who can program because it offers alot of power that way. But you dont have to program to get good use out of it. You can setup an automated home without using macros.

My words cant say enough how much I like CQC now that I have learned to use it. The only thing I can say is just try it.
 
Squintz said:
If you have devices that need drivers made so the CQC will support it dean will try his best to add the support himself. I have already asked him to add support for the NetCallerID which should be coming soon. I have asked for a special widget which he has agreed to. (A widget is like a button on a User Interface that has a special purpose)

...

Some of the cons of CQC are the macro (scripting) language is a little hard to get use to and you need to know a little about OOP to be able to use it. CQC is a program designed to be marketed to Professionals so its great for those of us who can program because it offers alot of power that way. But you dont have to program to get good use out of it. You can setup an automated home without using macros.
Click to expand...
I see this as a significant drawback - or at least something that would be a major factor in my decision on what to use.

The NetCallerID is about the simplest external device ever created. It is extremely easy to interface to HomeSeer with a simple script.

If it's that hard to interface to CQC, requiring effort from the original programmer, then it's too much work.
 
dang thread hijackers :blink:

what does CQC have to do with HS2? can this be moved to a more relevant place, like a review section?
 
Sorry for hijacking the thread.

Smee,

Implementing the NetCallerID is not hard to do with CQC. My point is that CQC is capable of controlling any of your hardware just like HS is but CQC is still young and has not had their eyes open yet to all the products that could be supported.

So even if you don't plan to use CQC you could always stop by their Forum and drop them a line about new products or even old products that you think they should support. I guess weather its a good thing or bad thing that support is mostly direct from the developer is everyones personal opinion. My opinion is that its better this way because the developer has all the tools at his fingertips to check for potential problems and conflict before releasing the driver.

A driver in CQC is basically a plug-in.

Another thing that I like about CQC is that the driver and macro designer are built into the application and offer great debuging support. So unlike HS you don't have to keep switching back and forth between the text editor, events tab, and loging tab. Everything is built into one nicely designed IDE.

CQC is not the perfect solution to everyones problems. But it does have huge potential. To be honest I am sad the my 30 trial is about to run out. It looks like I am going to have to help from the side lines until after my wedding before I buy the software. I am going to try and get an extended trial version so that I can play a little longer.

Again sorry for the hi-jacking
 
Are you successfully using VR and TTS? SAPI what?

$35 extra to do scheduled events????? :blink:
 
It would be trivial to do the caller id driver, it just hasn't been done yet because there are lots of things to do, and none of our existing customers have really pushed for it to be supported. We tend to prioritize device support based on what existing or incoming new customers need.

Anyone could do the caller id driver, it doesn't have to be me. For a device that simple our PDL (protocol description language) would likely be more than sufficient, which doesn't require any real programming expertise since it's a purely declarative language.

Here is the CQC PDL driver for the Lumagen video processor, as an example:

Code: 
[CQCProto Version="2.0" Encoding="ISO-8859-1"]

ProtocolInfo=
    TextEncoding="ASCII";
    ProtocolType="OneWay";
EndProtocolInfo;

Constants=

    // Command constants
    Constant=Cmd_PowerOff
        Type=Card1;
        Value=0x24;
    EndConstant;

    Constant=Cmd_PowerOn
        Type=Card1;
        Value=0x25;
    EndConstant;

EndConstants;

Maps=

    // A map for the input AR
    Map=InputARMap
        Type=Card1;
        Items=
            Item="1.33"     , 0x6E;
            Item="1.33LB"   , 0x6C;
            Item="1.78"     , 0x77;
            Item="1.85"     , 0x6A;
        EndItems;
    EndMap;

    // A map for the memories
    Map=MemMap
        Type=Card1;
        Items=
            Item="MemA"     , 0x61;
            Item="MemB"     , 0x62;
            Item="MemC"     , 0x63;
            Item="MemD"     , 0x64;
        EndItems;
    EndMap;

EndMaps;

Fields=

    Field=InputAR
        Type=String;
        Access=Write;
        Limits="Enum: 1.33, 1.33LB, 1.78, 1.85";
        Flags=WriteAlways;
    EndField;

    Field=MemorySelect
        Type=String;
        Access=Write;
        Limits="Enum: MemA, MemB, MemC, MemD";
        Flags=WriteAlways;
    EndField;

    Field=Power
        Type=Boolean;
        Access=Write;
        Flags=WriteAlways;
    EndField;

    Field=SrcInput
        Type=Card4;
        Access=Write;
        Limits="Range: 0, 9";
        Flags=WriteAlways;
    EndField;

EndFields;

WriteCmds=

    WriteCmd=InputAR
        Send=
            ToCard1(MapTo(InputARMap, &WriteVal));
        EndSend;
    EndWriteCmd;

    WriteCmd=MemorySelect
        Send=
            ToCard1(MapTo(MemMap, &WriteVal));
        EndSend;
    EndWriteCmd;

    WriteCmd=Power
        Send=
            BoolSel(&WriteVal, $Cmd_PowerOn, $Cmd_PowerOff);
        EndSend;
    EndWriteCmd;

    WriteCmd=SrcInput
        Send=
            ToCard1(Add(&WriteVal, 0x30));
        EndSend;
    EndWriteCmd;

EndWriteCmds;


It's not a complex language to master. The actual practical realities of device protocols is much more difficult than the PDL language itself.


We generally end up doing all of the complex devices, unless the person who wants that device happens to be fairly technicallly competent, because a complex device, even if you do know how to program, can be very hard to really do a quality two-way driver for. But, having said that, there are probably more drivres in the product that were done by others than were done by us. But we vet the drivers careful, because we just don't want to get into the situation HS is in, where we lose control of the situation.


$35 extra to do scheduled events?????
Click to expand...

Many of our customers don't use them. They are purely interested in active (user driven) control of a complex home theater in some cases, but not at all in full home control so they have no need for scheduled events.

So, to keep people from having to buy stuff they don't need, we have some option features. The core product is $200. Optional features are application control, scheduled events, and the XML Gateway, with .Net Viewer being an upcoming one. So we don't have lots of options that you have to buy separately. All drivers are included in the base package, and there are just a few optional features.

A full package license is $275, and that includes everything we've got. It might go up later when the .Net Viewer is added to the full package. And that's a site license. You only have to license a master server, then you can run CQC's client and ancillary background services on any other machines in the network.
 
The last point Dean made is another feature I really like. HS only allows for the speaker application to exist on multiple PC's whereas all of CQC is able to exist on other PC's allowing much more flexability.

I am not trying to fight a battle here of what HA application is better because both are very unique. But so far CQC has been my favorite #1 because of the customer service that I have been geting and #2 because the developer has taken the time to design a quality application. CQC it totally Object Oriented and its obvious as you are using the application.
 
I'm sure it does to a lot of people :-) But there's no programming in there at all. It's purely 'declarative', meaning that it just describes the format of messages that go back and forth, it doesn't define any logic. It describes how to pull info out of incoming messages (which you don't actually see in that one above since the Lumagen is one way), and how to build up the appropriate outgoing messages to change those aspects of the device that are supported by the driver.

There is a little 'housekeeping' stuff there. The Constants at the top are just a way to give names to magic numbers so that the names can be used in the rest of the file instead of the numbers. It makes the file more readable. The Maps section just provides a way to convert between the representation of the device for things likes (in this case) aspect ratio, and the representation that the driver wants CQC to expose to the user. So you don't have to remember that 0x6E means 1.33 AR, or whatever, you can just select 1.33 from a list and the driver handles translating back and forth.

The Fields part defines those named aspects of the device that CQC will be able to control, and defines their characteristics. And the WriteCmds part at the end defines how to build up the message to send out when a value is written to any of the writeable fields (which is all of them in this case since the Lumgen is write-only, i.e. one way.)

It would be hard to make a driver language much simpler that would be sufficienty flexible for a two-way control system. The complexity has little to do with the language, and mostly to do with the basic complexity of dealing with device control and the particular protocol of the device being interfaced to.

Some of our users who are not at programmers in any way have done PDL drivers for some fairly complex devices. If you can understand the format of messages as described in the protocol documentation, and grok the general issues of bits and bytes, then you can do a PDL driver with some effort.

It's obviously not expeced that the average user will do any drivers at all. But doing one for a simple device is well within the capabilities of anyone who feels pretty comfortable with computers and their basic concepts.
 
Dean,

How do you charge for upgrades? For instance, when these new .NET capabilities are implemented, will existing users have to pay for an upgrade? If so, what kind of costs could be expected? I have been using Mr House for about 6 years or so and am looking at alternative packages. I looked at CQC a while back, but it was in its very early stages. It looks like it has matured a lot since then.

thanks,

Joey
 
Our policy is to only charge an upgrade price for major version upgrades, of which there has never been one so far in the almost two years of the product's life.

If you buy a full system license, then we won't charge you for a new optional feature that becomes part of the full system in the next couple of dot releases, which in practical terms means 8 months or more. After that, you'd have to purchase newly arriving ones separately to add them to your license (but, we just don't have that many new optional features and won't have that many in the foreseeable future.)

If you don't buy a full system license, then if you want to add options, you have to buy them separately, but the existing ones are only like $35.

We feel that this is an extremely reasonable scenario.
 
There is already a Girder bridge that can send out commands to Girder. It's geen there for a long time.

http://www.charmedquark.com/Web/Documentat...eous/Girder.htm

Support for the Slinke is unlikely unless someone else does it. It's a discontinued product and it would take a good bit of time to support, so it's hard to make a business case for supporting it relative to the many other things that are waiting to be controlled.

The Ocelot is a more reasonable target, if we could get a loaner from them to use for the development. We just can't afford to buy all these devices ourselves, but if we can talk them into a loaner, I'd be willing to start working on it. Or, better yet, if someone wanted to take on that driver, I'd be very happy to give them all the help they want and trade them a license for the driver if it works well.
 
You must log in or register to reply here.

Similar threads

G
Looking for help from Network Guru
Replies
5
Views
257
George M
G
pete_c
OBITalk.com Consumer Portal Closure Notification
Replies
1
Views
284
JimS
J
S
HAI OMNI is still wonderful for its all-systems integration, what about " it's future"?
Replies
2
Views
171
ano
A
I
ELK-7TS (new Touchscreen) IP address oddities
Replies
4
Views
159
Ira
I
G
Is Charmed Quark gone?
2 3
Replies
39
Views
4K
kevinflynn
K
Back
Top