# Summary

This blog post provides some insights on how I managed to bridge over support for MQTT & HTTP to some cheap discount-store remote switches for my repos:

- https://github.com/thibmaek/homewizard-smartwares-api-proxy-rest
- https://github.com/thibmaek/homewizard-smartwares-api-proxy-mqtt

## The initial idea

Being very passionate about home automation and always on the lookout for new stuff to connect to the web, my eye quickly fell on these really [cheap remote controlled switches](https://www.action.com/nl-be/search/?q=flamingo) available from Dutch/Belgian discount store Action. After some quick researching on the web I found out these so-called 'Homewizard' switches should [be able to work with Homebridge (HomeKit node.js bridge/proxy)](https://github.com/rthewhite/homebridge-homewizard).

It seemed however that this specific type of switch used a derivative of the standard Homewizard app (called Homewizard Lite) and could not be used with this repository. I now had €25 worth of regular RF switches and while I was satisfied with that for a while, I decided to give it another try and see what I could come up with myself.

## Decoding Homewizard Lite

Let's dive into how the mobile app interacts with the switches so that they toggle state. Getting the correct request was easy enough: just monitor the network traffic with my iPhone as a target. Homewizard Lite communicates with a REST endpoint in the cloud at `https://plug.homewizard.com/…` where it sends some data to which in turn toggles the switch. As any good network request should, this call communicated over SSL with the endpoint but that made the work for me a little harder. Initially, I thought that I'd be blocked and had to abandon my idea since I could not decrypt SSL traffic in my monitor and thus would not see the correct request data. After some research on the web, I found out about [mitmproxy](https://mitmproxy.org/).

Mitmproxy allowed me to use a man-in-the-middle flow so I could decrypt SSL traffic after installing a self-signed certificate generated by mitmproxy on my iPhone. After this I found out that Homewizard Lite communicated in the following way to list the user's plugs & set a plug's state:

```console
GET https://plug.homewizard.com/plugs # Lists all plugs
POST https://plug.homewizard.com/plugs/<id>/devices/<deviceId>/action --data {"action": "On"}
```

To authenticate with the endpoint a token was sent along in the request headers as `X-SESSION-TOKEN`. This one was a bit more difficult to figure out though. I could just copy over the value from the headers I grabbed in mitmproxy but the token's value changed over time (every few minutes). The token also seemed to go out to a different endpoint (`https://cloud.homewizard.com/account/login`) to get the value, since in the mobile app you authenticate with an email & password combination.

Using an HTTP Basic Authentication method I tried sending my credentials to that endpoint. I was almost there but the request wasn't resolving. The final piece of the puzzle fell when I found out I needed to hash my password with SHA1 before creating the Basic Authentication auth header and sending it to the token endpoint. Now I finally got back the token I needed to authenticate requests to my plugs without using the mobile app.

## A simple REST microservice
With all the logic sorted out and a desk full of notes I quickly created a node express server which would act as a reverse proxy with friendlier endpoints and conventions to reflect changes to Homewizard plugs:

```console
GET localhost:3000/token                    # Returns a new token to use as the session header
GET localhost:3000/plugs                    # Lists all plugs (internet connected ones)
GET localhost:3000/plugs/<id>               # Lists all details about a plug
GET localhost:3000/plugs/<id>/location      # Lists the lat-long location of a plug
GET localhost:3000/plugs/<id>/isAvailable   # Outputs whether the plug is connected to the internet or not
GET localhost:3000/plugs/<id>/devices       # Lists all subdevices (RF switches) associated with the main device
POST localhost:3000/state/<id> --data {"deviceId": "5fah3…", "action": "on"}
```

Using a small piece of middleware, each request would first request a new token from `/token` and then merge it into the request headers so that using it, you wouldn't have to explicitly call the token endpoint before setting state or retrieving the plug list:

```js
const getToken = require(`../routes/token`);

module.exports = async (req, res, next) => {
  const {token} = await getToken();
  req.headers[`x-session-token`] = token;
  next();
};
```

Using nodemon this ran amazing locally and I later decided this was an ideal use-case to deploy as a microservice in the cloud using [Now](http://now.sh/). Because exposing your home to a cloud microservice might be tricky, a production build of the microservice will always require you to send along an `X-PROXY-API-TOKEN` in requests to the microservice.

This proxy API was now ready to [put up on Github](https://github.com/thibmaek/homewizard-smartwares-api-proxy-rest) and use in any project (Home Assistant, aRest, Arduino, ESP8266, etc.) that allowed for REST actions. One of the simplest things would be to connect this to an Amazon Dash button for example.

## An even simpler MQTT proxy

Since free microservices sleep very often after inactivity I had to look for something else in my own case and found that MQTT is tailored for home automation. I had never used MQTT before but it seemed fairly easy to do, being familiar with Websockets et al. I was stunned about the simplicity of MQTT using the `mqtt` module from npm. In about an hour I had replicated all the behavior and functionality from my proxy API to [an MQTT proxy](https://github.com/thibmaek/homewizard-smartwares-api-proxy-mqtt) which just listened to the following topic:

```console
mosquitto_pub -h localhost -t homewizard/switch/id/+/deviceId/+/setState -m on
```

## Integration into Home Assistant

Home Assistant makes MQTT ridiculously easy. They provide an add-on called `mosquitto-broker` in Hass.io which acts as the broker on your network to publish/subscribe to MQTT topics:

```console
mosquitto_pub -h hassio.local -t homewizard/switch/id/5fah3…/deviceId/dh36kd1…/setState -m on
```

Wiring up depends on the kind of equipment you have connected to the switches but there are components for `light.mqtt`, `switch.mqtt`, `sensor.mqtt`, etc. Three lines of configuration would allow me to toggle the string lights in my bedroom from Home Assistant:

```yaml
- platform: mqtt
  name: 'Bedroom Stringlight'
  command_topic: 'homewizard/switch/id/5fah3…/deviceId/dh36kd1…/setState' # the proxy takes care of On|on|ON as action, so no need to set the message explicitly!
```

## Going container-crazy

As a major downside, all this had to run locally which is not cool if you don't have an always-on laptop or computer to run the application as a cron or systemd unit. Creating a systemd unit for it on a spare Raspberry Pi is a possible solution, but instead, I chose (since the nature of the app allowed for it) to quickly create a Docker container, tailored to my Raspberry Pi's armhf architecture, and deploy that container with [resinOS](resinos.io). Below is the very, very simple Dockerfile which will let you deploy the mqtt application in minutes:

```docker
FROM resin/raspberrypi3-alpine-node:slim

ENV API_URL=https://plug.homewizard.com/plugs
ENV BROKER=192.168.x.x
ENV HOMEWIZARD_PASS=
ENV HOMEWIZARD_USER=

WORKDIR /usr/src/homewizard-smartwares-api-proxy-mqtt
COPY . .

RUN npm install

CMD [ "npm", "run", "dev" ]
```

### Conclusion

This project for me was a very challenging project but oh-so-much fun! I think this is one of the projects where I probably learned one of the most and got triggered by new, useful stuff like resinOS, MQTT & mitmproxy.

And of course, I ended up with a really cheap and cool personal solution to having 'smart lighting' for nearly every light in my room. Building up from here shouldn't even be too hard since I could snag a set of 3 plugs for €9.95 and connect them to my hub.

If you've read all the way through, thanks for that and I hope you learned something or are as eager as I was to deploy this at your home! 👋🏻

> Questions? Remarks? Feel free to get me in a loop on Twitter @thibmaek or contact me via email.

My experiment to creating a developer-friendly cheap smart lighting API

🔌 Bringing MQTT & HTTP to cheap budget-store remote switches

View at [https://thibmaek.com/posts/overview/1]

3 meters (electricity, heating & water) created via EnergieID's webhook integration.

EnergieID webhooks

3 Home Assistant RESTful Command services which we can call to update our meters

EnergieID rest commands HA

Creating an input helper for the electricity meter with a unit of kWh

ha energieid helpers

A new "Run" script with a sequence to update all meters by sending the state from the inputs to the restful commands / webhook we created earlier

ha energie id script

A Lovelace (UI) card with our inputs and the button so submit them to EnergieID

ha lovelace energieid

Simple first steps toward integrating EnergieID into Home Assistant.

🔋 Consumption monitoring with EnergieID & Home Assistant

A collection of utility types I always include into my project to ease working with type data.

Typescript utilities I always include

The list of Tasks VS Code can execute from your tasks.json configuration

VS Code RN Tasks

Some tasks for VS Code which will make working with React Native daily a breeze!

Thibault Maekelbergh

Engineering Lead at In The Pocket at dawn & tech nerd extraordinaire at dusk 🦉

I can't stop learning new stuff

Latest articles

🔌 Bringing MQTT & HTTP to cheap budget-store remote switches

🔋 Consumption monitoring with EnergieID & Home Assistant

Typescript utilities I always include

Using VS Code tasks for React Native development

New repositories

Top categories