Open kenny00869 opened 5 years ago
I wasn't very clear, but running on a LOLIN D32 Pro. Really appreciate all the effort you've put into this. Hoping to get this working, as others don't seem to work.
Similar issue also here:
Connecting to WiFi Connecting........... Connected to xxxx IP address: xxxxx Constructing device 1 Adding device 1 Constructing device 2 Adding device 2 Adding device 3 Espalexa Begin... MAXDEVICES 10 Done Got UDP! M-SEARCH * HTTP/1.1 Host: 239.255.255.250:1900 Man: "ssdp:discover" MX: 3 ST: ssdp:all
Got UDP! M-SEARCH * HTTP/1.1 Host: 239.255.255.250:1900 Man: "ssdp:discover" MX: 3 ST: upnp:rootdevice
Responding search req... Got UDP! M-SEARCH * HTTP/1.1 Host: 239.255.255.250:1900 Man: "ssdp:discover" MX: 3 ST: ssdp:all
Got UDP! M-SEARCH * HTTP/1.1 Host: 239.255.255.250:1900 Man: "ssdp:discover" MX: 3 ST: upnp:rootdevice
Responding search req... Got UDP! M-SEARCH * HTTP/1.1 Host: 239.255.255.250:1900 Man: "ssdp:discover" MX: 3 ST: ssdp:all
Got UDP! M-SEARCH * HTTP/1.1 Host: 239.255.255.250:1900 Man: "ssdp:discover" MX: 3 ST: upnp:rootdevice
Responding search req...
Hello from Espalexa!
Value of device 1 (Light 1): 0 Value of device 2 (Light 2): 255 Value of device 3 (Light 3): 128
Free Heap: 43832 Uptime: 277327
Espalexa library v2.3.2 by Christian Schwinne 2019
Any suggestion will be really appreciated
@kenny00869 and @Matz88 does the version 2.2.0 work for you? (you can get it in the Arduino library manager easily).
@kenny00869 it seems like your Echo doesn't send the required M-SEARCH packets with Man: "upnp:rootdevice"
. Sometimes it helps if you start a search for hue devices from the Alexa app or reboot the Echo.
@Matz88 What Echo and ESP are you using? For you, the Echo seems to send the correct discovery packet, but then makes no further requests via HTTP. Can you check that your router has Upnp enabled? Maybe the packet is somehow blocked...
I hope we'll get the library working for both of you!
I already tried before the last version from Arduino, is it by default the 2.2 or do I have to take one older from the history?
I'm using echo dot V3, wemos d1 Mini.
I'm sure we will manage together ;)
No, 2.2.0 is the only version in the library manager at the moment. I added color support recently in 2.2.0 (color is not yet supported by Dots apparently, but on/off/dimming should still work). Before that, version 2.1.2 seemed to cause very few issues, so you could try that while I figure out why 2.2+ doesn't work for you: https://github.com/Aircoookie/Espalexa/tree/f3fcd0f9fc10adf7b9961233e67f4f93815ace2b
With my Echo Dot 2, the discovery and control works well in 2.3.2 (just color support not working). @everyone is there someone else with 2.3.2 working with an Echo Dot?
Unfortunately does not work also with 2.1.2, don't I need to add any skill? or so? any other step that may I have missed?
aha! solved! with latest esp core you shall set LwIP Variant to "v1.4 Higher Bandwidth". You can change it from the Tools menu in the Arduino IDE
Thanks for the feedback! Definitely something to look out for, you wouldn't really expect that setting to cause any issues!
I just cant seem to get an esp8266, Wemos D1 mini clone, to be discovered by with Alexa. I don't have an echo or spot. I have tried discovery with alexa.amazon.com, the Android Alexa app V2.2.250163.0, and a 2nd gen FireTV Stick. I've tried various combinations of the 2.2.0 and 2.3.0 library, 2.3.0 and 2.5.0-beta1 board versions, 1.8.0 and 1.8.9 versions of Arduino IDE. I've set the LwIP Variant to "v1.4 Higher Bandwidth" when it's available. I've limited all devices to a 2.4Ghz network. In the end, I'm able to reach the IP/espalexa page. Connected to testnet IP address: 192.168.1.244 Constructing device 1 Adding device 1 Constructing device 2 Adding device 2 Adding device 3 Espalexa Begin... MAXDEVICES 10 Done Not-Found HTTP call: URI: / Body: AlexaApiCall HTTP Req espalexa ...
Got UDP! NOTIFY * HTTP/1.1 HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=60 LOCATION: http://192.168.1.1:5000/rootDesc.xml SERVER: OpenWRT/OpenWrt UPnP/1.1 MiniUPnPd/2.0 NT: upnp:rootdevice USN: uuid:e630219d-9b35-4139-8d03-c44a1a8e80bc::upnp:rootdevice
Got UDP! M-SEARCH * HTTP/1.1 HOST: 239.255.255.250:1900 MAN: "ssdp:discover" MX: 1 ST: urn:dial-multiscreen-org:service:dial:1 USER-AGENT: Google Chrome/71.0.3578.98 Windows
Is there any known combination of library, board version, board settings, and Arduino version that work?
I don't believe the local hue API Espalexa uses is implemented in the Fire TV stick Alexa. I'm sorry, but it appears a physical Echo device is required for my library to work...
Has anything recently changed w/the Alexa service? I had a working NodeMCU 1.0 using Espalexa and my own example application. Everything was working as I was developing code to control sound on my TV. Then I did too many things at the same time. I slightly altered my code, upgraded my ESP Arduno board support package from 2.4.2 to 2.5.0 & told Amazon / Alexa to forget all my devices in a bid to remove the unused device names. Now, I can only get Alexa to find the devices I have on a HUE Hub emulator running on a RPi. None of the HUE / Espalexa devices have shown up. I've tried many times. I've even downgraded the ESP Arduino board support package back from 2.5.0 to 2.4.2.
@st2000 @Aircoookie I can conform the library is broken now for both ESP8266 and ESP32. Just have a test for both devices, none can be discovered. It used to work very well.
FWIW, I think (don't know for sure because I changed so many things) I was ok until I told Alexa to forget the devices on the ESP. So it may be that the discovery is the only problem and that device operation would have been as expected if I didn't ask Alexa to forget the devices in the 1st place.
It may be many now using Espalexa (or devices on an ESP platform in general) will have the same problem if they tried to re-discover their devices. So... don't "forget" your devices, just in case. Not until this gets all worked out at any rate.
FWIW, I also have HUE Hub running on a RPi and "forgot" and "discovered" those devices w/o any problems during my problems "discovering" devices on the ESP platform.
@st2000 @eos1d3 Seems like the Alexa service changed again... I can confirm your findings, my existing devices can be controlled, but discovery no longer works. Enabling debug mode shows that most of the discovery is still done, ssdp packets are sent, description downloaded, device detail JSON requested. So it's the final stage of the discovery that fails, probably Alexa "dislikes" something about my device details JSON.
{
"state": {
"on": false,
"bri": 254,
"hue": 0,
"sat": 0,
"effect": "none",
"xy": [0.50, 0.50],
"ct": 500,
"alert": "none",
"colormode": "xy",
"mode": "homeautomation",
"reachable": true
},
"type": "Extended color light",
"name": "Stein",
"modelid": "LCT015",
"manufacturername": "Espalexa",
"productname": "E4",
"uniqueid": "DC:4F:22:65:DA:D1-2",
"swversion": "2.4.0"
}
Tomorrow I'll try whether aligning this packet more with the hue packet helps (for example changing manufacturer name). Fortunately the Echo is still sending SSDP packets, so it's likely that this issue is patchable.
Thanks for looking into the @Aircoookie! Is there a way I can see the conversation between my RPi Hue Hub (which appears to be discoverable) and compare that with what the Espalexa is responding with? Sorry for the beginner question. But maybe I can help out.
No problem, I hope to have the library back in a working state as soon as possible! It would be interesting for me to know what your RPI hub responds with when opening the URL [RPi IP]/api/test/lights/1
in your browser. Thank you!
Looks like this:
state:
on: false
bri: 0
hue: 0
sat: 0
effect: "none"
ct: 0
alert: "none"
reachable: true
type: "Dimmable light"
name: "front porch"
modelid: "LWB004"
manufacturername: "Philips"
uniqueid: "00:17:88:5E:D3:01-01"
swversion: "66012040"
Found "Espalexa" in the header file. Changed it to "Philips" and discovered all the missing devices. All my libraries and board support software are at their latest version (i.e. nothing is updateble).
Different problem now. Unfortunately, I can not get Alexa to adjust the value in the call back (i.e. the brightness level). I can set it to different levels at the end of the call back. And Alexa appears to be sending me the different levels. But unaltered. That is unexpected.
So Philips for manufacturername it is. I wanted to avoid this in order to not make the library appear to be an official product or service endorsed by Philips, but if it is required for discovery, this is a sacrifice we need to make. I've updated the swversion field to display espalexa-2.4.2
, so it is still possible to see if a given "Hue hub" is actually an ESP running Espalexa.
Did you try installing EspAsyncTCP and EspAsyncWebServer and then including #define ESPALEXA_ASYNC
before #include <Espalexa.h>
? I believe that you are unable to change the brightness because of #6.
I've made two new interesting findings, by the way! After this change/update all device types are discoverable again (dimmable/color temp/color/extended color), but the EspalexaDeviceType::onoff
cannot be discovered any more. For now I will map the onoff type to the dimmable type internally as a quick fix. The other observation is that sometimes, Alexa says she found no new devices, but the discovery worked regardless and the devices are perfectly controllable after the discovery!
Expect the v2.4.2 release in the next hour! All device types tested and working with ESP8266/32 and Echo and Echo Dot, respectively.
Thanks! But it is strange that Amazon suddenly checks manufacturer name.
I do suggest adding all headers to simulate real Hue if there are missing ones. With this they can't detect any more.
Those products are sold to market. They can't change all firmware of Hue. So I think it is still safe if we have identical response to Amazon.
I agree with you, really strange. Just released v2.4.2, you can check whether it fixes the discovery issue for you as well!
There are still many missing headers, but I'm not adding them until absolutely required, because they are pointless and would be causing quite a large overhead. Here's a sample obtained from my hue bridge (just for one light, so this scales with more lights added):
{
"state": {
"on": false,
"bri": 52,
"hue": 4814,
"sat": 254,
"effect": "none",
"xy": [
0.5934,
0.3819
],
"ct": 153,
"alert": "none",
"colormode": "xy",
"mode": "homeautomation",
"reachable": true
},
"swupdate": {
"state": "noupdates",
"lastinstall": "2018-12-23T13:44:02"
},
"type": "Extended color light",
"name": "Dodekaeder",
"modelid": "LCT015",
"manufacturername": "Philips",
"productname": "Hue color lamp",
"capabilities": {
"certified": true,
"control": {
"mindimlevel": 1000,
"maxlumen": 806,
"colorgamuttype": "C",
"colorgamut": [
[
0.6915,
0.3083
],
[
0.17,
0.7
],
[
0.1532,
0.0475
]
],
"ct": {
"min": 153,
"max": 500
}
},
"streaming": {
"renderer": true,
"proxy": true
}
},
"config": {
"archetype": "sultanbulb",
"function": "mixed",
"direction": "omnidirectional",
"startup": {
"mode": "safety",
"configured": true
}
},
"uniqueid": "00:17:88:01:03:7f:54:41-0b",
"swversion": "1.46.13_r26312",
"swconfigid": "52E3234B",
"productid": "Philips-LCT015-1-A19ECLv5"
}
I can't test right now until next week. But will test for sure.
I do similar hacks for other projects. One crazy server even detect header names and is case sensitive. I mean the header names, not their values. lol That is why I clone everything.
Let's see what will happen later. 😁
On Mon, Apr 15, 2019, 00:01 Aircoookie notifications@github.com wrote:
I agree with you, really strange. Just released v2.4.2, you can check whether it fixes the discovery issue for you as well!
There are still many missing headers, but I'm not adding them until absolutely required, because they are pointless and would be causing quite a large overhead. Here's a sample obtained from my hue bridge (just for one light, so this scales with more lights added):
{ "state": { "on": false, "bri": 52, "hue": 4814, "sat": 254, "effect": "none", "xy": [ 0.5934, 0.3819 ], "ct": 153, "alert": "none", "colormode": "xy", "mode": "homeautomation", "reachable": true }, "swupdate": { "state": "noupdates", "lastinstall": "2018-12-23T13:44:02" }, "type": "Extended color light", "name": "Dodekaeder", "modelid": "LCT015", "manufacturername": "Philips", "productname": "Hue color lamp", "capabilities": { "certified": true, "control": { "mindimlevel": 1000, "maxlumen": 806, "colorgamuttype": "C", "colorgamut": [ [ 0.6915, 0.3083 ], [ 0.17, 0.7 ], [ 0.1532, 0.0475 ] ], "ct": { "min": 153, "max": 500 } }, "streaming": { "renderer": true, "proxy": true } }, "config": { "archetype": "sultanbulb", "function": "mixed", "direction": "omnidirectional", "startup": { "mode": "safety", "configured": true } }, "uniqueid": "00:17:88:01:03:7f:54:41-0b", "swversion": "1.46.13_r26312", "swconfigid": "52E3234B", "productid": "Philips-LCT015-1-A19ECLv5" }
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Aircoookie/Espalexa/issues/38#issuecomment-483005788, or mute the thread https://github.com/notifications/unsubscribe-auth/APlCixehSpo9P8PozmZkuaHGwiG3UrlRks5vg1DUgaJpZM4aLzme .
@Aircoookie , all your suggestions put together work! However (there's always a however), I find it is no longer possible to dependably transmit IR signals from within the call back function. About 50% of the time I see some type of hex dump and / or an indication of a watch dog time out. Setting a flag and transmitting the IR signals outside the call back functions (but within the Arduino loop function) is working cleanly. I suspect the new "async" code is being starved of time should the call back functions do anything significant. Thanks!
I have just tested with ESP32 many times. It did not work again until I reboot my Echo Dot Gen3. After that, it can be discovered for the later tests.
And I am seeing more and more warnings since 2.3.
In file included from .piolibdeps/Espalexa_ID5525/src/Espalexa.h:60:0,
from /Volumes/Macintosh Data/Users/eos1d3/MCU/ESP32/PlatformIO/ESP32_Alexa/src/EspalexaFullyFeatured.ino:13:
.piolibdeps/Espalexa_ID5525/src/EspalexaDevice.h:6:15: warning: 'typedef' was ignored in this declaration
typedef class EspalexaDevice;
^
In file included from /Volumes/Macintosh Data/Users/eos1d3/MCU/ESP32/PlatformIO/ESP32_Alexa/src/EspalexaFullyFeatured.ino:13:0:
.piolibdeps/Espalexa_ID5525/src/Espalexa.h: In member function 'String Espalexa::typeString(EspalexaDeviceType)':
.piolibdeps/Espalexa_ID5525/src/Espalexa.h:102:12: warning: enumeration value 'onoff' not handled in switch [-Wswitch]
switch (t)
^
.piolibdeps/Espalexa_ID5525/src/Espalexa.h: In member function 'String Espalexa::modelidString(EspalexaDeviceType)':
.piolibdeps/Espalexa_ID5525/src/Espalexa.h:114:12: warning: enumeration value 'onoff' not handled in switch [-Wswitch]
switch (t)
^
In file included from /Volumes/Macintosh Data/Users/eos1d3/MCU/ESP32/PlatformIO/ESP32_Alexa/src/EspalexaFullyFeatured.ino:13:0:
.piolibdeps/Espalexa_ID5525/src/Espalexa.h: In destructor 'Espalexa::~Espalexa()':
.piolibdeps/Espalexa_ID5525/src/Espalexa.h:567:22: warning: deleting array '((Espalexa*)this)->Espalexa::devices'
~Espalexa(){delete devices;} //note: Espalexa is NOT meant to be destructed
In file included from .piolibdeps/Espalexa_ID5525/src/EspalexaDevice.cpp:3:0:
.piolibdeps/Espalexa_ID5525/src/EspalexaDevice.h:6:15: warning: 'typedef' was ignored in this declaration
typedef class EspalexaDevice;
^
.piolibdeps/Espalexa_ID5525/src/EspalexaDevice.cpp: In member function 'uint32_t EspalexaDevice::getRGB()':
.piolibdeps/Espalexa_ID5525/src/EspalexaDevice.cpp:114:9: warning: unused variable 'r' [-Wunused-variable]
float r, g, b;
^
.piolibdeps/Espalexa_ID5525/src/EspalexaDevice.cpp:114:12: warning: unused variable 'g' [-Wunused-variable]
float r, g, b;
^
.piolibdeps/Espalexa_ID5525/src/EspalexaDevice.cpp:114:15: warning: unused variable 'b' [-Wunused-variable]
float r, g, b;
.piolibdeps/Espalexa_ID5525/src/EspalexaDevice.cpp:219:42: warning: 'rgb[2]' may be used uninitialized in this function [-Wmaybe-uninitialized]
_rgb = ((rgb[0] << 16) | (rgb[1] << 8) | (rgb[2]));
^
.piolibdeps/Espalexa_ID5525/src/EspalexaDevice.cpp:219:36: warning: 'rgb[1]' may be used uninitialized in this function [-Wmaybe-uninitialized]
_rgb = ((rgb[0] << 16) | (rgb[1] << 8) | (rgb[2]));
^
.piolibdeps/Espalexa_ID5525/src/EspalexaDevice.cpp:219:19: warning: 'rgb[0]' may be used uninitialized in this function [-Wmaybe-uninitialized]
_rgb = ((rgb[0] << 16) | (rgb[1] << 8) | (rgb[2]));
^
Used basic sketch. WiFi connection completed, and sub page shows 3 devices. UPnP is enabled. Echo Dot Gen1, in the U.S. Alexa app does not discover new devices.
Serial with debug: Connecting to WiFi Connecting........ Connected to Raptor17 IP address: 192.168.1.140 Constructing device 1 Adding device 1 Constructing device 2 Adding device 2 Adding device 3 Espalexa Begin... MAXDEVICES 10 Done Got UDP! M-SEARCH * HTTP/1.1 HOST: 239.255.255.250:1900 ST: urn:schemas-upnp-org:device:InternetGatewayDevice:1 MAN: "ssdp:discover" MX: 2
Got UDP! NOTIFY * HTTP/1.1 HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 LOCATION: http://192.168.1.113:49153/nasdevice.xml NT: upnp:rootdevice NTS: ssdp:alive SERVER: Linux/3.2.26, UPnP/1.0, Portable SDK for UPnP devices/1.6.6 X-User-Agent: redson HTTP Req espalexa ...
sub page:
Hello from Espalexa!
Value of device 1 (Light 1): 0 Value of device 2 (Light 2): 255 Value of device 3 (Light 3): 128
Free Heap: 220632 Uptime: 29790
Espalexa library v2.3.2 by Christian Schwinne 2019
Any help greatly appreciated.