-
Notifications
You must be signed in to change notification settings - Fork 199
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Alexa Discovery Issues - Need to understand discovery process a bit more #1161
Comments
So, mDNS is in the ha-bridge, but I believe Alexa Echo does not support that. Please turn on traceupnp in the Bridge Control Settings and then do a discover after that. Please post the log. Include the IPs of the alexa and the ha-bridge. |
Did you see the (2) in the discovery guide above, where the url https://discovery.meethue.com is used to get bridge info? Also all the examples are using https. No idea which of these Amazon is using, but possibly (2) and not getting bridge ID? Here is my log, I'm afraid there is nothing useful, there is no local request from any Amazon device. I have tried gen 2, gen 3 and iOS App for discovery. This log is starting discovery from a gen2 Bridge: 10.134.10.124
|
So, I assume you did an Alexa discovery through this log. Since there is no log of receiving any UPNP SSDP Search messages from the Alexa or any devices (which is wierd) there may be an issue with your network settings. Did those change recently? Since you are looking at network packets, can you see the SSDP messages from the Alexa? P.S. |
OK, so looking at above log, I can see no traffic from Echo to bridge. Digging a little deeper, I confirmed this with tcpdump in the Pi runng habridge on the LAN
I have done some network traces and the Alexa is doing a SSDP multicast on the WLAN (as per developer doc above option (1)), but this is not arriving on LAN. It seems SSDP using address 239.255.255.250 is not traversing LAN <--> WLAN for some reason. I'm still looking into what is blocking the SSDP. I will get a USB wifi Pi adapter and attach to WLAN to confirm discovery of habridge is still working. |
Did you have any updates to your router firmware? Were there any updates to the firewall on your Pi? |
One thing I’ve noticed while tracing upnp traffic during discovery is that on 5.3, the bridge responds with 0.0.0.0:80 as the address. When rolling back to 5.1 the configured address is used in response. Maybe this is just a logging issue, but 5.1 consistently allows device discovery while 5.3 never does. Also, 5.3 never logs receiving any Alexa discovery requests. |
I too just found out that Alexa is no longer discovering new devices. Existing devices are showing as offline, but they are still working. I've not tested new device discovery in 5 months, until now. Log attached. |
I was reading through some of the Home Assistant forum and they’ve had the exact same issue. I skimmed through the thread but it sounds like they implemented a solution recently for the discovery and the “doesn’t support requested value” issue. Thanks Amazon. |
I 'discovered' same :) however in my case the reason 5.3 didn't log any requests was because it didn't receive any requests. What I have learnt so far: Initiating a discovery from Alexa will cause all the Alexa devices to send a SSDP multicast using destination ip address 239.255.255.250. Using tcpdump on my Pi connected to Ethernet, I did not see any of these requests from the Alexas connected to wifi. For some reason, that I don't fully understand (yet), these multicasts were not traversing from my wifi network to lan. I understand this is due to something called IGMP snooping: https://en.wikipedia.org/wiki/Internet_Group_Management_Protocol Some network devices (switches, routers, accesspoints?) implement this to create a multicast group to restrict multicast traffic to only those devices on the network that are interested in it. If this network is not working correctly, the SSDP multicasts will not be received on the habridge. There is a very easy way to test this if your habridge is running on a Pi on lan, use tcpdump with the multicast address from your Pi
You should see 3 SSDP requests from each Alexa on your network. If you dont see these, there is something wrong with your network, and you will need to figure out what, before looking at habridge logs. Restarting Pi, switches, access points, routers, Alexa's may help. Another solution is a wifi usb adapter for your Pi, so the Pi/habridge and Alexa(s) are all on wifi. If you see these SSDP requests in tcpdump, then you can dive a little deeper in habridge logs. HTH |
Just had a quick scan through your log, as you can see, you are getting the 3 SSDP requests from each of your Alexa devices, some IPs not listed in your summary at top? I would suggest disconnecting all bar one, and then initiating a discovery. |
Just a hint: you could try to have a look on the code from release 4.x.x and what has changed to the current 5.x.x release from habridge. I tried all the suggested solutions: The (simple) solution was: So, at the moment i'll keep the (old) 4.5.6-release running... :-) |
@Huibuh1111: you are completely right. For month I also did everything what had been discussed and suggested here without any success. Now after downgrading to 4.5.6 it works like a charm again. Thanks a lot :-) |
Got a new Echo for Christmas and added to my network (I previously just had 3 Echo Dots). When I went to try my lights on the new Echo they did not work. I checked the setup in the Alexa App and all my devices from HA Bridge are missing. I went to the HA Bridge on my Pi and removed all the ones I had and then added them again and tried to do the discovery. But Alexa is not finding the devices now. I had an issue before Christmas when I tried to add a single new x10 device - it was added OK to HA Bridge but Alexa did not find it. Then today I noticed all of them were missing. The devices are in HA Bridge and they work (I am using HA Bridge with HomeGenie on a Pi X10 Hub). I can turn them on via HA Bridge - just cannot get Alexa to discover the devices again. Any suggestions ? |
Same here, has to be a problem in habridge. The only way to recognise new devices is to remove all devices from alexa manually, renumber the device id's in habridge en discover again. This is a pain in the ass because you will lose all the routines you made for alexa.. Has to be in habridge, i think i will be going to do the same thing as MasterRay2.. downgrade to 4.5.6. Unless there will be a fix soon offcourse. |
For all: The new Release Candidate is out for testing.... https://github.com/bwssytems/ha-bridge/releases/tag/v5.3.1RC1 Please post your issues or successes at #1192 |
I have updated my previously working config to 5.3.1 and it still cannot discover devices, I have noticed this in all 5.x updates. I have 2 fire tvs v2 and 1 echo dot original and none of their discoveries work |
HABridge been fine for almost a year, since fixing the port 80 issue:
#1022 (comment)
I recently tried to add a new device, but Alexa wont discover. Deleted all devices, upgraded to 5.3.0, renumber, still no discovery.
I can see the SSDP broadcasts from the HAbridge on the network, but Alexa Gen2, Gen3 or Alexa iOS APP will not discover the HAbridge. There is no request from the Alexa devices to the HAbridge. I am wondering if Amazon has changed how they are now discovering the Hue?
I have been reading this:
https://developers.meethue.com/develop/application-design-guidance/hue-bridge-discovery/
"All our bridges support UPnP, but it is advised to move to using mDNS and N-UPnP as that will be faster, mDNS is supported by more devices, and we only use a subset of the UPnP protocol (SSDP). "
The text was updated successfully, but these errors were encountered: