Re: Organizing HA program rules/logic/code

["Dean Roddey" <droddey@xxxxxxxxxxxxxxxx>]

I guess what I was trying to get at in my post is that, there are ways to do
it that are well proven, but the fact that no one really does it well in the
way you are wanting, and the fact that there are so many benefits from doing
it well in that way, probably usually means that it's not really practically
doable in that way, else someone would have already done it and taken over
the world, right? I.e. if there's an obvious market, and everyone knows the
solution to tapping that market, but no one ever delivers the known solution
(even after years or decades to do so), there's probably something either
wrong with the supposedly well known solution or implementation of that
solution isn't practical for some reason?

In the software world, from a business standpoint, it would be great if
there was a way to do exactly what you want to do in a way that would allow
less skilled (read 'lower paid') people to do it. So there is a huge
financial incentive to create such a solution, which would obviously be
applicable to the far simpler scenario of automation logic. And there have
been many attempts in the software world to do these things, but I don't
think that they've really made more than incremental headway really, because
complexity is still complexity, no matter how pretty a face you put on it.
And the more complex, as I said before, actually the worse those types of
tools become because of the limited view into the data they provide.

I think that part of the problem is this: The complexity of the problem
space itself is as big a hurdle than the complexity of the tools. I.e. you
could make tools that would make the actual doing of the job easier, but
that doesn't make the actual problem space that much less complex in terms
of understanding all the issues required to actually create the logic
required. So perhaps you end up spending a huge amount of money to create a
very complex tool, but then you figure out that the market for that tool is
a relatively thin band of people where the group of people technical enough
to understand the problem space overlaps the people without the ability to
do it via other existing tools. On either side of that band, you have have
one group of people who can't do it no matter how helpful the tools, and on
the other side you have a group of people who don't need that kind of tool
to do it because they can do it via more powerful (though more complex)
tools.

Anyway, I'm not trying to dump on your concern, since it's obviously valid.
I'm just, for the sake of discussion, pointing out the issues with it. And
I'm not saying such things are a waste of time. I'm sure that such tools, in
particular applications, are a huge boon once the time is taken to create
them. But in certain problem spaces, and perhaps home automaiton is one of
them, I'm not sure, the problem space itself has sufficient complexity to
create the filtering issue discussed above and doesn't make for a large
enough market to justify creation of the tools.

Then again, perhaps I'm completely wrong.

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

<MFHult@xxxxxxxxxxxxxxxxxxxxx> wrote in message
news:6otda1pai1kq5mm8rvfj8nmnmrhoipnnsg@xxxxxxxxxx
> Interesting comments. But my question was not toward programmers, but
> towards the user experience. The inability to develop strategy for
> developing, checking, and presenting rules _ at the user interface _
> is a large part of the reason why HA has not thrived. Some software
> does it better than others -- none well enough for mainstream use in a
> moderately complex HA environment IME.
>
> Marc
>