I am looking for a cheap, low power micro board that has some i/o (mostly digital) and a communication bus suitable for a small home automation project. I am thinking of using CAN or 485. I remember seeing a relatively cheap system but I was not able to locate it. I think it had PIC micro on it. I found a similar product, SBC28PC-IR2 from modtronix. But, I am sure there was another one.
Also, are there any other buses that I can use. I would prefer one where I can use relatively thin cables that can be routed through existing wiring conduits. So, Ethernet is out. Besides, it costs a lot more and needs more power. I am leaning towards CAN because there is no master and that allows exceptions to be notified immediately.
For the master controller/user interface, I have a few boards lying around including an older PC. I am also thinking about adding a WiFi/ GPRS connection for remote access.
Have you looked at how your house is wired for low voltage stuff? Unless it's way different from the usual practice in the US, there are no "conduits" -- the cable is routed between the studs. Cat 5 cable is not going to be any harder to route than an infinitely thin string IMHO.
If you're building everything yourself, then CAN or RS-485 might be less expensive. But if even one device out of five is an old PC, then Ethernet will be less expensive.
CAN is prioritized per bit, and is much lower latency _per bit_, but you have to set the baud rate low enough that the transients and any propagation delay between the furthest-apart nodes are settled out in 1/2 a bit period. So the bits in Ethernet fly around a whole lot faster than you'll be able to achieve with a whole house wired for CAN.
In the US, routing signaling conductors through a conduit shared with "line voltage" conductors is a big-time Code violation. Likewise, running cables through ductwork is a no-no.
I.e., running cables is a PITA -- there are no shortcuts.
Cost is a relative thing. I've been doing a similar thing, here (security, VoIP, automation and multimedia) and wired ethernet was the most practical solution (bandwidth, security, power *distribuition*, etc.). Once you put an MCU on a piece of FR4, the costs of that MCU become relatively insignificant. OTOH, it opens the doors to other applications that CAN just can't address.
[OTOOH, a network stack is considerably (?) more work...]
If you are looking for least headache, consider a ZigBee solution. It sidesteps all of the wiring issues (trust me, wiring is a labor-intensive proposal! I have ~2K ft of CAT5 strung here...). And, if the duty cycles of your "devices" (motes?) is low enough, you can opt for *battery* power -- instead of having to locate a power supply (wall-wart?) adjacent to each device (what happens to your system when the power fails? Or, when it is *intentionally* interrupted??)
For the micro board, your first choice would be one from a processor family with which you are already familiar. Look at the development boards from Olimex, which are pretty widely known and distributed worldwide.
formatting link
carries them over there, probably other sources as well.
If you go Ethernet and you don't need TCP for the home automation part then you can probably write your own UDP/IP stack with reference to one of several existing projects on the web. Getting the damned checksums right is probably the hardest part and UDP is well suited to connectionless, declarative operation: tell me the temperature, turn on the light, this switch just opened, etc.
If you do need/want TCP on the nodes, though, you'll probably want to buy a stack rather than take the time to write/debug one on your own (unless that's part of the fun. ;-) An off-the-shelf TCP/IP stack will limit you in terms of which compilers and what hardware it supports. There are hardware solutions, like the Lantronix XPorts, that are easy to use but can really push the cost up for a home project with lots of nodes.
A CANbus is intrinsically slower than Ethernet, as Tim noted, but for reporting temperatures or commanding relays, a millisecond may be as good as a microsecond. Individual smart nodes connected over CAN with one bridge node on a well-protected PC for access to the outside world over Ethernet might be a reasonable architecture. The bridge to the PC could easily be over a normal serial port, as most microcontrollers with a CAN peripheral will have at least one UART available, so you would not need anything special on the PC other than the application software.
Horses before the cart, please. Choose the bus, the protocol, the topology, the physical link, type and number of interfaces, etc. Probably the most important decision is if you want (or not) to interface to commercially available switches, dimmers, sensors, etc. THEN select the board.
There is an AVR/CAN based project here:
formatting link
Probably two, even three or more. Small boards nowadays breed like rabbits.
I vaguely remembered "C-BUS" - Found this site,
formatting link
opened a document at random, lost interest when read the following: "All C-Bus addresses are one byte, encoded $00 to $ff" I believe they recommend Cat-5, in which case I would use Ethernet.
Others already commented on this.
The same can be accomplished with Ethernet and RS-485 ...
-- Roberto Waltman
[ Please reply to the group, return address is invalid ]
Checksums are optional in UDP (*technically*, they can be "turned off"... so its a semantic issue if your entire application implicitly turns them off -- thus, overriding the default "on").
You;d be wise to steal a checksum immplementation from a *real* network stack -- not a hobbyist implementation. There are a few subtleties that can bite you when implementing the checksums. Plus *lots* of efficiency hacks that can be inspirational in small systems!
The problem with UDP is that it makes no guarantees about delivery. E.g., get those checksums wrong (e.g., sum == 0x0000) and the protocol "silently discards the packet". How often this bites you is a function of your actual traffic, higher layer protocol, etc.
If you have "important" information flowing across the link(s), chances are, you may want some "confirmation of delivery". Or, even, "acknowledgement of intent"! This is where existing protocols (e.g., TCP) can pay for themselves as developing your own ad hoc protocol can be tricky unless you truly understand the "ethernet rules" and what you can and can't expect from the network. (i.e., not waiting long enough for an acknowledgement and reissuing a command/message... then, having to decide if the acknowledgement that comes in corresponds to your *first* issued command or the followup, etc. -- should you "expect one more"?)
E.g., if you send a command "Close Garage Door", you probably want acknowledgement that the command was received. *And*, you probably want to know that/when the door actually closes! I.e., you wouldn't want to risk that message being "dropped" (and come home to find the garage door wide open -- all day!)
I would advise *only* putting the user interface in a PC. (this could also include any "remote interface"). Rely on the "devices" themselves to actually *implement* the system itself. My first version of my system was built on PCB prototypes for a client -- it had gobs of hammer drivers and DIO's so I could use it for a lot of different "field configurations". Unfortunately, only had serial ports so I had to use EIA485 for inter-board communication (and a dedicated serial link to a PC to download configuration data).
The other big downside was that it was still too centralized. It relied on too much "wiring" to connect the field sensors/actuators to the boards. And, the boards were large. This led to the current redesign where "smaller is better" :>
E.g., your "thermostat" should be capable of maintaining the correct indoor temperature even if the PC is "off". I.e., the PC is just a pretty/convenient mechanism for telling the thermostat *how* to operate, not actually *performing* that function itself!
Also, consider how distributed your system wants to be. I.e., can the thermostat query the "(personal) weather station" to determine outdoor conditions and react accordingly? Or, must it rely on some other agent to do that on its behalf? Or, is it completely ignorant of the weather station's presence and any interaction between them happens at a much higher level in the *application* (i.e., the PC dynamically reprograms the thermostat based on data that the PC retrieves from the weather station).
In my case, I wanted to keep a lot of the intelligence in the actual devices so that they could *inter*-operate as well as
*independently* operate. The size of your pipe governs, to a large extent, how much of this you can do!
Thanks a lot for all the responses. I have a lot more planning to do.
Some updates:
1) I am in India and the houses have wiring conduits and solid walls. I was planning to use the existing conduits for intercoms and cable tv which are present in all the rooms except the kitchen.
2) For me, CAT5/6 is not just the cost on the board but also the much higher cost of cabling and the need for a hub/switch. Broadcast is a useful feature and I am now looking mostly at basic control and status messages. May be if I were doing it on a larger scale, it would make sense.
Oh, and this is an apartment and there are no garage doors. In fact most houses in India does not have automatic gates or garage door openers. :-)
I will definitely look at the wireless options. ZigBee looks interesting. Any cheap (< $100) devices with free software stack? I am hoping I can get an adapter board with a Linux driver on the main node. May be, I can use a hybrid model with CAT5/6 in some rooms where it is easier to pull cable and ZigBee for the kitchen and the balconies...
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.