The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


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

Re: HA Object Model or Taxonomy?



Hi Gavin,

>>> I think part of the reason that there is not an open, public
model for =
home automation is that many of the efforts in this area have been made by
=
companies who think that owning the object model is a way to give
themselve=
s competitive advantage;

Indeed. I guess it depends on what background you start from, but for some
=
reason in many industries it's still the conventional wisdom that
proprieta=
ry =3D=3D good  which, in my view, ignores abundant contrary evidence.=20

It's only in some areas of some industries that the power of common
standar=
ds (de-facto or otherwise) and truly open specifications to grow (or even
c=
reate) a market has been realised. The lack of really open standards is -
i=
n my estimation - the principal reason why HA take-up and acceptance has
be=
en so patchy and why so much of it is so clunky and hard to use.=20

People with a tech background, used to lots of open standards (designed to
=
facilitate true interoperability) can only stand back and gasp at the
stupi=
dity...... 8-) I think DLNA's lack of openness and genuine sector
leadershi=
p is a particular disappointment in this regard.


>>>to help home automation finally take off, we really need a
model which a=
nyone can use in order that they no longer need to reinvent the wheel for
t=
he basics, and can concentrate on the things which are really cool!

Yes. The great lesson of the IT and communications industries (and to some
=
extent the automotive industries) has been, make the base technologies
into=
open specification commodities and make money by adding value and intellec=
tual capital at the higher levels - where customers can see and appreciate
=
it. The per-product re-engineering of the basics that customers never see
i=
s bad bad business.

>>> In keeping with this approach: it is entirely right, proper,
and a thin=
g to be celebrated that you are already thinking of uses to which the
model=
could be put! I most certainly do not have a problem with using the potent=
ial model in your books, indeed if this project is to have any utility
then=
the more people who know about (and use) it, the better.=20

Great!

>>>I would only ask that we try to keep the model as generally
applicable a=
s possible, rather than focusing on an implementation which might lend
itse=
lf to use with microcontrollers.

Yes, absolutely. A model that aspires to become generally applicable but
wh=
ich actually prescribes an implementation is doomed! So that is definitely
=
something we must avoid. I will respond in detail to your other comments
on=
that area later on today.=20

>>>Though on that point - how are you planning to tackle
networking with th=
e AVR devices? Last time I looked, getting a TCP/IP stack working with
them=
was still a bit fiddly (though of course this is far from the only network=
implementation to be considered).

Well, late-model AVRs have code space memory (32K or more) that can take
an=
IP stack. There is a SLIP library which is only at 9KB big that can do IP =
pretty well over serial lines (and of course most AVRs have a built in
Seri=
al port and - using Arduino libraries - can software emulate additional
one=
s if you need them). In my current work, the projects just use custom
short=
message formats over a 433Mhz radio module (e.g. http://www.ebay.co.uk/itm=
/RF-Radio-Wireless-Data-Transmitter-Receiver-433MHz-NEW-/150780566460?pt=3D=
UK_Gadgets&hash=3Ditem231b38dbbc ) linking them to a serial port on a
deskt=
op machine - which works pretty well within a house, with just simple
check=
sum protection on the small packets. It's simple and its cheap to do and
pe=
rfectly adequate where you only need datagrams, not a full connection
proto=
col.

Generally, although it's the ideal world, I'm not altogether convinced
that=
using a full IP stack and CAT5 cabling or WiFI is good for HA because (a) =
it sets a fairly high minimum price point for anything you add to your HA
n=
etwork. Obviously if you're using full computer modules it's expensive,
but=
even going the microcontrollers route it's still an Arduino Uno with a CAT=
5 shield and cabling etc which will total well over =A350, and a bit more
t=
han that if you use a wifi shield. That's a big price tag if you're going
t=
o need lots of them around the home. My current approach of an RS433
module=
and an AVR chip costs about =A38 for the parts - though of course its more=
restricted in what you can do, but many HA stations don't actually need to=
do much more than signal simple messages. Also (b) using a full stack bump=
s up the spec of the compute power and memory you need in your HA
periphera=
l device, or if you stick with a micro controller such as an AVR, a PIC or
=
PICAXE it eats up quite a lot of your code space leaving less than you
migh=
t like for the actual application level. So, in short, I think there is a
c=
ase for using a full IP capability in some devices, but in others I think
i=
t's a barrier to viability.

For my HA project book (which I haven't really seriously started yet) I'm
p=
laying around with using CAN helper chips (SJA1000 and one other whose ID
e=
scapes me at the moment), which looks promising. I think CAN networks may
h=
ave a great applicability to HA, perhaps using a hybrid of CAN protocols
an=
d RS485 at the wire level or maybe the radio modules approach again.
That's=
all TBD at the moment until I complete the current work.=20

Anyway, I'll reply later to your thoughts on the object model. I'm glad we
=
can get this going!

Best regards
Alan T





------------------------------------

<*> Join the Automated Home Forums
http://www.automatedhome.co.uk/vbulletin/


UKHA_D Main Index | UKHA_D Thread Index | UKHA_D Home | Archives Home

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.