> 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