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

Re: Organizing HA program rules/logic/code



Some of this is reminiscent of the PCDOS-era discussions ;-)

Here are some suggestions some of which I know have been implemented in at
least some software but are still generally lacking.

1) A graphical interface for rule building (Cyberhouse went so far as to
use a symbol representing if-then-else as its logo ...)

One simple (seems to me) graphical tool could be a visual indicator of what
devices are affected by which rules (CyberHouse does this partially. )

2)  Built-in rule checking for internal consistency.  Rule checking should
prevent or otherwise flag the addition of a rule incompatible with existing
ones (ala Excel ?)

3) Grouping of rules into named sets which can be evoked and manipulated
together

4) More smart functions "Use running 30-day mean of turn ON/OFF date/time
for device X .)


And so on

There's no claim that this would inevitably lead to commercial success, but
I have seen near-nil progress in the last five years. And the failures
continue. Home Director (w/ IBM & Sears pocket backers among others)
bellied up finally last month.

Marc


On Wed, 08 Jun 2005 18:25:34 GMT, "Dean Roddey" <droddey@xxxxxxxxxxxxxxxx>
wrote in message  <yKGpe.1311$bv7.924@xxxxxxxxxxxxxxxxxxxxxxxxxx>:

>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
s>ome 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
>>
>



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