(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…
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:
1 2 3
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
this, using two shells:
1 2 3 4
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.
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.
Simple enough, switch to
/opt and get the source code.
This installs the required Rubygems into /opt/hestia_mqtt/vendor, where they won’t interfere with anything else.
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:
1 2 3
The Ruby app should now be running, as always you can check
ps axf or
Testing the control
hestia_mqtt running, it should already be outputting information. Grab
mosquitto_sub and try connecting to the
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!
1 2 3 4 5 6 7 8 9 10
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.
1 2 3 4
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
1 2 3 4
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….