>> This at least illustrates my point - which I think is that anyone 
>> dabbling with home automation, and perhaps even serious industrial 
>> automation developers, eventually needs/wants some kind of 
>> infrastructure like this.
> 
> I have seen this actually done or at least "proposed" by some big firms 
> around. Looks like people took some time :) but then this way of 
> thinking got spread - as the the more efficient. Personally, I'd say 
> that I was considering Ethernet as the medium of the future (for home 
> automation, but take it as car-automation too) back in 1997... but, 
> later, I saw that, smaller, more efficient (and less power/resources 
> hungry) protocols could act perfectly down there. But, then, you had to 
> interface those protocols to other standards and so...

I should clarify - I'm not suggesting that Ethernet is the right 
transfer medium for everything, just that it would be handy to have a 
library that can support Ethernet *from the workstation* (where it's 
easy) for free.

> And, even in 2008, having a "home automation" node, say a dimmer, with a 
> Ethernet I/F would be, IMO, a waste of space, power, and complexity.

Agreed.  But, giving it SOME kind of interface (like ZigBee or RS*) is 
essential to the "automation" part.  And once you can get that interface 
attached to a PC, you can get it anywhere else for free (with a bit of 
programming) (!).

> "Scalability" is probably the right word.

Right.

> Maybe that some "tailoring" will always be needed, i.e. it can be 
> somewhat easy to embed a 485 packet (or, for that matters, a X10 frame 
> or a Zigbee frame) into a UDP datagram... but requesting a value from a 
> Meteo-Station via a HTTP query is less-likely to be standard. Or maybe 
> it's just because no one has standardized it yet!

Yes - it's of course possible to propose a standard dictionary for 
certain kinds of values, and you could come up with a set for weather 
stations as an example.  I have a dictionary of values I'm interested 
in, you do too I'm sure.  Perhaps some of them are truly universal, like 
a "light level" from 0-255... but maybe you use 16-bit light levels!

And I think having the flexibility to support other devices that aren't 
specifically under the "home automation" umbrella would be good too.

So I think trying to standardize the data dictionary side of things is 
not the right way to go.  (This is where ZigBee appears to be headed 
now, which seems troublesome to me...)

>> Did you find any other options out there worth considering before 
>> rolling your own?
> 
> Hmmm, I started this home automation thing in 1992, developing some 
> Z80-based boards with expansion daughter boards, with I/O @24, 220V and 
> such. Then tried Power-line modems (ST7537 from ST and TDA5050...1 from 
> Philips) but they were not very good, at least to me. So I started using 
> PICs in 2001 and then chose to use RS485: I started out @9600 baud, then 
> moved 19200, then 57600 and now 115200.

Neat!  But it sounds like you didn't see anything else attractive for 
the protocol layer.

> Writing my own protocol was mostly... fun! But then, you learn a lot 
> from your errors and looking at other people's work - for instance, I 
> got the "repeated frame" thing attending a Nordic meeting.

What's that?

>> (I've generally discounted X10 and similar as too proprietary and 
>> expensive to invest in, especially for someone capable of working with 
>> PICs.)
> 
> yes, in fact.
> Actually they were also hard to find in Italy, at least back in the 90s 
> (where are you located by the way?)

New York State.

BTW, in honor of the summer solstice today, I put together a 
solar-powered wireless insolation (solar radiance) meter.  Uses the 
protocol I'm talking about above.  Should be graphing the amount of 
light getting into my office throughout the weekend; I'll see if it was 
working at the moment of the solstice when I go back on Monday.
-- 
Timothy J. Weber
http://timothyweber.org
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist