Core: Belkin WeMo plugs and switches are not being discovered

[jkseamons]

The problem

Upgraded from 0.110.5 to 0.111.2. Belkin WeMo plugs and switches are not being discovered. Changed discovery to static and added devices as static. 111 still not finding devices. Reverting back to 110.5 fixed issue.

Environment

• Home Assistant Core release with the issue: 0.111.2
• Last working Home Assistant Core release (if known): 0.110.5
• Operating environment (Home Assistant/Supervised/Docker/venv): Docker
• Integration causing this issue: WeMo
• Link to integration documentation on our website: https://www.home-assistant.io/integrations/wemo/

Problem-relevant configuration.yaml

wemo:
  discovery: false
  static:
    - 192.168.17.52
    - 192.168.17.53
    - 192.168.17.55
    - 192.168.17.56
    - 192.168.17.57

Traceback/Error logs

Logger: homeassistant.components.wemo
Source: components/wemo/__init__.py:169
Integration: Belkin WeMo (documentation, issues)
First occurred: 1:52:10 PM (5 occurrences)
Last logged: 1:52:10 PM

Unable to get description url for WeMo at: 192.168.17.53
Unable to get description url for WeMo at: 192.168.17.52
Unable to get description url for WeMo at: 192.168.17.57
Unable to get description url for WeMo at: 192.168.17.56
Unable to get description url for WeMo at: 192.168.17.55

Additional information

I've also checked the state in dev tools. The state is unavailable.

2020-06-13 13:51:41 INFO (MainThread) [homeassistant.setup] Setting up wemo
2020-06-13 13:51:42 INFO (MainThread) [homeassistant.setup] Setup of domain wemo took 0.3 seconds.
2020-06-13 13:51:42 INFO (Wemo HTTP Thread) [pywemo.subscribe] Listening on port 8989
2020-06-13 13:51:42 DEBUG (MainThread) [homeassistant.components.wemo] Adding statically configured WeMo devices...
2020-06-13 13:51:46 DEBUG (MainThread) [homeassistant.components.ssdp] Discovered wemo at http://192.168.17.153:49153/setup.xml
2020-06-13 13:51:46 DEBUG (MainThread) [homeassistant.components.ssdp] Discovered wemo at http://192.168.17.155:49154/setup.xml
2020-06-13 13:51:46 DEBUG (MainThread) [homeassistant.components.ssdp] Discovered wemo at http://192.168.17.156:49153/setup.xml
2020-06-13 13:52:10 ERROR (SyncWorker_0) [homeassistant.components.wemo] Unable to get description url for WeMo at: 192.168.17.53
2020-06-13 13:52:10 ERROR (SyncWorker_3) [homeassistant.components.wemo] Unable to get description url for WeMo at: 192.168.17.52
2020-06-13 13:52:10 ERROR (SyncWorker_4) [homeassistant.components.wemo] Unable to get description url for WeMo at: 192.168.17.57
2020-06-13 13:52:10 ERROR (SyncWorker_7) [homeassistant.components.wemo] Unable to get description url for WeMo at: 192.168.17.56
2020-06-13 13:52:10 ERROR (SyncWorker_8) [homeassistant.components.wemo] Unable to get description url for WeMo at: 192.168.17.55
2020-06-13 13:52:10 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event component_loaded[L]: component=wemo>
2020-06-13 13:52:55 DEBUG (MainThread) [homeassistant.components.ssdp] Discovered wemo at http://192.168.17.152:49153/setup.xml
2020-06-13 13:52:55 DEBUG (MainThread) [homeassistant.components.ssdp] Discovered wemo at http://192.168.17.157:49153/setup.xml

[hail2victors]

Same issue. Can no longer control wemo devices

[probot-home-assistant[bot]]

wemo documentation
wemo source
_{^{(message by IssueLinks)}}

[cannondale0815]

+1 same issue

[MikeFez]

+1, have not been able to control them as well. In my case, this happened around the time I activated the new "Wemo Account" that they're herding everyone into. I'm not sure if the account activation is the cause here or not.

[orbsmiv]

+1. The problem seems to be with WeMo and 0.111.x (I've tried each of the 0.111.x patch releases) as I'm running in Docker and have reverted to 0.110.7 and my WeMo devices are working again without issue.

Further notes:

• WeMo devices are not found when discovery: true.
• Using discovery: false and setting the devices' static IPs makes them _available_ in HA but with very intermittent connectivity, i.e. only a fraction of the WeMo Motion's activity is being registered in HA and the WeMo Switch is behaving erratically, e.g. switch status often doesn't reflect the device's actual state.
• I haven't created a _Wemo Account_ as referred to above.

[petrfaitl]

+1
Only one out of seven devices not discovered. It is a dimmer switch.

I went ahead and wiped the core.device-registry, just in case some settings have changed. but still no discovery.

• Both discovery: true and static IPs set.
• Wemo account created prior to the issue.
• Hassio 0.111.4

[FreelancerJay]

+1
Only have 1 wemo device, and HomeAssistant won't discover it.
Have not set up a Wemo account
Setup in the Integration UI, with no yaml configuration done.
Running Hassio 0.111.4 in Docker
Raspberry Pi 4, connected to network via ethernet
Wemo Switch v1, current firmware

[ertraid]

+1
2 wemo device, worked perfectly for the longest time, now cannot connect... tried discovery, manual IP or integration UI... none work.
Have not set up a Wemo account, but upgrading to the latest firmware did not fix it.
Running Hassio 0.112.2 in Docker ... errors happening since a couple of versions... not sure exactly when they started

EDIT: 0.112.4 seems to have fixed it (static IP config)..will test.

[ioannispelelis]

I am unsure if it is related but i am not using the integration via the configuration.yaml but directly from the menu/configuration/integrations.
I can see all 6 of my plugs through the belkin wemo integration and even set up sensors for the Watt and WattHour consumption.

However regularly some of the plugs will show as unavailable within the day.
And if I reboot HomeAssistant sometimes a plug will show as unavailable after the reboot. If that happens during the boot of HA then the plug will never activate in HA.. I will have to reboot over and over until some point all Wemo Plugs are detected on boot..
After a "clean" boot where all wemo plugs are detected it might happen that some plugs are temporarily unavailable but at least they come back after a few seconds..
This happened even before i created a Wemo Account. I also have updated to the latest Wemo Plug Firmware (around the time they introduced wemo accounts)

I just updated to HA 0.112.4 (installed on a VM on Docker). It looks like after update and reboot from 0.112.3 to 0.112.4 it still happenned with one plug being unavailable. I had to reboot a second time and the missing plug appeared again.

[FreelancerJay]

EDIT: 0.112.4 seems to have fixed it (static IP config)..will test.

@ertraid did it turn out to be fixed in 0.112.4?

[dlpnet]

I have the same issue, not all my Wemo are discovered:
hassos: 4.11
homeassistant: 0.113.0

[orbsmiv]

I've just updated to 0.113.0 and the issue is still as I described previously. In my experience the most recent reliable version for WeMo is still 0.110.7.

[orbsmiv]

From the logs it looks as though all of the activity is being captured by pywemo:

home-assistant-service_1   | 2020-07-24 00:33:17 INFO (Wemo HTTP Thread) [pywemo.subscribe] Received event from <WeMo Motion "Motion-dresser">(192.168.1.1) - BinaryState 0
home-assistant-service_1   | 2020-07-24 00:33:17 DEBUG (Wemo HTTP Thread) [homeassistant.components.wemo.binary_sensor] Subscription update for Motion-dresser
home-assistant-service_1   | 2020-07-24 00:33:17 DEBUG (Wemo HTTP Thread) [pywemo.ouimeaux_device] subscription_update BinaryState 0

However, the state-change of the WeMo device is only very occasionally getting passed to HA – here's an example of when it works: (It took about a minute of waving at the sensor to trigger this!)

home-assistant-service_1   | 2020-07-24 00:38:44 INFO (Wemo HTTP Thread) [pywemo.subscribe] Received event from <WeMo Motion "Motion-dresser">(192.168.1.1) - BinaryState 1
home-assistant-service_1   | 2020-07-24 00:38:44 DEBUG (Wemo HTTP Thread) [homeassistant.components.wemo.binary_sensor] Subscription update for Motion-dresser
home-assistant-service_1   | 2020-07-24 00:38:44 DEBUG (Wemo HTTP Thread) [pywemo.ouimeaux_device] subscription_update BinaryState 1
home-assistant-service_1   | 2020-07-24 00:38:46 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=binary_sensor.motion_dresser, old_state=<state binary_sensor.motion_dresser=off; friendly_name=Motion-dresser @ 2020-07-24T00:24:16.911475+01:00>, new_state=<state binary_sensor.motion_dresser=on; friendly_name=Motion-dresser @ 2020-07-24T00:38:46.993648+01:00>>
home-assistant-service_1   | 2020-07-24 00:38:46 DEBUG (MainThread) [homeassistant.components.websocket_api.http.connection.2918212824] Sending {'id': 15, 'type': 'event', 'event': <Event state_changed[L]: entity_id=binary_sensor.motion_dresser, old_state=<state binary_sensor.motion_dresser=off; friendly_name=Motion-dresser @ 2020-07-24T00:24:16.911475+01:00>, new_state=<state binary_sensor.motion_dresser=on; friendly_name=Motion-dresser @ 2020-07-24T00:38:46.993648+01:00>>}
home-assistant-service_1   | 2020-07-24 00:38:47 DEBUG (MainThread) [homeassistant.components.websocket_api.http.connection.2915205904] Sending {'id': 2, 'type': 'event', 'event': <Event state_changed[L]: entity_id=binary_sensor.motion_dresser, old_state=<state binary_sensor.motion_dresser=off; friendly_name=Motion-dresser @ 2020-07-24T00:24:16.911475+01:00>, new_state=<state binary_sensor.motion_dresser=on; friendly_name=Motion-dresser @ 2020-07-24T00:38:46.993648+01:00>>}

[esev]

@orbsmiv see https://github.com/home-assistant/core/issues/37544 for the issue of the state not changing properly.

[esev]

Looking at this issue a bit more, it sounds like three different issues are being reported.

1. Some devices aren't being auto-discovered at startup. These devices remain unavailable in HA and will not be available again until HA is restarted. Adding the devices to the static part of the configuration.yaml file helps solve this but also isn't entirely a reliable solution.
2. Devices are sometimes showing as unavailable but as long as they were detected at startup they eventually start showing as available again. This can happen multiple times.
3. The HA state is not being updated quickly when the device is turned on or motion is detected. Pressing the buttons in the UI causes the device to turn on, but the button in the HA UI then behaves weirdly and turns off and on.

Does this sound accurate? Are there more issues?

For 2, are there corresponding Lost connection to messages in the logs for both 0.110 and newer releases? Is this a new issue or has it been happening for a while and was just uncovered now because of 1 & 3?

For 3, I think the root cause has been identified in https://github.com/home-assistant/core/issues/37655 and a fix is underway.

[jkseamons]

@esev I am currently on 110.5. Upgrading to 111.0 or anything newer results with all my devices (3 outlets, 2 switches) as unavailable. I have restarted HA, my router, and power cycled the devices. Currently they are set to auto discover. Adding the devices as static has had no affect on them showing as available.

[orbsmiv]

@esev thanks for summarising and, at least for me, this is broadly accurate. A couple of differences...

1. Post-0.110.7 my WeMo devices haven't appeared _unless_ I've added them to the static part of the config – auto-discovery has been completely broken. I've had a perennial issue (since 2016) with WeMo devices (particularly WeMo Motion) where auto-discovery is unreliable and historically I've done as you suggest, i.e. restart HA until they appear.
2. I haven't experienced this – once a device is connected it's remained available, although not reporting re your 3rd point.
3. Yes, although in the case of the WeMo Motion the state is not being updated slowly but rather not being updated at all. Your description of the UI switch is accurate.

Thanks for all you work on this – looking at the other mentioned issues you seem to have been busy!

[esev]

Let's try to tackle 1. Are you able to get a command prompt/shell on your HA docker container or VM? If so, here's what I'd need to get started.

One thing that changed in pywemo was the way that it detects your IP address. Start python and confirm that your IP address shows up when you run ifaddr.get_adapters(). See below:

/config # python
Python 3.8.3 (default, Jul 10 2020, 17:15:14) 
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ifaddr
>>> print(ifaddr.get_adapters())

If that works, then try this from within the same Python shell:

>>> import pywemo
>>> print(pywemo.discover_devices())

Run that last statement print(pywemo.discover_devices()) a few times to see if it ever detects the devices. If this manual discovery is working, your devices should be printed in the output. I don't always see all my devices being printed when I run this. But I'm curious to see what results others have.

Let me know how that works for you. Also, if you could post the model number for your device that would be helpful.

[petrfaitl]

@esev having tried your instructions to no avail (no rediscovery) I have decided to reset the Wifi settings on the switch (dimmer).

Eventually, the switch is being discovered again.
Currently, I have autodiscovery: true and static IP assignments as well.

For completeness, I'm using Unifi equipment USG, 8-port Switch, AP-AC-PRO, AP-AC-LR. Both 2G and 5G are on.

BTW, I had noticed that whilst I was able to control the switch from the Wemo app, when I went into the reset settings in the app it wouldn't allow me to reset/change anything, claiming I need to be on the same Wifi network. After my manual reset at the switchplate, all is good within the Wemo app and hassio.

So, all the issues would point towards the switch, rather than hassio.

Hope it helps.

Thanks, guys.

[esev]

@petrfaitl that's very interesting. Thanks for running the tests and reporting back what worked for you.

[kpine]

@esev Discovery in HA has not worked for me for some time, not sure when it started but I had previously tried the experiment of manually calling pywemo.discover_devices() and it would always return an empty list. I switched to a static IP (which works fine) when I found this issue. I thought that maybe being in the docker environment was the problem, even though I'm using host networking, so I tried the same thing in the host OS but no difference.

Today I realized I could do the same test in other environments and hosts. I was surprised by the results. All of the hosts/environments are in the same network subnet as the Wemo Mini, 192.168.1.0/24. The Wemo has a static dhcp lease. All hosts except the Macbook are wired, and each one shows their own IP address in the results from ifaddr.get_adapters().

Host 1: Inside the HA container:

/config # python3
Python 3.8.3 (default, Jul 10 2020, 18:54:27)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pywemo
>>> print(pywemo.discover_devices())
[]

Host 1: directly from the host's python3 installation (Raspberry Pi, Debian Buster):

dietpi@hasspi:~$ python3
Python 3.7.3 (default, Dec 20 2019, 18:57:59)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pywemo
>>> print(pywemo.discover_devices())
[]

Host 3: A Debian Buster VM (a guest of Host 3, bridged IP):

$ python3
Python 3.7.3 (default, Dec 20 2019, 18:57:59)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pywemo
>>> print(pywemo.discover_devices())
[<WeMo Switch "Wemo Mini">]

Host 4: Windows 10 WSL (Python 2)

$ python
Python 2.7.12 (default, Nov 12 2018, 14:36:49)
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pywemo
>>> print(pywemo.discover_devices())
[<WeMo Switch "Wemo Mini">]

Host 5: Macbook Air w/ MacOS 10.13.6 High Sierra, using a Nix-installed python3

% python3
Python 3.8.3 (default, Jul  6 2020, 11:34:28)
[Clang 7.1.0 (tags/RELEASE_710/final)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import pywemo
>>> print(pywemo.discover_devices())
[]

Host 6: Freenas Jail

root@mpd:~ # python3
Python 3.7.6 (default, Jan 30 2020, 01:17:40)
[Clang 8.0.0 (tags/RELEASE_800/final 356365)] on freebsd11
Type "help", "copyright", "credits" or "license" for more information.
>>> import pywemo
>>> print(pywemo.discover_devices())
[<WeMo Switch "Wemo Mini">]

I was expecting everyone to show empty results, but strangely it's not the case; what's the difference?

[esev]

@kpine thanks for sharing. That's a very interesting result!

Could you try increasing the log level and see if that surfaces anything interesting?

>>> import logging
>>> logging.basicConfig(level=logging.DEBUG)
>>> import pywemo
>>> print(pywemo.discover_devices())

I'm also tinkering with pywemo to see if I can increase the reliability of discovery. You're welcome to try that and see if it improves things. You'll need to replace the file in your python site-packages directory /usr/local/lib/python3.8/site-packages/pywemo/ssdp.py for the HA container.

https://github.com/esev/pywemo/blob/ssdp/pywemo/ssdp.py

[esev]

@kpine for the Host 5: Macbook Air, I wonder if it's failing due to the default firewall settings.

[kpine]

@esev Funny, I was in the middle of a long write up, including that, so I'll just scrap it. On the Mac I was prompted this time to allow python3.8. Allowing it does work, if I block it it stops working again.

For the RPi, I think the discovery timeout is too low (only 5 seconds it looks like). I added some debug logging to the original ssdp.py file and it returns out of the loop without discovering anything because of the seconds_left <= 0 check. Is there a way I can increase it in the interpreter?

Your version of ssdp.py works just fine.

[esev]

@kpine It doesn't look like there is an easy way to increase the timeout with pywemo.discover_devices(). Under the hood that calls pywemo.ssdp.scan(). You can pass that method a timeout parameter print(pywemo.ssdp.scan(timeout=60))

Your version of ssdp.py works just fine.

Just to clarify, does it work inside the HA container?

[kpine]

I think it's taking too long to enumerate all of the sockets and send the SSDP requests, and by the time it's done the timeout is already expired and it never polls the sockets.

[kpine]

Just to clarify, does it work inside the HA container?

Yours works inside and outside the container.

[esev]

I think what you described in your previous comment is correct. It could be taking too long to get to parsing the responses before it times-out. One of the things I changed was to make it always try to process all responses before hitting that timeout. I'll send that change as a PR to pywemo.

[kpine]

Yep, looks that way. I added some more debug logging just to confirm, and bumped the timeout to 30, and that works. As you can see, it takes a hair over 5 seconds just to build and send the ssdp requests, which would cause it to exit early with a 5 second timeout. With 30 seconds it idles for a long time as the responses were received nearly instantly.

sending ssdp requests 0:00:00.000020
done 0:00:05.015394
1 sockets are ready 0:00:05.015665
checking socket 0 response 0:00:05.015726
found entry with valid description
1 sockets are ready 0:00:05.039055
checking socket 0 response 0:00:05.039137
found entry with valid description
0 sockets are ready 0:00:30.064761
seconds_left expired: 0, total time: 0:00:30.065165, entries: 1
[<WeMo Switch "Wemo Mini">]

[esev]

That's a good observation. I just moved the start of that timer to after the initial request is sent in my PR. That way all time is spent waiting for the responses.

[elliotthome]

Newbie, Really sorry,if I am interrupting this discussion.

I also have a terrible time while upgrading Hassio 108.6 to 112.x
We have following Wemo devices that were working without much hiccups until 108.6.

1x Wemo maker (garage door opener)
15x Wemo LED bulbs.
6x Wemo Switches/2 insight switches.

After upgrading to 112.x, none of the Wemo devices discovered. So about 80% of our home smart devices and automatons went offline.

So reverted back to 108.6 and now all Wemos are working as usual. So I have no idea , why Wemo discovery broken down in these recent upgraded releases!

But now stuck with 108.6 release without a hope to upgrade any further. So really looking forward for some good news. Thanks.
FYI: All devices are in Ubiquiti network & HA in RPI.

(Background: Mechanical engineer ~ close to zero knowledge in coding etc, but using Homeasistant for past 4 years, by reading various forums/posts and tips that posted by awesome peoples like you!! Thanks a lot for all that great work!).

[esev]

@esev I am currently on 110.5. Upgrading to 111.0 or anything newer results with all my devices (3 outlets, 2 switches) as unavailable. I have restarted HA, my router, and power cycled the devices. Currently they are set to auto discover. Adding the devices as static has had no affect on them showing as available.

@jkseamons this is interesting. The fact that it still doesn't work after configuring the devices as static could indicate another issue beyond discovery. Are you using HA on a Raspberry Pi? If you unplug and plug back in one of the outlets that is configured statically, does that help?

Are you able to login to your HA container, or able to install pywemo on another computer/VM? If so, having the output from the commands below could help troubleshoot this more.

/config # python
Python 3.8.3 (default, Jul 10 2020, 17:15:14) 
[GCC 9.3.0] on linux
>>> import logging
>>> logging.basicConfig(level=logging.DEBUG)
>>> import pywemo
>>> print(pywemo.ssdp.scan(timeout=60))

[esev]

@jkseamons looking at your original description of the problem, it looks like there used to be 5 devices being discovered.

2020-06-13 13:51:46 DEBUG (MainThread) [homeassistant.components.ssdp] Discovered wemo at http://192.168.17.153:49153/setup.xml
2020-06-13 13:51:46 DEBUG (MainThread) [homeassistant.components.ssdp] Discovered wemo at http://192.168.17.155:49154/setup.xml
2020-06-13 13:51:46 DEBUG (MainThread) [homeassistant.components.ssdp] Discovered wemo at http://192.168.17.156:49153/setup.xml
2020-06-13 13:52:55 DEBUG (MainThread) [homeassistant.components.ssdp] Discovered wemo at http://192.168.17.152:49153/setup.xml
2020-06-13 13:52:55 DEBUG (MainThread) [homeassistant.components.ssdp] Discovered wemo at http://192.168.17.157:49153/setup.xml

The IP address for these devices are 192.168.17.(152,153,155,156,157).

In the static configuration, there were devices with these IP addresses 192.168.17.(52,53,55,56,57)

It seems coincidental that the last digit for each of the IP addresses differ by exactly 100. Is it possible that there was a typo in the static configuration?

Note: This doesn't take away from the fact that discovery is broken. I'm only trying to understand if there are additional things that are broken too and try to work toward identifying what might be causing these breakages.