Re: Some upcoming CQC 1.4 teasers

["Robert Green" <ROBERT_GREEN1963@xxxxxxxxx>]

"Dean Roddey" <droddey@xxxxxxxxxxxxxxxx> wrote in message

> > OK.  Just kidding. We're *sure* that your new release supports it,
> > but what is it?  The .Net Interface Viewer, that is.
>
> The interface viewer is the thing that loads and animates the graphical
user
> interfaces that you design using the interface designer.

What do you have in the way of demos other than a trial version?  I saw a
lot of tutorials (very nice) on your site, but is there an MPG or a
slideshow that really illustrates CQC?

<snip>

> This lets you view CQC graphical interfaces on things like
> PocketPCs and various CE.Net web tablet type devices.

That's good.  For HA to be used, it's got to be simple and relatively
foolproof.

> > That's nice to know, but I suppose I'd rather know "how many devices are
> > out
> > there to drive?" and what percentage of that base you've got drivers
for.
> > When I go looking for operating manuals on sites like Sony and
Panasonic,
> > I'm astounded by the sheer number of different models they make of
almost
> > every consumer item imaginable.  How can you or anyone else in the
driver
> > business hope to keep up?
>
> The current list of devices is here:
>
> http://www.charmedquark.com/Documentation/Drivers/Drivers.htm

I looked through it and found relatively few devices that I own that are
supported.  I know it sounds like a "knock" but it isn't.  It's more a
comment on the absolutely unending tidal wave of new equipment appearing
each year.  For example, I blew out my primary sound amp, a 5 year old Sony
mid-line receiver.  Since I wanted to put a larger amp in the family room, I
thought I'd buy another Sony and use that in the living room and put the
repaired Sony in the family room when it came back from the shop.   Boy, was
I surprised to find that none of my IR codes for the old Sony worked for the
new.  So it's obvious that manufacturers don't even care about being
compatible with their own equipment.

> It's difficult to keep up. What generally happens is that drivers get done
> on a 'demand' basis, i.e. when a potential customer needs them. They are
> often done by technical customers, so we don't do them all ourselves.

That's good, but I seem to recall that was an issue you had with HomeSeer.
IIRC, it was that their plug-ins may not be designed by the same person who
wrote all the code.  Now I am aware that a plug-in is not a driver, but I
think the principles in creating either are fairly similar and the
opportunities for trouble are there in both drivers and plug-ins.

> some cases they are done by the company that makes the device.

What percent is that?  I can't imagine that many companies like Sony or LG
have much of an interest in control SW that they don't own.

> In some cases, there are 'protocol families' that cover a number of
models.

> For instance, we have a 'universal' Denon DVD driver, that covers a whole
> family of Denon serially controllable players. Or the HAI Omni protocol
that
> works for the whole Omni line, that kindof thing.

No offense meant, but that's more a function of *them* getting the
"standardization religion" than you, who already likely has it!  I finally
bought an Omni LT because I was impressed by the very modular (and
self-compatible) path they've chosen.  I'm sure your sort of work teaches
the value of "universality" early on.
>
> > I guess I don't wonder much why "Home Automation" seems to have stalled
> > when
> > you remind us that interfacing with most modern consumer electronics has
> > to
> > be done on a case-by-case basis.  Theoretically "toy" makers should be
> > building to a common control bus spec and provide some sort of
universally
> > accepted configuration firmware on board to provide setup and
operational
> > details.
>
> Don't hold your breath on that one.

Don't worry.  I'm not.  The DVD +- debacle along with the new HD DVD format
wars tells me things haven't gotten any better.   I'd say that they've
actually gotten worse.

> The thing is, you could put in a year
> creating this incredible layered generic protocol that would solve
> everyone's problems, and put it out with great fanfare and get completely
> ignored pretty much. And most of those who didn't ignore you would just
sit
> on teh sideliesn and heckle you and pick it all apart and ridicule the
whole
> thing. There are some attempts. UPnP and xAP are some examples.

I had great hope for UPnP - and it may still flourish one day.  But I sadly
agree that such a schema is not likely to evolve from the current
manufacturing environment.  It's too bad, too.  Imagine yourself freed from
the drudgery of writing driver after driver.  You could spend lots more time
on the command and control functions, not the low-level wiring.  I'm hoping
that when Zigbee finally starts shipping in quantity it will become a
defacto standard that manufacturers might be willing to adhere to in fear of
being left in the dust if they didn't.

> I could certainly create a small set of protocols and easily adaptable
> implementations that would serve most devices and make them available for
> free, but few folks would use them. The level of NIH syndrome in place at
> big companies like Sony or Samsung or IBM or Microsoft and so forth is
> enormous.

I agree.  Worse, still, I don't see much on the horizon that would force an
end to that sort of tunnel vision.

> > Not sure *why* you would want to do that or what kind of events
> > would cause a restart.
>
> Not all users keep their automation system on all the time, or they might
> bring it down to change hardware or some such thing. Whatever the reason,
> there was a wee bug that could cause CQC to think that today's event had
> already occured and it would reschedule for tomorrow, skipping today's
> sunset event.

I see.  I've never been a fan of PC-controlled home automation because of
all the issues I had when trying HomeSeer with a CM11A.  I've come to
realize that the CM11A deserved most of the blame for quirky performance.
Were I to return to PC controlled automation, it would be one of the very
small, dedicated PC boxes that did nothing but HA and ran 24 by 7 with a
UPS.

> >> Z-Wave Driver Improvements. The initial Z-Wave driver became available
in
> >> the previous CQC release. Based on feedback since then, some
improvements
> >> have been made.[/LIST]
> >
> > For instance?
>
> Purely internal, based on improved understanding of the protocol. Nothing
> end user visible, but it will just make the driver more reliable.

OK.  Sounds fair, although a little reminiscent of MicroSoft's touting of
XP - "this one works!  Really!"  I read through the support notes at your
site about Z-wave and while it cleared up some questions about how Z-wave
secures itself, I was disappointed by the case sensitivity issues as well as
a lack of automatic replication of the primary controller.

It would be nice if the replication took place without having to aim IR
receivers, i.e. you could specify a secondary domain controller and
automatic replication.  Again, this is not your fault, clearly, but the
Z-wave folks' fault.  And it's hard to blame them much for their approach
because it seems to be an integral part of their security design.

Well, thanks for taking the time to respond and congratulations on the very
professional looking website.

--
Bobby G.