Re: Some upcoming CQC 1.4 teasers

["Dean Roddey" <droddey@xxxxxxxxxxxxxxxx>]

> The information above just about begs me to ask: "Does this version
> support
> the .Net Interface Viewer?"  :-)  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. These interfaces
are the primary interaction mechanism for most automation systems, often on
a locked dwon PC running on a touch screen in a kiosk sort of mode. The .Net
version of the interface viewer is based on .Net and therefore should be
able to run on most devices that support the CE.Net 4.2 or the 'mobility'
version of the .Net framework. This lets you view CQC graphical interfaces
on things like PocketPCs and various CE.Net web tablet type devices.

> 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

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. In
some cases they are done by the company that makes the device.

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.


> 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. 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 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.


> 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.


>> 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.

-------------------------------------
Dean Roddey
Chairman/CTO, Charmed Quark Systems
www.charmedquark.com