Discovery Failure

Posted on
Fri Nov 24, 2017 1:55 pm
alexg offline
Posts: 10
Joined: Apr 01, 2009
Location: Los Altos Hills, CA

Discovery Failure

Can't seem to get Alexa to discover Indigo devices; Running MacOS 10.11.6, Indigo 7.1.1, WiFi connected IMac (192.168.0.217) in the below. Alexa on same WiFi network, in fact same access point. Just trying to discover two devices to start. Startup of the plug-in seems fine, with continuous auto-discovery enabled. No other apps on port 1900:

ov 24, 2017, 11:34:19 AM
Disabling plugin "Alexa-Hue Bridge 3.0.19"
Stopping plugin "Alexa-Hue Bridge 3.0.19" (pid 1178)
Alexa-Hue Bridge Alexa-Hue Bridge shutdown requested
Alexa-Hue Bridge HTTP server stopping...
Alexa-Hue Bridge HTTP server stopped
Stopped plugin "Alexa-Hue Bridge 3.0.19"
Enabling plugin "Alexa-Hue Bridge 3.0.19"
Starting plugin "Alexa-Hue Bridge 3.0.19" (pid 1195)
Alexa-Hue Bridge Alexa-Hue Bridge initialising . . .
Alexa-Hue Bridge Plugin Host IP Address is discovered as: '192.168.0.217'
Alexa-Hue Bridge Alexa discovery request logging enabled
Alexa-Hue Bridge Warning Debugging enabled for Alexa-Hue Bridge: General, Server, Broadcaster, Responder, Method Trace
Started plugin "Alexa-Hue Bridge 3.0.19"
Alexa-Hue Bridge Alexa-Hue Bridge initialization complete
Alexa-Hue Bridge 'Alexa' has 2 Alexa Devices published
Alexa-Hue Bridge Starting Hue Bridge 'Alexa' web server thread
Alexa-Hue Bridge Starting Hue Bridge 'Alexa' discovery thread as 'Auto Start Discovery' requested
Alexa-Hue Bridge Alexa-Hue Bridge 'Alexa' started: Host: 192.168.0.217 Port: 8178
Alexa-Hue Bridge Alexa-Hue Bridge checking network access by attempting to access 'www.google.com'
Alexa-Hue Bridge Alexa-Hue Bridge network access check to www.google.com successfully completed.
Alexa-Hue Bridge Alexa-Hue Bridge checking for Plugin update
Alexa-Hue Bridge Checking for updates...
Alexa-Hue Bridge No updates are available
Alexa-Hue Bridge Alexa-Hue Bridge next update check scheduled for: Saturday, 2017-Nov-25 at 11:34

Below is the log from the plug in after I say "Alexa, discover devices." When the discovery fails Alexa seems to have a hint that we are trying to use the emulated Phillips Hue system, since she says "If you have Phillips Hue press the button on the bridge and rerun discovery." Any idea at all where this is failing? Any ideas greatly accepted.

Marker - Nov 24, 2017, 11:34:50 AM
2017-11-24 11:35:05.970 DEBUG Plugin.responder.run Responder.run: received: M-SEARCH * HTTP/1.1
MX: 3
ST: upnp:rootdevice
HOST: 239.255.255.250:1900
MAN: "ssdp:discover"


2017-11-24 11:35:05.970 DEBUG Plugin.responder.respond Responder.respond called from address ('192.168.0.238', 50000)
HTTP/1.1 200 OK
CACHE-CONTROL: max-age=100
EXT:
LOCATION: http://192.168.0.217:8178/description.xml
SERVER: FreeRTOS/7.4.2, UPnP/1.0, IpBridge/1.7.0
ST: urn:schemas-upnp-org:device:basic:1
USN: uuid:72288317-d143-11e7-9cc6-985aebdf1f49


2017-11-24 11:35:05.971 DEBUG Plugin.responder.respond Responder.respond: creating output_socket
2017-11-24 11:35:05.971 DEBUG Plugin.responder.respond Responder.respond: calling output_socket.sendto
2017-11-24 11:35:05.971 DEBUG Plugin.responder.respond Responder.respond: closing output_socket
2017-11-24 11:35:05.971 DEBUG Plugin.responder.respond Responder.respond: UDP Response sent to ('192.168.0.238', 50000)
2017-11-24 11:35:05.971 DEBUG Plugin.responder.run Responder.run: received: M-SEARCH * HTTP/1.1
MX: 3
ST: ssdp:all
HOST: 239.255.255.250:1900
MAN: "ssdp:discover"


2017-11-24 11:35:05.971 DEBUG Plugin.responder.respond Responder.respond called from address ('192.168.0.238', 50000)
HTTP/1.1 200 OK
CACHE-CONTROL: max-age=100
EXT:
LOCATION: http://192.168.0.217:8178/description.xml
SERVER: FreeRTOS/7.4.2, UPnP/1.0, IpBridge/1.7.0
ST: urn:schemas-upnp-org:device:basic:1
USN: uuid:72288317-d143-11e7-9cc6-985aebdf1f49


2017-11-24 11:35:05.971 DEBUG Plugin.responder.respond Responder.respond: creating output_socket
2017-11-24 11:35:05.971 DEBUG Plugin.responder.respond Responder.respond: calling output_socket.sendto
2017-11-24 11:35:05.971 DEBUG Plugin.responder.respond Responder.respond: closing output_socket
2017-11-24 11:35:05.971 DEBUG Plugin.responder.respond Responder.respond: UDP Response sent to ('192.168.0.238', 50000)
2017-11-24 11:35:06.585 DEBUG Plugin.responder.run Responder.run: received: M-SEARCH * HTTP/1.1
MX: 3
ST: upnp:rootdevice
HOST: 239.255.255.250:1900
MAN: "ssdp:discover"


2017-11-24 11:35:06.585 DEBUG Plugin.responder.respond Responder.respond called from address ('192.168.0.238', 50000)
HTTP/1.1 200 OK
CACHE-CONTROL: max-age=100
EXT:
LOCATION: http://192.168.0.217:8178/description.xml
SERVER: FreeRTOS/7.4.2, UPnP/1.0, IpBridge/1.7.0
ST: urn:schemas-upnp-org:device:basic:1
USN: uuid:72288317-d143-11e7-9cc6-985aebdf1f49


2017-11-24 11:35:06.585 DEBUG Plugin.responder.respond Responder.respond: creating output_socket
2017-11-24 11:35:06.585 DEBUG Plugin.responder.respond Responder.respond: calling output_socket.sendto
2017-11-24 11:35:06.585 DEBUG Plugin.responder.respond Responder.respond: closing output_socket
2017-11-24 11:35:06.585 DEBUG Plugin.responder.respond Responder.respond: UDP Response sent to ('192.168.0.238', 50000)
2017-11-24 11:35:06.585 DEBUG Plugin.responder.run Responder.run: received: M-SEARCH * HTTP/1.1
MX: 3
ST: ssdp:all
HOST: 239.255.255.250:1900
MAN: "ssdp:discover"


2017-11-24 11:35:06.585 DEBUG Plugin.responder.respond Responder.respond called from address ('192.168.0.238', 50000)
HTTP/1.1 200 OK
CACHE-CONTROL: max-age=100
EXT:
LOCATION: http://192.168.0.217:8178/description.xml
SERVER: FreeRTOS/7.4.2, UPnP/1.0, IpBridge/1.7.0
ST: urn:schemas-upnp-org:device:basic:1
USN: uuid:72288317-d143-11e7-9cc6-985aebdf1f49


2017-11-24 11:35:06.585 DEBUG Plugin.responder.respond Responder.respond: creating output_socket
2017-11-24 11:35:06.585 DEBUG Plugin.responder.respond Responder.respond: calling output_socket.sendto
2017-11-24 11:35:06.585 DEBUG Plugin.responder.respond Responder.respond: closing output_socket
2017-11-24 11:35:06.585 DEBUG Plugin.responder.respond Responder.respond: UDP Response sent to ('192.168.0.238', 50000)
2017-11-24 11:35:06.905 DEBUG Plugin.server.handle HttpdRequestHandler.handle invoked for 'Alexa' with data:
GET /description.xml HTTP/1.1
Host: 192.168.0.217:8178
Connection: Keep-Alive
User-Agent: Android/5.1.1 UPnP/1.0 Cling/2.0




2017-11-24 11:35:06.909 DEBUG Plugin.server.send_headers HttpdRequestHandler.send_headers: Sent content type: application/xml
2017-11-24 11:35:06.910 DEBUG Plugin.server.get_response hue_listener.get_response for 'Alexa', request string: /description.xml
2017-11-24 11:35:06.910 DEBUG Plugin.server.get_response hue_listener.get_response request file: /description.xml
2017-11-24 11:35:06.911 DEBUG Plugin.server.get_response hue_listener.get_response for 'Alexa', serving from a local file: /description.xml
2017-11-24 11:35:06.911 DEBUG Plugin.server.get_response hue_listener.get_response for 'Alexa', returning file description.xml with data:
<?xml version="1.0"?>
<root xmlns="urn:schemas-upnp-org:device-1-0">
<specVersion>
<major>1</major>
<minor>0</minor>
</specVersion>
<URLBase>http://192.168.0.217:8178/</URLBase>
<device>
<deviceType>urn:schemas-upnp-org:device:Basic:1</deviceType>
<friendlyName>Alexa Hue Bridge</friendlyName>
<manufacturer>Royal Philips Electronics</manufacturer>
<manufacturerURL>http://www.philips.com</manufacturerURL>
<modelDescription>Philips hue Personal Wireless Lighting</modelDescription>
<modelName>Philips hue bridge 2012</modelName>
<modelNumber>929000226503</modelNumber>
<modelURL>http://www.meethue.com</modelURL>
<serialNumber>001788101fe2</serialNumber>
<UDN>uuid:72288317-d143-11e7-9cc6-985aebdf1f49</UDN>
<presentationURL>index.html</presentationURL>
<iconList>
<icon>
<mimetype>image/png</mimetype>
<height>48</height>
<width>48</width>
<depth>24</depth>
<url>hue_logo_0.png</url>
</icon>
<icon>
<mimetype>image/png</mimetype>
<height>120</height>
<width>120</width>
<depth>24</depth>
<url>hue_logo_3.png</url>
</icon>
</iconList>
</device>
</root>

2017-11-24 11:35:06.932 DEBUG Plugin.server.handle HttpdRequestHandler.handle invoked for 'Alexa' with data:
GET /description.xml HTTP/1.1
Content-Type: application/json
User-Agent: Dalvik/2.1.0 (Linux; U; Android 5.1.1; AEORD Build/LVY48F)
Host: 192.168.0.217:8178
Connection: Keep-Alive
Accept-Encoding: gzip




2017-11-24 11:35:06.932 DEBUG Plugin.server.send_headers HttpdRequestHandler.send_headers: Sent content type: application/xml
2017-11-24 11:35:06.933 DEBUG Plugin.server.get_response hue_listener.get_response for 'Alexa', request string: /description.xml
2017-11-24 11:35:06.933 DEBUG Plugin.server.get_response hue_listener.get_response request file: /description.xml
2017-11-24 11:35:06.933 DEBUG Plugin.server.get_response hue_listener.get_response for 'Alexa', serving from a local file: /description.xml
2017-11-24 11:35:06.934 DEBUG Plugin.server.get_response hue_listener.get_response for 'Alexa', returning file description.xml with data:
<?xml version="1.0"?>
<root xmlns="urn:schemas-upnp-org:device-1-0">
<specVersion>
<major>1</major>
<minor>0</minor>
</specVersion>
<URLBase>http://192.168.0.217:8178/</URLBase>
<device>
<deviceType>urn:schemas-upnp-org:device:Basic:1</deviceType>
<friendlyName>Alexa Hue Bridge</friendlyName>
<manufacturer>Royal Philips Electronics</manufacturer>
<manufacturerURL>http://www.philips.com</manufacturerURL>
<modelDescription>Philips hue Personal Wireless Lighting</modelDescription>
<modelName>Philips hue bridge 2012</modelName>
<modelNumber>929000226503</modelNumber>
<modelURL>http://www.meethue.com</modelURL>
<serialNumber>001788101fe2</serialNumber>
<UDN>uuid:72288317-d143-11e7-9cc6-985aebdf1f49</UDN>
<presentationURL>index.html</presentationURL>
<iconList>
<icon>
<mimetype>image/png</mimetype>
<height>48</height>
<width>48</width>
<depth>24</depth>
<url>hue_logo_0.png</url>
</icon>
<icon>
<mimetype>image/png</mimetype>
<height>120</height>
<width>120</width>
<depth>24</depth>
<url>hue_logo_3.png</url>
</icon>
</iconList>
</device>
</root>

2017-11-24 11:35:06.994 DEBUG Plugin.responder.run Responder.run: received: M-SEARCH * HTTP/1.1
MX: 3
ST: upnp:rootdevice
HOST: 239.255.255.250:1900
MAN: "ssdp:discover"


2017-11-24 11:35:06.994 DEBUG Plugin.responder.respond Responder.respond called from address ('192.168.0.238', 50000)
HTTP/1.1 200 OK
CACHE-CONTROL: max-age=100
EXT:
LOCATION: http://192.168.0.217:8178/description.xml
SERVER: FreeRTOS/7.4.2, UPnP/1.0, IpBridge/1.7.0
ST: urn:schemas-upnp-org:device:basic:1
USN: uuid:72288317-d143-11e7-9cc6-985aebdf1f49


2017-11-24 11:35:06.994 DEBUG Plugin.responder.respond Responder.respond: creating output_socket
2017-11-24 11:35:06.994 DEBUG Plugin.responder.respond Responder.respond: calling output_socket.sendto
2017-11-24 11:35:06.995 DEBUG Plugin.responder.respond Responder.respond: closing output_socket
2017-11-24 11:35:06.995 DEBUG Plugin.responder.respond Responder.respond: UDP Response sent to ('192.168.0.238', 50000)
2017-11-24 11:35:06.995 DEBUG Plugin.responder.run Responder.run: received: M-SEARCH * HTTP/1.1
MX: 3
ST: ssdp:all
HOST: 239.255.255.250:1900
MAN: "ssdp:discover"


2017-11-24 11:35:06.995 DEBUG Plugin.responder.respond Responder.respond called from address ('192.168.0.238', 50000)
HTTP/1.1 200 OK
CACHE-CONTROL: max-age=100
EXT:
LOCATION: http://192.168.0.217:8178/description.xml
SERVER: FreeRTOS/7.4.2, UPnP/1.0, IpBridge/1.7.0
ST: urn:schemas-upnp-org:device:basic:1
USN: uuid:72288317-d143-11e7-9cc6-985aebdf1f49


2017-11-24 11:35:06.995 DEBUG Plugin.responder.respond Responder.respond: creating output_socket
2017-11-24 11:35:06.995 DEBUG Plugin.responder.respond Responder.respond: calling output_socket.sendto
2017-11-24 11:35:06.995 DEBUG Plugin.responder.respond Responder.respond: closing output_socket
2017-11-24 11:35:06.995 DEBUG Plugin.responder.respond Responder.respond: UDP Response sent to ('192.168.0.238', 50000)
2017-11-24 11:35:07.609 DEBUG Plugin.responder.run Responder.run: received: M-SEARCH * HTTP/1.1
MX: 3
ST: upnp:rootdevice
HOST: 239.255.255.250:1900
MAN: "ssdp:discover"


2017-11-24 11:35:07.609 DEBUG Plugin.responder.respond Responder.respond called from address ('192.168.0.238', 50000)
HTTP/1.1 200 OK
CACHE-CONTROL: max-age=100
EXT:
LOCATION: http://192.168.0.217:8178/description.xml
SERVER: FreeRTOS/7.4.2, UPnP/1.0, IpBridge/1.7.0
ST: urn:schemas-upnp-org:device:basic:1
USN: uuid:72288317-d143-11e7-9cc6-985aebdf1f49


2017-11-24 11:35:07.609 DEBUG Plugin.responder.respond Responder.respond: creating output_socket
2017-11-24 11:35:07.609 DEBUG Plugin.responder.respond Responder.respond: calling output_socket.sendto
2017-11-24 11:35:07.609 DEBUG Plugin.responder.respond Responder.respond: closing output_socket
2017-11-24 11:35:07.609 DEBUG Plugin.responder.respond Responder.respond: UDP Response sent to ('192.168.0.238', 50000)
2017-11-24 11:35:07.609 DEBUG Plugin.responder.run Responder.run: received: M-SEARCH * HTTP/1.1
MX: 3
ST: ssdp:all
HOST: 239.255.255.250:1900
MAN: "ssdp:discover"


2017-11-24 11:35:07.609 DEBUG Plugin.responder.respond Responder.respond called from address ('192.168.0.238', 50000)
HTTP/1.1 200 OK
CACHE-CONTROL: max-age=100
EXT:
LOCATION: http://192.168.0.217:8178/description.xml
SERVER: FreeRTOS/7.4.2, UPnP/1.0, IpBridge/1.7.0
ST: urn:schemas-upnp-org:device:basic:1
USN: uuid:72288317-d143-11e7-9cc6-985aebdf1f49


2017-11-24 11:35:07.609 DEBUG Plugin.responder.respond Responder.respond: creating output_socket
2017-11-24 11:35:07.609 DEBUG Plugin.responder.respond Responder.respond: calling output_socket.sendto
2017-11-24 11:35:07.609 DEBUG Plugin.responder.respond Responder.respond: closing output_socket
2017-11-24 11:35:07.610 DEBUG Plugin.responder.respond Responder.respond: UDP Response sent to ('192.168.0.238', 50000)
2017-11-24 11:35:08.018 DEBUG Plugin.responder.run Responder.run: received: M-SEARCH * HTTP/1.1
MX: 3
ST: upnp:rootdevice
HOST: 239.255.255.250:1900
MAN: "ssdp:discover"


2017-11-24 11:35:08.018 DEBUG Plugin.responder.respond Responder.respond called from address ('192.168.0.238', 50000)
HTTP/1.1 200 OK
CACHE-CONTROL: max-age=100
EXT:
LOCATION: http://192.168.0.217:8178/description.xml
SERVER: FreeRTOS/7.4.2, UPnP/1.0, IpBridge/1.7.0
ST: urn:schemas-upnp-org:device:basic:1
USN: uuid:72288317-d143-11e7-9cc6-985aebdf1f49


2017-11-24 11:35:08.018 DEBUG Plugin.responder.respond Responder.respond: creating output_socket
2017-11-24 11:35:08.018 DEBUG Plugin.responder.respond Responder.respond: calling output_socket.sendto
2017-11-24 11:35:08.018 DEBUG Plugin.responder.respond Responder.respond: closing output_socket
2017-11-24 11:35:08.019 DEBUG Plugin.responder.respond Responder.respond: UDP Response sent to ('192.168.0.238', 50000)
2017-11-24 11:35:08.019 DEBUG Plugin.responder.run Responder.run: received: M-SEARCH * HTTP/1.1
MX: 3
ST: ssdp:all
HOST: 239.255.255.250:1900
MAN: "ssdp:discover"


2017-11-24 11:35:08.019 DEBUG Plugin.responder.respond Responder.respond called from address ('192.168.0.238', 50000)
HTTP/1.1 200 OK
CACHE-CONTROL: max-age=100
EXT:
LOCATION: http://192.168.0.217:8178/description.xml
SERVER: FreeRTOS/7.4.2, UPnP/1.0, IpBridge/1.7.0
ST: urn:schemas-upnp-org:device:basic:1
USN: uuid:72288317-d143-11e7-9cc6-985aebdf1f49


2017-11-24 11:35:08.019 DEBUG Plugin.responder.respond Responder.respond: creating output_socket
2017-11-24 11:35:08.019 DEBUG Plugin.responder.respond Responder.respond: calling output_socket.sendto
2017-11-24 11:35:08.019 DEBUG Plugin.responder.respond Responder.respond: closing output_socket
2017-11-24 11:35:08.019 DEBUG Plugin.responder.respond Responder.respond: UDP Response sent to ('192.168.0.238', 50000)

--AlexG

Posted on
Fri Nov 24, 2017 2:48 pm
autolog offline
Posts: 3988
Joined: Sep 10, 2013
Location: West Sussex, UK [GMT aka UTC]

Re: Discovery Failure

Hi AlexG,

I can't see any messages in the log that appear to come from an Amazon Echo.

Is this the first time you have installed the plugin i.e. is it a new install?
What type of Alexa device are you using?
If not a new install, have the devices been defined before and if so have you forgotten the devices by logging into your Alexa account via a web browser prior to doing the discovery - this may help?

You could try changing the port to say 8188 and then do a discovery again.

Posted on
Fri Nov 24, 2017 3:48 pm
alexg offline
Posts: 10
Joined: Apr 01, 2009
Location: Los Altos Hills, CA

Re: Discovery Failure

Yes, fresh install of the V3 plug in. Brand new Echo as well. So no devices to forget.

You note that you don't see anything from the Echo, but the log messages I note below came *immediately* after I said "Alexa, discover devices" and I believe 192.168.0.238 is indeed the Echo (Mac being 192.168.0.217). What else would generate this log message stream from the plug-in?

Will try changing port to 8188.

--AlexG

Posted on
Fri Nov 24, 2017 3:57 pm
alexg offline
Posts: 10
Joined: Apr 01, 2009
Location: Los Altos Hills, CA

Re: Discovery Failure

Rebooted Mac, restarted Indigo, restarted plug-in with new port. And for good measure restarted the Echo. Same result:

Lots of plug-in log activity, no device discovery.

--AlexG

Posted on
Sat Nov 25, 2017 10:05 am
autolog offline
Posts: 3988
Joined: Sep 10, 2013
Location: West Sussex, UK [GMT aka UTC]

Re: Discovery Failure

Hi AlexG,
I have analysed this a bit further and I think it is an issue with Discovery with Echo (version 2) devices. We have had recent previous post on this. :|

I have today ordered a new Echo (Version 2) so that I can do further testing and see how we can get round this. This is scheduled for delivery by end of day next Tuesday. So expect some feedback later next week. :)

Posted on
Sat Nov 25, 2017 10:39 pm
jay (support) offline
Site Admin
User avatar
Posts: 18199
Joined: Mar 19, 2008
Location: Austin, Texas

Re: Discovery Failure

Do you have 2 network interfaces active (WiFi and ethernet perhaps)? That can cause issues.

Jay (Indigo Support)
Twitter | Facebook | LinkedIn

Posted on
Tue Nov 28, 2017 9:22 am
devros offline
Posts: 30
Joined: Oct 04, 2005

Re: Discovery Failure

Having exactly the same issue. New install of the plugin, new Echo v2. Only one interface(ethernet) is active.

Posted on
Tue Nov 28, 2017 9:40 am
autolog offline
Posts: 3988
Joined: Sep 10, 2013
Location: West Sussex, UK [GMT aka UTC]

Re: Discovery Failure

I have now received my 2nd Gen Echo and I am also having the issue when discovering using the new Echo. :|

It will respond to voice commands for already discovered devices (via a 1st Gen Echo). So that is one work-around for those who have both generations of Echos i.e. do discovery using a Gen 1 device.

In the meanwhile I have installed Wireshark network sniffer to try and determine the differences between the two generations. This presents me with a bit of a challenge as I have to learn how to use Wireshark and then how to interpret the results. I have started this process. :wink:

I have read elsewhere on the interweb that the new 2nd Generation Echos expect the hue Hub to be using port 80. If this is the case it could be a bit problematic as it is such a common port used by web servers etc. It might be worth trying to set the port to 80 and see if that works? I haven't been able to prove or disprove this yet as I am running Apple server (which uses port 80) on both my production and development Apple Macs. These other references to Gen 2 Echo problems (with other Hue bridge software) would seem to indicate that the issue is wider than just an issue with the Alexa-Hue Bridge plugin. :|

In the meanwhile I will continue to pursue Wireshark to try and understand what is going on. :)

Posted on
Tue Nov 28, 2017 10:36 am
jay (support) offline
Site Admin
User avatar
Posts: 18199
Joined: Mar 19, 2008
Location: Austin, Texas

Re: Discovery Failure

I think you may run into an issue trying to use port 80 - macOS has some permission checking around lower-numbered ports and that might block the plugin from opening the port without explicit permission from the user. Certainly give it a try - just wanted to point out that may be a problem.

Jay (Indigo Support)
Twitter | Facebook | LinkedIn

Posted on
Tue Nov 28, 2017 11:41 am
autolog offline
Posts: 3988
Joined: Sep 10, 2013
Location: West Sussex, UK [GMT aka UTC]

Re: Discovery Failure

One thought I had is whether using NAT (Network Address Translation) to receive on port 80 and then route it to say e.g. 8178. So the plugin could tell the Echo to use Port 80 but accept incoming on e.g. 8178.

If the port 80 is a requirement for 2nd Gen devices then that presents another problem in that we were using the port number to determine which Alexa-Hue Bridge device the incoming Alexa command was for. The only way that I have thought to get round this (untested) is to define multiple IP addresses on the network adapter (can be done via System Settings) and again use NAT to route and change the port number. Then it would be easy enough to determine the Alexa-Hue Bridge by IP number.

Unfortunately, once we get into using NAT, defining multiple IP addresses the level of complexity for the average user is probably going to be unacceptable. Also it is likely going to throw up a load more support issues. :|

I'll see how I get on Wiresharking. :)

Posted on
Wed Nov 29, 2017 9:46 am
devros offline
Posts: 30
Joined: Oct 04, 2005

Re: Discovery Failure

Interesting bit of intel here. Discovery still fails with a 2nd gen Echo, but does work if you do it with a 2nd generation Echo Dot.

Posted on
Wed Nov 29, 2017 10:08 am
devros offline
Posts: 30
Joined: Oct 04, 2005

Re: Discovery Failure

Also, you can only control it with the Dot. If I have that unplugged and just the regular Echo plugged in, it won't work.

Posted on
Wed Nov 29, 2017 11:01 am
CliveS offline
Posts: 761
Joined: Jan 10, 2016
Location: Medomsley, County Durham, UK

Re: Discovery Failure

devros wrote:
Interesting bit of intel here. Discovery still fails with a 2nd gen Echo, but does work if you do it with a 2nd generation Echo Dot.


That is good news as I have a 2nd gen Dot just arrived from Amazon that I now need to setup. I will have to read up on installing the Alexa plugin.

CliveS

Indigo 2023.2.0 : macOS Ventura 13.6.3 : Mac Mini M2 : 8‑core CPU and 10‑core GPU : 8 GB : 256GB SSD
----------------------------------------------------------------------------------
The best way to get the right answer on the Internet is not to ask a question, it's to post the wrong answer

Posted on
Wed Nov 29, 2017 12:36 pm
autolog offline
Posts: 3988
Joined: Sep 10, 2013
Location: West Sussex, UK [GMT aka UTC]

Re: Discovery Failure

devros wrote:
Also, you can only control it with the Dot. If I have that unplugged and just the regular Echo plugged in, it won't work.


That's very interesting info. :)

I have 5 devices enabled. I ran a test where I switched off two Echo's and a Dot in various rooms, just leaving a new Gen 2 Echo (named Alexa) and Gen 1 dot (named Echo) on in my Study. Asking either of those devices to turn on/off devices failed with "device not responding". I turned on the other two Echo's and still no response. I then turned on the Dot that I originally turned off and then I could issue commands on the Echo and Dot in my Study.

I need to do more testing of this to see if I can analyse a pattern but it is quite confusing at the moment. :?

Posted on
Thu Nov 30, 2017 12:24 pm
autolog offline
Posts: 3988
Joined: Sep 10, 2013
Location: West Sussex, UK [GMT aka UTC]

Re: Discovery Failure

I thought I better give an update as I am not making much headway with this - the Echo Gen 2 just isn't asking for the devices when discovery is invoked. It seems to proceed as normal up to the point it should ask for the devices and the plugin receives nothing. Wireshark indicates that nothing is received from the device. :|

Not quite sure where to go with this now. :?:

I will see if I can make the port 80 work but this may be a red herring.

What I have found interesting during testing using Wireshark is that you can ask an Echo Dot to turn on a lamp and the the return request coming through to the plugin to request the action can come from a different Echo Dot or Echo (depends how many Alexa devices you have). :?

I will post an update if and when I discover more. :)

Who is online

Users browsing this forum: No registered users and 0 guests