Teardown: Broadlink RM Mini 3

You might have read already, that I don’t like the Broadlink products as they do not offer any open APIs. But maybe, they are at least hackable?

Let’s check the RM Mini 3 Infrared sender/receiver.

Taking of the cap shows us the infrared LEDs and a single IR receiver:


This is what I would have expected. Are there any surprises on the main board?


Not really. The main processor is an Marvel 88MC200. This is a simple Cortex M3 based micro-controller that is clocked at 200 MHz. There is no need for a more powerful processor in this device. As it doesn’t have a WiFi controller integrated, there is a second controller on the board: the 88W8801 is a Marvel WiFi chip.

While in theory it might be possible to upload a different software onto the system, it will be quite complicated. You don’t want to fiddle around multiple days to re-use a 20$ device? The easiest way to re-use it is removing the whole controller, replace it with an ESP8266 and put your own firmware onto it. However, for this you don’t need to buy this device first. You can just directly connect some IR LEDs to an ESP8266 chip. This will be cheaper than the RM Mini 3.

Broadlink products – no APIs and other surprises

If you surf on Chinese shopping web sites you might have seen devices from Broadlink like the A1. They are quite cheap and seem to be powerful. However, have a second look before buying.

First of all, some sellers claim that the A1 has a PM2.5 particle sensor “coming soon”. Looks like this isn’t implemented yet in this software – right? Wrong! The device doesn’t have the necessary hardware included. There might be an add-on module coming in the future, but it will be a hardware-add-on, not just a software upgrade.

a1Another thing that Broadlink doesn’t publicly communicate is the fact that there are no open interfaces available. It seems that there is an SDK for the device, but Broadlink only allows to use it under NDA and it is only available as library for IOS and Android. That makes it hard to impossible to use this hardware as a part of a larger integration.

Therefore I can’t recommend any of the Broadlink products as long as Broadlink doesn’t offer any documented APIs.

5 Ways to start Home Automation for under $50

Home Automation is getting more and more simple with each day. Using WiFi, almost everything in your house can become ‘smart’. For under $50 you can begin to monitor and control your house, from anywhere, without breaking the bank.

Hook-Budget-Home-Automation-SystemHook: The Hook home hub finds its origins in DIY Home Automation. With successful crowdfunding, Hook is a low-cost Automation system that can control up to 15 devices remotely; in partnership with IOS, Android, Amazon Alexa, and the IFTTT web server. With Radio Frequency compatibility, Hook can convert any cheap RF socket to a smart socket. The Hook hub ships this month for just $49.95.

tplinkTP Link: This smart outlet is an affordable Home Automation device that can give your house a lived-in look to deter burglars with its ‘away mode’ protocols, turn your devices on and off from afar, and control your appliances. Compatible with Android, iOS and Amazon Alexa, the outlet also integrates energy monitoring, and can be controlled through their free Kasa app. A low-cost beginning that save you money and monitors your home, the TP Link comes with a 2-year warranty and 24/7 customer support to guide you through the transition of smart-proofing your home. The TP Link can be purchased for $40.72, with cheaper options starting at $29.95.

huePhilips Hue lighting:  Starting at $29.99, your investment need not go beyond a lightbulb. The Philips hue lighting products offer lighting protocols that adjust to your time of day; creating a natural light that can also be customized for specific moods and settings. With daily routines and quick-control features, you can flick the switch; dimming or turning off your lighting, from your smart light-switch on your phone. With the addition of an optimized, open source Home Automation system such as Hobson, this investment can be the first piece of your Home Automation framework, and control your in-home lighting remotely, for ‘lived-in’ protection in your house. Philips Hue also offers a free app tailored specifically towards this product.

insteonforscamInsteon Remote Control Plug-In On/Off Module: This small hub can control lamps and other small appliances. The perfect introduction to Home Automation, Insteon is compatible with smartphones for remote accessibility. Starting at $49.99, the Insteon can also be connected to a larger hub, for when you need to expand upon your Home Automation.

Foscam Camera: Using Home Automation, you can check on your house remotely with this IP camera. With its own remote viewing and recording system, this device can easily be linked into any open source software, as part of your User Interface; growing with multiple devices. Pricing for Foscam IP cameras start at $39.99

Home Automation has become a vast and diverse landscape of options. Expanding outside of WiFi’s limitations, Investment in Home Automation seeks to revitalize your household with Infrared, Bluetooth and Z-wave compatibility.

Hacking the H801 LED dimmer

I just received the H801 LED dimmer. I couldn’t figure out, what the “W1” and “W2” connectors on this device were. So I removed the case and checked the board. I was pleasantly surprise to see that this isn’t a 3 channel (RGB) but a 5 channel device. The W1 and W2 connectors are 2 additional channels.

Installation isn’t complicated. You connect the power supply and the LEDs and turn on the device.

With a laptop or mobile device, you connect to the WiFi network HCX_856705 (the numbers might be different) and use the password “88888888”.  Now, the trouble begins if you don’t have an Android phone. I was expecting there is at least a simple web interface available that allows to configure WLAN credentials. Nope! The only way to control the device with the initial firmware is an Android app.

You now have 2 options if you don’t own an Android phone: flash another firmware or install an Android emulator on your PC. It used Droid4X. However, I wasn’t able to connect to the device. I’m note sure if this Application supports using the WLAN connection from the Mac.

Ok, back to the start. Flash another firmware. This is usually something that I don’t do easily, but on a device that costs less than 20$ and isn’t useable for me otherwise, I tried this. Luckily the board design makes it easy to flash a new firmware. The board is already prepared with 2 headers: RX/TX/GND/3.3V and J3. Just solder headers and use your existing ESP8266 programmer.


As software I used the Arduino sketch from Eryk.io and adapted it slightly. My sketch can be downloaded from Github.

The GPIOs are used as follows:

Pin Function
15 Output red
13 Output green
12 Output blue
14 Output white 1
4 Output white 2
1 Internal LED green / Signal
5 Internal LED red / Power

Battery powered ESP8266 sensor

The ESP8266 is a powerful and inexpensive device. There is almost no need anymore to use proprietary RF protocols like the nRF24 chip that was popular some years ago. However, there is one major problem when using WLAN: power consumption.

When connected to a WLAN, the ESP8266 consumes at least 80mA – sometimes even more. If you use 3 2400mAh that means, they will be empty in a bit more than a day. This doesn’t sound like a good deal.

Luckily, for sensor applications, you don’t have to be connected to the LAN the whole time. You don’t even have to have the ESP itself running. To save as much power as possible, you have to do the following:

  1. Collect your data. If this takes time, do it before connecting to WLAN. If it takes just a few millesconds, it doesn’t matter much.
  2. Connect to WLAN.
  3. Send data.
  4. Go to deep sleep mode. You use the ESP.deepSleep() method for this.

You have to look at a few things when using the ESP.deepSleep() method:

  1. To wake up after sleeping, GPIO16 of the ESP8266 has to be connected to RESET. Otherwise the device won’t wake up again.
  2. The delay parameter is defined in microseconds (not seconds or milliseconds). If it looks like your device isn’t sleeping at all, you might have used a value that is too small (you won’t even notice if the device sleeps for 3600 microseconds)
  3. There is a second parameter that can have the values WAKE_RF_DEFAULT, WAKE_RFCAL,WAKE_NO_RFCAL, WAKE_RF_DISABLED. The WAKE_RF_DISABLED looks good, but beware to use it. Using this does not mean that the RF subsystem is disabled during sleep (it always is), but that it is disabled when waking up again. Your ESP8266 won’t be able to do any network communication anymore.

A few other tips to save energy:

  1. Do not turn on LEDs for a longer time. Flashing them a few milliseconds is usually a good visual feedback and will consume only a tiny bit of energy.
  2. If you need to have LEDs on for a longer time, dimm them. analogWrite is your friend for this.

Check out this sample code. It uses WiFiManager which helps to connect to configure your WLAN SSID/password and even the name/IP address of the MQTT broker.

#include         // Generic ESP8266 WiFi routines
#include        // MQTT client
#include           // Local DNS Server used for redirecting all requests to the configuration portal
#include    // Local WebServer used to serve the configuration portal
#include         // WiFi Configuration Magic

const char* mqtt_server = "";
const char* mqtt_channel_up = "active";
const char* mqtt_channel_data = "sensor/%d/adc";

const int pin_red = 15;
const int pin_green = 12;
const int pin_blue = 13;
const int pin_button = 4;
const int analog_ldr = 0;

const int sleepSeconds = 60 * 15;

WiFiManager wifiManager;
WiFiClient espClient;
PubSubClient client(espClient);

void send_sensor_data(void) {
  Serial.println("Sending sensor data\n");
  int data = analogRead(A0);
  char s_channel[50];
  char s_id[10];
  char s_data[10];
  sprintf(s_channel, mqtt_channel_data, ESP.getChipId());
  sprintf(s_id, "%d", ESP.getChipId());
  sprintf(s_data, "%d", data);

  digitalWrite(pin_blue, HIGH);
  digitalWrite(pin_blue, LOW);
  if (! client.connected()) {
    Serial.println("Could not connect to MQTT broker, doing nothing");
  } else {
    digitalWrite(pin_green, HIGH);
    client.publish(mqtt_channel_up, s_id); // show that this device is up
    client.publish(s_channel, s_data); // send sensor data
    digitalWrite(pin_green, LOW);

void setup() {
  delay(500); // This makes it easier to upload new firmware and/or press the "clean" button

  pinMode(pin_red, OUTPUT);
  pinMode(pin_green, OUTPUT);
  pinMode(pin_blue, OUTPUT);

  digitalWrite(pin_red, HIGH);

  // Setup Serial interface for debugging

  //  Bring up WLAN
  WiFiManager wifiManager;

  //sets timeout until configuration portal gets turned off
  //useful to make it all retry or go to sleep
  //in seconds

  WiFiManagerParameter custom_mqtt_server("server", "mqtt server", mqtt_server, 40);

  if (digitalRead(pin_button) == 0) {
    // reset settings

  //fetches ssid and pass and tries to connect
  //if it does not connect it starts an access point with the specified name
  //here  "AutoConnectAP"
  //and goes into a blocking loop awaiting configuration
  if (!wifiManager.autoConnect()) {
    Serial.println("failed to connect and hit timeout");
    // do nothing: deep sleep, but longer than usual. Something might be wrong and
    // we should save power
    ESP.deepSleep(sleepSeconds * 10 * 1000000, WAKE_RF_DISABLED);

  mqtt_server = custom_mqtt_server.getValue();

  Serial.println("WiFi connected");
  Serial.println("IP address: ");

  // Setup MQTT client
  client.setServer(mqtt_server, 1883);

  digitalWrite(pin_red, LOW);

void loop(void) {
  Serial.printf("Sleeping deep for %i seconds...", sleepSeconds);
  ESP.deepSleep(sleepSeconds * 1000000);

How secure is KNX?

Looking at modern home automation communication technologies (like Z-Wave or Zigbee), it seems that most of them have some security issues. These may or may not been fixed in the future. If these modern architectures already show a lot of problems, what about KNX? Let’s make it quick: from an computer security point of view, KNX is not just insecure, but the worst kind of protocol. All devices communicate on a shared medium, there is no encryption, no authentication, no authorisation. If you have access to the KNX bus, you can do everything.

Luckily, there is one good thing about KNX: You need access to the bus. If somebody has physical access to your bus, he can do crazy things. But this means, this person is already in your flat. Even without home automation, a person that has physical access to a light switch can turn it on and off. This means that for a residential installation, cabled KNX installations are perfectly fine, if they are running standalone. However, modern installations aren’t standalone. Nobody wants to install an home automation system anymore that is not somehow connected to a network.

Here are some tips how to make sure this system is still secure.

  1. Don’t simply connect your KNX network to your home LAN (that might be even allow guest WLAN access).
    KNX/IP interfaces are cool products and you will need one. However, be clear that these do not have any security built in. That means everybody that has access to your network can do everything on your home automation installation. This might not be the best idea. I would recommend some gateway that makes sure only authorised system can access your KNX bus.
  2. If you use any commercial product to connect your KNX bus to your LAN, (there are a lot of products available) make sure, the supplier provides regular updates and reacts on security incidents. If the last firmware you can find is 17 months old, the supplier most likely doesn’t do a good job. Most of these gateways are Linux based and you will need regular updates for it.
  3. If you implement some kind of gateway/firewall by yourself, make sure it is designed with security in mind and you also update it regularly.

Remark 1: The concept of physical security can be very critical in environments where multiple parties share a KNX installation. This can be a problem not only in office buildings, but also apartment complexes. If you live in an apartment with some kind of “smart” technology, have a look how it is implemented and who might be able to access it.

Remark 2: With ETS 5.5 the KNX association now supports some kind of encryption. I haven’t looked into it. Why? Because all old devices do not have any idea about it. It might become more popular in the future, but in today’s practical KNX installations, it is usually not supported by the devices that are already in place.

Is wireless the future?

Looking at new companies in the home automation industry it looks like many of them prefer some kind of radio frequency data transmission. This makes sense as customers don’t want to have additional cables in their home. But is this really the future of home automation? I’m not sure. Here are some arguments against wireless control:

  1. Reliability: with more and more devices communicating wireless, interoperability problems can become more and more problematic.
  2. Power supply: with some exceptions (e.g. EnOcean), even wireless devices need a power supply. This mean either cabling or batteries that need to be changed regularly
  3. Security: Wireless devices are easier to attack than wired devices (at least if these are not connected to a public network).

Especially the security aspect is important in my point of view. Many home automation devices will be used for 10-50 years. While it might be reasonable to buy a new music player every 5 years, you don’t want to change your wall switches every 10 years. The development of encryption algorithms has shown that no algorithm is secure forever. This means the software has to be updated from time to time. Newer encryption algorithms might even need more powerful hardware. Do you believe your supplier will provide software updates for the devices during the next 20 years?