Apr 30

Home Automation with Arduino MQTT

I've been working on a few networked projects with Arduino lately as well as looking into combining the various home automation hacks into a more cohesive system. MQTT has kept popping up on my radar for a while now and is perfect for building my centralised home automation system. Basically MQTT is a lightweigt publish/subscribe messaging protocol, every message has a topic and an optional payload.

I have had the Open Source Mosquitto MQTT Broker set up on our server for a while now. Added a basic Python script doing some logic and some Arduino clients using the Arduino MQTT library to send button presses and flash LEDs etc.

As a proof of concept it's working fantastically, but to go further I need some sort of defined schema for home automation using MQTT. I thought I would publish this in the hopes that someone else has thought about this before and has feedback/suggestions/criticism on it.

Below is what I've come up with so far - really just a brain dump. The left side of the = being the topic and the right side being the various payload options (separated by a forward slash or a range shown by a dash). 00:00:00:00:00:00 is an example MAC address of an input or output node. $PERSON represents a unique person id.

General environmental;

/home/all/time = sunrise/sunset
/home/all/alarm = security/fire/earthquake/flood

Some meta messages designed to be sent on startup of the node, notifying the server of start and the various inputs or outputs that are available.

/home/00:00:00:00:00:00/meta/start
/home/00:00:00:00:00:00/meta/output/0 = digital/fader
/home/00:00:00:00:00:00/meta/input/0 = button/motion/light

Some environmental data, temperature etc. The beginnings of prescence to facilitate actions on peoples movements;

/home/00:00:00:00:00:00/event/env/temperature = 18.2
/home/00:00:00:00:00:00/event/env/humidity = 50
/home/00:00:00:00:00:00/event/env/light = 0-100
/home/00:00:00:00:00:00/event/presence/$PERSON = enter/exit

And the guts of it, inputs and outputs, this is the part I'm struggling with the most currently - whether to breakout the events into buttons, motion, timers etc. or stick with just input/output;

/home/00:00:00:00:00:00/input/0 = press/hold/release/motion/no-motion
/home/00:00:00:00:00:00/input/0/feedback = ?
/home/00:00:00:00:00:00/output/0 = on/off/blink/fade=0-100/timer=10

The inputs/outpus may well be on different nodes, an Arduino lightswitch, an Arduino Mega or Beaglebone inside a switching box etc.

There's other things to consider, for starters; the input/output id (on the end of the topic) will need to be translated on the node.

If anyone has any suggestions on the general schema, language used, or anything I would welcome it. Please let me know, either in the comments below or by email.

13 responses to "Home Automation with Arduino MQTT"

  1. This was written quite late and after re-reading it it seems I've missed quite a bit of context.

    I've also discovered since posting on Twitter that there's a few other people doing the same thing; @marekkuziel and @SuperHouseTV - there's some info on the Freetronics forum here;

    http://forum.freetronics.com/viewforum.php?f=30

    and on the MQTT Google Group here;

    https://groups.google.com/forum/?fromgroups#!topic/mqtt/wk3MhXKYIZA

    About that context. My current thought iteration is very centralised, the nodes are dumb and don't contain any logic at all, instead just send and receive events leaving all the logic to a Python "logic server" script which subscribes to the entire topic tree on the MQTT broker.

    Whether this is the way I will end up going or not I'm not sure, there will possibly be a mixture of that and a little logic in the nodes for reliability/fall-back purposes.

    In the above brain dump, the nodes would just subscribe to;

    /home/all/#
    /home/$NODE_MAC_ADDRESS/output/+

    to cut down on the messages that they need to process. All the other messages/topics would be incoming to the logic server.

    hads
  2. Hello,

    I totally agree, MQTT really needs some schemas or profiles. I believe most current deployments of MQTT are closed propriety systems and don't need to interoperate between multiple vendors. The good news is that I believe that it is something that the Eclipse Paho project will be looking at it:
    http://www.eclipse.org/proposals/technology.paho/

    I am not sure about putting the MAC address into the topic name - makes it harder to swap devices in and out. Think it would be better to put some sort of alias in. What if you had multiple devices, that should all be turned on when the 'living room lights' scene 1 should be turned on? With your approach, would you have some sort of central event processor that maps incoming button push events to resulting outputs?

    I have been looking at mapping X10 to MQTT for a bridge but didn't get much further than:
    /x10/$house/$unit = 255

    Pretty important that it all interoperates!

    nick.
  3. Hi Nick,

    Thanks very much for the comment.

    I'll have to take a look at the Paho project, looks interesting.

    Yes the "central event processor" (or "logic controller" as I referred to) is key to the system I'm talking about above. The reason you missed the reference is that this ended up being more of a brain dump that I originally planned.

    All of the mapping from MAC address to location(s) in this particular system would be done in the logic processor which would hold a database of where to route actions from events.

    Cheers,

    hads
  4. Hi Hads,

    As per my tweet: good post & nice timing!

    Here's a few of my current thoughts:

    - I agree with Nick re using MAC address as ID of a device being not an ideal solution.
    - I like the architecture described at the MQTT Google Group thread. mount_points are nice way how to make sense out all of it.
    - Scenario I am thinking about is to have a central "brain" ie. Linux box that would be on top of the hierarchy (/home). Parts of the system (ie. Arduino based devices) would be then mount_pointed in eg. /home/room/1
    - In terms of profile/schema for MQTT. I think about it as a set of MQTT APIs defined by parts of the system separately eg. energy monitor, lights controller, heating controller,.. central box connects all the bits together and does control and/or serves web interface to allow user to control.

    I'll be posting my notes on the topic on my site. Happy to discuss further.

    Cheers,
    Marek
  5. Hi Marek,

    Thanks for your comment. I agree about the mount_points architecture, I think this is a good idea.

    Regarding the MAC addresses, I can see where you're coming from but, taking the Arduino for example, it makes deployment an issue.

    I would rather not have to code a unique identifier into each device when programming for deployment, what if I'm doing 50 or more of them?

    With the MAC address I can either randomly generate a MAC on first boot, or as Jon Oxer has done, use a DS18B20 and generate the MAC from the unique ID of that.

    Cheers,

    hads

  6. Hi Marek,

    By the way I have some initial (Python) code to bridge between MQTT and websockets on the server, this should make building a responsive web interface for tablets/computers/etc. pretty straight forward.

    I'll elaborate on that in a future post.

    hads

  7. Hi Hadley,

    A number of years ago the UK home automation group developed a protocol with similar aims to MQTT and were hoping that it would take the world by storm. The protocol was called xAP. Unfortunately (IMHO) it splintered and a similar but different variant called xPL was also developed. I actually use xAP at home.

    However reason for posting is not to encourage xAP but rather to state that they did put quite a bit of thought into schemas and developed both specific and a general (basic I think they called it) schema. Specification documents are available publically and might be worth a look to see if any of their thoughts could be a stimulus for your schemas, especially since theirs are based on a reasonable amount of real world usage, albeit in a smallish community.

    Cheers
    Shane
  8. Hi Shane,

    Thanks for the suggestion that's great, I'll have to hunt that down and have a look. Real world usage is certainly the best thing and what I'm lacking right now.

    Cheers,
    hads
  9. Hadley, I'm very interested in the scripts you have for a MQTT web interface if you are still keen to share.
    Andrew
  10. Hi Hadley,
    I've now got a couple of multiple input temperature sensor nodes and also a control node working via MQTT on the LAN.
    I've spent time in the last two weeks trying to get my head around websockets so as to allow for data visualisation and control via computer / televisions also on the LAN.
    My intent was to install this service onto the VM running mosquitto, so any fore thought or web search data you would be willing to share would be appreciated.

    Thanks again for providing the service you do.

    Andrew
  11. Hi Andrew,

    Check out timestore by Mike Stirling, http://www.mike-stirling.com/redmine/projects/timestore

    I've been testing this out myself for storing sensor data.

    Cheers,

    hads
  12. Don't know if this topic is still active, but if it is, I think you guys should take a look a this project: https://github.com/binarybucks/homA

    It's a set of tools written in nodejs that talks to a MQTT broker (mosquitto).

    It defines a "schema" that devices can use and it already has a web and android UI that subscribes to the MQTT schema and shows all the device information. It's really very cool! :]
  13. Thanks very much. It's certainly still active for me.

Leave a comment