[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

Re: Dedicated Z-wave sites?



"Dean Roddey" <droddey@xxxxxxxxxxxxxxxx> wrote in message
news:dnqgh.9365$hI.3594@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> "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.

No, I am saying (and research that I cited appears to agree) is that crappy
drivers come from "good" companies *and* "bad" ones and it sounds as if one
has to have a considerable amount of driver evaluation expertise to be able
to tell what they can load on a CQ system.  I'm trying to determine how you
implement what you claim to be immunity to the types of driver issues that
plague other software applications.  I'm wondering how that's done in an
environment where a driver can disrupt a data structure in the kernel that
shits (too good a Freudian slip to elide!) er . . . *shuts* down the
systems.

What I've said before I'll say again.  Bad drivers can come from good
companies.  It depends on deadlines, access to needed interoperation HW and
SW, competence of the programmers, complexity of the driver, etc.  However,
it's clear from your previous responses that you intend CQ to be installed,
configured and maintained by professionals.  That means *they* get to worry
about a client wanting to plug a new Panasonic Netcam into their Ethernet.

> So don't  stick a crappy piece of hardware in your car engine. Problem
solved.

I've got to find a better way to express what I am trying to say.  How does
an end user of typical smarts know whether a new, inexpensive model of a
Panasonic Netcam contains a good driver or a crappy driver. I know the
typical way:  He installs it and it either crashes or it doesn't.  If it
didn't crash, it doesn't really mean it's a good driver, BTW, it just means
it didn't encounter any exceptions.  This time.

> If you  insist on buying junk, I don't think you should be suprised at
what happens.

Are you calling Panasonic a "junk" company or are you just impugning my
buying habits in general?  (-:   I happen to own a lot of very high end
equipment.  It's usually when anything inferior just won't do.  Browning is
a favorite choice of mine because it's so reliable.  So is Nikon because a
picture is only as good as its lens.   Sony is, too, because very little was
able to match the quality and performance of something like the D8 DAT
recorder.

You've been talking about how Windows can be made reliable when sequestered
deeply enough.  I've been implying that it's getting harder and harder to do
that.  I find it more and more necessary to connect to the web for upgrades
to SW and FW and having to deal with Windows installation breaking ANY time
I upgrade any hardware.  In other words, I find your recommendations of
isolation to achieve reliability to be increasingly less practical in the
real world.

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

What happens when I plug it into my CQ server?  Will it break the whole
thing down?  Will I be able to easily add a mass-marketed device like a
netcam from a major market player to my CQ HA server or do I need to wait
until you get around to coding for it?  Please explain!  I'll send you mine
to evaluate if you're not sure how to answer the question.

> Else, do a little research and find out what works, since you will seldom
be
> the first person to do anything.

That's not true.  I was one of the first people here to work with the XTB.
Unfortunately, I am an early adopter of some types of technology.  I'm going
to buy a Rozetta, just as I was one of the first people here to use Control
Linc Maxi's from Smarthome to control all my house and unit codes from a
single device.  I just bought three brand new items.  A multiple channel
timer with voice labeling, a timer that's got a remote pager and an new X-10
Pro LCD based mini-timer for X-10 that runs for a long time on two AA's as
backup.

The first two are brand new on the market and I got them for my wife mostly,
but for me too as a way to monitor the end of Ebay auctions.  Although they
are stand alone, I'm going to integrate them into my HA "messaging" speakers
that were inspired by a design I borrowed from John Warner, IIRC.  So,
anyway, your "seldom be the first" may apply to a lot of people, but not to
me.  You might be confused simply because I refuse to abandon the known
demons of X-10 for the unknowns of some of the more recent protocols.
That's me Scot's blood, laddy!

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

I think that once Vista hits, with its very different way of doing things,
your already incredible workload will double and you won't be able to keep
up.  It's a pattern so common it's sad, really.  I've seen it, closeup, at
least ten times, maybe more.  Those are the spectacular ones I can recall,
where someone mortgaged his home to propel the software business.  This goes
back to the days of 386MAX, built and marketed just blocks from where I
worked 20 years ago.  When MS put EMM's inside the OS, the bottom fell out
for third party memory managers.  Can you really afford to split your
current level of resourcing when Vista arrives?

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

Now *that's* a bulletproofing technique that I can understand but as you
point out, there are both benefits and costs to your way of doing things.
The most important is that it puts a lot more work on your shoulders and
increases the risk of "keymanning" yourself - being the only one who really
understands how everything works and the underlying design philosophy.  What
happens to CQ if, God forbid, you became incapacitated for six months?

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

As long as you have installers and professional configuration people do
perform those tests and to ghost the machine before any new HW or SW is
installed, that's fine.  But as I said to Marc, there are ideal business
practices and there's what people do in the real world.  In the real world,
they unwrap the new toy, plug the disk in and follow the instructions.  Out
of the many people whom I've taught some PC skills to, only one religiously
backs up her machine before any changes are made.  And that's only because
she's encountered the "killer application" several times before.  That's the
new piece of HW or SW that causes the dreaded BSOD.

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

That's why I took issue here.  While what you describe are excellent
business practices, it's just not how most *lay* people work.  Despite
decades of trying to get end users to pay attention, I'm lucky if someone
scribbles the actual words of an error message to me in an email when they
have a problem.  You've made it clear, though, that CQ is really aimed at an
HA professional with a lot of data and networking skills.  They'll probably
back up a server before modifying it because their time is money!  And
they'll know what devices should and shouldn't be connected.

--
Bobby G.






comp.home.automation Main Index | comp.home.automation Thread Index | comp.home.automation Home | Archives Home