What is wrong with CQC?
- Thread starter Dean Roddey
- Start date
I have spoken about this before, but I'm always happy to repeat it. It is actually my job to evaluate technology. What splits me here is should I answer this from my viewpoint as a former user, or should answer from what I feel the difficulties might be from the general home automation community in general.
Let me start at the beginning. I used QCQ for more than 5 years, but i dodn't use it now. I used Homeseer for many years before that. I left Homeseer because, at least back then, it was very unreliable. CQC was a nice change, and for the most part it was very reliable. That is the good news. The product is robust, and once running it runs, at least the operational part of CQC. The building tools are not so robust, and crashes are pretty common.
I give Dean much credit for creating CQC which is a massive undertaking. Its an environment, tools, a programming language, you name it, but it massiveness is also its weakness. Anything this massive requires massive documentation and training, and this is very light with videos the main teaching tool. I wasn't a big fan of the videos because they are too time consuming to use to look something up.
So to jump into CQC from the start is difficult. Lots to learn and lots to learn just to do basic things, and I believe this is where many just give up. I stayed with it, but there was a long learning curve, and that is just to use the GUI based system. I never made the jump to the CQC programming language. Although I have a software background from the C days, the learning curve here was just too much for me. I could have done it, but its just a matter of how much time can I give to it? Without learning this programming, I couldn't create driver or update drivers, so I was at the mercy of others, and this was the next problem, many drivers are buggy and nobody updates them.
My system used UPB and HAI/Leviton access extensively, but both of these drivers had problems. The UPB driver developer was long gone and nobody had updated it in years. Status wasn't accurate, and multiple UPB transmissions in a row would cause some to get lost. The tool to build the device file is no longer even available. I tried various queing plans, but they didn't work, and in the end, i just lived with it.
Dean wrote the HAI/Leviton interface, but that wasn't updated in years, and many newer features added to the Omni were never supported by the driver, and I wasn't savy enough to fix the code myself. Other drivers had problems as well, and nobody was fixing many of them. (This was the same with Homeseer.) I made a few tweaks to a few of them, but it was too much work just to make small tweaks.
Then there was outside access. The world is going (or has gone) web based and CQC has no good web based solution. For remote access you had to put another app on your phone, and remote PCs, and there were more new protocols to learn. Just imagine if every web site on the web required its own special browser? This is how CQC is. Everything on CQC is reinventing the wheel. More programs to load, more new programming to learn, more proprietary solutions. It just got to be too much.
Dean has since added some simple ways to get your system going, but in my opinion, that goes too much in the opposite direction. We don't need things to dumb-down things, we need documentation and support for existing technology so we can create what we want.
Finally Dean was spending much of his time (in my opinion) on GUI tweaks but my system really didn't use displays. I used LED signs and text-to-speech, lighting control, and other real-time control, and this isn't Dean's priority. I felt that in the last 3 or 4 years, very few of the CQC improvements added really helped me at all, while I lived with the most basic buggy drivers not being updated. Its clear Dean has his vision, but it doesn't match my vision, and that is the biggest problem. Vision is great, but I don't beleive Dean's vision og CQC represents most users, not mine at least.
So: 1) CQC is just too proprietary. Why reinvent the wheel. HTML and various scripting languages are redily available, and documented. Why create others that I have to learn? I just don't have the time to learn proprietary scripting and display languages, and since they are proprietary, I don't want to spend the time to learn them. In addition, Dean doesn't have the time to fully document them so users suffer, and we have.
2) Drivers need to be such that users can create them, or at the very least, maintain and fix the ones out there. In QCQ you could do that, in theory, but it was VERY difficult to jump in and write a driver, and i don't want to spend my limited time to learn a proprietary language.
3) Keep basic drivers ALWAYS updated. Dean made no secret that he liked ELK better than Leviton, so the ELK driver was updated, but the Leviton was not. Dean liked Z-Wave but not UPB, so guess what, Z-wave was updated, UPB was not. Many driver were never updated so there needs a way to get people rewarded for updating drivers that others use. If I develop a Windows or iOS or Android program, I don't have to fix the APIs and interfaces if they are buggy, Microsoft or Apple or Google does that.
Because Dean spent his time creating this giant huge proprietary programming environment, it is impossible for him to document it all, its impossible for users to learn it all, and its impossible for us and Dean to keep it all updated. There are plenty FREE open source or Microsoft or Apple supported technologies out there to build on and these need to be used as much as possible and then Dean could work just on the home automation secret sauce.
So CQC is far too complexe to learn and master at more advanced levels, its hard to maintain and fix hardware interfaces which are the lifesblood of home automation software, and at the very least, CQC needs to have an embedded web browser, and speak HTML, like the rest of the world.
If it ever goes in that direction, I might come back, but not in the current situation, not for me at least.
Finally price. For me that isn't the biggest obstacle, but I want to understand what I am getting for what price, and that is a bit foggy.
Having said all this, I know the home automation software market is challenging, and I know there are reasons Dean decided to go the way that he did, but these methods are just not compatible with my way of thinking, and just not compatible with how the world of technology is evolving.
Let me start at the beginning. I used QCQ for more than 5 years, but i dodn't use it now. I used Homeseer for many years before that. I left Homeseer because, at least back then, it was very unreliable. CQC was a nice change, and for the most part it was very reliable. That is the good news. The product is robust, and once running it runs, at least the operational part of CQC. The building tools are not so robust, and crashes are pretty common.
I give Dean much credit for creating CQC which is a massive undertaking. Its an environment, tools, a programming language, you name it, but it massiveness is also its weakness. Anything this massive requires massive documentation and training, and this is very light with videos the main teaching tool. I wasn't a big fan of the videos because they are too time consuming to use to look something up.
So to jump into CQC from the start is difficult. Lots to learn and lots to learn just to do basic things, and I believe this is where many just give up. I stayed with it, but there was a long learning curve, and that is just to use the GUI based system. I never made the jump to the CQC programming language. Although I have a software background from the C days, the learning curve here was just too much for me. I could have done it, but its just a matter of how much time can I give to it? Without learning this programming, I couldn't create driver or update drivers, so I was at the mercy of others, and this was the next problem, many drivers are buggy and nobody updates them.
My system used UPB and HAI/Leviton access extensively, but both of these drivers had problems. The UPB driver developer was long gone and nobody had updated it in years. Status wasn't accurate, and multiple UPB transmissions in a row would cause some to get lost. The tool to build the device file is no longer even available. I tried various queing plans, but they didn't work, and in the end, i just lived with it.
Dean wrote the HAI/Leviton interface, but that wasn't updated in years, and many newer features added to the Omni were never supported by the driver, and I wasn't savy enough to fix the code myself. Other drivers had problems as well, and nobody was fixing many of them. (This was the same with Homeseer.) I made a few tweaks to a few of them, but it was too much work just to make small tweaks.
Then there was outside access. The world is going (or has gone) web based and CQC has no good web based solution. For remote access you had to put another app on your phone, and remote PCs, and there were more new protocols to learn. Just imagine if every web site on the web required its own special browser? This is how CQC is. Everything on CQC is reinventing the wheel. More programs to load, more new programming to learn, more proprietary solutions. It just got to be too much.
Dean has since added some simple ways to get your system going, but in my opinion, that goes too much in the opposite direction. We don't need things to dumb-down things, we need documentation and support for existing technology so we can create what we want.
Finally Dean was spending much of his time (in my opinion) on GUI tweaks but my system really didn't use displays. I used LED signs and text-to-speech, lighting control, and other real-time control, and this isn't Dean's priority. I felt that in the last 3 or 4 years, very few of the CQC improvements added really helped me at all, while I lived with the most basic buggy drivers not being updated. Its clear Dean has his vision, but it doesn't match my vision, and that is the biggest problem. Vision is great, but I don't beleive Dean's vision og CQC represents most users, not mine at least.
So: 1) CQC is just too proprietary. Why reinvent the wheel. HTML and various scripting languages are redily available, and documented. Why create others that I have to learn? I just don't have the time to learn proprietary scripting and display languages, and since they are proprietary, I don't want to spend the time to learn them. In addition, Dean doesn't have the time to fully document them so users suffer, and we have.
2) Drivers need to be such that users can create them, or at the very least, maintain and fix the ones out there. In QCQ you could do that, in theory, but it was VERY difficult to jump in and write a driver, and i don't want to spend my limited time to learn a proprietary language.
3) Keep basic drivers ALWAYS updated. Dean made no secret that he liked ELK better than Leviton, so the ELK driver was updated, but the Leviton was not. Dean liked Z-Wave but not UPB, so guess what, Z-wave was updated, UPB was not. Many driver were never updated so there needs a way to get people rewarded for updating drivers that others use. If I develop a Windows or iOS or Android program, I don't have to fix the APIs and interfaces if they are buggy, Microsoft or Apple or Google does that.
Because Dean spent his time creating this giant huge proprietary programming environment, it is impossible for him to document it all, its impossible for users to learn it all, and its impossible for us and Dean to keep it all updated. There are plenty FREE open source or Microsoft or Apple supported technologies out there to build on and these need to be used as much as possible and then Dean could work just on the home automation secret sauce.
So CQC is far too complexe to learn and master at more advanced levels, its hard to maintain and fix hardware interfaces which are the lifesblood of home automation software, and at the very least, CQC needs to have an embedded web browser, and speak HTML, like the rest of the world.
If it ever goes in that direction, I might come back, but not in the current situation, not for me at least.
Finally price. For me that isn't the biggest obstacle, but I want to understand what I am getting for what price, and that is a bit foggy.
Having said all this, I know the home automation software market is challenging, and I know there are reasons Dean decided to go the way that he did, but these methods are just not compatible with my way of thinking, and just not compatible with how the world of technology is evolving.
Dean Roddey
Senior Member
Just some comments on Ano's post...
1. Just for the record I don't like Z-Wave at all. It find it quite annoying. I didn't work on the Z-Wave driver because I like it, but because more people were using it. I wish it would go away, but it's actually pretty ubiquitous.
2. There's a constant pull in two directions here. People say it's too complex, and you say we didn't improve the HAI driver. But we did improve it massively, in that we wrote a completely new one that conforms to our V2 spec and therefore can be used within our auto-generation system, in order to make it more accessible, and made it much more flexible and supportable. Exposing every feature of a device is the opposite of making it easier to use, more robust, and standardizing things so that it's easier to get going. You can't do both at the same time, but often folks tend to want both these contradictory things.
Of course if everyone was saying, hey it's really easy to use but we need more device functionality exposed, then we'd go that way. But that doesn't seem to be the case at all, and even you are saying it's too complex.
3. We are working on an HTML5 client. The next release will have an initial version of it, and it'll continue to grow. But, I have to say, it's just a fact that the 'standard' technologies are very weak. If you are looking to write fairly small apps, then that's fine. But serious development is pretty much beyond the capabilities of these technologies, at least in a practical way. On the periphery is fine, and something like the HTML5 client is on the periphery. But basing the product in general on these weak technologies just isn't practical. We'd never be able to support the product. So this is one area in which our ability and/or inclination to move is fairly small.
As I've mentioned before, we also now support Websockets, so you are free to use web based client development technology to create your own client. These don't need to be really extensive in many cases, they might be for very specific functionality.
4. As to documentation, of course it's always difficult to fully document a large system. We aren't the only system that has this issue, but we do want to do better. I've been working on an introductory document to help people get started and get the big picture of how the pieces go together. There's lot of technical docs, but there needs to be more big picture stuff to glue it together. We'll see if that helps.
1. Just for the record I don't like Z-Wave at all. It find it quite annoying. I didn't work on the Z-Wave driver because I like it, but because more people were using it. I wish it would go away, but it's actually pretty ubiquitous.
2. There's a constant pull in two directions here. People say it's too complex, and you say we didn't improve the HAI driver. But we did improve it massively, in that we wrote a completely new one that conforms to our V2 spec and therefore can be used within our auto-generation system, in order to make it more accessible, and made it much more flexible and supportable. Exposing every feature of a device is the opposite of making it easier to use, more robust, and standardizing things so that it's easier to get going. You can't do both at the same time, but often folks tend to want both these contradictory things.
Of course if everyone was saying, hey it's really easy to use but we need more device functionality exposed, then we'd go that way. But that doesn't seem to be the case at all, and even you are saying it's too complex.
3. We are working on an HTML5 client. The next release will have an initial version of it, and it'll continue to grow. But, I have to say, it's just a fact that the 'standard' technologies are very weak. If you are looking to write fairly small apps, then that's fine. But serious development is pretty much beyond the capabilities of these technologies, at least in a practical way. On the periphery is fine, and something like the HTML5 client is on the periphery. But basing the product in general on these weak technologies just isn't practical. We'd never be able to support the product. So this is one area in which our ability and/or inclination to move is fairly small.
As I've mentioned before, we also now support Websockets, so you are free to use web based client development technology to create your own client. These don't need to be really extensive in many cases, they might be for very specific functionality.
4. As to documentation, of course it's always difficult to fully document a large system. We aren't the only system that has this issue, but we do want to do better. I've been working on an introductory document to help people get started and get the big picture of how the pieces go together. There's lot of technical docs, but there needs to be more big picture stuff to glue it together. We'll see if that helps.
NeverDie
Senior Member
Dean Roddey said:
I probably should have been more precise in my phrasing, because in retrospect I can perhaps see how, in my attempt to be concise, the meaning I was attempting to convey might have unintentionally come across more strongly than I meant it to. So, to amend that, let me begin by saying I haven't done an exacting dissection of the forum to analytically differentiate opinion leaders from those who aren't, nor do I have a spreadsheet or database or anything similar to track who is using what. Also, I've only read a fraction of the threads here. So, with all that as background, I was relying on memory, which is fallible, and I meant for my comment to be taken more as my personal take-away impression rather than as rock-solid fact. So, maybe there are in fact opinion leaders here using CQC, and for whatever reason I just don't recollect it or I wasn't reading those threads or paying enough attention or what have you. I really do wish I had time to vet CQC for myself so I could have a better informed opinion, and the thread on frustration with home automation software did peak my interest in doing so, because it does sound like CQC has an interesting approach.
Dean Roddey
Senior Member
There are industry leaders I guess, or at least people who consider themselves so at the very least, and probably people who consider other people so. In the broader area of the industry web sites and magazines, you'll seldom hear of any companies mentioned that don't buy advertising, and so they tend to very much stick to the biggest players. They'd be happy to do a story on a company like us or some of our peers if we were to crash and burn, but probably not otherwise.
If you consider the leaders to be other end of the scale, i.e. people who soldering iron and script hacking oriented, then CQC is probably too way too 'producty' for a lot of them. They are looking to do it for the challenge probably and want to do as much themselves as possible, and usually spend absolutely no more than necessary. But that's a wee, tiny sliver of a sliver of a niche market. CQC definitely isn't trying to address that market, so it's to be expected that they wouldn't be interested in it. It's not the right tool for the job they want to do.
Ultimately, CQC is best targeted for the commercial and custom residential markets, where its very strong customization capabilities are often seen as requirements, not problems. But even there, there's plenty of room for a simplified system, so we've been working hard towards that, though it's been quite an effort.
If you consider the leaders to be other end of the scale, i.e. people who soldering iron and script hacking oriented, then CQC is probably too way too 'producty' for a lot of them. They are looking to do it for the challenge probably and want to do as much themselves as possible, and usually spend absolutely no more than necessary. But that's a wee, tiny sliver of a sliver of a niche market. CQC definitely isn't trying to address that market, so it's to be expected that they wouldn't be interested in it. It's not the right tool for the job they want to do.
Ultimately, CQC is best targeted for the commercial and custom residential markets, where its very strong customization capabilities are often seen as requirements, not problems. But even there, there's plenty of room for a simplified system, so we've been working hard towards that, though it's been quite an effort.
Dean Roddey
Senior Member
az1324 said:
Yeh, being a Windows based product, we tend to post things in WMA, since it's the native format. I guess we could provide them in multiple formats.
* Of course it would also be nice if Apple didn't consider themselves too good to support other platform's formats, since other platforms typically support Apples'.
Dean Roddey said:
I definitely see how this can be viewed as conflicting, and I think its a good topic because "complexity" and "CQC are often used in the same sentence, and this can be a complex topic, literally.
When new users say CQC is too complex, what they are actually are saying is that CQC is not approachable. That the level of work involved just to try it is more than what the user is prepared to offer, for whatever reason. Dean, you have tried to address this with wizards and videos, but in some ways, this doesn't help. These can be a bit complex, and may bring out a bit of the "weirdness" of CQC and may scare away people even more. Understanding human perceptions is not an easy thing.
I have used CQC for many years, and I'm fairly tech-savy and I also think CQC is complex. Documentation can be limited, and even when there was documentation, things are difficult to find. There is an action reference, a CML language guide, driver guide, event guides, interface viewer guide, an interface development guide, RIVA guide, and even a web server guide, which I always found amusing because CQC doesn't have a web server in it that I have seen. I have worked on the missile launch systems on Trident Nuclear missiles and i can tell you its easier to launch a missile than to do some things in CQC. Why is there a need for so many documents? Why can't there be built-in help? If i don't understand an Excel function, there is built-in help with all the parameters.
There are just so many browsers, and editors, and compilers, and viewers. Why are there so many programs? There needs to be one and only one program, with built-in help. it all needs to be integrated together better and simpler. Microsoft Excel is a very complex program with lots of capabilities, but I can start it from day one and do stuff with it. CQC should be the same.
Also, instead of wizards, give examples. People learn by example. Include these in the built-in help. Also, include better overviews on what all the parts and pieces do. Write step-by-step instructions on how to do common tasks. How do i write a driver? What skills do i need? What are the steps. Don't force me to watch a video to learn.
Some of these things will go a long way to make CQC much more approachable.
Dean Roddey
Senior Member
Actually CQC does have a web server, has had for a long time. Of course we couldn't be doing an HTML5 client or support Websockets without that.
Anyhoo, yeh, documentation is a tricky thing. If we moved it all into the product, many people would probably complain about that as well, I'm guessing, because a lot of people don't like that type of hot linked help presentation. I know I often will go look for something, find some basic discussion of it, and dig in, and ultimately find myself right back where I started, without really any better understanding of what I was looking for. Different people I guess like different formats for documentation. Some people love the videos, some people don't. At least a linear document can lay out what's important in order of importance, while hyperlinked help often tends to be more amorphous, though I guess it can be done well also with sufficient care.
The 'one program' thing has been discussed many times. It's certainly a goal, but man would that be tough to do. It would be a an enormous program, and would almost certainly increase the likelihood of instability in the tools, because it would be so much harder to keep it all stable when in a single executable. I'm not sure it would ultimately simplify things though? You'd still need to know what you are looking for. For many people it might make it worse, since they may only ever use a couple tools, and so don't even need to know about the others.
The introductory document I'm working on has a "How do I?" section, that includes a good list of possible things you'd want to do and explains how to go about them, so hopefully that will help.
Anyhoo, yeh, documentation is a tricky thing. If we moved it all into the product, many people would probably complain about that as well, I'm guessing, because a lot of people don't like that type of hot linked help presentation. I know I often will go look for something, find some basic discussion of it, and dig in, and ultimately find myself right back where I started, without really any better understanding of what I was looking for. Different people I guess like different formats for documentation. Some people love the videos, some people don't. At least a linear document can lay out what's important in order of importance, while hyperlinked help often tends to be more amorphous, though I guess it can be done well also with sufficient care.
The 'one program' thing has been discussed many times. It's certainly a goal, but man would that be tough to do. It would be a an enormous program, and would almost certainly increase the likelihood of instability in the tools, because it would be so much harder to keep it all stable when in a single executable. I'm not sure it would ultimately simplify things though? You'd still need to know what you are looking for. For many people it might make it worse, since they may only ever use a couple tools, and so don't even need to know about the others.
The introductory document I'm working on has a "How do I?" section, that includes a good list of possible things you'd want to do and explains how to go about them, so hopefully that will help.
ChrisCicc
Active Member
Since you asked for opinions, I'll chime in with mine as a fellow programmer 
I couldn't disagree more about using frameworks. Honestly, I never understood (though I respect the accomplishment of it) why you built your own framework/environment on Windows instead of using the standard Windows API? Now those Windows APIs have expanded into standards based tech that is cross platform. And that's only considering the Microsoft ecosystem, not open source options. You are an incredible programmer - but I agree with others that supporting your own framework will hinder your home automation software built on that framework. Which is better - CQC scripting language or C#? The latter costs nothing to implement, save this single line of code: dynamic script = CSScript.Evaluator.LoadFile(scriptFilePath); You can do anything, it's just harder and takes longer with your architecture.
.mp4 is your friend. WMV/A is for all intents and purposes dead.
ano said:
Dean Roddey said:
I couldn't disagree more about using frameworks. Honestly, I never understood (though I respect the accomplishment of it) why you built your own framework/environment on Windows instead of using the standard Windows API? Now those Windows APIs have expanded into standards based tech that is cross platform. And that's only considering the Microsoft ecosystem, not open source options. You are an incredible programmer - but I agree with others that supporting your own framework will hinder your home automation software built on that framework. Which is better - CQC scripting language or C#? The latter costs nothing to implement, save this single line of code: dynamic script = CSScript.Evaluator.LoadFile(scriptFilePath); You can do anything, it's just harder and takes longer with your architecture.
Dean Roddey said:
.mp4 is your friend. WMV/A is for all intents and purposes dead.
Dean Roddey
Senior Member
ChrisCicc said:
But see, that's the point. We don't want you to be able to do anything you want. That's a road to hell (or at least Chucky Cheese) paved with good intentions. Other companies have already been down it, and have already arrived, and we didn't want to go there. Robustness is ultimately what it's all about. That has to be the overriding goal of any serious automation system. By using a language that is specialized for the task at hand, that limits to a very small number of ways how you can shoot yourself in the foot and the ways you might destabilize the system as a whole, you maximize stability of the product.
IMO, anyone who knows C# or Java and can't pick up CML in a day, I just don't want to use any code they would be writing, not in my automated home. And the less knowledgeable your, the less I'd want to you to be able to insert some uncontrolled code into my automation system that I depend on.
But, in the end, I don't think this issue should be over-emphasized, given that probably less than 1% of our customers ever need to use CML It really only comes into play wrt to device drivers, and as I said, if you can't pick up a very simple language like CML easily, then probably writing a high quality, two way driver isn't something you should be taking on, because nothing will be right if the drivers aren't tight (hey, there's a good tag line.) The advantages of having happy customers for the devices that are supported outweighs the benefits of having a lot of other drivers that probably wouldn't be so good.
Honestly I think a lot more companies would go our way if they could, but they just aren't in a position to do so. Obviously we wouldn't have if we just popped up and wanted to write an automation system. But for us it was the other way around, we wanted to create a powerful object framework and did that first, and then ended up using it to create an automation system. It's just a quirk of fate that allowed us to do that. Even a very large automation company would not likely consider making that type of commitment, even if they wanted to.
Dean Roddey
Senior Member
Don't get me wrong, there are multiple ways of skinning the cat. And different users may prefer different types of products. Some might be looking for products that want to party, and some may be looking for programs that are deadly serious about the P's and Q's and whatnot, or somewhere in between. CQC just leans towards the Ps/Qs side of it. Mostly this is because we have to get commercial and residential business in order to make money and they aren't tolerant of failure, given that they get called on Saturday night if something goes wrong. So anything that reduces the possibility of failure (and human failure is a big component of that) is a good thing, and having tools that restrict you to what is safe go a long way towards reducing the prospect of human mistakes.
It's the old 'write once, debug forever' thing, i.e. would you rather be fast or safe sort of thing. In automation, safe pretty much has to trump fast. It's worth it to learn a tool that watches your back very carefully, because mistakes, particularly in drivers, are just brutally easy to make and they can make the whole system seem very unstable, even though it's just this one little piece of code that's the problem.
Give people an open ended, multi-thread capable language and let them throw some code into the automation system, and it can get really weird.
I always point to Homeseer, and how hard it was for them to transition away from such a system (their original architecture I guess it was) to something more structured. Once you let everyone do anything at any time, then you have almost no latitude to change how the system works without causing possibly very difficult to diagnose problems.
It's the old 'write once, debug forever' thing, i.e. would you rather be fast or safe sort of thing. In automation, safe pretty much has to trump fast. It's worth it to learn a tool that watches your back very carefully, because mistakes, particularly in drivers, are just brutally easy to make and they can make the whole system seem very unstable, even though it's just this one little piece of code that's the problem.
Give people an open ended, multi-thread capable language and let them throw some code into the automation system, and it can get really weird.
I always point to Homeseer, and how hard it was for them to transition away from such a system (their original architecture I guess it was) to something more structured. Once you let everyone do anything at any time, then you have almost no latitude to change how the system works without causing possibly very difficult to diagnose problems.
Even on your sales page all I see is how complicated you product is. After reading and rereading I still cannot find an actual product price. I see some upgrade options priced but where is your simply stated $XX?
This comes across as "something to hide" and causes mistrust.
Also I expect this post to get a bark back of some kind as briefing over the other helpful suggestions in this I see you answer back what appears as a "No it isn't!" to almost every suggestion instead of a "Thank you for your input. I will take that into consideration" .
It's hard to be a programmer, and I assume you must be a very good one, marketer, and a good document writer. You are probably s deep into your project you have no idea what people need to see to get them started. Your website is telling me how many complex modules this takes and all I want to hear is about a single program, maybe with some device driver options.. I don't even want to hear about an "app" as the latest and greatest fad language to sound "cool" by the techies.
Make your basic program complete with the necessary driver for people to get started for a money back satisfaction guarantee .A few clicks should set it up to a basic running stage. I don't want to do programming or complex stages of installations. I sent fourty years programming and I am sick of it. Charge for add-on drivers. set the hook and then reel in expansion money. Set the hook first. if your system is good the market will develop. Use XBMC as a model. get participation from others you can manage and control by approvals.
Why do I not have CQC? I use Insteon devices and some old X10 units. Insteon has a superior comm method AFAIC. I can drop in an ISY994i unit that draws less than 2 watts and it just works with minimum setup. Most users can write their first lamp control in 5-20 minutes. I can expand it to web control, interface to RPi, CAI, dozens of Web Relays, 1wire, z-wave(yuk), zigbee, etc.with easy drop-in modules that I pay for as needed. They install from inside the Admin Console. I don't need no stinkin' PC with harddrives, Windoze, lousy MTBFs, additional high costs, and energy wasting.
Get your product into a RPi with it's multiple USB ports and Ethernet, massive quantities of drivers and supported hardware adapters including 1wire probes for temperature controls like pools, hot tubs, aquariums. Offer a box one can plug in and play in "30 minutes or it's free" j/k.
Make SDKs for those python and Linux boys. Get with that or be left in the dust by the hackers. Those are the ones that will make your kernel soar in ways you haven't imagined yet. The coloured lighting is becoming a big market. How many system's hubs drivers can you write in the next six months yourself? I have a Phillips Hub and a MiLight bridge so far and ISY994i can operated them both. Individually addressable LED strips to come soon. Some hacker will drop that out there soon....free.
Al in all, best luck. You seem like you have a head start in this up and coming market with great possibilities. Concepts change fast in this market and being buried in code for years can leave you in yesterdayland chasing electron around when everybody else is chasing galaxies.
This comes across as "something to hide" and causes mistrust.
Also I expect this post to get a bark back of some kind as briefing over the other helpful suggestions in this I see you answer back what appears as a "No it isn't!" to almost every suggestion instead of a "Thank you for your input. I will take that into consideration" .
It's hard to be a programmer, and I assume you must be a very good one, marketer, and a good document writer. You are probably s deep into your project you have no idea what people need to see to get them started. Your website is telling me how many complex modules this takes and all I want to hear is about a single program, maybe with some device driver options.. I don't even want to hear about an "app" as the latest and greatest fad language to sound "cool" by the techies.
Make your basic program complete with the necessary driver for people to get started for a money back satisfaction guarantee .A few clicks should set it up to a basic running stage. I don't want to do programming or complex stages of installations. I sent fourty years programming and I am sick of it. Charge for add-on drivers. set the hook and then reel in expansion money. Set the hook first. if your system is good the market will develop. Use XBMC as a model. get participation from others you can manage and control by approvals.
Why do I not have CQC? I use Insteon devices and some old X10 units. Insteon has a superior comm method AFAIC. I can drop in an ISY994i unit that draws less than 2 watts and it just works with minimum setup. Most users can write their first lamp control in 5-20 minutes. I can expand it to web control, interface to RPi, CAI, dozens of Web Relays, 1wire, z-wave(yuk), zigbee, etc.with easy drop-in modules that I pay for as needed. They install from inside the Admin Console. I don't need no stinkin' PC with harddrives, Windoze, lousy MTBFs, additional high costs, and energy wasting.
Get your product into a RPi with it's multiple USB ports and Ethernet, massive quantities of drivers and supported hardware adapters including 1wire probes for temperature controls like pools, hot tubs, aquariums. Offer a box one can plug in and play in "30 minutes or it's free"
j/k.Make SDKs for those python and Linux boys. Get with that or be left in the dust by the hackers. Those are the ones that will make your kernel soar in ways you haven't imagined yet. The coloured lighting is becoming a big market. How many system's hubs drivers can you write in the next six months yourself? I have a Phillips Hub and a MiLight bridge so far and ISY994i can operated them both. Individually addressable LED strips to come soon. Some hacker will drop that out there soon....free.
Al in all, best luck. You seem like you have a head start in this up and coming market with great possibilities. Concepts change fast in this market and being buried in code for years can leave you in yesterdayland chasing electron around when everybody else is chasing galaxies.
Dean Roddey
Senior Member
The price is on the Try/Buy -> Buy It page. There are multiple tiers, and each one has a different price. In Try/Buy -> Information there's information about the various tiers.
If you are looking for a single, simple program that's going to magically set itself up in a few clicks, you are definitely in another market. That's all that needs to be said and thanks for that feedback. CQC isn't that product, and likely never will be. It's just at a different place on the effort vs. rewards scale.
As to my "no it's not', I've made it clear to a number of suggestions that they are understood to be important, sometimes on the list already to be implemented when possible, and in some cases already implemented and/or in the process of being implemented. But in some cases suggestions are just not practical. There's no point me in pretending we are going to do things we know we can't, right? Saying that we would in order to get people to buy in, and then never doing them, *that* is what would make me 'great marketer', I'm afraid. I'm not a marketer at all, sadly. Having a somewhat less rigid view of the truth would probably be good for business.
Anyway, though we understand that someone might like a very different type of product, we don't necessarily always want to be that product.
If you are looking for a single, simple program that's going to magically set itself up in a few clicks, you are definitely in another market. That's all that needs to be said and thanks for that feedback. CQC isn't that product, and likely never will be. It's just at a different place on the effort vs. rewards scale.
As to my "no it's not', I've made it clear to a number of suggestions that they are understood to be important, sometimes on the list already to be implemented when possible, and in some cases already implemented and/or in the process of being implemented. But in some cases suggestions are just not practical. There's no point me in pretending we are going to do things we know we can't, right? Saying that we would in order to get people to buy in, and then never doing them, *that* is what would make me 'great marketer', I'm afraid. I'm not a marketer at all, sadly. Having a somewhat less rigid view of the truth would probably be good for business.
Anyway, though we understand that someone might like a very different type of product, we don't necessarily always want to be that product.
ddennerline
Active Member
Unfortunately, HA companies are dumbing down their offerings to appeal to wider audience. You can walk into HomeDepot/Lowes and see the writing on wall. Leviton now sells a Vizia+ light switches without association class to avoid paying Lutron. Dirty little secret is Z-Wave network without asynchronous notification will require polling every device which Z-Wave is not good at. It’s basically a race to the masses.
Perhaps a very select, small, group of customer would could/would ever use a programming language – especially if it was procedural based. So unless your newfangled HA solution can show value in less than a few hours, buyers become disinterested and move onto their next toy.
Basically, I didn’t buy CQC because I have an Elk and didn’t to want to spend $300 plus time building/managing a new HA box. For $300, I wanted a fully automated, low powered, appliance that solves some home problem particularly well that cannot be solved by Elk.
I just tried installing CQC; unfortunately it’s not Grandma proof. Why a ZIP file? How many people understand what “administrator rights” are [note: I know how to work around these problems.] For me, if a program doesn’t install in five minutes, I give up – figuring more pain is ahead.
Unfortunately, IMHO CQC main audience is HA integrators – not the members on this forum. I believe the CQC (based on watching some of the videos) opinions on what is core feature-set are a reflection of wide variety of users. You’re not going to please them all. If you want to appeal to consumer audience, then context aware help and wizards are important. If you want to appeal to integrators, then customization/flexibility/serviceability are important. Having both is recipe for bankruptcy.
Perhaps a very select, small, group of customer would could/would ever use a programming language – especially if it was procedural based. So unless your newfangled HA solution can show value in less than a few hours, buyers become disinterested and move onto their next toy.
Basically, I didn’t buy CQC because I have an Elk and didn’t to want to spend $300 plus time building/managing a new HA box. For $300, I wanted a fully automated, low powered, appliance that solves some home problem particularly well that cannot be solved by Elk.
I just tried installing CQC; unfortunately it’s not Grandma proof. Why a ZIP file? How many people understand what “administrator rights” are [note: I know how to work around these problems.] For me, if a program doesn’t install in five minutes, I give up – figuring more pain is ahead.
Unfortunately, IMHO CQC main audience is HA integrators – not the members on this forum. I believe the CQC (based on watching some of the videos) opinions on what is core feature-set are a reflection of wide variety of users. You’re not going to please them all. If you want to appeal to consumer audience, then context aware help and wizards are important. If you want to appeal to integrators, then customization/flexibility/serviceability are important. Having both is recipe for bankruptcy.
