OpenHAB, MQTT, Arduino and ESP8266: Part 2 – Publish, Subscribe, Command, State, and WTFs

The following series of posts will document my journey to full Home Automation using the MQTT protocol, all custom hardware (Arduino and ESP8266 based), and all tied together using OpenHAB

  • Part 1:  Setting up the server / environment
  • Part 2:  Publish, Subscribe, Command, State, and WTFs
  • Part 3:  Hardware:  Arduino with Ethernet Shield
  • Part 4:  Hardware:  ESP8266 with NodeMCU firmware
  • Part 5:  Hardware:  Sensors
    • Part 5.1:  Graphing Sensor Data
  • Part 6:  OpenHAB Automation Rules

In this part, we will begin to build our own basic configuration (replacing the Demo configuration) but for now, left have a quick talk about MQTTs role in the OpenHAB event bus (or as items)

MQTT allows you to exchange messages, via a broker – by Publishing a message to a Broker.  All the clients that are Subscribed to the topic you are publishing to, will receive the message once published.

A topic can be for example

  • /home/openHAB/in/GarageDoor/state
  • /home/openHAB/out/GroundFloor_Office_Light/command

A message publish to these topics could be:

  • /home/openHAB/in/GarageDoor/state = OPEN
  • /home/openHAB/out/GroundFloor_Office_Light/command = OFF

And a subscription, could be to

  • /home/openHAB/in/GarageDoor/state (will receive OPEN from the broker when the published sends OPEN)
  • /home/#  – wait what’s this?  I can subscribe to an exact subtopic, OR I can subscribe to a list of topics (:  – very useful for a device with many functions (:

Now before you even begin configuring devices, I want to lay down some advice I learned along the way during this project:

  1. Decide on STANDARDS RIGHT NOW!!! Deciding on topic names should make a lot of sense as you will be typing them a lot (short is better) and tracking message flow through Mqtt-spy – you want it to be clear enough that you can immediately see what you are looking for
  2. Configure any device to send a confirmation “state” message after it switches or gets queried, this will just make sure your OpenHAB instance stays sane!  The worst thing is when you see a light as switched off in the OpenHAB interface only to be blinded by it still shining in your eyes… Initially I thought I was battling hardware configs, then I thought I had relays latching, then I thought I had a bad network…   Later on I realised that adding simple Status publishes from the device to ensure OpenHAB always knows its real state – is a LOT more important and robust

In my initial playing I followed the naming from the demo configuration  for example GF_Office_Lamp for example for a Ground Floor (level),  Office (room) Lamp (device)

As soon as I started designing hardware I realised this standard is going to become HELL!!!

Instead I decided to have a much simpler Numbering scheme and rather configure names in OpenHAB to avoid confusion

So for example instead of trying to address the desk lamp in my office as

/home/openHAB/out/GF_Office_Lamp/command=ON

I am rather going for

/home/1/ard1/p1/com=ON

  • /home/ is a wide topic set covering all the home automation messages.
  • /home/1/ signifies Room 1 (my office) – makes for a LOT less typing
  • /home/1/ard1 is a device in my Office – a Arduino with a ethernet shield
  • /home/1/ard1/p1 is Port 1 of this Arduino device.   Since the Arduino sketch can handle tens of relays – I can have P1-P14 (:
  • /home/1/ard1/p1/com = Command topic – for P1 I want both a Command and a State topic available:  Command being messages that CONTROL the device, and State being messages from the device, telling OpenHAB it’s status (ON or OFF?)

In my OpenHAB item file I can manage this device by defining it as:

Switch lamp1 "Office Lamp" (all) {mqtt=">[broker:/home/1/ard1/p1/com:command:on:ON],>[broker:/home/1/ard1/p1/com:command:off:OFF],<[broker:/home/1/ard1/p1/com/state:state:default"}

You may notice that for this device I expect it to have two Commands (ON or OFF) and one subscription to the State topic (to change the status of the “Switch” object)

lamp1

Depending on the device (for example in the Arduino sketch) you may want the message to be formatted differently.  In my example sketches later on you may notice my Arduino sketch expects 1 or 0 for on/off.  The ESP8266 sketch expects ON|OFF

You can specify this on the configuration line as well:

Switch lamp1 "Office Lamp" (all) {mqtt=">[broker:/home/1/ard1/p1/com:command:on:1],>[broker:/home/1/ard1/p1/com:command:off:0],<[broker:/home/1/ard1/p/com/state:state:default"}
Advertisements