Re: [ha] Basics
Loi Tran (leotran.at.worldnet.att.net)
Thu, 15 Oct 1998 16:54:16 -0500
At 08:23 PM 10/15/98 +0100, you wrote:
>On Thu, 15 Oct 1998 07:32:56 -0700 rah.at.atdot.org wrote:
>> Actually, the inclusion of "extensible" would also mean that "PC interface"
>> would be one of the "device ideas" that the ha system would accept.
>Yes indeed. I thought it was worth mentioning the PC interface as a
>goal in its own right as it is something that I hope most contributors
>would want developed early on. An extensible protocol design is a
>must, but actually extending it into relatively specialist areas like
>greenhouse-watering and MP3-playing would be a low priority at the outset.
>
>> How about functional specifications? Hardware and software specs?
>Maybe we should list those as specific goals instead of just in the
>general statement of purpose. I suppose we are working on the functional
>specification already.
>
>We need to define hardware and software standards at several levels
>(to borrow the slightly inappropriate names from ISO):
> physical (with alternatives for mains/radio/IR/dedicated wiring)
> data link (framing/error checking, closely entangled with physical)
> network (how packets are formatted)
> application (what packets mean)
>
>It may be that we can adopt existing standards for the bottom layers
>(like SLIP over mains or radio, RC5 over infra-red and I2C for dedicated
>wiring; maybe IP/UDP for the network layer) which leaves us free to
>concentrate on the interesting and novel parts at the application layer.
>
>> I kind of remember one comment that the homeowner shouldn't need access
>> to an EPROM burner but without some kind of logic store I'm not sure we'll
>> be able to implement a great amount of intelligence to the system, which
>> is first and foremost the goal as I understand it.
>There are several microcontrollers around which have on-board long-term
>EEPROM program and data storage. Many of these can be programmed with
>just a standard serial port (like the 68HC11) or with a simple circuit
>hanging off a parallel port (like the PIC family). I think we can assume
>that active participants of this list have a computer:-)
>
>Anyway, once the bottom layers of the project are worked out and we
>have some controllers designed and built, I imagine that those people
>capable of production would be willing to make and distribute PCBs,
>pre-programmed controllers or even complete modules at reasonable cost
>to the less well equipped members of the group.
>
>> What about a packaged control system like The Stamp (a microcomputer/ROM
>> based BASIC system) as 'brains?'
>I don't know much about the BASIC Stamp's capabilities, but if it has a
>simple programming interface, a reasonable quantity of I/O and is cheap,
>it may be exactly the sort of unit we need to get going. But isn't
>it proprietary? Does that matter anyway?
>
>Also, remember that there's no need to have only one sort of brain.
>As long as the protocol is well-defined, contributors should be free
>(and even encouraged) to use their own favourite platform. I'd rather
>have a dozen different solutions 90% complete by Christmas than spend
>the next two years arguing about the perfect design. All the designs
>will be shared, so we can all learn from other ways of thinking and make
>improvenets as time goes on. The software reference implementation
>should be written in something portable (which, I think, still means
>C until embedded Java gets a bit more mature), so no platform will be
>particularly favoured. What may well happen is that one design will
>win out over the others for some reason---cost, simplicity to build,
>quality of support tools, size, whatever---but there's no need to
>pre-judge the issue.
>
>> ... In the US at least, and I'm sure the other countries represented here
>> have similar laws, you need to be sensitive to the requirements of UL.
>UL?
>
>> IIRC they have some stringent guidelines when dealing with power
>> control circuits which may make an enterprise like this, even hobbyist
>> as it is, fraught with danger. And a lot of times the design effort
>> to gain compliance will drive up the cost of the product significantly.
>
>Oops, yes ``Safe'' is an obvious omission. It should be near the top
>of the goals list, maybe with ``Meets all relevant approvals''. But I
>must admit to not being too bothered about compliance with approvals;
>obviously I don't want to be responsible for killing anybody or blowing
>up a power station so safety is a must, but this isn't going to be a
>consumer product so it doesn't have to meet all the petty rules about
>colour of labels and such. If someone wanted to take the design and
>market it commercially, that's great, but it would be that person's
>responsibility to meet whatever approvals were necessary. If we were
>to distribute our design under the GNU Public Licence any changes made
>by such an entrepreneur would have to be contributed back to the project
>so we would all benefit without the cost.
>
>The point I really wanted to make with the "low cost for simple modules"
>goal is that we shouldn't depend on (for example) US$300 wireless LAN
>units to do the communication between light switches (but it might be
>quite acceptable to use such technology for a communal MP3 server).
>I didn't put a specific price goal in because I think it's impossible
>to set a budget when we don't have much idea what the system is going
>to be able to do (and not do). But cost matters: I have about 20 lights
>alone and more than twice as many mains appliances, so unless the modules
>cost only tens of pounds each, it's going to be too expensive to convert
>my whole house to use them, which would be a significant disincentive.
>Prototypes and special stuff can cost more, of course, but we shouldn't
>get too fancy with the basics. Remember: KISS (Keep It Simple, Stupid).
>
>Robin.
>--
>R.M.O'Leary <robin.at.acm.org> +44 7010 7070 44, PO Box 20, Swansea SA2 8YB, UK
Okay, so we've basically agreed to
1) extensibility
2) safety
3) open-free standards
4) minimal cost
5) assembly with minimal hardware
I hope I didn't miss anything. So, who'll start the draft on the standards?
Or should we just keep adding to a list of standards and cut and slash from
there?
Loi