Timothy J. Weber wrote:

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

no, neither me: I was talking about the "Ethernet physical level" i.e. 
RJ, cable, chipser...
agreed on the other part.


>>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) (!).

sure, exactly!


>>Maybe that some "tailoring" will always be needed, i.e. it can be 
>>[...]

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

yep.
no, just 64 levels seem to be ok :)

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

yeah

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

I agree on this. I found their "dictionary" quite complex and 
complicated. Of course, one can use only the part he needs, but it may 
still look hostile.
But, indeed, some standard way of "naming" things or actions has to be 
there.

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

Oh, I started out with what I considered necessary (in first draft in 
1992 I did not even have a checksum, just parity bits... but I was very 
young :) )
Then I added features, increased stability and reliability, borrowed 
some ideas from here and there... The Powerline protocol, for example, 
was "very" complicated and had a lot of overhead.
I digged into TCP/IP only later, and by the time I found out that... 
things almost always go that way!

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

Nordic wireless chipsets, such as 2401. I used them a lot, and the 
meeting was good on the technical level.
I also found good information and hints in the CC2420 (Chipcon/Texas) 
application notes.


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

nice!
I installed solar panels on the roof of new home, I still have to move 
there though. The inverter has an Ethernet port and should be SNMP 
capable, so I'll probably use it to monitor it.


Happy solstice everyone :)

-- 
Ciao, Dario -- ADPM Synthesis sas -- http://www.adpm.tk
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist