New Arduino based home automation concept (Due+Micro)

Projects General Guidance
1

Hi there!

I am new to the Arduino platform, but I am an experienced professional software engineer with basic skills in electronics and microcontrollers. I am currently planning a new approach to home automation (I think) for my house. I have conventional cabling in my house plus ethernet (Cat 5e) cable running from wall outlet to wall outlet. So, there is no dedicated place for a single home automation central, and i need a decentralized concept. I built the house 10 years ago and I did all electrical installations myself.

My first thought was a network of Arduino Micros, connected by 1-Wire or I2C busses. On second thought, I preferred a CanBus network, which is much more capable and much more robust. To support it on the Arduino platform, I would either need a CanBus shield or an Arduino Due with only transceivers. The CanBus library is currently under development. But those Dues are way to large for outlet sockets.

So I developed a third, mixed strategy: Every room gets a large „head“ controller and small headless peripherals. The head will be an Arduino Due with Touch-LCD (or a cheap Android device), while the peripherals can be Micros or just external Buttons. The controllers will be networked with each other using CanBus. Each controller has one or more peripherals, connected using I2C.

I will make larger holes into the walls for the controllers, which I expect to have a „connection shield“ (CanBus, I2C, Buttons) and the TFT shield with the TFT on top (3.2“ TFT by SaintSmart). But the peripherals should go into standard outlet sockets. I will design a printed circuit board with two buttons, a status LED and a photo resistor on top, and a socket for the Arduino Micro plus connectors for I2C, buttons and relay boards below. This PCB will cover one outlet socket. The bus cable will contain CanBus, I2C and power supplies. The connecter will be an RJ-45. Maybe every controller should have its own power supply to avoid introducing a single point of failure?

I have played with a Micro and a starter kit and I got pretty far just within 2 hours, so I am pretty optimistic I can write all the software I need. I will try to use just one software for all modules with #ifdefs for the additional Due parts (CanBus, IR-Remote, TFT). This way I won’t have to mess with different software variants.

The hardware variants for controlling lights, window blinds or external buttons will all share the same PCB, just configured differently. All lights we be dimmable using the famous Velleman K8064 dimmer kit, the window blinds will be controlled by the very fine SaintSmart relay boards (mostly the SSR ones), so I can exchange them later on.

Mechanical problems will be solved using custom 3D-prints: Boxes and casings for the different modules as well as a switch mechanic pressing the buttons and using the original switch covers of my existing installation. Since all of these 3D-printed parts are invisible, a cheap printer will do, so I might get one myself. The only visible part would be the frames around the TFTs. I consider this not important.

Finally, a central home server will be added to bring it all into my intranet. This will be a RaspberryPi, a BeagleBoneBlack or the Arduino Tre (once that becomes available). It will run headless in the „engine room“ and it will need CanBus connectivity, as well.

I just ordered a Due with TFT and TFT shield to get familiar with it, to experiment with TFT programming and I2C communication over several meters to my Micro. Once this works, I will order a couple more. and try to get that running, as well. Then I will design, order and assemble the PCB. If this also works I will construct and print the 3D-Parts. And after that everything will be ready to install. I probably will iterate theses steps room- or floorwise.

BoM:

  • Basement: 2 controllers, 2 light peripherals, 4 external buttons
  • Ground floor: 1-4 controllers, 6 window blinds peripherals, 4 light peripherals, 8 external buttons
  • 1st floor: 4 controllers, 5 window blinds peripherals, 2 light peripherals, 5 external buttons
  • 1 home server

This means

  • 36 identical boards (custom PCB), each with 2 buttons, pressed by a 3D-printed mechanic
  • 10 Arduino Due with LCD and probably another custom PCB (connection shield)
  • 19 Arduino Micro

So, what do you guys say, is this realistic? Is there a chance it will finally work? Or are there major flaws in my big plan? Because to me this all seems almost too easy! 8)

Best regards,
KussBus

2

Very large project! I have no idea about CAN bus. If you have Ethernet in every room, can you use Ethernet shield or module with arduino micro and some cheap "power over etherent" connector from sparkfun for power? This way you have TCP protocol and the physical location of master/slave or what not is not important anymore. You can even get a wifi gateway and several wireless units and just hang them on the wall, no holes :slight_smile:

3

KussBus instead of CANBUS you can use MODBUS too, and you save money because no shield is needed, you just need the MAX485 for each device, and it is robust too. There is a MODBUS library for Arduino.

4

liudr:
Very large project! I have no idea about CAN bus. If you have Ethernet in every room, can you use Ethernet shield or module with arduino micro and some cheap "power over etherent" connector from sparkfun for power? This way you have TCP protocol and the physical location of master/slave or what not is not important anymore. You can even get a wifi gateway and several wireless units and just hang them on the wall, no holes :slight_smile:

Hi liudr,

no, I don't have Ethernet in every room. E.g. there is none in the bathing room. In fact, Ethernet was my first thought, but I have the wrong sort of cabling for that. Also, the Ethernet ports are nowhere near the bus cabling. And there is no way for shields to fit into the switch sockets.

5

mart256:
KussBus instead of CANBUS you can use MODBUS too, and you save money because no shield is needed, you just need the MAX485 for each device, and it is robust too. There is a MODBUS library for Arduino.

Yes, MODBUS would be another option, that's right. But a shield would be needed anyway just for the MAX485 and RJ-45 sockets. The Due has 2 CanBus Ports onboard, so the shield would just contain one or two cheap transceivers (around .50-1.50 $ or €).

But, I think you suggested to not make any difference between "controllers" and "peripherals", but to hook all of them to the same MODBUS? That's tempting...

I will definitely have a look at MODBUS, thank you!

6

Using official Arduinos and separate shields and relay boards etc is going to ramp up the cost but more importantly the physical size. I suggest you look at using much smaller and cheaper clones, which will be easier to package. For example, for driving blinds you could look at the Pololu Baby Orangutan which has an integral dual b-bridge driver capable of handling an amp, which is enough to get substantial torque from a geared micro motor.

7

PeterH:
Using official Arduinos and separate shields and relay boards etc is going to ramp up the cost but more importantly the physical size. I suggest you look at using much smaller and cheaper clones, which will be easier to package. For example, for driving blinds you could look at the Pololu Baby Orangutan which has an integral dual b-bridge driver capable of handling an amp, which is enough to get substantial torque from a geared micro motor.

The motors are 230V AC motors, and I will definitely need relays to drive them. I might get them on the bottom side of the PCB, but I prefer having the high voltage on a seperate board. Apart from that, the Micro is very small, as well and just as cheap as the Baby Orangutan. The Due I ordered is a SaintsSmall clone which comes bundled with the TFT and the TFT shield.

8

I agree that mains voltages should be kept completely isolated from low voltage electronics, and to control a mains voltage AC motor you need a relay or triac, not the sort of h-bridge driver I suggested.

9

I've read the Modbus specifications and found a few things I don't like. First of all, it's a master/client architecture, where clients never initiate communication. Which means masters must poll all clients all the time. There is a multi-master concept, too, but this is just for a few masters.

The information transported is very limited and old-fashioned. While I could arrange myself with it, I don't like it.

What I have in mind is a message broadcast concept. If e.g. a button is pressed, its controller looks up its rules table and broadcasts a message including to itself. All controllers receiving this message look up their rules and react accordingly. All controllers are treated equally. Collision detection and handling is needed. The CanBus telegrams model this concept in a better way.

Or I might even use hierarchical I2C busses. I am expecting very little communication (a message once in a while), so CanBus may be too much overhead (the APIs currently are really big). I2C bus ranges may be extended by lowering the bit rate and by using driver ICs. I will experiment a little, once I have a couple of controllers.

A unique ID, some group IDs, the rules table and some settings (like dimming values) will have to be stored in the EEPROM. Which may become a problem, since you can't be too clever in 1k. I am dreaming about broadcasting a global rules table over the bus. Every controller parses it and filters the rules. Only those matching one of its IDs get stored in the local EEPROM.