De-clouding IoT

There is a lot of IoT (Internet of Things) stuff these days, and it is impressive what you can do with home automation - linking sensors and devices and command speakers and phones and all sorts. It is even impressive that third party linking services like If This Then That even exist now!

A lot of these devices make use of The Cloud in one way or another, but not all, and not all to the same extent. This is both good and bad, and represents something of the age old compromise of security and convenience in a way.

Today I am playing with three devices: A Daikin air-conditioning unit (as per my blog), a Withings Sleep monitor (as per my blog), and some new SONOFF switches. All have different approaches. All work with IFTTT, so if I was happy to just use the cloud, this would all be simple.

What's wrong with the cloud?


The first thing that is right with the cloud is the convenience - simply connect a device, load a phone app, set up and it is working. Devices that live on your home WiFi and talk to servers on The Internet do tend to just work and be easy to use. But this convenience comes at a cost...


One of the issues is privacy - the data from these devices is going to third parties - companies you don't know, or may not even know which country they are in. Often the "service" they provide is not something you even knew was needed when buying the product and is some separate "agreement". GDPR should make your data safe, but it is a law not a technical means. They may not understand GDPR (Withings clearly don't, and have been reported to the ICO). Even if they do understand GDPR you have no real way to know if they are following it properly, or if they will ever get hacked.

The main way to ensure privacy is to keep control of your data. A cloud based service inherently takes that control away.


If a device needs the cloud to work, that is also a problem. Even the Withings Sleep monitor, which is totally cloud might seem like it is not an issue if your WiFi or Internet is down or they are doing maintenance on their servers, etc, but when you use the real-time triggers for getting up or going to bed to work the lights and heating and so on, suddenly it matters.

With locally connected and controlled devices in your home you can remove that reliance on the Internet and The Cloud, but at the cost of a single point of failure and equipment you have to maintain.

You also have to allow for the fact that this is most likely a free service, and something they can stop by choice, or because they go bust, or even politics between countries, and suddenly your devices are useless.

Adding extra parties like IFTTT just adds to the issues.


Finally security - this is a huge issue with IoT. "The S in IoT stands for Security".

The Daikin air-con have no security - simple http requests. Even if there was a password it would be easy to snoop. It means anyone on your home network / WiFi can access the air-con.

Does it matter? After all anyone with a remote can do the same in the house or even from outside through the window (stories of someone turning on neighbours air-con through the letter box whilst they are away so heat rises to their flat and saves them money). But is it a big deal? Well, remember, this is not just about you - if someone could control all air-con in a country they could make them all turn on at the same second and cause a major power blip? They could monitor when you are in and not and break in when not. It is not so simple.

But they need to be one local network / WiFI? Well, no, they just need a compromised broadband router or compromised device (a lot of IoT is very hackable) on your LAN, or even some background secret function in some popular phone app. It is not as hard as it sounds.

So security of IoT really needs to improve.

What do I mean by de-clouding?

Basically I want to have devices I control, and home automation I manage using my computers in my home without using The Cloud. I can set up any remote access I want with a secure VPN. I then control my systems, and control my data. It means I have to maintain a machine, but I do that anyway, and it is not that hard - could even be a Raspberry Pi or some such.


As per my blog, this was simple - no authentication just local http - it has no security.

The good news is that it makes it simple for me to lock down on separate WiFi SSID and VLAN and easy for me to write my own controls.

Apart from a lack of security, the other failing is a lack of documentation. I'd prefer if the API was actually documented - why not, Daikin?

Withings Sleep

The Withings Sleep monitor was more of a challenge - the security is trying with this one.

The device does an HTTP request to fetch the public key used for HTTPS, but includes its MAC and a random challenge in the request and gets a digest in the response. Any change to the response key, or even the request MAC causes it to abort and start again (DHCP, DNS, HTTP, etc). So it seems there is likely to be a per-device key check on the response and as such I cannot simply replace the public key returned. It then checks the public key on the HTTPS.

So yes, I am stuck. The good news is that it does do IFTTT and that can be linked by creating an applet to a webhook to poke my own server for triggers. Sadly this is not direct from the device, but via Withings, so no chance to intercept / hack that either. It has all the disadvantages of cloud and local servers combined, but does mean I can then control the actions I take directly - such as changing air-con settings, turning lights on/off, etc.


I was inspired by a blog post (here). It seems SONOFF are very cheap and very popular, even with alternative code that people flash in to the units. However, the security is poor in the first place meaning one can control them off-the-shelf. This is bad for security but good for de-clouding them.

First off, the simple in-line power switch (e.g. for lighting circuits) - which I have connected to a table lamp (purchases especially for this test, and obviously pixar style).

It was incredibly difficult to see the AP mode SSID pop up and connect to it, and I wonder if you just have to try several times. You long hold the button and it shows up if you are lucky (ITEAD-1000xxxxxx with password 12345678) But then the /device and /ap http commands work as explained in that blog. It seems serverName can be a host name.

As expected it then connects https. Unfortunately, even where the server has proper https and the name matches, it is just closing the connection after getting server certificate details. Arrrg.

Reading some of the comments, it seems I am not alone - even with a valid (LE) cert, the sonoff is not happy with the https negotiation. Grrr.

This sort of leaves me either using IFTTT and cloud, again, or re-flashing the code. Not amused.

What I think would help...

Firstly I think all IoT needs better security - maybe there needs to be a testing standard as part of compliance for CE marking (scary).

But also I really think the APIs should be published. This would allow devices to work directly with IFTTT or competing home automation systems or local controllers.

At the end of the day the closed approach, and forcing all data via the cloud maybe made commercial sense when companies could collect and use all that lovely personal data. GDPR kills that business model, and even makes having that data a potential liability! So please, let's open the APIs (securely) to allow more competition in the home automation market.

Oh, and don't forget support of the current IP protocol (IPv6).

Update: Current plan is to re-flash SONOFF. I'll blog more on that soon.


  1. I have a Sonoff controlling my kitchen light (which is a 600x600 LED panel like you have), I flashed Tasmota and it's controlled (and monitorable) using MQTT, I use Home Assistant for that.

    The Sonoff is pretty easy to flash - the case cracks open easily and you solder a strip of header pins on the board, then connect it to a serial > USB board and run the software.

  2. I have a TP-Link HS110 Smartplug and those have a decent local API that you can prod. It's not published, but it's been well reversed engineered and there's a Node library tplink-smarthome-api that you can find all the info in. I used it to make little tool for logging the energy use at regular intervals to give more detail than the official app gives (JJC1138/smartplug-energy-logger on GitHub). Oh, and I should mention: the local security is non-existent as per usual with these things, and the Wi-Fi is 2.4Ghz only.

  3. +1 for tasmota on your sonoffs (well plus a million as I was heavily involved in the early stages of development)
    I have a bunch of sonoffs based gear now all running tasmota to a local mqtt server. You can then link it up to openhab, hassio or (as I do) node-red

  4. Plus more for tasmota and home assistant. Note you don't really need to solder the headers, I drive this with my early ones but now just hold the pins in place on the pads ... Extra hand may be required! I have it running on both sonoff kit (seems well made), but also some 12v magic home LED controllers.

    Surely you run a separate vlan and SSID for this stuff?

    This actually helps with e.g. the broadlink IR devices. The IHC app insists on 2.4G network (you also need to allow ports 80/443 out for initial setup).

    The TP link stuff also works well with local control. I only but stuff where you can do this. Because whilst you've talked about the IoT device security, how much do you trust the multitude of apps needed to control them as standard?

    Running home assistant (or others) means you can build ifttt type automations without the cloud.

  5. The default Sonoff cloud solution is provided directly by the Chinese manufacturer. Given the issues with internet service and security in China (and the lack of any data protection arrangement there) I'd definitely look at replacing the firmware on the Sonoff. Some good articles at https://tech.scargill.net/?s=sonoff and https://www.superhouse.tv/?s=sonoff with detailed overviews of the options available and how to arrange the toolchain to create your own firmware.

    Regarding IFTTT. Don't rely on it for anything that you need to be reliable. Especially the webhooks service! For clarity, here are the four possible outcomes with the webhooks service with their IFTTT responses:

    1. Webhook API key incorrect. IFTTT returns ERROR (correct)

    2. Webhook call OK, backend service returned OK. IFTTT returns SUCCESS (correct)

    3. Webhook error, backend service never called. IFTTT returns SUCCESS (WTF?!)

    4. Webhook works OK, backend service returns error. IFTTT returns SUCCESS (WTF?!)

    Clearly the response from the IFTTT webhook cannot be used in one's software to make any deductions as to whether the call was successful or not. Thus it can't really be relied upon for anything more than trivial novelty. Which is a great shame as it could (with a little effort) be a great solution to using many closed devices.

    IFTTT's response to this is that "Webhooks is offered as-is with no warranty". They have no interest whatsoever in fixing this somewhat irrational behaviour.

    Based on an email I (and many others) received the other day from Google, it appears they have the same laissez faire attitude with their Gmail applet which Google is about to remove because they haven't updated their T&Cs.

  6. Maybe I am a dinosaur, but I simply will not have any Cloud based stuff at home. I am quite capable of running my own rotating backups, and I don't have to worry about third parties having my data or devices ceasing to work suddenly.

    But I also don't have any IoT devices, I just don't see the point. Network controlled air con, network controlled lights, why? I just can't see the point of any of them. Light switches on the wall work fine, as does IR remote control for the air con. On holiday? Run a timeswitch for some lamps. The rest is just a waste of time, needless use of technology for the sake of it. I do have a SqueezeBox network music player, that actually does something useful. But I run it on my own local server.

    1. Owen, I'll say here much the same thing I've said to you in person: because it expands possibilities. For example, "everyone has gone to bed, please confirm that all downstairs lights are off and external doors are closed and locked". Or indeed "the alarm has gone off, turn on all the lights".

      That said, I agree that requiring external connectivity and servers is a mug's game.


Comments are moderated purely to filter out obvious spam, but it means they may not show immediately.

Breaking my heart

One of the things I suffer from is tachycardia. My first memory of this was in secondary school, when I got a flat tyre cycling to school an...