Discovery Failure

Posted on
Sat Dec 30, 2017 6:45 am
autolog offline
Posts: 3235
Joined: Sep 10, 2013
Location: West Sussex, UK [GMT+1 aka UTC+1]

Re: Discovery Failure

RAID5 wrote:
Thanks for your help, I thought I needed to use the skill, I just asked Alexa to discover devices and they were found. Now it rocks!! Thanks again!!

Great - pleased it is now working for you. :D

Posted on
Tue Jan 09, 2018 2:09 am
gmoeller offline
Posts: 20
Joined: Jun 03, 2016
Location: Cologne, Germany

Re: Discovery Failure

Hi,

Santa brought me an Amazon Echo Gen2 for Christmas and I tried to make it work with the Alexa-Hue plugin. As already mentioned by others, the discovery process is not discovering anything besides the native HUE devices.

Maybe I missed that bit in the discussion but if I buy an Echo Dot and do the discovery procedure with the Echo Dot, would afterwards all devices be accessible by the Echo Gen2 as well?
Or only with the Dot?

Thanks a lot in advance!

Guido

Posted on
Tue Jan 09, 2018 6:00 am
autolog offline
Posts: 3235
Joined: Sep 10, 2013
Location: West Sussex, UK [GMT+1 aka UTC+1]

Re: Discovery Failure

Hi Guido,
gmoeller wrote:
... if I buy an Echo Dot and do the discovery procedure with the Echo Dot, would afterwards all devices be accessible by the Echo Gen2 as well? ...

I haven't got a Gen 2 Echo Dot but others have reported it discovers OK. I have got a Gen2 Echo and that won't discover but it does respond to commands as long as the Echo Dot is connected.

I am just in the final stages of testing a change to the Alexa-Hue Bridge plugin. This change will enable you to define additional devices of type "Amazon Echo" for each of your real Echo devices. The device is very simple you just name it as normal and in device settings specify the Echo's IP address. Once the devices are set-up it facilitates extra visibility of what is going on in the Plugin. When you issue a command to an Echo e.g "Alexa turn on dining lamp", the plugin will report this request with the additional detail of the name and port the request came from. In addition the Echo devices status in Indigo will change from No Activity to Active and the associated coloured dot from grey to green (for 15 seconds).

With this change, I can see that for the most part, whatever Alexa device I ask to do something, it is always the Echo Dot in my study that is issuing the command to Indigo. :)

Posted on
Sat Jan 13, 2018 10:50 pm
tshort offline
Posts: 2
Joined: Jan 07, 2018

Re: Discovery Failure

I have been trying to get this to work all night, until I found this thread. Yes, we just got a Gen 2 Echo.

The first problem I thought I had was that when I created two "virtual hubs", I had two listeners on port 1900, which I wasn't sure would work.

Code: Select all
$ lsof -i :1900
COMMAND    PID   USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
IndigoPlu 1280 tshort   10u  IPv4 0x42d8f365c1781ae1      0t0  UDP *:ssdp
IndigoPlu 1280 tshort   13u  IPv4 0x42d8f365c1782041      0t0  UDP *:ssdp
$

After removing one of the hubs, I only had one listener.
I am noticing that my Echo is attempting to connect to the port configured for the virtual hub:

Code: Select all
$ netstat -na | grep 8180
tcp4       0      0  192.168.1.2.8180       *.*                    LISTEN     
tcp4       0      0  192.168.1.2.8180       192.168.1.169.43542    TIME_WAIT 
tcp4       0      0  192.168.1.2.8180       192.168.1.169.52983    TIME_WAIT 
tcp4       0      0  192.168.1.2.8180       192.168.1.184.62481    TIME_WAIT 
$

Where 192.168.1.169 is my Amazon Echo. So, the Echo is accepting the uPnP responses from the plugin and attempting to connect to the 8180 port that I specified.
However, a subsequent request to port 80 also occurs, and subsequently fails (see later), this agrees with previous posts about attempting to connect to port 80, which would be a problem for those with web services on our machines.

Here is that request to port 8180:
Code: Select all
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.1.2:8180
Connection: Keep-Alive
Accept-Encoding: gzip

HTTP/1.1 200 OK
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Content-type: application/xml

<?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.1.2:8180/</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:8ecc3e54-f8b2-11e7-924f-a820662e4fb4</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>

Echo request to port 80:

Code: Select all
POST /api 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.1.2
Connection: Keep-Alive
Accept-Encoding: gzip
Content-Length: 22

{"devicetype": "Echo"}

HTTP/1.1 503 Service Unavailable
Date: Sun, 14 Jan 2018 04:39:54 GMT
Server: Apache/2.4.28 (Unix) LibreSSL/2.2.7
Content-Location: websitesoff403.html.en
Vary: negotiate,accept-language
TCN: choice
Last-Modified: Wed, 20 Sep 2017 20:17:40 GMT
ETag: "631-559a4aae20100;561f69eb40400"
Accept-Ranges: bytes
Content-Length: 1585
Cache-Control: no-cache
Connection: close
Content-Type: text/html
Content-Language: en

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

/* HTML follows */

Posted on
Thu Jan 18, 2018 10:26 am
jtburgess offline
User avatar
Posts: 43
Joined: Jan 17, 2018
Location: NJ

Re: Discovery Failure

I am having a slightly different problem -- it seems the UPNP/SSDP multicast packets are being ignored.
My configuration:
Indigo 7.1.0 with the ALexa-Hue-Bridge 3.0.20, on a Mac Mini running High Sierra, wired ethernet with static IP address
new Amazon Echo, device software version 595530420 whatever that means
wireshark running on the same Wireless network as the Echo (I have 3 base stations; the one they are both connected to is an Airport Express)

Wireshark sees multicast SSDP packets from both the Echo (M-SEARCH) AND the Mac Mini (NOTIFY).
FWIW, I also see SSDP multicast from a Linksys router/wireless base station. Those seem to be just about its own auto-config/UPNP capabilities.
I don't know how SSDP is supposed to work. Is there something missing?

I see no direct traffic between the MacMini and the Echo in either direction. Should I? or is it all multicast?

Posted on
Thu Jan 18, 2018 10:50 am
autolog offline
Posts: 3235
Joined: Sep 10, 2013
Location: West Sussex, UK [GMT+1 aka UTC+1]

Re: Discovery Failure

It seems that the Echo (Gen2) doesn't work. It isn't only this plugin, other implementations for other systems have the same issue. Gen 2 Echo Dots do work AFAIK. Once the devices are discovered, the Gen 2 Echo should work for controlling devices. :|

Posted on
Fri Jan 19, 2018 5:16 pm
jtburgess offline
User avatar
Posts: 43
Joined: Jan 17, 2018
Location: NJ

Re: Discovery Failure (echo doesnt work)

autolog wrote:
It seems that the Echo (Gen2) doesn't work. ... Gen 2 Echo Dots do work AFAIK. ....


So I guess my options are to either wait for Amazon to fix the Echo or go buy a Dot.
Sigh.

Thanks for the info!

Posted on
Thu Mar 08, 2018 12:18 pm
jtburgess offline
User avatar
Posts: 43
Joined: Jan 17, 2018
Location: NJ

Re: HUE Discovery Failure

I contacted Amazon/Alexa Support and they said:

I'm sorry about the issue with connecting your Hue bridge via Echo device.
Upon checking, I've found that currently we are not facing any issue with connecting the Hue bridge with Echo device.
I apologies for the any miscommunication happened with previous conversation.
Since in this case, I request you to follow the below steps, to connect the Hue bridge:
Philips smart home devices with the V1 Hue Bridge (circle-shaped) are only compatible with:
- Amazon Echo (1st Generation)
- Amazon Echo (2nd Generation)
- Echo Plus
- Echo Dot
- Amazon Tap
The V2 Hue Bridge (square-shaped) required the Hue skill and is compatible with all Alexa devices.


I have an Echo 2nd generation, software version: 601480920.
I'm running Indigo 7.1.0, and the Alexa-Hue Bridge version 3.0.20

When I try to enable the Hue Skill, as soon as I login it says "There are no bridges on your network". .. without the expected 20 second delay.
I get the same response on the meethue.com web site when I try to add a bridge, even when I do it from the same Mac running Indigo! How does THAT SITE know?

So now where do you think the problem is, and who should I work with to resolve it?

Posted on
Thu Mar 08, 2018 12:34 pm
autolog offline
Posts: 3235
Joined: Sep 10, 2013
Location: West Sussex, UK [GMT+1 aka UTC+1]

Re: Discovery Failure

The Skill isn't needed for the plugin to work. The plugin will only respond to direct requests from Alexa.

As previously stated the plugin doesn't appear to work with the Gen 2 Echo, it does with the 2nd Gen echo Dot. :)

Posted on
Thu Mar 08, 2018 8:58 pm
jtburgess offline
User avatar
Posts: 43
Joined: Jan 17, 2018
Location: NJ

Re: Discovery Failure

They why doesn't it work with the meethue.com web site. That has nothing to do with any Alexa device?

Posted on
Fri Mar 09, 2018 2:11 am
autolog offline
Posts: 3235
Joined: Sep 10, 2013
Location: West Sussex, UK [GMT+1 aka UTC+1]

Re: Discovery Failure

jtburgess wrote:
They why doesn't it work with the meethue.com web site. That has nothing to do with any Alexa device?

When you say 'it', do you meen the plugin? :?

The plugin has been written to only respond to requests from a physical Amazon Echo device only. As previously stated, some of the newer Echo models don't appear to work with the plugin. :)

Posted on
Fri Mar 09, 2018 4:31 pm
jtburgess offline
User avatar
Posts: 43
Joined: Jan 17, 2018
Location: NJ

Re: Discovery Failure

Sorry, I should have been clearer. I clicked the "Add a Bridge" button at https://account.meethue.com/bridge
from Safari on the Mac running Indigo and the Alexa/Hue plugin, and it immediately responded
There are no bridges on your network
and
Please ensure that your bridge is turned on and that you are connected to the same network as your bridge.

I have every debug and logging option enabled in the plugin, and there is nothing in the log.
The web page seems to think it can access the network, and the Alexa/Hue plugin is not responding
(or it's just lying and didn't really test anything).

Posted on
Fri Mar 09, 2018 4:54 pm
jtburgess offline
User avatar
Posts: 43
Joined: Jan 17, 2018
Location: NJ

Re: Discovery Failure

I just discovered the separate Indigo plugin log directory. In there, I DO see it replying to my Echo (IP addr 192.168. 0.15)
2018-03-09 17:49:04.034 DEBUG Plugin.responder.respond Responder.respond called from address ('192.168.0.15', 50000)
HTTP/1.1 200 OK
CACHE-CONTROL: max-age=100
EXT:
LOCATION: http://192.168.0.5: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:da151438-fa2b-11e7-a3f5-38c9862674d9


2018-03-09 17:49:04.034 DEBUG Plugin.responder.respond Responder.respond: creating output_socket
2018-03-09 17:49:04.034 DEBUG Plugin.responder.respond Responder.respond: calling output_socket.sendto
2018-03-09 17:49:04.035 DEBUG Plugin.responder.respond Responder.respond: closing output_socket
2018-03-09 17:49:04.035 DEBUG Plugin.responder.respond Responder.respond: UDP Response sent to ('192.168.0.15', 50000)

So the echo doesn't understand that response.
Are there different flavors of the UPN protocol?

Posted on
Sat Mar 10, 2018 5:21 am
autolog offline
Posts: 3235
Joined: Sep 10, 2013
Location: West Sussex, UK [GMT+1 aka UTC+1]

Re: Discovery Failure

The issue AFAIUI is that when the plugin sends a response to the Echo it doesn't reply on the same port but I think uses port 80. Earlier models don't exhibit this behaviour. The plugin never receives the request to provide information to later Echos.

As I stated earlier, the work around is to use an Echo Dot for discovery. :)

Given there is a solution, I am unlikely to devote further time to trying to resolve this specific issue. The plugin is open source and available on Github for anyone who wants to devote time to trying to resolve it. :wink:

The longer term solution will be for an Alexa Skill that supports Indigo. This requires changes to Indigo to support the authentication model needed by the skill - not a simple job. :)

Posted on
Sat Mar 10, 2018 12:10 pm
jtburgess offline
User avatar
Posts: 43
Joined: Jan 17, 2018
Location: NJ

Re: Discovery Failure

OK. I'll take a look at the GitHub source, and maybe in conjunction with some packet sniffing I can figure out what's going on.

Who is online

Users browsing this forum: No registered users and 1 guest