Using Google Assistant to control your ESP8266 devices

In my last post I tried to explain how to access your IoT devices at home from the Internet in a secure way using a reverse proxy. Truth is that I had it running since maybe 6 months ago without giving it too much use until recently. Reason? My Nexus 5 had been having serious problems (battery not charging, screen broken, earpiece not working,…) and I decided to replace it with a new mobile phone and the new one has Google Assistant built in.

So one of the first things I have tried is to make Google Assistant toggle my smart switches flashed with ESPurna. Nad as it turns out it’s not hard to do but -at the moment- you have to relay on a cloud service like IFTTT (IF This Then That). This is a key difference with Amazon Alexa services you have to be aware. It has some benefits but also some drawbacks.

Amazon Alexa vs. Google Assistant

The “vs.” might sound a bit like a fight but I’ll be focusing on few aspects on the way the two work when managing IoT devices like smart switches.

First let me name things correctly. Amazon Alexa is the service behind devices like Amazon Echo [Ebay] or Amazon Dot [Ebay]. The same way Google Assistant is the intelligence behind Google Home [Ebay]. On Android or iOS you have, for instance, Reverb, which is an app that uses Amazon Alexa to answer your commands. You can use it with your smart home devices that support Alexa too. Same thing for Google Assistant or Allo, both apps use Google Assistant servers. So I’m not focusing on the devices here but the service underneath, although some differences between the two have to do with the devices themselves.

Amazon Alexa


On one hand the standard way to use Amazon Alexa is using skills, either the ones you can create or third party ones available in the Amazon Alexa web page. Here you have skills to control your Philips Hue [Ebay] or your Belkin Wemo switches [Ebay], amongst others.

The case of the Wemo switches is well known since the protocol was reverse engineered. Basically, your Amazon Alexa powered device is listening for a key work to wake up (“Alexa”or “Echo”), then it records your command and sends it to Amazon servers to decode it. The command, now converted in something your device can understand, comes back to it and it executes the action. For Wemo switches it an be a discovery process (Belkin uses a standard uPNP process) or an event, a custom TCP connection requesting the switch to turn on or off.

Since we know the protocol we can emulate being a Wemo switch and accept commands from an Amazon Echo or Dot, that’s how my fauxmoESP library for ESP8266 works. Unfortunately, not all Amazon Alexa powered devices support the Wemo protocol the same way Echo or Dot does, and that means that if you are using a AlexaPi on a Raspberry Pi or Yonomi on your mobile phone you are out of luck. Reverb is a brilliant exception, since it looks like it communicates with your Amazon devices and commands them to execute the actions.

Anyway, for this specific use case (emulating being an Alexa compatible smart switch), only the translation from your voice command to machine language is performed outside your network. The communication with Alexa Voice Service (AVS) is done using HTTPS so, as long as you trust Amazon you are good and secure.

Google Assistant


As for Google Assistant (GA), everything is a service, as you might have guessed. Google is partnering with different providers to include options for their services on Google Assistant. One of such partners is IFTTT (IF This Then That) which means you can create custom behaviours responding to your voice commands. That’s pretty cool and IFTTT has already a ton of different options. One of this options is WebHooks, which provides an API to perform HTTP requests.

So the standard way to interact with your IoT devices using Google Assistant implies that:

  1. You speak your command
  2. Google voice services transcript it and search the different providers for one that can handle it, including IFTTT
  3. IFTTT grabs the command and tells GA “yeah, I can do that”
  4. IFTTT translates it again based on an applet you have defined
  5. The action in your applet instructs IFTTT to tell WebHooks to do an HTTP request
  6. WebHooks performs the request to an address that points to your device
  7. Your device executes the action

Some very important things are missing in the previous explanation. On point 6 you have to have a way to redirect that request to your device but that’s exactly what I was explaining on my previous post about secure access your network. And on point 7 your device has to understand the command. Well, ESPurna does have an HTTP API!!

The main differences with the way Amazon Alexa works are obvious here. You have 3 different cloud services involved here: Google Assistant itself, IFTTT and WebHooks. Again it’s a matter of trusting them (!!). And the final command comes from outside your network, always.

HTTP API for your DIY IoT device

Stop writing and let’s do something to make this work. First thing is to be able to send an HTTP request to your device from outside your network. If you have read my previous post about secure accessing your home network you already know the basics. Go ahead and install a reverse proxy with HTTPS support. That’s the first thing to do.

Second requirement is to have an device with an HTTP API. Some commercially available do. If you are a maker and you use ESP8266 on your home devices (and if you are reading this blog chances are you are) you know some open source firmwares for ESP8266-based smart switches/sensors do have an HTTP API. And ESPurna does have. Of course, you can also build your own firmware or use an REST library like aRest.io.

For instance. I can control my living room light using my browser by browsing to “http://livinglamp.local/api/relay/0?apikey=0123456789ABCDEF&value=2” (faked API key :). That URL will toggle the light (value=2 means “toggle”, 0 for “off” and 1 for “on”).

From the command line using cURL I would do a PUT request instead since it’s more ortodox (ESPurna supports GET when setting values out of convenience):

curl -X PUT http://livinglamp.local/api/relay/0 --data "apikey=0123456789ABCDEF&value=2"

But ESPurna uses HTTP, not HTTPS. Inside your home network it’s fine (mostly) but that’s not an option from the outside. Here’s where the reverse proxy comes to play. The configuration in my previous post maps this device inside my home to a certain domain and URL inside the domain and only allow HTTPS communication, so I can do the same test from a machine outside my network, using also cURL:

curl -X PUT https://geek.fibonacci.com/livinglamp/api/relay/0 --data "apikey=0123456789ABCDEF&value=2"

Here “geek.fibonacci.com” is the example subdomain I’m using. As you can see the protocol and URI has changed from “http://livinglamp.local/” to “https://geek.fibonacci.com/livinglamp/”, no more changes are needed. And it does toggle my ESPurna powered lamp!

Creating an IFTTT applet



Now let’s configure the applet in IFTTT. You will have to create an account if you have not created one before. Then go to “My Applets” and click on “New Applet”. An applet is a combination of a trigger and an action. Both are provided by “services”. Our trigger will be provided by Google Assistant. Click on the “this” word and look for “google assistant” on the search box.

Each provider could provide one or more services, here we need the “Say a phrase with a text ingredient”. We will use the text ingredient to specify wether we want to switch it on, off or toggle the switch. As you can see in the screenshot below you can configure several (up to 4) different ways to say the command and the dollar sign will be replaced by the ingredient.

Once you have it configured click next and choose an action. In this case the only one provided by WebHooks, the “Make a web request”. We will just fill the fields with the same option as in the cURL command before replacing the value field in the body with “{{TextField}}”, to pass the ingredient that Google Assistant has identified.


Finally it will ask you to name the applet and once activated you are ready to go. In my case I click and hold the home button in my mobile phone to wake Google Assistant and speak “Turn on living lamp” and enjoy.

NOTE: As you might have noticed the “ingredient” will be a word. ESPurna 1.9.3 (still not realeased) supports “ON”, “OFF” and “TOGGLE” to change the status of the relay. If using a previous version or your device only supports numbers you might want to test the “Say a phrase with a number” trigger service instead. In this case you might want to be able to say “Set living room status to 1”, for instance. Less human-friendly but still usable.

All an all this approach is more flexible than that from Amazon, even thou there are more services involved. Using IFTTT alone, without Google Assistant, can provide an easy way to do schedules or actions depending on, for instance, an email or a tweet. That’s something you can also do with Node-RED for instance but IFTTT provides an easier way to do it…

As always, comments welcome!


CC BY-SA 4.0 Using Google Assistant to control your ESP8266 devices by Tinkerman is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

18 thoughts on “Using Google Assistant to control your ESP8266 devices

    1. Xose Pérez Post author

      Thanks. I think Arendst’s is a superb peace of software.
      I did use the v1 Dash Button for some time, with the classic hack, but I found it extremely slow for most scenarios. Don’t know about the v2 but I guess it could be fun to do something with the ultrafreq mic.

  1. Athar

    Can you have a look at v2 🙂
    The BT and ultrafreq features look interesting compared with ESP.

    Is there any recent blog post on v2 you have seen?

    Why was v1 slower than ESP8266?

    1. Xose Pérez Post author

      I’m not very interested on the dash. I’m sure there are or will be nice hacks with it but I have plenty of ideas (and work) to do.
      It was (is?) not slower because of the microcontroller. The dash button is a single-purpose device. It is switched off most of the time to save battery and when you click the button it boots, connects to the stored WiFi and sends a request to Amazon API to buy whatever it’s linked to. The hack waits for the device to popup in the network to send an MQTT message (for instance). This proces takes some time, a few seconds. So if you have it connected to a light at home, for instance, you click the dash button and several seconds after the light turns on. Not very real time 🙂

  2. Sachin Filinto

    Interesting article. glad to know how google’s assistant works.

    Rather then using a reverse proxy + HTTP api, have you considered, Google > ifttt > mqtt to turn the device ON or OFF ?
    i have experimented with ifttt > adafruit Service (mqtt) > Espurna but not been successful as yet. (to be honest i have not spent a lot of time trying to figure it out )

    1. Xose Pérez Post author

      It would have to be MQTT over SSL. I have tested the uplink (from ESPurna to Adafruit) and it works but it leaves very little room (memory) for other stuff. I recall having issues with the downlink…

  3. Tim

    Hey there, I like your instructions, also folled your tutorial regarding ghe secure rpi proxy.
    Got it all to work, but I’m facing problems to connect IFTTT to my local access.
    Are you aware if IFTTT can send a request to an IPv6 connection? Couldnt find any information by now.

    1. Xose Pérez Post author

      Well, I don’t know, but googling a bit shows that you are not the only one having this problem. Have you tried contacting them?

    1. Xose Pérez Post author

      I don’t think so. Voice-to-code translating aside, it looks like Google Assistant action are executed from the cloud. But it’s been a while since I tested it and I don’t use it.

  4. Alex P.

    I use OpenHab as system and this allows you to command your devices via cloud without too much hassle.
    Once all is configured, I use IFTT to command OpenHab to turn lights on and off

    1. Xose Pérez Post author

      I also prefer to manage my voice commands from a centralized point. I use Node-RED with an Alexa plugin to manage all the switches at home.

  5. Pingback: IoT 스위치 로드맵 - Story of Jacob

Leave a Reply (all comments are moderated, be patient)

This site uses Akismet to reduce spam. Learn how your comment data is processed.