Echo 2 f/w 599473420 not finding devices

wingett commented 6 years ago

Operating system and version:
Python version:
Fauxmo version (fauxmo --version):
Echo device type (e.g. Echo, Echo Plus, Dot):
Echo Firmware Version:

My Issue

Echo 2nd gen not discovering devices Firmware version : 599473420

WHYT

Python 3.6.1 and 3.6.4 on Raspberry PI 3 (using pyenv) Fauxmo 0.4.5 master and dev branch Used SimpleHTTPPlugin & CommandLinePlugin

Can see another device retrieving setup.xml from fauxmo but cannot see Echo requesting a response during the discovery phase. I can however see the request going out, so assume that the Echo is not recognising our response string.

My config.json is as below:


{
  "FAUXMO": {
    "ip_address": "auto"
  },
  "PLUGINS": {
    "CommandLinePlugin": {
      "path": "/opt/pyenv/versions/3.6.1/lib/python3.6/site-packages/fauxmo-plugins/commandlineplugin.py",
      "DEVICES": [
        {
            "name": "Lounge lights",
            "port": 42131,
            "on_cmd": "/home/pi/bin/socket 1 on",
            "off_cmd": "/home/pi/bin/socket 1 off",
            "state_cmd": "ls testfile.txt"
        }
      ]
    }
  }
}

The log file is attached below:

fauxmo.log

For info, the IP address of the Echo is 192.168.3.50 The .91 address is another Raspberry Pi running "an open source media player" :) There are two Sky TV boxes which are also using DLNA - not sure if these other devices are causing an issue in the discovery process, but will try later with everything else unplugged to see if the results are any different.

Please make sure you've taken these steps before submitting a new issue:

[ ] Try to reproduce the issue with Fauxmo installed in a venv
[ ] Ensure you're running a supported version of Python
- Requires Python >= 3.2 for Fauxmo < 0.3.0
- Requires Python >= 3.4.4 for Fauxmo >= 0.3.0
- Requires Python >= 3.6.0 for Fauxmo >= 0.4.0
[ ] Run Fauxmo in debug mode (-vvv) and include relevant output
[ ] Include your Fauxmo config.json
[ ] Search the existing (including closed) issues
[ ] Please use codeblocks around your debug output and config

wingett commented 6 years ago

Going through the log file a bit more, I can see that the request received from the Echo is different to the other devices:

From the Echo:

M-SEARCH * HTTP/1.1

From other devices:

NOTIFY * HTTP/1.1

Another change by Amazon in their latest firmware?

n8henrie commented 6 years ago

It could be, I'll not be able to check things out for a couple days, sorry. Your logs look like mostly search requests that may be from other devices, they don't look like the usual Echo requests (I wonder about UPNP requests from the media player on your other Pi).

wingett commented 6 years ago

I think I've got it, but not 100% sure. The initial request from the Echo is showing up as 'Man: "ssdp:discover"' whereas the one we responded to had 'MAN: "ssdp:discover"'. Checked protocols.py it looks like it is case sensitive in the discovery patterns?

While I've got you, just wanted to say absolute kudos to you for doing this project. Pretty fantastic functionality, so thank you very much for all of your efforts.

I'm going to uppercase the string in the discover_patterns and convert the data to uppercase before parsing it to see if that makes any difference. Need to brush up on my Python skills first though.

n8henrie commented 6 years ago

responded to had 'MAN: "ssdp:discover"'. Checked protocols.py it looks like it is case sensitive in the discovery patterns?

Good catch, that could be it. I wonder why it's now coming out as Man:? It seems like this is not in keeping with the spec: http://upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf

Just to verify:

You're positive the Echo IP is correct, that this isn't a different device making the requests (I assume so, but this seems unusual).
You're triggering the searches in the usual way ("discover devices" or through one of the apps).

While I've got you, just wanted to say absolute kudos to you for doing this project.

Thanks so much! It's been a lot of fun and has taught me a lot about Python.

The following change in protocols.py ~L342 should probably work for testing purposes:

if any(['MAN: "ssdp:discover"' in data, 'Man: "ssdp:discover"' in data]) and discover_pattern:

wingett commented 6 years ago

The echo is definitely 192.168.3.50 - I have dhcp running on the same Pi so can see what it dishes out to the other boxes on the network.

It looks like it is the discovery patterns - I'll try your change to protocols.py later on(case of trying to avoid divorce @ home) I changed the string to match the case exactly and fauxmo responded, but the Echo didn't recognise the response as a valid device. I was thinking of trying a physical reset of the Echo as it has been a fair few attempts to discover devices. Otherwise I'll get wireshark out to have a proper look at what is going on. I am learning far too much about UPnP here. Way more than I intended to when I started this home automation lark.

As to adhering to standards - some overly zealous developer at Amazon didn't like the aesthetics of "MAN" vs "Man"? :)

kirkinbommer commented 6 years ago

I'm in the same boat after changing the string - fauxmo responds now but the Echo doesn't see device. Can anyone provide a dump from a real wemo device so we can fix this?

wingett commented 6 years ago

Okay - went out and bought a Wemo to try this with. Got the trace attached but not had a proper look at it yet. Alexa=192.168.3.50 Wemo=192.168.3.13 (I think) My laptop was 192.168.3.66 and it was running Wireshark in promiscuous mode - hence it appearing in the trace as the source for some of the packets

wemo_discovery.pcapng.gz

I'll look at it tonight or tomorrow but if you want to have a look at it in the meantime, feel free.

cjvdev3 commented 6 years ago

I've been following this post silently but I've read the other issue #38 and installed the dev branch but still didn't work either. Just got a echo plus the other day and there is so many created open source commands / bridges with smart devices that all require fauxmo. Thank you guys for working on this!!!

wingett commented 6 years ago

Ignore my pcap - wrong IP address.... Doh! Will start tracing it again hopefully with the right IP address this time

wingett commented 6 years ago

Been using Wireshark to try and see what is happening with the discovery process from the Echo to the Wemo. I can see the request going from the Echo but I can't see anything back from the Wemo at all. However, the Wemo appears as a new device on Alexa.

It looks as though the process has completely changed, and not 100% it is entirely on Amazon's side. I know the IP address of the Wemo - 100% sure of that as I used a separate Python script to control it. I know the IP address of the Echo - 100% sure of that too. However I can't see any packets going through the Wireshark capture - despite it being run in Promiscuous mode. Any tips on how to sniff a UPnP discovery process between two known MAC addresses, regardless of protocol?

wingett commented 6 years ago

I thought that's what I'd actually got, but I get the distinct impression that I'm going to have to find a hub to plug into. There is literally no traffic showing from the Wemo to the Echo/Alexa - both going through an Apple Time Capsule which I didn't think worked as a switch

wingett commented 6 years ago

I'm kind of getting stuck with this now. I have done some wireless captures, using a Mac on the same network as a sniffer. I can see traffic going directly from the Wemo to the Echo but can't seem to make any sense of it. I have uploaded the captures but won't post the WPA keys - PM me for those and I'll send them across to see if you can make head or tail of the exchange, but I can't see any intelligible responses in the capture.

2018.02.05_21-09-08-GMT.wcap.gz

drduker commented 6 years ago

I am eagerly waiting for a fix this hopefully will provide. I have tried multiple times installing this on a raspberry pi zero w. I have a dot rev 1 and 2 and a regular echo. A couple of times I was able to get it working but I'm never able to reproduce and usually after hours of building python 3.6 from source each time. Python 3.6 is the biggest pain in the butt. I wish there was a two minute installer out there. Currently installing with pyenv but even that takes an hour-ish on the zero w. I think it very strange how my pi3 still has fauxmo working devices and can be discovered time and again with or without my echo v1 plugged in. It's like my pi3 is "approved" but no other devices are not.

wingett commented 6 years ago

@drduker - which firmware do you have on the Echo when Alexa discovers the fauxmo devices? Is there any chance that you could post the setup.xml from Fauxmo? Using http://ip_address:port/setup.xml to get it from a browser?

I can see differences between fauxmo and the real Wemo but would like to see a working one if possible as my Echo is pretty new so can’t downgrade the firmware to the best of my knowledge.

n8henrie commented 6 years ago

@drduker -- I'm surprised it takes that long to build 3.6.4 on a zero. It takes 979.572 seconds on my Pi3 -- I'll have to test on my zero. You should also not have to reinstall 3.6 at any point, it should be installed once, with no need to reinstall as far as I can think.

@wingett -- do you have the wemo skill installed? If so, I think that may be the problem, I think it maybe routes the communication through the network instead of directly device-to-device. One of the other issues had a discussion about how their transition to using the skill (on their end) could break Fauxmo.

Current dev version of Fauxmo is still working fine on my end (early generation Echo on 599469720 and Dot on 599473420) -- discovery, device state updates, and toggling switches. Sorry you guys are having trouble with the newer generation devices.

n8henrie commented 6 years ago

Can anybody else with an Echo Plus run Fauxmo in debug mode and see if their Alexa device discovery requests look like the following:

2018-02-01 14:42:33 fauxmo:332      DEBUG    M-SEARCH * HTTP/1.1
Host: 239.255.255.250:1900
Man: "ssdp:discover"
MX: 3
ST: ssdp:all

From @wingett's log, I'm surprised to see:

Man: instead of MAN: (mine still shows MAN:)
MX is now 3 instead of 15 (mine still shows 15)

n8henrie commented 6 years ago

@drduker -- You're right, on my Pi Zero it takes 74m36.443s to install 3.6.4. Crazy that it's such a huge difference.

drduker commented 6 years ago

@wingett - I originally setup the discovery of my pi3 (jessie lite) with a rev1 echo dot (currently running 599473420) around October of last year using https://github.com/kanesurendra/echo-pi which uses fauxmo. Then I bought the echo dot v2 (599473420) and the echo (599473420) on the black Friday sales. That pi3 continued to work until now even with the echo dot r1 disconnected. Echo-pi stuff is all automatic as it just broadcasts every single GPIO (or at least 15-28 or something). This isn't ideal if I want to setup a pin to just read a sensor - like a reed sensor on one of my three doors. So that is why I started trying to look fauxmo and wemore directly to see if I could show the status but there wouldn't actually be any command done if on/off was pressed.

I have been testing fauxmo with just using the example json. It actually worked twice so far but I didn't notice that it was working BOTH times until later after I had already re-imaged the sd card with etcher. I saw the three examples listed on my echo smart home list. So I know it is possible I'm just trying to figure out how to duplicate the steps because I have like 6 zero w's I want to do this on. When I tried to register them initially it would appear that the echo and the pi were communicating in verbose mode, BUT they would never show up. I have tried with jessie lite and stretch to get this working but I don't remember which one the three test devices actually showed up on.

I will work on this tomorrow and see if I can't provide some step by step walkthrough on the zero w. IF i can get it working I'll post, but it doesn't seem reliable yet like it seemed reliable back last October.

wingett commented 6 years ago

@n8henrie You could be on the right track with the Wemo Skill. I "had" it installed originally as I misread some of the blurb on it and thought it was required. It is quite possible that the Echo is still maintaining some settings from that. Did a factory reset this morning, but even that doesn't seem to have wiped all of the settings as it still going back on with the same Amazon account after setup, so I guess some stuff is stored in their cloud.

I have the setup.xml from Fauxmo and the one from a pukka Wemo switch just to compare and there are a fair few differences (love the version number on Fauxmo!)

Proper Wemo_setup.xml below

<root xmlns="urn:Belkin:device-1-0">
<specVersion>
<major>1</major>
<minor>0</minor>
</specVersion>
<device>
<deviceType>urn:Belkin:device:controllee:1</deviceType>
<friendlyName>WeMo Switch</friendlyName>
<manufacturer>Belkin International Inc.</manufacturer>
<manufacturerURL>http://www.belkin.com</manufacturerURL>
<modelDescription>Belkin Plugin Socket 1.0</modelDescription>
<modelName>Socket</modelName>
<modelNumber>1.0</modelNumber>
<modelURL>http://www.belkin.com/plugin/</modelURL>
<serialNumber>221713K110010B</serialNumber>
<UDN>uuid:Socket-1_0-221713K110010B</UDN>
<UPC>123456789</UPC>
<macAddress>58EF68979360</macAddress>
<firmwareVersion>WeMo_WW_2.00.10966.PVT-OWRT-SNS</firmwareVersion>
<iconVersion>0|49153</iconVersion>
<binaryState>0</binaryState>
<iconList>
<icon>
<mimetype>jpg</mimetype>
<width>100</width>
<height>100</height>
<depth>100</depth>
<url>icon.jpg</url>
</icon>
</iconList>
<serviceList>
<service>
<serviceType>urn:Belkin:service:WiFiSetup:1</serviceType>
<serviceId>urn:Belkin:serviceId:WiFiSetup1</serviceId>
<controlURL>/upnp/control/WiFiSetup1</controlURL>
<eventSubURL>/upnp/event/WiFiSetup1</eventSubURL>
<SCPDURL>/setupservice.xml</SCPDURL>
</service>
<service>
<serviceType>urn:Belkin:service:timesync:1</serviceType>
<serviceId>urn:Belkin:serviceId:timesync1</serviceId>
<controlURL>/upnp/control/timesync1</controlURL>
<eventSubURL>/upnp/event/timesync1</eventSubURL>
<SCPDURL>/timesyncservice.xml</SCPDURL>
</service>
<service>
<serviceType>urn:Belkin:service:basicevent:1</serviceType>
<serviceId>urn:Belkin:serviceId:basicevent1</serviceId>
<controlURL>/upnp/control/basicevent1</controlURL>
<eventSubURL>/upnp/event/basicevent1</eventSubURL>
<SCPDURL>/eventservice.xml</SCPDURL>
</service>
<service>
<serviceType>urn:Belkin:service:firmwareupdate:1</serviceType>
<serviceId>urn:Belkin:serviceId:firmwareupdate1</serviceId>
<controlURL>/upnp/control/firmwareupdate1</controlURL>
<eventSubURL>/upnp/event/firmwareupdate1</eventSubURL>
<SCPDURL>/firmwareupdate.xml</SCPDURL>
</service>
<service>
<serviceType>urn:Belkin:service:rules:1</serviceType>
<serviceId>urn:Belkin:serviceId:rules1</serviceId>
<controlURL>/upnp/control/rules1</controlURL>
<eventSubURL>/upnp/event/rules1</eventSubURL>
<SCPDURL>/rulesservice.xml</SCPDURL>
</service>
<service>
<serviceType>urn:Belkin:service:metainfo:1</serviceType>
<serviceId>urn:Belkin:serviceId:metainfo1</serviceId>
<controlURL>/upnp/control/metainfo1</controlURL>
<eventSubURL>/upnp/event/metainfo1</eventSubURL>
<SCPDURL>/metainfoservice.xml</SCPDURL>
</service>
<service>
<serviceType>urn:Belkin:service:remoteaccess:1</serviceType>
<serviceId>urn:Belkin:serviceId:remoteaccess1</serviceId>
<controlURL>/upnp/control/remoteaccess1</controlURL>
<eventSubURL>/upnp/event/remoteaccess1</eventSubURL>
<SCPDURL>/remoteaccess.xml</SCPDURL>
</service>
<service>
<serviceType>urn:Belkin:service:deviceinfo:1</serviceType>
<serviceId>urn:Belkin:serviceId:deviceinfo1</serviceId>
<controlURL>/upnp/control/deviceinfo1</controlURL>
<eventSubURL>/upnp/event/deviceinfo1</eventSubURL>
<SCPDURL>/deviceinfoservice.xml</SCPDURL>
</service>
<service>
<serviceType>urn:Belkin:service:smartsetup:1</serviceType>
<serviceId>urn:Belkin:serviceId:smartsetup1</serviceId>
<controlURL>/upnp/control/smartsetup1</controlURL>
<eventSubURL>/upnp/event/smartsetup1</eventSubURL>
<SCPDURL>/smartsetup.xml</SCPDURL>
</service>
<service>
<serviceType>urn:Belkin:service:manufacture:1</serviceType>
<serviceId>urn:Belkin:serviceId:manufacture1</serviceId>
<controlURL>/upnp/control/manufacture1</controlURL>
<eventSubURL>/upnp/event/manufacture1</eventSubURL>
<SCPDURL>/manufacture.xml</SCPDURL>
</service>
</serviceList>
<presentationURL>/pluginpres.html</presentationURL>
</device>
</root>

Don't know if that helps at all?

wingett commented 6 years ago

And the fauxmo setup.xml although I doubt you'll need that somehow since you generated it in the first place.

<root>
<specVersion>
<major>1</major>
<minor>0</minor>
</specVersion>
<device>
<deviceType>urn:Belkin:device:controllee:1</deviceType>
<friendlyName>Lounge lights</friendlyName>
<manufacturer>Belkin International Inc.</manufacturer>
<modelName>Emulated Socket</modelName>
<modelNumber>3.1415</modelNumber>
<UDN>
uuid:Socket-1_0-4eebb5f6-8daa-351b-a927-3fb16b68e478
</UDN>
<serviceList>
<service>
<serviceType>urn:Belkin:service:basicevent:1</serviceType>
<serviceId>urn:Belkin:serviceId:basicevent1</serviceId>
<controlURL>/upnp/control/basicevent1</controlURL>
<eventSubURL>/upnp/event/basicevent1</eventSubURL>
<SCPDURL>/eventservice.xml</SCPDURL>
</service>
<service>
<serviceType>urn:Belkin:service:metainfo:1</serviceType>
<serviceId>urn:Belkin:serviceId:metainfo1</serviceId>
<controlURL>/upnp/control/metainfo1</controlURL>
<eventSubURL>/upnp/event/metainfo1</eventSubURL>
<SCPDURL>/metainfoservice.xml</SCPDURL>
</service>
</serviceList>
</device>
</root>

Note that this is a regular Echo (2nd gen), not a Plus. I saw in your comment above you were asking about a Plus. The one thing I can say that might differ from your setup is that this is set up as UK, not US.

wingett commented 6 years ago

@n8henrie I bit the bullet and went out and bought an Echo Dot to go with the Echo. F/W version on that is 599473420

With that on the network, and the changes you suggested to match both MAN: and Man: then I can get fauxmo to respond to the Dot. I can see specifically that it is the Dot and not the Echo doing the business here, by the IP addresses. Alexa recognises the devices I set up in config.json and controls them properly, providing the Dot is still on.

I disconnected the Dot from the network to see if Alexa would still control the devices from the Echo and although the Echo still has the devices listed, it says that the device isn't responding. Plug the Dot back in again and it all works properly.

So it must be something to do with the latest firmware on the 2nd gen Echo, or something specific in the UK version. No idea which. But progress of a sort anyway.

drduker commented 6 years ago

protocols.py doesn't even have 300 lines, where is L342? trying to implement this: if any(['MAN: "ssdp:discover"' in data, 'Man: "ssdp:discover"' in data]) and discover_pattern:

This process has not worked for me:

Flash with etcher Rasbian Jessie or Stretch lite
Add ssh.txt and wap_supplicant.conf to boot file system
Plug microsd card and boot up pi zero W.
Ssh in and "sudo su -" to root
Run these commands to install and run: wget https://bootstrap.pypa.io/get-pip.py sudo apt-get update sudo apt-get install build-essential tk-dev libncurses5-dev libncursesw5-dev libreadline6-dev libdb5.3-dev libgdbm-dev libsqlite3-dev libssl-dev libbz2-dev libexpat1-dev liblzma-dev zlib1g-dev sudo install -o $(whoami) -g $(whoami) -d /opt/pyenv git clone https://github.com/yyuu/pyenv /opt/pyenv echo 'export PYENV_ROOT="/opt/pyenv"' >> ~/.bashrc echo 'export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.bashrc echo 'eval "$(pyenv init -)"' >> ~/.bashrc source ~/.bashrc pyenv install 3.6.1 "$(pyenv root)"/versions/3.6.1/bin/python3.6 -m pip install fauxmo

"$(pyenv root)"/versions/3.6.1/bin/fauxmo -c /home/pi/config.json -vvv

root@raspberrypi:/home/pi# 2018-02-12 04:26:44 fauxmo:37 2018-02-12 04:26:44 fauxmo:38 [GCC 4.9.2] 2018-02-12 04:26:44 fauxmo:24 2018-02-12 04:26:44 fauxmo:37 2018-02-12 04:26:45 fauxmo:100 2018-02-12 04:26:45 fauxmo:103 2018-02-12 04:26:45 asyncio:1067 2018-02-12 04:26:45 fauxmo:121 2018-02-12 04:26:45 fauxmo:103 2018-02-12 04:26:46 asyncio:1067 2018-02-12 04:26:46 fauxmo:121 2018-02-12 04:26:46 fauxmo:103 2018-02-12 04:26:46 asyncio:1067 2018-02-12 04:26:46 fauxmo:121 2018-02-12 04:26:46 fauxmo:123 2018-02-12 04:26:46 asyncio:947 2018-02-12 04:27:03 asyncio:1379 2018-02-12 04:27:03 fauxmo:223 2018-02-12 04:27:03 fauxmo:224 2018-02-12 04:27:03 asyncio:1379 2018-02-12 04:27:03 fauxmo:223 2018-02-12 04:27:03 fauxmo:224 2018-02-12 04:27:03 asyncio:1379 2018-02-12 04:27:03 fauxmo:223 2018-02-12 04:27:03 fauxmo:224 2018-02-12 04:27:03 asyncio:1379 2018-02-12 04:27:03 fauxmo:223 2018-02-12 04:27:03 fauxmo:224 2018-02-12 04:27:03 asyncio:1379 2018-02-12 04:27:03 fauxmo:223 2018-02-12 04:27:03 fauxmo:224 2018-02-12 04:27:03 asyncio:1379 2018-02-12 04:27:03 fauxmo:223 2018-02-12 04:27:03 fauxmo:224 2018-02-12 04:27:08 asyncio:1379 2018-02-12 04:27:08 fauxmo:223 2018-02-12 04:27:08 fauxmo:224 2018-02-12 04:27:10 asyncio:1379 2018-02-12 04:27:10 fauxmo:223 2018-02-12 04:27:10 fauxmo:224 2018-02-12 04:27:12 asyncio:1379 2018-02-12 04:27:12 fauxmo:223 2018-02-12 04:27:12 fauxmo:224 2018-02-12 04:27:14 asyncio:1379 2018-02-12 04:27:14 fauxmo:223 2018-02-12 04:27:14 fauxmo:224 2018-02-12 04:27:16 asyncio:1379 2018-02-12 04:27:16 fauxmo:223 2018-02-12 04:27:16 fauxmo:224 2018-02-12 04:27:18 asyncio:1379 2018-02-12 04:27:18 fauxmo:223 2018-02-12 04:27:18 fauxmo:224 2018-02-12 04:27:20 asyncio:1379 2018-02-12 04:27:20 fauxmo:223 2018-02-12 04:27:20 fauxmo:224 2018-02-12 04:27:20 asyncio:1379 2018-02-12 04:27:20 fauxmo:223 2018-02-12 04:27:20 fauxmo:224 2018-02-12 04:27:21 asyncio:1379 2018-02-12 04:27:21 fauxmo:223 2018-02-12 04:27:21 fauxmo:224 2018-02-12 04:27:22 asyncio:1379 2018-02-12 04:27:22 fauxmo:223 2018-02-12 04:27:22 fauxmo:224 2018-02-12 04:27:22 asyncio:1379 2018-02-12 04:27:22 fauxmo:223 2018-02-12 04:27:22 fauxmo:224 2018-02-12 04:27:24 asyncio:1379 2018-02-12 04:27:24 fauxmo:223 2018-02-12 04:27:24 fauxmo:224 "$(pyenv root)"/versions/3.6.1/bin/fauxmo -c config.json -vvv INFO Fauxmo v0.4.5 DEBUG 3.6.1 (default, Feb 12 2018, 02:51:29) DEBUG Attempting to get IP address automatically DEBUG Using IP address: 192.168.1.127 DEBUG plugin_vars: {} DEBUG device config: {'port': 12340, 'on_cmd': 'http://192.168.1.104/myserver/fakeswitches/01/on', 'off_cmd': 'http://192.168.1.104/myserver/fakeswitches/01/off', 'method': 'GET', 'name': 'fake switch one'} INFO <Server sockets=[<socket.socket fd=8, family=AddressFamily.AF_INET, type=2049, proto=6, laddr=('192.168.1.127', 12340)>]> is serving DEBUG Started fauxmo device: {'name': 'fake switch one', 'plugin': <fauxmo.plugins.simplehttpplugin.SimpleHTTPPlugin object at 0xb610e810>} DEBUG device config: {'port': 12341, 'on_cmd': 'http://localhost:54321/devices/garage%20light', 'off_cmd': 'http://localhost:54321/devices/garage%20light', 'on_data': {'isOn': 1}, 'off_data': {'isOn': 0}, 'user': 'this', 'password': 'that', 'method': 'PUT', 'name': 'fake Indigo switch'} INFO <Server sockets=[<socket.socket fd=9, family=AddressFamily.AF_INET, type=2049, proto=6, laddr=('192.168.1.127', 12341)>]> is serving DEBUG Started fauxmo device: {'name': 'fake Indigo switch', 'plugin': <fauxmo.plugins.simplehttpplugin.SimpleHTTPPlugin object at 0xb5f7dfb0>} DEBUG device config: {'name': 'fake home assistant switch by REST API', 'port': 12342, 'on_cmd': 'http://192.168.1.104:8123/api/services/switch/turn_on', 'off_cmd': 'http://192.168.1.104:8123/api/services/switch/turn_off', 'method': 'POST', 'headers': {'x-ha-access': 'your_hass_password'}, 'on_data': {'entity_id': 'switch.fake_hass_switch'}, 'off_data': {'entity_id': 'switch.fake_hass_switch'}} INFO <Server sockets=[<socket.socket fd=10, family=AddressFamily.AF_INET, type=2049, proto=6, laddr=('192.168.1.127', 12342)>]> is serving DEBUG Started fauxmo device: {'name': 'fake home assistant switch by REST API', 'plugin': <fauxmo.plugins.simplehttpplugin.SimpleHTTPPlugin object at 0xb5f8c8d0>} INFO Starting UDP server DEBUG Datagram endpoint remote_addr=None created: (<_SelectorDatagramTransport fd=11 read=idle write=<idle, bufsize=0>>, <fauxmo.protocols.SSDPServer object at 0xb610e590>) INFO poll took 17523.433 ms: 1 events DEBUG Received data below from ('192.168.1.140', 50000): DEBUG b'M-SEARCH HTTP/1.1\r\nHost: 239.255.255.250:1900\r\nMan: "ssdp:discover"\r\nMX: 3\r\nST: ssdp:all\r\n\r\n' DEBUG poll took 0.217 ms: 1 events DEBUG Received data below from ('192.168.1.140', 50000): DEBUG b'M-SEARCH HTTP/1.1\r\nHost: 239.255.255.250:1900\r\nMan: "ssdp:discover"\r\nMX: 3\r\nST: upnp:rootdevice\r\n\r\n' DEBUG poll took 0.217 ms: 1 events DEBUG Received data below from ('192.168.1.140', 50000): DEBUG b'M-SEARCH HTTP/1.1\r\nHost: 239.255.255.250:1900\r\nMan: "ssdp:discover"\r\nMX: 3\r\nST: ssdp:all\r\n\r\n' DEBUG poll took 0.219 ms: 1 events DEBUG Received data below from ('192.168.1.140', 50000): DEBUG b'M-SEARCH HTTP/1.1\r\nHost: 239.255.255.250:1900\r\nMan: "ssdp:discover"\r\nMX: 3\r\nST: upnp:rootdevice\r\n\r\n' DEBUG poll took 0.216 ms: 1 events DEBUG Received data below from ('192.168.1.140', 50000): DEBUG b'M-SEARCH HTTP/1.1\r\nHost: 239.255.255.250:1900\r\nMan: "ssdp:discover"\r\nMX: 3\r\nST: ssdp:all\r\n\r\n' DEBUG poll took 0.222 ms: 1 events DEBUG Received data below from ('192.168.1.140', 50000): DEBUG b'M-SEARCH HTTP/1.1\r\nHost: 239.255.255.250:1900\r\nMan: "ssdp:discover"\r\nMX: 3\r\nST: upnp:rootdevice\r\n\r\n' INFO poll took 4692.692 ms: 1 events DEBUG Received data below from ('192.168.1.118', 37795): DEBUG b'M-SEARCH HTTP/1.1\r\nMX: 4\r\nMAN: "ssdp:discover"\r\nHOST:239.255.255.250:1900\r\nST: urn:Belkin:device:lightswitch:1\r\n\r\n' INFO poll took 1978.784 ms: 1 events DEBUG Received data below from ('192.168.1.118', 53898): DEBUG b'M-SEARCH HTTP/1.1\r\nMX: 4\r\nMAN: "ssdp:discover"\r\nHOST:239.255.255.250:1900\r\nST: urn:samsung.com:device:RemoteControlReceiver:1\r\n\r\n' INFO poll took 1984.705 ms: 1 events DEBUG Received data below from ('192.168.1.118', 46646): DEBUG b'M-SEARCH HTTP/1.1\r\nMX: 4\r\nMAN: "ssdp:discover"\r\nHOST:239.255.255.250:1900\r\nST: urn:schemas-upnp-org:device:basic:1\r\n\r\n' INFO poll took 1976.710 ms: 1 events DEBUG Received data below from ('192.168.1.118', 38093): DEBUG b'M-SEARCH HTTP/1.1\r\nMX: 4\r\nMAN: "ssdp:discover"\r\nHOST:239.255.255.250:1900\r\nST: urn:smartspeaker-audio:service:SpeakerGroup:1\r\n\r\n' INFO poll took 1976.864 ms: 1 events DEBUG Received data below from ('192.168.1.118', 35290): DEBUG b'M-SEARCH HTTP/1.1\r\nMX: 4\r\nMAN: "ssdp:discover"\r\nHOST:239.255.255.250:1900\r\nST: urn:schemas-upnp-org:device:MediaRenderer:1\r\n\r\n' INFO poll took 1983.489 ms: 1 events DEBUG Received data below from ('192.168.1.118', 34202): DEBUG b'M-SEARCH HTTP/1.1\r\nMX: 4\r\nMAN: "ssdp:discover"\r\nHOST:239.255.255.250:1900\r\nST: urn:Belkin:device:insight:1\r\n\r\n' INFO poll took 1977.030 ms: 1 events DEBUG Received data below from ('192.168.1.118', 54331): DEBUG b'M-SEARCH HTTP/1.1\r\nMX: 4\r\nMAN: "ssdp:discover"\r\nHOST:239.255.255.250:1900\r\nST: urn:Belkin:device:controllee:1\r\n\r\n' DEBUG poll took 7.245 ms: 1 events DEBUG Received data below from ('192.168.1.116', 63358): DEBUG b'M-SEARCH HTTP/1.1\r\nHOST: 239.255.255.250:1900\r\nMAN: "ssdp:discover"\r\nMX: 1\r\nST: urn:dial-multiscreen-org:service:dial:1\r\nUSER-AGENT: Google Chrome/64.0.3282.140 Mac OS X\r\n\r\n' DEBUG poll took 981.038 ms: 1 events DEBUG Received data below from ('192.168.1.116', 63358): DEBUG b'M-SEARCH HTTP/1.1\r\nHOST: 239.255.255.250:1900\r\nMAN: "ssdp:discover"\r\nMX: 1\r\nST: urn:dial-multiscreen-org:service:dial:1\r\nUSER-AGENT: Google Chrome/64.0.3282.140 Mac OS X\r\n\r\n' DEBUG poll took 946.725 ms: 1 events DEBUG Received data below from ('192.168.1.118', 43510): DEBUG b'M-SEARCH HTTP/1.1\r\nMX: 4\r\nMAN: "ssdp:discover"\r\nHOST:239.255.255.250:1900\r\nST: urn:Belkin:device:sensor:1\r\n\r\n' DEBUG poll took 5.635 ms: 1 events DEBUG Received data below from ('192.168.1.116', 63358): DEBUG b'M-SEARCH HTTP/1.1\r\nHOST: 239.255.255.250:1900\r\nMAN: "ssdp:discover"\r\nMX: 1\r\nST: urn:dial-multiscreen-org:service:dial:1\r\nUSER-AGENT: Google Chrome/64.0.3282.140 Mac OS X\r\n\r\n' INFO poll took 1984.411 ms: 1 events DEBUG Received data below from ('192.168.1.116', 63358): DEBUG b'M-SEARCH HTTP/1.1\r\nHOST: 239.255.255.250:1900\r\nMAN: "ssdp:discover"\r\nMX: 1\r\nST: urn:dial-multiscreen-org:service:dial:1\r\nUSER-AGENT: Google Chrome/64.0.3282.140 Mac OS X\r\n\r\n'

n8henrie commented 6 years ago

protocols.py doesn't even have 300 lines, where is L342?

@drduker You're looking at the wrong branch. Everyone in this thread should be looking at the dev branch, which @wingett mentioned having tried in the original post but I suppose should have been clarified. https://github.com/n8henrie/fauxmo/blob/4e2e34cca7846ae53653b4c862beaf1fe857bf33/src/fauxmo/protocols.py#L342

drduker commented 6 years ago

Finally! It took several discoveries and I waited an hour or so before I attempted the last discovery that worked. If only it worked the first time!

n8henrie commented 6 years ago

@drduker -- was that with or without the changes to 342? What fauxmo version? (I just release 0.4.6 today.)

n8henrie commented 6 years ago

@wingett -- what might be most helpful is another fauxmo log (like in your original post), but a little simplified.

Would you be willing to temporarily:

Leave only the Echo Plus plugged in (unplug the Dot, other Alexa devices)
Power off your other upnp media server
Uninstall the Wemo skill
Forget all devices in the Alexa app
Start Fauxmo in debug / -vvv mode
"Discover Devices" on the Echo

And then capture and post a debug log including a description of the IP addresses that appear?

I realize that's a lot of work, but I think that's the next step to continuing to work on Echo Plus compatibility.

drduker commented 6 years ago

@n8henrie - That was with the 342 change. And version 0.4.5 but I swapped out the protocols.py file with what was in dev.

wingett commented 6 years ago

@n8henrie - I'm more than happy to give it a go, but it will have to wait for a couple of weeks. I'm out of the country now for a fortnight, with no physical access to the boxes at home.

The only way I got the response from Fauxmo to be recognised by the Echo(s) were when I had the Echo 2 turned off, and just the Dot doing the device discovery.

I only noticed afterwards that the firmware levels are the same, so it has to be some specific difference between the Echo and the Dot.

On a side note, is there a way that anyone knows of to specifically search from one unit? Rather than turning stuff off?

I'll carry on looking remotely, but can't physically disconnect the other UPnP devices for the moment. I'm not going to even attempt to talk the wife through disconnecting and reconnecting devices 😊

From: Nathan Henrie notifications@github.com Sent: 12 February 2018 23:40:26 To: n8henrie/fauxmo Cc: Andrew Smith; Mention Subject: Re: [n8henrie/fauxmo] Echo 2 f/w 599473420 not finding devices (#49)

@wingetthttps://github.com/wingett -- what might be most helpful is another fauxmo log (like in your original post), but a little simplified.

Would you be willing to temporarily:

Leave only the Echo Plus plugged in (unplug the Dot, other Alexa devices)
Power off your other upnp media server
Uninstall the Wemo skill
Forget all devices in the Alexa app
Start Fauxmo in debug / -vvv mode
"Discover Devices" on the Echo

And then capture and post a debug log including a description of the IP addresses that appear?

I realize that's a lot of work, but I think that's the next step to continuing to work on Echo Plus compatibility.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/n8henrie/fauxmo/issues/49#issuecomment-365087945, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ADnyTlt2nkOqCLmF-tsWQoY5G-lrXu2Xks5tUL3agaJpZM4R1wf5.

drduker commented 6 years ago

@wingett. I've observed similar things. In order to get my devices discovered faster rather than waiting 30minutes+, I have been able to discover devices within 5 minutes or so if I continue pressing the discover over an over again and meanwhile unplug and replug my rev2 dot or echo while the rev1 remains plugged in. This is just a theory but there might be some discovery recheck or a special process that happens during a power on of a device and its communication with Amazon.

Until we figure out what happens when a echo dot rev2 or echo does during boot to allow discovery, I've got a samsungs smartthings controlled wifi outlet switch attached to my echo dot so I can make config changes remotely :)

wingett commented 6 years ago

@drduker -I’ll give that a go when I get back home. To be fair I’m a bit reluctant to do the discovery process again as it’s working now. Too worried it’ll break ;)

First time I tried it, it didn’t detect any devices. It was only the 2nd or 3rd attempt with just the Dot plugged in that I got it to work. I’ll try it again when I get back and will set the logging up so we can see what is happening here. I’m most interested in seeing how it differs between the Echo and the Dot as they are both running the same firmware versions.

On 13 Feb 2018, at 19:11, drduker notifications@github.com<mailto:notifications@github.com> wrote:

@wingetthttps://github.com/wingett. I've observed similar things. In order to get my devices discovered faster rather than waiting 30minutes+, I have been able to discover devices within 5 minutes or so if I continue pressing the discover over an over again and meanwhile unplug and replug my rev2 dot or echo while the rev1 remains plugged in. This is just a theory but there might be some discovery recheck or a special process that happens during a power on of a device and its communication with Amazon.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/n8henrie/fauxmo/issues/49#issuecomment-365354111, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ADnyTlxlVisWqCVVo6obg4sOzfZMgeEHks5tUdBVgaJpZM4R1wf5.

GlennPegden2 commented 6 years ago

I'm in a VERY similar position to Wingett, Echo Plus (UK version), I even have a couple of SkyQ boxes that poll ssdp like crazy too.

I initially got everything working for a few weeks after issue 38 was solved, but yesterday discovery stopped working (I'm working on a python script to manage SkyQ/Xbox/LG WebOS TV a little more intelligently from the Alexa using fauxmo, so I regularly update config.json to offer new devices).

As of yesterday, (re)discovery stopped working and I ONLY have the Echo Plus (no other Echo devices) on the network and I can confirm the following ssdp poll.

2018-02-18 16:22:26 asyncio:1379     DEBUG    poll took 0.110 ms: 1 events
2018-02-18 16:22:26 fauxmo:324      DEBUG    Received data below from ('192.168.95.31', 50000):
2018-02-18 16:22:26 fauxmo:325      DEBUG    b'M-SEARCH * HTTP/1.1\r\nHost: 239.255.255.250:1900\r\nMan: "ssdp:discover"\r\nMX: 3\r\nST: upnp:rootdevice\r\n\r\n'

Which confirms the new casing of Man: and the new MX value.

Fixing the protocols.py to cope with either casing got the response to the Echo appearing in the log (sample below), but the devices still aren't recognised by the Echo.

2018-02-18 18:00:41 fauxmo:367      DEBUG    Sending response to ('192.168.95.31', 50000):
HTTP/1.1 200 OK
CACHE-CONTROL: max-age=86400
DATE: Sun, 18 Feb 2018 18:00:41 GMT
EXT:
LOCATION: http://192.168.95.4:12347/setup.xml
OPT: "http://schemas.upnp.org/upnp/1/0/"; ns=01
01-NLS: 11a517bf-b853-48e0-9574-bdb8ac41e672
SERVER: Fauxmo, UPnP/1.0, Unspecified
ST: urn:Belkin:device:**
USN: uuid:Socket-1_0-1c679a85-6755-3238-ae03-d3d7545262c1::upnp:rootdevice

The URI in Location: does return a valid-looking xml

Echo software version is 599473620

One caveat to all this is I suspect I'm not running quite the latest dev build as the line to change in protocols.py was a few lines earlier than stated and the string needed to be a byte literal (i.e. prefixed with b). I'll clone the latest dev build and retest when I got another window to test in, but I thought it was worth sharing my findings so far.

GlennPegden2 commented 6 years ago

Ok, here's logs having now pulled a slightley newer build

2018-02-18 18:54:31 asyncio:1379     DEBUG    poll took 508.754 ms: 1 events
2018-02-18 18:54:31 fauxmo:331      DEBUG    Received data below from ('192.168.95.31', 50000):
2018-02-18 18:54:31 fauxmo:332      DEBUG    M-SEARCH * HTTP/1.1
Host: 239.255.255.250:1900
Man: "ssdp:discover"
MX: 3
ST: ssdp:all

2018-02-18 18:54:31 fauxmo:393      DEBUG    Sending response to ('192.168.95.31', 50000) with mx 3.0:
b'HTTP/1.1 200 OK\nCACHE-CONTROL: max-age=86400\nDATE: Sun, 18 Feb 2018 18:54:31 GMT\nEXT:\nLOCATION: http://192.168.95.4:12343/setup.xml\nOPT: "http://schemas.upnp.org/upnp/1/0/"; ns=01\n01-NLS: f3335d07-9f24-40bf-892b-e37be7ce4dd9\nSERVER: Fauxmo, UPnP/1.0, Unspecified\nST: ssdp:all\nUSN: uuid:Socket-1_0-b6acc4b0-478b-3716-96ec-936c1249e38a::ssdp:all\n\n'
2018-02-18 18:54:31 fauxmo:393      DEBUG    Sending response to ('192.168.95.31', 50000) with mx 3.0:
b'HTTP/1.1 200 OK\nCACHE-CONTROL: max-age=86400\nDATE: Sun, 18 Feb 2018 18:54:31 GMT\nEXT:\nLOCATION: http://192.168.95.4:12344/setup.xml\nOPT: "http://schemas.upnp.org/upnp/1/0/"; ns=01\n01-NLS: bbb74449-1dc4-42d7-bdc0-0216a7423bfc\nSERVER: Fauxmo, UPnP/1.0, Unspecified\nST: ssdp:all\nUSN: uuid:Socket-1_0-13eaf99c-8cf6-39e2-803a-d682b05fcbcd::ssdp:all\n\n'
2018-02-18 18:54:31 fauxmo:393      DEBUG    Sending response to ('192.168.95.31', 50000) with mx 3.0:
b'HTTP/1.1 200 OK\nCACHE-CONTROL: max-age=86400\nDATE: Sun, 18 Feb 2018 18:54:31 GMT\nEXT:\nLOCATION: http://192.168.95.4:12345/setup.xml\nOPT: "http://schemas.upnp.org/upnp/1/0/"; ns=01\n01-NLS: 3034e019-0028-4545-b1c3-b7edd49fde49\nSERVER: Fauxmo, UPnP/1.0, Unspecified\nST: ssdp:all\nUSN: uuid:Socket-1_0-013da23d-d6b3-326e-872b-a9ab97b04113::ssdp:all\n\n'

That's the first 3 devices it responds with, it does return a lot more.

wingett commented 6 years ago

Back in the country now so got a chance to do some more testing. I've attached 3 log files fauxmo_echo.log where only the Echo was turned on fauxmo_dot.log where only the Dot was on fauxmo_both.log with everything running as normal

fauxmo_both.log fauxmo_dot.log fauxmo_echo.log

Forgot to put in the IP addresses: Echo - 192.168.3.50 Dot - 192.168.3.110 Fauxmo - 192.168.3.189

wingett commented 6 years ago

@n8henrie - I am wondering if this originates from one of your original theories regarding the Wemo skill for Alexa. I had installed it, then disabled (which I assume 'removes' it too) it to get rid of it. I still don't see the traffic between the Echo and Fauxmo on an IP level. Doing a factory reset on the Echo doesn't seem to remove the settings as they get restored again as soon as you re-associate with the same account, or they appear to be anyway.

@GlennPegden2 Did you ever have the Wemo skill installed on your Echo? I can imagine that is why you're seeing the same thing as me? The only thing I can think of here is to create a new Amazon account, reset the Echo and associate it with the new account. Not sure if that will wipe the whole Wemo setup and allow us to get a new trace on a 'clean' installation?

In terms of source changes, I'm thinking of changing the MX response to always use 15 and ignore the value sent in the discovery request. There definitely seem to be differences between the Echo and the Dot (on identical firmware) in the way they do device discovery. And I still haven't found how to get a specific device to perform the discovery.

GlennPegden2 commented 6 years ago

@wingett I've never had the skill installed as I don't have a physical WeeMo, so it had never dawned on me to try, so that could be a red herring.

I do however have a work colleague about to lend me an actual WeMo, so I can compare pcaps from fauxmo to the real thing in the next few days, hopefully.

GlennPegden2 commented 6 years ago

Having now compared tcpdumps from my failing setup with the spec, I believe the responses to the ST: ssdp:all that the echo is sending are incorrect (it may be I'm misinterpreting the spec, but I don't think you'd ever respond with the ST: set to ssdp:all, even if that's what you received.

However, I believe the responses to ST: unp:rootdevice are valid.

That said, looking at @n8henrie 's excellent notes in protocol_notes.md it looks like he's expecting the Echo to send a Search Type of ST: urn:Belkin:device:** where as I don't see that at all from my echo, only ST: ssdp:alland ST: upnp:rootdevice

Hopefully I'll have more of a clue when my actual WeMo arrives.

GlennPegden2 commented 6 years ago

Just musing on my own findings above, could it be that in the discovery phase, Amazon have gone from looking for a few specific vendors and are instead querying ALL ssdp devices and then deciding which ones they support via the Description (or possibly the SERVER: header)?

wingett commented 6 years ago

@GlennPegden2 I agree with you on what the Echo is sending/receiving. Not convinced this isn't a bug on the Echo side. I've done further testing with the Dot disconnected and can get the devices discovered, but looking at closer the Echo doesn't normally discover the actual Wemo until the 2nd or 3rd discovery attempt. Plug the Dot back in and everything works as expected.

I'm beginning to think this is something they have just plain broken on the 2nd gen Echo with the latest firmware update.

I forced a response with MX set to 15 and the Echo received a response from Fauxmo but then did nothing further with it. You can see the response going back and being actively processed when the Dot comes into the equation.

n8henrie commented 6 years ago

Sorry, I've been watching the thread with great interest but very busy at work (and out of town this week). Thanks to all for participation and contribution.

That said, looking at @n8henrie 's excellent notes in protocol_notes.md it looks like he's expecting the Echo to send a Search Type of ST: urn:Belkin:device:** where as I don't see that at all from my echo, only ST: ssdp:alland ST: upnp:rootdevice

Correct, used to, but this seems to have changed.

In terms of source changes, I'm thinking of changing the MX response to always use 15 and ignore the value sent in the discovery request.

I thought I'd read in the official UPnP spec this should be less than 5... here it is.

wingett commented 6 years ago

Goes to show, I should have read the manual first, shouldn't I? (Always RTFM!) I didn't know what the MX component was, but obviously now I see it is a timeout.

ST appears to be different between the two. I've double-checked and the firmware is definitely the same on both the Dot & the Echo so it is looking more and more like a bug in the device rather than anything Fauxmo is doing wrong.

GlennPegden2 commented 6 years ago

Are the dot and the echo both sending the same ssdp discovery multicasts (ST: ssdp:all and ST: upnp:rootdevice).

I think I can explain why the Echo isn't working, but not why the dot is (assuming the same discovery message are sent by the dot).

RaphaelVogel commented 6 years ago

Didn't read/understand all things here, but maybe it's valuable information. Other emulators do also have problems. In their case it's some timing issue. Maybe it also helps here: https://github.com/bwssytems/ha-bridge/issues/860

n8henrie commented 6 years ago

Interesting thread. Looks like they’re going through similar steps to try to debug the issue (e.g. messing with MX).

GlennPegden2 commented 6 years ago

I finally have a physical WeMo switch and a lab that allows me to sniff the traffic in and out of it (I haven't put the echo plus in there yet, but may do if just monitoring the WeMo doesn't highlight anything useful)

The key difference I've noticed so far is fauxmo responds to ssdp:all where as the real device doesn't (it only responds to upn:prootdevice).

The body sent in the upnp:rootdevice is nearly identical

Real WeMo sends

HTTP/1.1 200 OK CACHE-CONTROL: max-age=86400 DATE: Sun, 01 Apr 2018 17:50:48 GMT EXT: LOCATION: http://192.168.95.37:49153/setup.xml OPT: "http://schemas.upnp.org/upnp/1/0/"; ns=01 01-NLS: 8d1dd87c-1dd2-11b2-af21-e50a56279fe9 SERVER: Unspecified, UPnP/1.0, Unspecified X-User-Agent: redsonic ST: upnp:rootdevice USN: uuid:Socket-1_0-221713K1100581::upnp:rootdevice

FauxMo sends

HTTP/1.1 200 OK CACHE-CONTROL: max-age=86400 DATE: Sat, 24 Feb 2018 21:29:09 GMT EXT: LOCATION: http://192.168.3.189:12344/setup.xml OPT: "http://schemas.upnp.org/upnp/1/0/"; ns=01 01-NLS: 23e13314-9aa4-4c8c-a357-c9100c7dbd18 SERVER: Fauxmo, UPnP/1.0, Unspecified ST: upnp:rootdevice USN: uuid:Socket-1_0-fd393afe-d967-3c03-bae4-636bca39a090::upnp:rootdevice

So that's the addition of an X-User-Agent header, the formatting of the UID within the USN and the Server name in the SERVER: header.

I've previously tried changing the fauxmo nic mac address to be a Belkin one to no avail (though I may try that again now I can clone it from an actual WeMo address) and I haven't yet dropped the Echo Plus into my lab environment to see if between ssdp/upnp response and the /setup.xml requrest (not) happening, if there is a sneaky call off to AWS to validate the device is legit or something (I can see the WeMo is sending data out to AWS periodically though).

If anyone wants pcaps, just shout.

n8henrie commented 6 years ago

This is great, thanks.

Are you using the Belkin / wemo "Alexa Skill"?

Can we get the full verbose Fauxmo log when doing a "discover devices" with your Echo Plus (with the sample config)?

If nothing obvious, a pcap of the interaction between your WeMo devices and the Plus may be helpful.

GlennPegden2 commented 6 years ago

Nope, I'm not using the skill

So, here's the pcap of the Echo Plus doing discovery of both the WeMo and FauxMo. I've filtered out some SSDP traffic from a couple of other hosts on the network for clarity, but it should include everything else to/from the WeMo and FauxMo during the discovery stage.

pcaps EchoPlus-WeMo-FauxMo2.zip

Fauxmo Config config.json.txt

IP addresses

Echo Plus - 192.168.95.31 WeMo - 192.168.95.37 FauxMo - 192.168.95.5

One thing I have just noticed now, the line endings. WeMo is using CR LF, where as FauxMo is using just LF.

GlennPegden2 commented 6 years ago

Boom!

Changing

        response = '\n'.join([
            'HTTP/1.1 200 OK',
            'CACHE-CONTROL: max-age=86400',
            f'DATE: {date_str}',
            'EXT:',
            f'LOCATION: {location}',
            'OPT: "http://schemas.upnp.org/upnp/1/0/"; ns=01',
            f'01-NLS: {uuid.uuid4()}',
            'SERVER: Fauxmo, UPnP/1.0, Unspecified',
            f'{discover_pattern}',
            f'USN: {usn}',
            ]) + '\n\n'
        asyncio.ensure_future(
                self._send_async_response(response.encode('utf8'), addr,
                                          mx)
                )

to

        response = '\r\n'.join([
            'HTTP/1.1 200 OK',
            'CACHE-CONTROL: max-age=86400',
            f'DATE: {date_str}',
            'EXT:',
            f'LOCATION: {location}',
            'OPT: "http://schemas.upnp.org/upnp/1/0/"; ns=01',
            f'01-NLS: {uuid.uuid4()}',
            'SERVER: Fauxmo, UPnP/1.0, Unspecified',
            f'{discover_pattern}',
            f'USN: {usn}',
            ]) + '\r\n\r\n'
        asyncio.ensure_future(
                self._send_async_response(response.encode('utf8'), addr,
                                          mx)
                )

in protocols.py has now caused it to discover all the fauxmo devices!

n8henrie commented 6 years ago

Huh, that's odd. I was using CRLF previously but went to LF after a fair amount of testing didn't make any difference. I wonder if something changes or is different with the Echo Plus.

Will test and get back to you, thanks and good catch.

wingett commented 6 years ago

@Glenn - damn good catch! I reckon because I once installed the Wemo skill on my Echo it messed everything up in terms of capturing info. Even tried a complete reset of the device and it still doesn’t help with the capture process.

So just to clarify, you have a regular Echo 2nd gen (and no other Echo devices on the network) and you can now discover fauxmo devices?

On 2 Apr 2018, at 18:21, Glenn Pegden notifications@github.com<mailto:notifications@github.com> wrote:

Boom!

Changing

    response = '\n'.join([
        'HTTP/1.1 200 OK',
        'CACHE-CONTROL: max-age=86400',
        f'DATE: {date_str}',
        'EXT:',
        f'LOCATION: {location}',
        'OPT: "http://schemas.upnp.org/upnp/1/0/"; ns=01',
        f'01-NLS: {uuid.uuid4()}',
        'SERVER: Fauxmo, UPnP/1.0, Unspecified',
        f'{discover_pattern}',
        f'USN: {usn}',
        ]) + '\n\n'
    asyncio.ensure_future(
            self._send_async_response(response.encode('utf8'), addr,
                                      mx)
            )

to

    response = '\r\n'.join([
        'HTTP/1.1 200 OK',
        'CACHE-CONTROL: max-age=86400',
        f'DATE: {date_str}',
        'EXT:',
        f'LOCATION: {location}',
        'OPT: "http://schemas.upnp.org/upnp/1/0/"; ns=01',
        f'01-NLS: {uuid.uuid4()}',
        'SERVER: Fauxmo, UPnP/1.0, Unspecified',
        f'{discover_pattern}',
        f'USN: {usn}',
        ]) + '\r\n\r\n'
    asyncio.ensure_future(
            self._send_async_response(response.encode('utf8'), addr,
                                      mx)
            )

in protocols.py has now caused it to discover all the fauxmo devices!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/n8henrie/fauxmo/issues/49#issuecomment-377984258, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ADnyTmIDwcKsfQvkdo8YQVU8uW6lOjjgks5tkl4YgaJpZM4R1wf5.

GlennPegden2 commented 6 years ago

@wingett

I can't check the firmware from here, but it's an Echo Plus (so same gen as 2nd gen standard Echo, I believe) purchased in December. The fact we're both in the UK may or may not just be a coincidence. It's the only Echo device I have and the first attempt at discovery after making the changes above, it discovered all the fauxmo devices again (I haven't done subsequent test to remove them all again and rediscover).

@n8henrie

Do you want me to bother with a pull request? I'd imagine for such a simple change it's not worth it, but I'm happy to if you want.

n8henrie / fauxmo

Echo 2 f/w 599473420 not finding devices #49

My Issue

WHYT