(This is part 2 of my home automation blog series. See the automation category for the whole set)

So, in part 1 I laid out the aims of the first part of this project - read that if you’re confused. In this part, I’ll detail how to get HestiaPi Classic and MQTT to play nicely together…

Installing MQTT

MQTT is just a standard - not a programming language in it’s own right. For that, we’ll need some implementations…

Firstly, we’ll need an MQTT broker - that’s the server all the clients will connect to. Happily, there’s a well tested and stable open-source MQTT broker called mosquitto. Let’s get it installed.

I chose to run this on my OpenHab server, since it was already installed, but you could easily run it on HestiaPi Classic itself. The defaults are fine for our use:

apt-get install mosquitto mosquitto-clients
systemctl start mosquitto && systemctl enable mosquitto    # for newer systems like Debian Jessie
/etc/init.d/mosquitto start                                # for older systems like HestiaPi Classic

We install mosquitto-clients just so that we can test the broker - you can uninstall it later. Once the broker is running (check in ps axf for it) you’ll be able to connect to it using mosquitto_pub and mosquitto_sub. Try this, using two shells:

# Shell 1
mosquitto_sub -h localhost -t 'test/hestia'
# Shell 2
mosquitto_pub -h localhost -t 'test/hestia' -m 'hi there'

You should see hi there printed in the mosquitto_sub shell. That’s all there is to MQTT, really, although you can look into configuring all sorts of extras like authentication, QoS, message persistence, and so on. The MQTT and Mosquitto websites are your friends, and maybe I’ll blog about it later on too.

Coding MQTT for HestiaPi Classic

OK, so we have a working broker, but we still need to get HestiaPi Classic talking to it. Enter some real programming.

As most of you probably know, I’m a Ruby guy, and it so happens there’s already a solid MQTT Rubygem which I can use. Coding with MQTT is pretty trivial, the examples on the gem’s homepage are great.

Over a couple of days, I worked out all the calls I needed to make to HestiaPi Classic to control it’s functions and query it’s status. Most of this is done over the web interface, but getting the local temperature requires using a shell script on the HestiaPi Classic itself, so the app has to be run on HestiaPi Classic itself.

Installing the MQTT app on HestiaPi Classic is easy enough. Let’s walk through it, starting with some dependencies.

apt-get install bundler git-core

Bundler is used to manage the Rubygems we need to run the app. Git is optional and used to clone the repo in the next step; you could download the tarball from GitLab instead if you prefer.

cd /opt
git clone https://gitlab.com/gwmngilfen/hestia_mqtt.git

Simple enough, switch to /opt and get the source code.

cd /opt/hestia_mqtt
bundle install --path vendor

This installs the required Rubygems into /opt/hestia_mqtt/vendor, where they won’t interfere with anything else.

vi config/settings.yaml

This step is important. The defaults here assume Mosquitto is running on the HestiaPi Classic and that you’ve not changed the default login credentials for the HestiaPi Classic web browser. You may also want to change the default MQTT topic, and the log location (I log to /var/log/hestia_mqtt.log for example).

Once updates, we can start the service:

cp extra/hestia_mqtt.init.d /etc/init.d/hestia_mqtt
/etc/init.d/hestia_mqtt start
update-rc.d hestia_mqtt enable

The Ruby app should now be running, as always you can check ps axf or /etc/init.d/hestia_mqtt status.

Testing the control

With hestia_mqtt running, it should already be outputting information. Grab your trusty mosquitto_sub and try connecting to the hestia channels.

mosquitto_sub -h localhost -t 'hestia/#' -v

Obviously replace localhost with wherever your broker is. The # is a wild card that subscribes to all channels under the hestia prefix - you’ll need to change hestia to match the prefix in the hestia_mqtt config file if you changed it.

With any luck, you’ll now be seeing output!

hestia/temp_c 19.437
hestia/status/temp_c 19.75
hestia/status/heat OFF
hestia/status/water ON
hestia/status/boost_heat OFF
hestia/status/boost_heat_time 0
hestia/status/boost_water OFF
hestia/status/boost_heat_water 0
hestia/status/setpoint 21.0
hestia/status/boost_water_time 0

Awesome! We’re now getting reports from HestiaPi Classic over MQTT of it’s current status. Let’s try controlling it - for this you’ll want to tail your hestia_mqtt.log to see the log of commands received.

mosquitto_pub -h openhab -t 'elysium/hestia/boost_heat' -m '30'
tail /var/log/hestia_mqtt.log

[2017-04-20 23:43:00] - Heating boost set to 30 [code: 200]

Perfect! In this case we sent 30 minutes to the boost_heat command channel. You can also send a number of minutes to boost_water, or a desired temperature to set_temp:

root@raspberrypi:~# mosquitto_pub -h openhab -t 'elysium/hestia/set_temp' -m '22'
root@raspberrypi:~# tail -n2 /var/log/hestia_mqtt.log
[2017-04-20 23:45:26] - Setpoint decreased to 22.0 [code: 200]
[2017-04-20 23:45:27] - Setpoint now 22.0

That’s it! The hestia_mqtt Ruby app will retry if it detects network errors connecting to the MQTT broker, so it should keep running smoothly. You’ve now got MQTT control and reporting for HestiaPi Classic! Contributions to the codebase are, of course welcome!

In the next blog post, I’ll detail how we integrate this into OpenHab….