Re: Dedicated Z-wave sites?

["Dean Roddey" <droddey@xxxxxxxxxxxxxxxx>]

"Robert Green" <ROBERT_GREEN1963@xxxxxxxxx> wrote in message
news:LsKdnXy1WohgYRzYnZ2dnUVZ_vyunZ2d@xxxxxxxxxx
>
> It's got to do with why HA programs like CQ are slow to gain acceptance.
> I
> just bought a Panasonic Netcam from Smarthome.  I want to plug it into my
> system and email pictures to my cellphone.  Wouldn't the natural place to
> install such a beast be the HA server?  If a net cam has a *really* bad
> driver, it's going to blow up CQ.

I'm still confused. You are kind of saying, if I stick a crappy piece of
hardware in my car engine, it could fail. Well, yeh, it would. So don't
stick a crappy piece of hardware in your car engine. Problem solved. If you
insist on buying junk, I don't think you should be suprised at what happens.
If you are first person on the planet to buy such a camera, then I guess you
will have to try it yourself and if it turns out to be junk, send it back.
Else, do a little research and find out what works, since you will seldom be
the first person to do anything.

As to CQC being slow to gain acceptance, this is just business reality. Most
new products are slow to gain acceptance when they are entering an existing
market that has settled into a pretty solid pattern, and they are trying to
create a new pattern. The market, for us, is the professional market, and
the gatekeepers of that market are custom installers. We have to convince
them that both the product and the company are solid. That is now starting
to happen, given that we've been improving the product rapidly for years
now, and have put out a very solid 2.0 product. But of course they are
(understandably) conservative and tend to stick to what they know, so the
process is always slower than we'd hope. But it's happening. We've had a
over 5x increase in systems shipped this year, and I think it'll be more
than that next year.

>  Many people cite the decline of Homeseer reliability as
> coinciding with the heavy reliance on "plug ins" - really another form of
> device drivers.  Something I saw today said that 6/7ths of the existing
> Linux codebase now consists of device driver code.
>

Homeseer allowed people to implement plugins using third party languages and
to do whatever they wanted. This is not the case with CQC. Drivers are
written in CML or PDL, which we control and which are highly strict
languages that very much limit the ways in which a driver can destablize a
system. There's reall only two ways. They can into an infinite loop, or they
can eat up memory without stopping. Both of these can be found with a fairly
trivial amount of testing and user beta testing.

Now that allowed users to extend HS in a lot of ways, but the price is loss
of control. We've often had to do a lot of arguing that forcing the use of
CML/PDL was improtant for just this reason, even if it meant that many new
features must be provided by us, not by third parties. I think that this
conservative position has proven out. We just did our 2.0 release and it
went very smoothly for a major version upgrade with huge product
improvements/changes. I've always taken this conservative approach that, at
least in our target market, no amount of functionality is going to sell if
it's not solid.

> I dunno.  I have plenty of machines that serve more than dual purposes.
> Were I to strictly devote one PC per application, I would be running a
> server farm.  While it may certainly be best practices for a business,
> size
> and money constraints often dictate that more than one application is
> going
> to live on a server, especially on a home network.

Plenty of our users use their servers for more than one thing without any
problems. They just don't throw junk onto their systems. Plenty of them are
using the same machine as an automation server and media server, for
instance. It just requires that you do some due diligence and have a burn in
period for any bits that you are going to use.

And the same would apply even if you are using a completely solid state
controller because the controller is in turn controlling devices, which
could possibly have errors in their protocols (and they sometimes do.) So of
course you must test out your configuration and give it a real world break
in period and deal with any issues.

This is not something that most users will do themselves, as I said. So most
folks will hire someone to do it for them. That person, one would hope, is
not lying about his/her experience and will be qualified to insure that it
all works together correctly. In most cases, where possible, the installer
will use components that experience has proven are solid. If the user
insists otherwise, the installer will probably charge them more to cover the
extra work required to validate those unknowns.

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