No discovery without physical Echo #38
Comments
|
I wasn't very clear, but running on a LOLIN D32 Pro. |
|
Similar issue also here: Connecting to WiFi Got UDP! Responding search req... Got UDP! Responding search req... Got UDP! Responding search req... Hello from Espalexa! Value of device 1 (Light 1): 0 Free Heap: 43832 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 @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). |
|
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. Got UDP! Got UDP! 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? |
|
@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. {
"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 |
|
Looks like this: |
|
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 Did you try installing EspAsyncTCP and EspAsyncWebServer and then including 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 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 ***@***.***> 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
<#38 (comment)>,
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. And I am seeing more and more warnings since 2.3. |
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.
The text was updated successfully, but these errors were encountered: