Generation 2 devices support

Issue #39 resolved
Xose Pérez repo owner created an issue

Current fauxmoESP code is not 100% compatible with Gen2 devices like the Echo Plus. There have been several issues discussing the topic. This issue is meant to centralize development on this line.

Comments (42)

  1. Alexander Pankow

    The adjustments of @bibbbi in #35 seem to work only with Gen2 Echo Dot, but not with the Gen2 Echo. First, I only had two Amazon Echo (2nd Gen) but it didn't start working until I set up an Echo Dot (2nd Gen).

  2. Jezz

    Bibi's update was the only one that worked perfectly on my Echo plus (2nd Gen) with out any other Echo's on the network. Now have it working nicely with 144 WS2813B LEDs and the FastLED library on a nodeMCU clone too.

  3. ThorC

    Not working on my Gen2 Echo Dot either. I think it requires the WeMo skill, which requires the MAC address of the WeMo device.

  4. ThorC

    Hi everybody! I've found a way to get it to work after reading a lot of issues online.

    I have the newest Echo Dot, purchased it less than a week ago from Amazon.

    Use the latest version of fauxmoESP. Then, you'll want to go into your Board Managers in the Arduino IDE, and remove the esp8266 boards, and reinstall version 2.3.0.

    Doing this, the Echo Dot is able to natively find it without requiring the installation of the WeMo skill.

  5. SaucedCowboy

    I got the latest version of fausmoESP, removed the esp8266 boards, installed board version 2.3.0, compiled and ran the fauxmoESP_Basic sketch. The sketch does log onto my network but my Amazon Echo V2 will not find the “switch one” that the sketch creates. It just keeps repeating “[MAIN] Free heap: 46472 bytes” in the serial monitor and never responds to the probes from the Amazon Echo.

  6. ThorC

    @SaucedCowboy I think that the fix only works for the Echo Dot gen 2. The regular Echo doesn't work with it.

  7. Jezz


    Try rebooting your Echo, if that don't work, Try resetting the echo. I found some times after many attempts to discover devices it failed to even discover Philips hue stuff until i reset it.

    Bibi's fixed worked perfectly on my Echo plus (Gen 2)

  8. Erik Lane

    Nothing else was working for me. I had a heck of a time going round and round with many different versions and trying all kinds of things. Finally resorted to resetting the Echo (first gen, I'm pretty sure) and after another couple tries, it showed up and is now working perfectly! Thanks!!!

  9. Jezz

    @ejlane. 1st Gen Dot has 2 buttons and a volume ring, 2nd Gen Dot has 4 buttons and no volume ring. 1st Gen Echo, is all plastic with a volume ring. 2nd Gen Echo usually has a fabric sides and no volume ring, Echo plus (which is a Gen 2) looks like the Gen 1 Echo with a volume ring, but has the power socket on the back, with an 3.5mm Audio out jack and a built in Zigbee (Philips Hue) hub, The Gen 1 Echo has the power socket underneath with no 3.5mm Audio out and no built in Zigbee hub.

    Hope this helps...

  10. Erik Lane

    Okay, so it's a Gen 1 Echo, like I thought. Thanks for the clarification. It's still working beautifully with the light. :)

  11. György Fenyvesi

    I purchased a Zolo Halo. This is the Anker version of Echo Dot, Amazon doesn't deliver to Hungary where I live. The exact differences between Echo Dot and Zolo is not known.

    Anyway the fauxmoESP program doesn't recognize the fauxmo. (Arduino esp8266 2.3.0). I checked the local network traffic and didn't see any discovery action related to this device. I have the feeling that it is controllable only through skills. (Skills work.) To check the idea I tried discovery through browser and see a suspicious content in the outgoing traffic: SUPPORTS_CONNECTED_HOME_CLOUD_ONLY If I understand it correctly, then the local discovery is not able to work.

    It would be good to know what is this parameter in case of working and not-working other devices. If anybody would be so kind to check I'd be happy.

    Thanks. George

    Firefox, Web Console, Network, one of the GETs The whole capability list:

    accountName George's Halo appDeviceList [] capabilities […] 0 ### # SUPPORTS_CONNECTED_HOME_CLOUD_ONLY ### #

    1 SLEEP

    2 GOLDFISH 3 AUDIBLE 4 TUNE_IN 5 CHANGE_NAME 6 PEONY 7 TIMERS_AND_ALARMS 8 PERSISTENT_CONNECTION 9 I_HEART_RADIO 10 KINDLE_BOOKS 11 AUDIO_PLAYER 12 AMAZON_MUSIC 13 DEREGISTER_DEVICE 14 REMINDERS ### charging null clusterMembers [] deviceAccountId AIJNT1E6U65QB deviceFamily UNKNOWN deviceOwnerCustomerId A34LRNB6EAPENZ deviceType A1P31Q3MOWSHOD deviceTypeFriendlyName Halo essid null language null macAddress null online false parentClusters [] postalCode null registrationId null remainingBatteryLevel null serialNumber 45a317f3d53f4ca4bf3b3a95293b9db0 softwareVersion 0

  12. Martin Doubek

    I have tried using version 2.4.0 and 2.4.2 together with 2.3.0 version of Arduino Core. Neither did work with my Echo Gen2. It is the only device I have, so I hope it can be fixed and will be fixed soon.

  13. Mayur Patel

    Hi frnds.. i was also trying the same thing with my Echo dot v2. but was not showing my devices. after as i read above @bibi and all others, i just downgraded my library from 2.4.0 to 2.3.0 and thats all... recompiled and on the next move i saw my devices in alexa app.. i dont know what makes it incompatible with the new 2.4.0. That we have to find out..

  14. Martin

    Hi, I've been gettings Issue #35 (that has been mark as duplicated and redirected to this one, but I'm using a GEN 1 Echo DOT... so, is it possible this is expanding to all generations ?

    In my case my main problem is that after some random times, Alexa just say's SWITCH ONE is not responding, you wait about 10-20 seconds, try again and works perfectly fine.

    I have created an android APK to work with this library, that basically sends SOAP messages to the ESP and the weird thing is that when Alexa says the switch is not responding, the APK works perfectly fine... so it's something with the Alexa - Fauxmo relationship I think (not an specialist, just wondering).


  15. Martin

    Not sure if this can help, but this is the link of a Fauxmo for RPi3 (Python) version that is a fork of the original Fauxmo and it's currently working fine with Gen2 devices (although I actually have problems with Gen1 too). I've already asked the owner for some info, but I'm not good at this so, maybe someone smarter can find a solution looking there.

  16. uDude

    @Mopheus, that python lib is a more complete SSDP implementation. I only have gen 1 devices or I'd sniff the traffic and find the issue. This library may be missing (ok is in at least the instance I'll quote) some basic error checking.

    Where _udp.beginMulticast() is called to start a multicast igmp group for SSDP it returns 1 on success and 0 failure. These return values are not checked.

    A quick glance at that section of the code tells me that two people with differing philosophies of where to start the multicast group have been used. One person does it in the constructor and the other in the begin function. This code could use someone overseeing consistency to make it easier to update (and no I am not volunteering and I am generally not in a position to perform the function successfully due to an extended illness leading to a seriously messed up brain much of the time -- you caught me on a relatively good couple of hours right now.)

    Enjoy --- hopefully someone will implement some #DEBUG statements to serial for you to test with and discover where you are not reaching in the code as well as add in missing error checking.

    The Arduino UI will allow you to set DEBUG at compile time so you can control turning it on when you want [normally off is the recommendation].

  17. Giuseppe Lap

    Doesn't work in 2.4.2 or 2.3.0 with echo dot and echo gen 2 .

    In 2.3.0 I have some trace in debug console like this :

    HTTP/1.1 200 OK
    CACHE-CONTROL: max-age=86400
    DATE: Mon, 22 Jun 2015 17:24:01 GMT
    OPT: ""; ns=01
    01-NLS: 4445569995DF00
    SERVER: Unspecified, UPnP/1.0, Unspecified
    X-User-Agent: redsonic
    ST: urn:Belkin:service:basicevent:1
    USN: uuid:Socket-1_0-4445569995DF00::urn:Belkin:service:basicevent:1

    in 2.4.2 I have nothing shown.

    Thank for your library

  18. Patrick Harrer

    I have tested a bit with an eco dot gen 2 and version 2.4.2 of the library and came to the conclusion:

    • You have to downgrade the Arduino Core for the esp8266 to version 2.3.0

    When I used version 2.4.0 or 2.4.1 of the Arduino Core the eco dot wouldn't detect any smart home devices but when the devices were already detected they still work

    • onGetState() has to be defined correctly

    When I defined onGetState() incorrectly the eco dot only detected the last virtual device. I think the eco dot checks the device state when it detects it and when there is no or a false respond the eco dot ignores it.

    I also include my modified example sketch

    #include <Arduino.h>
    #ifdef ESP32
        #include <WiFi.h>
        #include <ESP8266WiFi.h>
    #include "fauxmoESP.h"
    #include "credentials.h"
    #define SERIAL_BAUDRATE                 115200
    fauxmoESP fauxmo;
    bool testswitch[3]= {false, false, false};
    void wifiSetup() {
    // -----------------------------------------------------------------------------
    // Wifi
    // -----------------------------------------------------------------------------
      // Set WIFI module to STA mode
      // Connect
      Serial.printf("Verbindungs zu %s wird aufgebaut ", WIFI_SSID);
      WiFi.begin(WIFI_SSID, WIFI_PASS);
      // Wait
      while (WiFi.status() != WL_CONNECTED) {
      // Connected!
      Serial.printf("Verbunden! SSID: %s, IP Adresse: %s\n", WiFi.SSID().c_str(), WiFi.localIP().toString().c_str());
    void callbackSetState(unsigned char device_id, const char * device_name, bool state){
       Serial.printf("[MAIN] Device #%d (%s) state: %s\n", device_id, device_name, state ? "ON" : "OFF");
       testswitch[device_id] = state;
    bool callbackGetState(unsigned char device_id, const char * device_name){
      return testswitch[device_id];
    void setup() {
      // Init serial port and clean garbage
      Serial.println("Nach dem Verbinden, sage 'Alexa, schalte <Gerät> 'an' oder 'aus'");
      // Wifi
      // You can enable or disable the library at any moment
      // Disabling it will prevent the devices from being discovered and switched
      // Geräte Definieren
      fauxmo.addDevice("switch one");   //ID0
      fauxmo.addDevice("switch two");   //ID0
      fauxmo.addDevice("switch three"); //ID0
      // Calback
        // fauxmoESP 2.0.0 has changed the callback signature to add the device_id,
        // this way it's easier to match devices to action without having to compare strings.
    void loop() {
      // Since fauxmoESP 2.0 the library uses the "compatibility" mode by
      // default, this means that it uses WiFiUdp class instead of AsyncUDP.
      // The later requires the Arduino Core for ESP8266 staging version
      // whilst the former works fine with current stable 2.3.0 version.
      // But, since it's not "async" anymore we have to manually poll for UDP
      // packets
  19. Former user Account Deleted

    Hi, i did some research on the Issue with Echo V2 Devices. I enabled debugging in fauxmo and it seems that the GetState and SetState Messages sent by the Echo are getting cut off. See this Log, that is what Echo is sending after i say "Switch on Lamp":

    [FAUXMO] Client #0 connected [FAUXMO] Device #0 /upnp/control/basicevent1

    This is the answer of the Echo V2:

    POST /upnp/control/basicevent1 HTTP/1.1 SOAPACTION: "urn:Belkin:service:basicevent:1#SetBinaryState" Content-Type: text/xml; charset="utf-8" Accept: User-Agent: Dalvik/2.1.0 (Linux; U; Android 5.1.1; AEORD Build/LVY48F) Host: Connection: Keep-Alive Accept-Encoding: gzip Content-Length: 299

    <?xml version="1.0" encoding="utf-8"?><s:Envelope xmlns:s="" s:encodingStyle=""><s:Body><u:SetBinaryState xmlns:u="urn:Belkin:servic

    (As you can see this ends with 'urn:Belkin:servic' <---the rest is missing!!!!! Echo says 'Content-Length: 299' but we get only 215!!)

    [FAUXMO] Client #0 disconnected

    But with an Echo Dot V2 everything is fine:

    [FAUXMO] Client #0 connected [FAUXMO] Device #0 /upnp/control/basicevent1

    This is the answer of the Echo Dot V2:

    POST /upnp/control/basicevent1 HTTP/1.1 SOAPACTION: "urn:Belkin:service:basicevent:1#SetBinaryState" Content-Type: text/xml; charset="utf-8" Accept: User-Agent: Dalvik/2.1.0 (Linux; U; Android 5.1.1; AEORD Build/LVY48F) Host: Connection: Keep-Alive Accept-Encoding: gzip Content-Length: 299

    <?xml version="1.0" encoding="utf-8"?><s:Envelope xmlns:s="" s:encodingStyle=""><s:Body><u:SetBinaryState xmlns:u="urn:Belkin:service:basicevent:1"><BinaryState>1</BinaryState></u:SetBinaryState></s:Body></s:Envelope>

    [FAUXMO] Client #0 disconnected

    As you can see nothing is cut off and it works fine. That cut off issue has nothing to do with the fauxmo library!!!! The error must be somewhere in the 'ESPAsyncTCP' library as the async client used in fauxmo already sends back the cut off data!! I wasted hours on checking the ESPAsyncTCP lib, but thats out of my skill. So if someone is interested, that may be a hint to go further.

    PS: On the ESP32 with the corresponding 'AsyncTCP' lib thre is also no cut off and everyting is working.

  20. ivan

    Using Arduino IDE, changing ESP8266 version to 2.3.0 worked for my recently purchased (July 2018) Echo Dot (2nd Generation). Previously using the latest (i think 2.4.x) did not allow me to discover the device. Using a NodeMCU 1.0.

  21. Thibault Marrannes

    My Echo gen 2 still can't find devices. I'm using version 3.0.0 and ran the example code on a Nodemcu. Anything we need to do? Does it still only work with ESP8266 version set to 2.3.0?

  22. Sasivarnan R

    I am using Wemos D1 mini and Echo Dot Gen 2.

    When using the latest ESP8266 my device is not discovered whereas using 2.3.0 works like a charm.

  23. Ran Talbott

    Also using Wemos D1 mini and Echo Dot Gen 2. Arduino IDE 1.8.4, ESP8266 2.3.0

    I've been trying for almost a year, off and on, to get this to work. back in January, I got some intermittent results: devices would come and go. Sometimes they would work even though the didn't show up in the Android Alexa app. Sometimes they wouldn't.

    More recently, I've tried versions 2.3.0, 2.4.4 (or maybe 2.4.5: the version numbers in the source files are inconsistent) and 3.0.0.

    Neither the Dot nor the Alexa app can discover either the basic examples or my own code. Neither can gssdp-discover on Linux. The debug messages on the D1 never show it got any kind of request during discovery attempts. With 3.0.0, I do sometimes get debug messages saying it's responding to M-SEARCH requests, but I can't tell whether they're from the Linux gupnp-universal-cp app, or from the Belkin router, which also does UPNP queries at seemingly-random times.

    I've tried doing some WIreshark captures of various apps doing discovery, but it appears that it's not capturing everything on the WiFi like it does on Ethernet.

    An suggestions for debug tools (preferably Linux-based) would be appreciated.

  24. Carlos Yz

    I was using esp8266 core 2.3.0 and fauxmoESP 2.4.0 with Bibi´s patch and it was ok. The only way it worked.

    I have only an Echo Dot 2nd Gen.

    Then I had a clue at #58, thanks to Andrew D. When I set Tools/"IwIP variant" to "v1.4 Higher Bandwidth" with core 2.4.2, all examples worked to me. I tested fauxmoESP 2.4.4 and 3.0.2 with original examples, changing just credentials.h and uploaded it. Discovery, turns on/off and "set light one to fifty", etc. worked fine.

    I used IDE 1.8.5, generic ESP-12E as "NodeMCU 1.0" board, Witty USB-Serial base.

    And sorry for my English.

  25. Giovanni

    I'm trying to make running the basic test with my new echo 2 but it is not found. I'm using fauxmo 3.0.2 and esp32. Are the issues with echo v2 fixed?

  26. Grant J

    I did everything I could find in the threads related to fauxmo not working (which exhausted much time this weekend):

    1. Turned off all of my Gen 2 Echo devices

    2. Did a reset on all of my Gen 2 Echo

    3. Reverted the Arduino IDE ESP8266 Board to ver 2.3

    4. Reverted the fauxmoESP version from current to ver 2.4.4 to emulate WeMo instead of Hue

    5. Tried the Example code instead of my own code

    6. Tried discovery before and after pressing the middle button on my Hue bridge with all of the iterations above

    7. Tried discovery on my phone app instead of Browser

    . . .To seemingly no avail.

    I went back to the current version of 3.0.2 using Hue emulation one last time with no luck again and was ready to give up for a while. My next project at home was to install a few Hue lights for a few more rooms in the house. Hue discovery did not work for my 1st light until I entered its serial number. I did 2 lights like this and added my rooms in the Hue app. Once I was done, I went to my Alexa app to update my new Hue configuration and I unexpectedly got the "light 1" & "light 2" to show up on my Alexa Devices with voice control working to control the LED on my NodeMCU (ESP8266) chip. I do not know what part of the process forced it to work. Maybe the Hue bridge must be forced to search it's network in a way the incomplete implementation is not triggering.

    Anyway, Thank You to everyone contributing to this project.

  27. Peter Feerick

    tl;dr - 'v1.4 Higher Bandwidth' worked for me with an Echo Dot Gen 2. I just got myself an Echo Dot Gen 2 and have been getting a basic sketch working with an ESP8266 'Witty' module (handy for this sort of testing due to an onboard RGB/three colour LED which I'm using to represent three devices. With Arduino IDE 1.8.7, ESP8266 Arduino Core 2.4.2 and fauxmoESP v3.0.2, I was having trouble getting the Echo Dot to discover the ESP8266. I spotted Issue #58 where it was suggested to try the v2.3.0 version of the core - which made no difference. Then saw mention of changing the lwIP version, so I reverted back to v2.4.2 of the Arduino core, and tried the 'v2 Higher Bandwith' lwIP option. And presto, the Echo Dot started seeing the ESP8266 module. Could turn the LEDs on and off correctly, so all was looking good. So tried the 'turn on at 50' type command, and the ESP8266 would promptly crash with a WDT reset. So it looks like something was timing out, and forcing a reset. I thought I'd try the 'v1.4 Higher Bandwidth' option since it was mentioned in this issue, and now the ESP8266 is working perfectly. It is discoverable and is turning the light on and off, and the brightness command is being received, but not acted upon in my code yet, without crashing the ESP8266. I did notice when unplugging the ESP8266 and the Echo at some point, that the Echo stopped controlling the ESP8266 - basically saying it was not responding even though it was connected and running fine. I told the Echo to 'discover devices' and even though it didn't find anything new, it promptly started controlling the ESP8266 again, so maybe discovery can clear out cobwebs?

  28. Carlos Yz

    Feerick, same here. I also suspected the need of re-discover devices to reactivate the control. I turned off and on the Esp8266, but the my Echo Dot Gen 2 didn't find the devices. Yesterday I put a reconnect call trying to fix the problem, before read your post.

  29. Peter Feerick

    I've just been chasing my tail for the last hour or so trying to work out why the code stopped, and it seems (for some reason I don't understand as I haven't dug through the code to find out how all this works) that you may actually need the enable/disable/enable sequence in order for the device to be properly visible... maybe something isn't set right and the disable then enable sets it properly. Whatever... anyway... having just fauxmo.enable(true); on it's own resulted in no device. Having


    as per the example resulted in it being discoverable again... And I have been able to replicate this multiple times just by making the echo forget all devices, and discover again... grrr! Obviouly one bit I can't cut out just yet when trying to streamline the code...

  30. Francisco Garcia

    Thanks Peter, It works! I tested using Dot Gen 2. None of previous methods worked for me, but curiously enable - disable - enables does the trick!

  31. Sabhay Sardana

    Does anyone experience this issue in which if nodemcu power gets off and it turned on back, then the device is not discovered, I need to manually reset the nodemcu board although the device is still connected to the wifi.

  32. Sabhay Sardana

    @peter feerick where I have to add your solution?

  33. Peter Feerick

    It's not my solution per se... it's straight from the example code... I just realised if I got rid what I thought was a redundant / example false/true combo that the Echo Dot 2nd Gen started seeing the ESP8266 again. It goes in the setup section, and you can do it after you connect to wif. Have a look at where it is in the example here :

  34. Xose Pérez reporter

    The issue with the enable() call has been solved. It was really stupid, my bad. It should work now only calling fauxmo.enable(true); once.

  35. Peter Feerick

    He he... I was more interested in what caused it... just hadn't gotten around to looking any further at the code than getting it to "it works" state... ;) Now that you've fixed it the gremlin it makes perfect sense... nasty one that! Thanks for fixing it. I'll be sure to try out the latest changes and the dev branch in the next day or so and report back. :)

  36. Peter Feerick

    @xoseperez Against ESP8266-Arduino core 2.5.0-beta1, with lwIP set to 1.4 Higher Bandwidth, on a Wemos R1 Mini, the dev branch example is working just great with a Echo Dot 2nd gen - only changing the pin mapping for the lights, and add wifi SSID. Will be trying out the new setState function (perfect timing that... I currently have another unit controlling a desk lamp, and wanted a manual control option also!) and testing the library further, but looking good so far. Regarding the note in the basic example on ln117 - "// Checking for device_id is simpler ... comparing the device_name is safer." - isn't that only the case if you don't get the device_id as returned by addDevice? i.e. my quick attempt at using the device_id is currently looking like...

      // Add virtual devices
      mode1 = fauxmo.addDevice("christmas lights 1 static");
      mode2 = fauxmo.addDevice("christmas lights 1 fading");

    with a device_mode = device_id; in the callback, and if (device_mode == mode1) else if (device_mode == mode2) type affair in the loop...

  37. Xose Pérez reporter

    Good news then. The device_id is just the order in the internal array of devices. The problem is: if you remove any of the devices that index stops making sense. So, for fail-proof matching, use the device_name.

  38. Log in to comment