2
\$\begingroup\$

I am half-way through building my home automation system. As an electronic engineer/software developer a lot of this has been rolled myself from scratch and I will hopefully be starting to blog more and build up/publish my story and workings once complete.

I am now at the point of lighting automation. I have approximately 30 wall switches running a prototype touch sensor faceplate and I need to now connect these back to my Win7 Embedded automation computer. I also need to connect about 30-40 dimmers and relays.

As far as I can see I have a couple of options for protocols both at physical/application level and really am looking for any comments or advice on the below options, plus if anyone has any other suggestions.

Right now, all controllers are running off ARM M3 processors and I have both Ethernet and CANopen stacks available. The system needs to be "multi master" and ideally support both event driven (e.g. someone presses a button) and process driven (querying a sensor every 30 seconds, or asking a specific node a question).

CANopen

  • Multi-master and automatic error correction/collision avoidance
  • Process, service and event options for messages
  • Can be complicated to "virtually wire" up device. Lots of configuration potentially required
  • Cheap to implement in hardware, relatively scalable. Limit of 127 devices on a bus. Daisy-chain network.

Ethernet

  • Multicast UDP, or broadcast? Not sure which is more appropriate
  • Probably have to roll my own messaging protocol or API on-top to handle all the types of events I require, not sure about event driven actions
  • Star network, BUT could support PoE which is nice
  • More expensive in hardware
  • Much more expandable in software (potentially infinite number of devices, etc).

Has anyone got any comments or thoughts on which may be the best route to proceed? I have a feeling Ethernet may be the way but worry there is far more implementation required in software.

Thanks

\$\endgroup\$
9
  • 1
    \$\begingroup\$ I don't think CAN makes sense, purely based on the distances involved in a house. I like using CAN but think about the network topology, need for termination, etc, vs running Cat6 drops everywhere from a patch panel where you'll have a large amount of flexibility. \$\endgroup\$
    – Krunal Desai
    Commented Dec 26, 2015 at 23:42
  • 4
    \$\begingroup\$ Ethernet. CAN is a solution to a different problem which you don't have: high reliability and real time. [In response to @Krunal . House-sized distances are not too long for CAN. Creating a CAN bus the size of a bus is possible.] \$\endgroup\$
    – Nick Alexeev
    Commented Dec 26, 2015 at 23:53
  • 1
    \$\begingroup\$ Ah yes, I'm aware that's it's theoretically possible to do CAN busses of that size, it's just that after designing several for actual trucks and busses, I don't think it's the easiest / most practical design for a home when Ethernet is available (considering the reduction in performance and other issues that arise with longer busses). But yes, I doubt home lighting is safety-critical / requires determinism, unless SeBen is Tony Stark. \$\endgroup\$
    – Krunal Desai
    Commented Dec 26, 2015 at 23:57
  • \$\begingroup\$ Note that you are mixing two things here: Ethernet, and UDP. You can run pretty much anything over Ethernet, including raw frames if you are so inclined (but I probably wouldn't be). UDP is probably handy because it gives you a lot of functionality for free, but there's absolutely no ready you have to use one just because you use the other. \$\endgroup\$
    – user
    Commented Dec 27, 2015 at 0:09
  • 2
    \$\begingroup\$ Another benefit to ethernet is that the hardware is much more commonly available for the backend. Off the shelf can save a lot of time. If you're just doing it as an at home project you could even use an ethernet to serial adapter from a company like wiznet and then use simpler controllers to simplify the design. \$\endgroup\$
    – alphasierra
    Commented Dec 27, 2015 at 0:10

2 Answers 2

Reset to default
2
\$\begingroup\$

Although you could use Ethernet and implement a TCP/IP Stack on each controller, and surely use UDP to broadcast sensor readings/commands/etc. I would recommend the use of CAN for the following factors:

  1. Easier to Implement/Code
  2. Very, very lightweight. You can integrate with smaller controllers. A MCP2515 can be used if the MCU doesn't have CAN.
  3. You could use CAT5/CAT6 and use the spare wires and carry 24V or 36V to power the nodes.
  4. The small message frame can be easily fitted inside a sub-1Ghz RF frame if you decide to extend the Bus over RF. You just need to code a CAN to RF gateway, maybe using el-cheapo RFM69 modules.

There's a blog that explore the use of CAN bus for similar use, might worth checking it out: talk2.wisen.com.au

Anyway, if you decide go with Ethernet, UDP would be better so you don't need to worry much with node addressing.

All the best!

\$\endgroup\$
-5
\$\begingroup\$

CAN is much simpler because is a revisited RS232 / RS485 but limited in number and functions. Wiring is standard serial and is much simpler than LAN. LAN and Wifi are surely much better because more functions are available, obviously prices are higher. Wifi could have the advantage of not requiring other cables than the power ones. Many cheap interface like Velleman ones are connected with RS485 or CAN but WIFI and LAN are way better if you like to develop your controlled devices.

\$\endgroup\$
0

Not the answer you're looking for? Browse other questions tagged or ask your own question.