Secure Home Automation Controls via a Telegram Bot

Connecting any web application server securely to the Internet can be a challenge. Doing so on a shoestring with low-cost open source hardware and software even more so, especially when you don’t have security experts to call upon.

One way to avoid these issues is to make use of a secure messaging service that supports “bots” and end-to-end encryption. That is what the following flows use.

As you will see, writing a decent bot, even with Node-RED helping, can also be a challenge, there’s a lot to think about in terms of the flow logic if you don’t want to leave your users stranded in the middle of a conversation with the bot.

This set of flows aims to illustrate a simple bot that will let you see the status of a set of wireless controlled lights or switches. It will also let you turn them on or off remotely.

Prerequisites 🔗︎

• An account on the Telegram messaging service.

• An API ID.

• Node-RED - I am using v0.18 with Node.js v8.9 - I developed this on Windows 10, any supported platform should be fine.

• An MQTT broker.

  The example uses MQTT to issue commands to MQTT. You will need to have existing logic to convert the MQTT messages into commands that control your hardware. I use an existing Node-RED based home automation setup with a mix of wireless switch devices.

• The following Node-RED nodes will also need to be installed:

  • node-red-contrib-telegrambot - A simple set of nodes to interact with the API. This is the heart of the “bot”.
  • node-red-contrib-rive - A Rivescript implementation. Rivescript allows a richer set of interactions with users without having to generate large amounts of complex code.

The MQTT Message Schema 🔗︎

I have a very simple schema for monitoring and issuing commands to my remote switches.

The topic structure is:

COMMAND/SWITCHnn

Where “nn” is the number assigned to the switch device.

The payload structure is even simpler. It is one of On or Off. Text case is not relevant.

A flow in Node-RED listens to changes on the topics and translates the device to a physical device output.

I use the retain flag on the messages so that, on startup of any service that is subscribed to COMMAND/#, that service will receive all of the current switch statuses.

These flows subscribe as above and maintain an in-memory copy of the statuses.

Switch Metadata 🔗︎

Since SWITCH01, etc. is not terribly friendly, I also maintain an in-memory set of data, keyed on the switch number. This is used to provide friendly names and location information as needed. An example set of data is included in the first of the two flows.

Flow 🔗︎

Import this flow to Node-RED.

Make sure that The ‘Save Switch Metadata’ is on the first tab of your flows so that it is executed early. Alternatively, add it to your settings.js file.