Wemo switches unavailable in HASS but still controllable by mobile Wemo app #62224

DavidRBailey · 2021-12-17T17:56:06Z

The problem

Some Wemo switches in Home Assistant gray out in the dashboard showing they are unavailable, yet they remain available and controllable from the Wemo iOS/Android app.

Restarting the Wemo switch resolves the problem, but it eventually happens again.

The network is reporting no errors with good connectivity to the switches.

The issue seems most common with the Wemo Light Switch 2nd Gen or V2 (WLS040) and Wemo Smart Light Switch 3-Way (WLS0403), and doesn't seem to be common with the Wemo Smart Dimmer Switch (WDS060).

What version of Home Assistant Core has the issue?

2021.11.5

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Wemo

Link to integration documentation on our website

https://www.home-assistant.io/integrations/wemo/

Example YAML snippet

No response

Anything in the logs that might be useful for us?

2021-12-12 17:14:18 ERROR (Wemo Events Thread) [pywemo.ouimeaux_device] Unable to reconnect with Bathroom Fan

2021-12-12 17:14:18 WARNING (Wemo Events Thread) [pywemo.subscribe] Resubscribe error for <Subscription basicevent "Downstairs Bathroom Fan"> (HTTPConnectionPool(host='192.168.7.97', port=49153): Max retries exceeded with url: /upnp/event/basicevent1 (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f5dfd9610>: Failed to establish a new connection: [Errno 111] Connection refused'))), will retry in 60s

2021-12-12 17:14:18 ERROR (Wemo Events Thread) [pywemo.ouimeaux_device] Unable to re-probe wemo <WeMo LightSwitch "Downstairs Bathroom Fan"> at 192.168.7.97

2021-12-12 17:14:23 ERROR (Wemo Events Thread) [pywemo.ouimeaux_device] Unable to reconnect with Downstairs Bathroom Fan

2021-12-12 17:14:29 WARNING (SyncWorker_7) [urllib3.connectionpool] Retrying (Retry(total=0, connect=None, read=None, redirect=None, status=None)) after connection broken by 'NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f89acd640>: Failed to establish a new connection: [Errno 111] Connection refused')': /upnp/control/basicevent1

2021-12-12 17:14:29 WARNING (SyncWorker_7) [pywemo.ouimeaux_device.api.service] Error communicating with Downstairs Bathroom Fan at 192.168.7.97:49153, HTTPException(MaxRetryError("HTTPConnectionPool(host='192.168.7.97', port=49153): Max retries exceeded with url: /upnp/control/basicevent1 (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f53027760>: Failed to establish a new connection: [Errno 111] Connection refused'))")) retry 1

2021-12-12 17:14:29 ERROR (SyncWorker_7) [pywemo.ouimeaux_device] Unable to re-probe wemo <WeMo LightSwitch "Downstairs Bathroom Fan"> at 192.168.7.97

2021-12-12 17:14:34 ERROR (SyncWorker_7) [pywemo.ouimeaux_device] Unable to reconnect with Downstairs Bathroom Fan

2021-12-12 17:14:34 WARNING (SyncWorker_7) [urllib3.connectionpool] Retrying (Retry(total=5, connect=None, read=None, redirect=None, status=None)) after connection broken by 'NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f5a6f29d0>: Failed to establish a new connection: [Errno 111] Connection refused')': /upnp/control/basicevent1

2021-12-12 17:14:38 WARNING (SyncWorker_7) [urllib3.connectionpool] Retrying (Retry(total=4, connect=None, read=None, redirect=None, status=None)) after connection broken by 'NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f8d543940>: Failed to establish a new connection: [Errno 111] Connection refused')': /upnp/control/basicevent1

Additional information

See other similar reports documented here- https://community.home-assistant.io/t/wemo-switches-unavailable-in-hass-but-can-still-be-controlled-by-mobile-wemo-app/360147

probot-home-assistant · 2021-12-17T17:56:09Z

Hey there @esev, mind taking a look at this issue as it has been labeled with an integration (wemo) you are listed as a code owner for? Thanks!
_{^{(message by CodeOwnersMention)}}

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

esev · 2021-12-17T18:27:24Z

Connection refused is odd.

Are these devices on the same LAN/subnet as Home Assistant? Are the devices being discovered automatically, or are these devices using static configuration.

mlohus93 · 2021-12-18T02:55:24Z

Though I am not the original poster, I have the same problem as described, though rebooting HA rarely resolves the unavailable devices... occasionally they wake up themselves, but only consistent way to get them back is to reboot the device. Agree its the V2's, in my case it's the V2 single switch, and the V2 3-way switches. I do not have the Wemo dimmers. I do have mine using the Static configuration in my configuration.yaml file... all of my Wemos are defined with DHCP reservations. I had the problem with my Apple AirPort Extreme network (one as Router, two more setup as Access Points with wired connection to router). I recently replaced with an Eero WiFi 6 mesh system (router and two nodes). Same problems exist. I saw in the Wemo integration a recommendation to have port 8989 open on your firewall... unfortunately I cannot open it across all/multiple IPs (or even all Wemo IPs), only port forwarding a port to a single IP/MAC address; same scenario with Apple network and Eero network. Finally yes, all on the same LAN/Subnet as Home Assistant. Incidentally, the Wemos which have gone Unavailable are not only alive and kicking in the Wemo App as mentioned by OP, but they are also fully functional via HomeKit all the time they are unavailable in Home Assistant. I am running HA Core 2021.12.2, Supervisor 2021.12.2, OS Home Assistant OS 7.0 on an Home Assistant Blue (ODroid). I have a backup HA system powered down and every couple of months brought up long enough to update and back shutdown... it is an Intel box running Debian 11 Supervised HA. However a couple of months ago (and again a couple weeks ago) I ran it instead of my HA-Blue for a couple of days only to find it has the same problem with Wemos going unavailable. Thought maybe that info might be helpful.

esev · 2021-12-18T03:21:20Z

@mlohus93 are you seeing the same Failed to establish a new connection: [Errno 111] Connection refused in the log messages? Or are you seeing Connection to <<ip_address>> timed out?

DavidRBailey · 2021-12-18T19:13:27Z

Connection refused is odd.

Are these devices on the same LAN/subnet as Home Assistant? Are the devices being discovered automatically, or are these devices using static configuration.

In my case, they are on the same LAN/subnet. Home Assistant is on an ethernet cable and the switches are on Wifi on the same subnet. They are being automatically discovered, but have static DHCP assignments, so their IP addresses don't change.

I wonder if HASS has a lower-bar for thinking a device is unavailable than the Wemo app? Perhaps it doesn't always respond within a specified timeframe?

The crazy thing is HASS shows the switch as unavailable, and even if I try to switch it, it doesn't work, while at the same time, I can go into the Wemo app and turn the light or fan on and off using the same network connection.

esev · 2021-12-18T19:27:36Z

Connection refused means the device is connected to wifi on the local subnet and is refusing requests on the local uPnP API. It's responding with the equivalent of "I don't support this service".

My guess is the device itself is in some kind of hung state where it's not responding on the local network and not responding to physical presses, but is still communicating with Belkin's cloud service.

AFAIK there is no way to communicate with the device when it gets into this state. And unfortunately, Belkin's cloud service does not have a published API.

DavidRBailey · 2021-12-18T23:41:04Z

So what you're saying is the app is using a different method of communication with the switches than HASS? Is there a way to leverage the other method?

esev · 2021-12-18T23:52:35Z

That's correct. The WeMo devices have at least two communications methods:

There is an UPnP API that can be accessed on the device itself.
And there is a cloud service that Belkin runs that the device connects to.

Home Assistant uses (1) and the Belkin WeMo app uses (2). Belkin does not make their cloud service available publicly. So there is no way for Home Assistant (or pywemo) to use that.

It looks like when the device gets into this state, the local UPnP service gets disabled somehow on the device. The only way to restart it may be to restart the device itself. It may be that the device is defective too, or Belkin has shipped them with buggy firmware.

DavidRBailey · 2021-12-19T01:10:08Z

This is a long shot, but is there any way to remotely request a switch restart that might resolve the issue without requiring someone to walk to the switch and manually reset it?

Maybe something like- device.reset(data=False, wifi=False)

https://pypi.org/project/pywemo/#device-reset-and-setup

esev · 2021-12-19T01:38:17Z

This is a long shot, but is there any way to remotely request a switch restart that might resolve the issue without requiring someone to walk to the switch and manually reset it?

Maybe something like- device.reset(data=False, wifi=False)

https://pypi.org/project/pywemo/#device-reset-and-setup

I wish it would work. But pywemo uses the local UPnP API. And it's this API that has the Connection refused issue.

DavidRBailey · 2021-12-19T01:41:20Z

I read here that the Wemo UPnP service is buggy and can crash if an invalid argument is sent to it. Is it possible that there could be bad commands going to the Wemo switches causing the service to fail?

esev · 2021-12-19T01:48:26Z

That is possible, yes. If that is the case there should be a log message about it. Do you see any other log messages related to pywemo/wemo?

DavidRBailey · 2021-12-19T02:52:53Z

I'm opening a ticket with Wemo. I'll reset the switches and recheck the logs.

DavidRBailey · 2021-12-19T03:05:09Z

I can confirm @mlohus93 's report that the Wemo Smart Light Switch 3-Way (WLS0403) is also showing this same behavior.

@esev As far as HASS goes, the errors in the log just stop occurring once the Wemo switch is restarted and HASS can again communicate with it. Is there a debug mode I should enable in HASS to get more information?

At this point, the system apparently functions fine until the next Wemo switch UPnP service failure.

DavidRBailey · 2021-12-19T03:22:59Z

The Wemo case number is #14310240. If you're having similar problems you might want to contact Wemo and refer to this case.

I had to explain multiple times that the failure in the service is on the Wemo switch, not the third-party home automation software. BTW- I had a similar problem on Homebridge that I used to run before I switched over to HASS.

DavidRBailey · 2021-12-19T04:53:41Z

A longer log file that might have useful information. I've removed messages from a few other integrations that have nothing to do with this.

home-assistant.log
.

mlohus93 · 2021-12-19T05:29:10Z

@esev - you asked "are you seeing the same Failed to establish a new connection: [Errno 111] Connection refused in the log messages? Or are you seeing Connection to <<ip_address>> timed out?"... The answer is both. Looking back an one of my switches which went unavailable around 22:31ET tonight, around 22:26ET I got an error line stating that switch had a Resubscribe error, included a comment about max retries exceeded and then the line ended the Timed Out error you mentioned. The following lines in the error log included the "Failed to establish a new connection: [Errno 111] Connection refused" errors about every 60 seconds thereafter. Oh and some Unable to re-probe wemo errors and unable to get description errors too. It is a hot mess... this is just one of many V2 switches I have which act this way. Attaching an excerpt of the log for this 8000 one particular Wemo.

Foyer-Wemo-Errors.txt
.

esev · 2021-12-19T17:13:54Z

@DavidRBailey could you double-check something for me? Are all of these dimmers? If any of them are switches, or three-way switches, please let me know. This is unrelated to the issue you're having, just want to make sure what I've done properly gets rid of those Failed to enable long press support for device error messages in your log. I'm expecting them all to be the WDS060 model.

Bathroom Lights
Bathroom Shower-Toilet Light
Bedroom Closet
Bedroom Lights
Cold Storage Light
Dining Room Lights
Downstairs Bathroom Light
Downstairs Hall
Family Room Light
Family Room Office Light
Front Entryway Light
Hallway Light
Kitchen Cabinet Lights
Kitchen Pendant Lights
Kitchen Recessed Lights
Living Room Recessed Lights
Powder Room Light
Squires Room Light
Utility Room Light

esev · 2021-12-19T19:16:08Z

@DavidRBailey to get more debugging, you can change the log level within pywemo with the logger.set_level service.

https://www.home-assistant.io/integrations/logger/#service-set_level

service: logger.set_level
data: 
  pywemo: debug

Set it back to warning or error if it causes too much logging.

esev · 2021-12-19T19:19:05Z

Kind of a long-shot here, but if either of you are comfortable with modifying the files inside your Home Assistant instance, could you try this? pywemo/pywemo#275 (comment)

The down-side is that, when you press the light switch manually, it can take a while before the change shows-up in Home Assistant. Beware though that this specifically has a bad impact on WeMo motion detectors; Home Assistant may not even see motion being triggered with that change.

DavidRBailey · 2021-12-19T20:21:24Z

@DavidRBailey could you double-check something for me? Are all of these dimmers? If any of them are switches, or three-way switches, please let me know. This is unrelated to the issue you're having, just want to make sure what I've done properly gets rid of those Failed to enable long press support for device error messages in your log. I'm expecting them all to be the WDS060 model.

All my lights, with the exception of the outdoor ones and the stairway 3-way switches are on dimmers, so yes. These are all WDS060 Smart Dimmer switches.

DavidRBailey · 2021-12-19T20:31:17Z

service: logger.set_level
data: 
  pywemo: debug

When I put this into the top of my configuration.yaml file, I get the following error when trying to restart Core.

Failed to restart Home AssistantCore

The system cannot restart because the configuration is not valid: Integration error:
service Integration 'service' not found. Integration error: data Integration 'data'
not found.

DavidRBailey · 2021-12-19T20:36:39Z

Kind of a long-shot here, but if either of you are comfortable with modifying the files inside your Home Assistant instance, could you try this? pywemo/pywemo#275 (comment)

The down-side is that, when you press the light switch manually, it can take a while before the change shows-up in Home Assistant. Beware though that this specifically has a bad impact on WeMo motion detectors; Home Assistant may not even see motion being triggered with that change.

Sure. I'll give that a try.

Where can I find wemo_device.py? (Forgive me, I recently migrated from HOOBs to Home Assistant.)

DavidRBailey · 2021-12-19T20:43:33Z

FYI- I spoke with a second-level tech at Wemo/Belkin regarding case number #14310240.

They first tried to tell me that it was the problem of "third-party software" (Home Assistant) that they don't support. I told them it was ALL third-party software, including Homebridge that was affected. Then they told me Wemo only supports Apple HomeKit, Google Home, and Alexa.

I then told them that it didn't matter which software I used, that even command line UPnP tools were failing once the switch's UPnP service stopped responding and the only way to reliably fix it was to restart/reboot the switch. They then tried to tell me that the UPnP API was no longer being used on the Wemo switches once they had been added to the Wemo Cloud. (e.g. it's just an initial set up service)

I pointed them to this page which says that the UPnP interface is the method that all third-party developers are integrating with Wemo switches- http://developers.belkin.com/wemo/sdk

They said they'd get back to me. At this point, I wouldn't be surprised if they take down the page.

Who wants to take on reverse engineering the Wemo firmware so we can create an open source version?

esev · 2021-12-19T20:47:45Z

When I put this into the top of my configuration.yaml file,

Oh oops. That wasn't meant to go in the configuration.yaml file. It was meant to be called via the Developer Tools -> SERVICES tab.

Here is what would go into configuration.yaml:

logger:
  default: info
  logs:
    pywemo: debug

esev · 2021-12-19T20:49:47Z

Where can I find wemo_device.py? (Forgive me, I recently migrated from HOOBs to Home Assistant.)

Probably the easiest way to find it would be to run: find / -name wemo_device.py

They said they'd get back to me. At this point, I wouldn't be surprised if they take down the page.

Doh! :)

Who wants to take on reverse engineering the Wemo firmware so we can create an open source version?

There are some tips on how to get started here: https://github.com/pywemo/pywemo/wiki/WeMo-Firmware

DavidRBailey · 2021-12-19T20:51:08Z

Probably the easiest way to find it would be to run: find / -name wemo_device.py

I tried that with no result, and trying sudo or su didn't seem to help.

I'm running HASSIO core-2021.11.5.

esev · 2021-12-19T20:55:31Z

Probably the easiest way to find it would be to run: find / -name wemo_device.py

I tried that with no result.

Oh! I'm not sure then. I use Home Assistant Docker not Home Assistant OS. If they're the same, the file lives here on my Docker instance: /usr/src/homeassistant/homeassistant/components/wemo/wemo_device.py

DavidRBailey · 2021-12-19T20:57:24Z

Hmmm.

[core-ssh ~]$ find / -iname homeassistant
/config/blueprints/automation/homeassistant
/config/blueprints/script/homeassistant

They must hide the files from the command line access.

Rabman416 · 2022-02-17T16:21:38Z

I will give it a try. I have found the setting and will turn it off and restart the switches.

…

________________________________ From: Matheson Steplock ***@***.***> Sent: Thursday, February 17, 2022 8:46:44 AM To: home-assistant/core ***@***.***> Cc: Rabman416 ***@***.***>; Mention ***@***.***> Subject: Re: [home-assistant/core] Wemo switches unavailable in HASS but still controllable by mobile Wemo app (Issue #62224) @Rabman416<https://github.com/Rabman416> WeMo switches are not compatible with Wi-Fi roaming I had to disable this on my Ubiquiti AP's, after that they haven't dropped a ping, it looks like the deco calls this "fast roaming", Disable that then restart the switches and let us know if that fixes it https://community.tp-link.com/en/home/forum/topic/180194 — Reply to this email directly, view it on GitHub<#62224 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AXUES27KJW6VYJ3IJ6UMWUDU3T34JANCNFSM5KJMP5WA>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

Rabman416 · 2022-02-17T23:32:31Z

I gave this a try and saw no noticeable improvements unfortunately. I also tried switching to router mode on the DECO and it resulted in many more issues so switched it back to Access Point mode. I am out of ideas other than switching them back to the Archer router.

…

________________________________ From: Matheson Steplock ***@***.***> Sent: Thursday, February 17, 2022 8:46:44 AM To: home-assistant/core ***@***.***> Cc: Rabman416 ***@***.***>; Mention ***@***.***> Subject: Re: [home-assistant/core] Wemo switches unavailable in HASS but still controllable by mobile Wemo app (Issue #62224) @Rabman416<https://github.com/Rabman416> WeMo switches are not compatible with Wi-Fi roaming I had to disable this on my Ubiquiti AP's, after that they haven't dropped a ping, it looks like the deco calls this "fast roaming", Disable that then restart the switches and let us know if that fixes it https://community.tp-link.com/en/home/forum/topic/180194 — Reply to this email directly, view it on GitHub<#62224 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AXUES27KJW6VYJ3IJ6UMWUDU3T34JANCNFSM5KJMP5WA>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

Rabman416 · 2022-02-18T03:07:53Z

So I have solved the problem after much effort.

In the DECO access point - I have created a Guest network which is where I have all of the wemo devices attached. I had the box checked for "Isolate from main network". In theory, I would love to isolate the devices from the main network, for security reasons, but Home Assistant and Wemos won't function with this checked. I probably realized this quite some time ago on the Archer router as I had this unchecked already on it.

Thanks to all for their efforts!

mlohus93 · 2022-03-21T03:28:14Z

@esev How are things going with implementing the changes you suggested? I am still getting errors related to Subscription and long-press. If implemented is there something I need to do to implement/make it work as I am not seeing it. Thanks!

Logger: pywemo.subscribe
Source: /usr/local/lib/python3.9/site-packages/pywemo/subscribe.py:477
First occurred: March 19, 2022, 3:45:28 AM (3602 occurrences)
Last logged: 11:18:50 PM

Resubscribe error for <Subscription basicevent "Stairway"> (HTTPConnectionPool(host='192.168.1.229', port=49153): Max retries exceeded with url: /upnp/event/basicevent1 (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0xfffe4f917ee0>: Failed to establish a new connection: [Errno 113] Host is unreachable'))), will retry in 60s
Resubscribe error for <Subscription basicevent "Guest Room Light"> (HTTPConnectionPool(host='192.168.1.240', port=49153): Max retries exceeded with url: /upnp/event/basicevent1 (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0xfffe4f917250>: Failed to establish a new connection: [Errno 113] Host is unreachable'))), will retry in 60s
Resubscribe error for <Subscription basicevent "Bonus Room Light"> (HTTPConnectionPool(host='192.168.1.169', port=49153): Max retries exceeded with url: /upnp/event/basicevent1 (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0xfffe4fbb5e50>: Failed to establish a new connection: [Errno 113] Host is unreachable'))), will retry in 60s
Resubscribe error for <Subscription basicevent "Guest Room Fan"> (HTTPConnectionPool(host='192.168.1.228', port=49153): Read timed out. (read timeout=10)), will retry in 60s
Resubscribe error for <Subscription basicevent "Garage Door"> (HTTPConnectionPool(host='192.168.1.207', port=49153): Max retries exceeded with url: /upnp/event/basicevent1 (Caused by ConnectTimeoutError(<urllib3.connection.HTTPConnection object at 0xfffe4fc1ce80>, 'Connection to 192.168.1.207 timed out. (connect timeout=10)'))), will retry in 60s

and

Logger: pywemo.ouimeaux_device
Source: /usr/local/lib/python3.9/site-packages/pywemo/ouimeaux_device/init.py:201
First occurred: March 19, 2022, 3:50:14 AM (3686 occurrences)
Last logged: 11:19:01 PM

Unable to re-probe wemo <WeMo LightSwitchLongPress "Guest Room Fan"> at 192.168.1.228
Unable to re-probe wemo <WeMo Switch "HASS-2"> at 192.168.1.201
Unable to re-probe wemo <WeMo LightSwitchLongPress "Stairway"> at 192.168.1.229
Unable to re-probe wemo <WeMo LightSwitchLongPress "Guest Room Light"> at 192.168.1.240
Unable to re-probe wemo <WeMo LightSwitchLongPress "Bonus Room Light"> at 192.168.1.169

esev · 2022-03-21T15:24:37Z

Hi @mlohus93, the code change is a pending review from the HA Core Dev team.

mlohus93 · 2022-03-26T05:22:15Z

Hi @mlohus93, the code change is a pending review from the HA Core Dev team.

@esev Thanks much! Although I have used HA for about 18+ months, I never watched anything go thru the process like this so have been trying to understand how it works. Glad it’s progressing.

hitnrun30 · 2022-04-07T17:03:56Z

This just happened to me, I have one of the older switches, in fact I have 2 and only one of them I have an issue with. This just started with 2022.4

When is this update being pushed?

klein1jo · 2022-04-18T19:59:30Z

The title certainly matches my issue. Problem started in the last few days. I have 21 WeMos. I noticed some weren't being controlled by my automations anymore. I removed the WeMo integration, restarted HA, and re-added the WeMo integration. HA is now only discovering 11. I've walked around and unplugged/plugged in all my WeMos. HA will not find them. They all work fine via the WeMo app and physical button presses on the device.

hitnrun30 · 2022-04-18T21:02:03Z

You want to hear the worst story. I got tired of waiting for an important wemo switch to be found. I have extra tuva/smart life switches. I changed it out and when I went into HA the 4th wemo, the one that I replaced, came up and was available. Tuva it's always better.

mlohus93 · 2022-04-21T03:52:37Z

@esev - I cannot find any clear info on the promotion process for HA code/integration fixes, but my perception is that because your proposed fix #56972 had it's "smash" designation removed after someone made a further enhancement suggestion about your code, that we may be back to the drawing board? If so, not suggesting this is your fault, but sure would like to appeal to someone/everyone to quit interfering and let you give whatever you have a try. I respect good testing and checkouts, I respect change control, but after 4 months it would be cool to see if your fix has wings and kick it out of the nest... and I'd bet this integration isn't your day-job so your time is limited too.

I continue to have Wemos (in particular 2nd Gen wall light switches and 3-way wall light switches) drop like flies. I removed the Wemo integration from HA for about 2.5 months this winter (relied solely on rules and automations within Wemo and HomeKit apps) and didn't have a single one drop out of Alexa, HomeKit, or the Wemo app the whole time. Reinstalled the Wemo integration into HA and the circus resumed as before... a minimum of 5 random Wemos drop every day and must be rebooted. I suspect it was probably a change Wemo made in their firmware along the way, because hasn't always been this way. I would have scrapped HA as soon as I started with it if this was normal. I have way too many Wemos for any home automation solution to be worth the effort if it doesn't work properly with my Wemos.

Thank you for your fine work; it is appreciated so much.

timmeade · 2022-05-06T12:11:33Z

I just want to add to this as i have the exact same issue. About 10 switches. Seems to be the 3 way switches with the most issues. My main garage lights currently do not work. All the rest do. They work in Homekit Homebridge and the Wemo App. Just not in HA.

mlohus93 · 2022-05-09T02:16:12Z

@timmeade Welcome to the ever-growing group. I suspect there have to be a lot of people who have this problem, but haven't figured it out yet.

macbisho · 2022-06-04T05:18:22Z

Just adding on - I’ve not had any network changes etc. Wemo Cloud still works, but 3 switches are now not showing up in HomeAssistant.

I reset all three switches, reconnected them and HA just doesn’t see them any more. Discovery turned on - no devices detected.

It’s annoying and frustrating as the switches are being used as the sockets are in hard to get to areas, that are for items that are used daily.

hitnrun30 · 2022-06-04T13:08:59Z

I changed it out for tuya and sure enough that is when it came up again. Now I have the issue with a tuya, but I'm just going to re add it and see. Damn free home assistant, went can't it work for free, lol.

dasb00ter · 2022-06-14T01:51:17Z

Wow what a mess. My Wemo Insight switches have been working without a hitch in Home Assistant I just found my way here looking for a local API access only but it appears that is not available and its cloud or nothing. Its too bad bc these Insight switches are well built in this world of cheaper and cheaper production.

esev · 2022-06-14T02:04:07Z

@dasb00ter the local uPnP API is still working. Home Assistant uses the pyWeMo python library for accessing the local API.

shad0wca7 · 2022-06-20T02:41:14Z

I’ve started having this issue now too. No changes, been working for about two years and now one of the two switches is showing unavailable in HA but works in the wemo app..

mlohus93 · 2022-07-12T04:27:38Z

@esev I don’t know that I have tried this before or reported it… thought I would share: Tonight (as frequently happens) my Garage lights which are controlled by a 2nd Gen Wemo light switch (specifically a 3-way switch) stopped working in Home Assistant and Alexa, however it worked just fine with my Google Home mini… at least I guess that’s what you call Googles version of an Echo Dot. I only have one Google mini and it is in the garage … it is set to only control the garage lights, nothing else. Point is, whatever is whacking my Wemo switches, HA and the Alexa/Echos it is not effecting the Google Mini (odd).

ginobuzz · 2022-07-22T14:42:03Z

Same issue. Been dealing with it for nearly a year on all 8 of my switches. Getting ready to abandon WeMo and swap them all out.

klein1jo · 2022-07-22T15:33:47Z

The title certainly matches my issue. Problem started in the last few days. I have 21 WeMos. I noticed some weren't being controlled by my automations anymore. I removed the WeMo integration, restarted HA, and re-added the WeMo integration. HA is now only discovering 11. I've walked around and unplugged/plugged in all my WeMos. HA will not find them. They all work fine via the WeMo app and physical button presses on the device.

I cannot remember why, but back in April I ended up rebooting my wireless access points and everything started working again. Just recently I had 7/21 WeMos stop working again. Same symptoms as before, they work in the WeMo app and in Google Assistant, but do not work in HA. This time it did not only affect my WeMos though. It also affected my OpenSprinker and 1/7 of my Shellys. All stuff HA talks to locally. I started doing the same thing as before; blaming HA, re-adding integrations, etc... I could not remember what fixed my issue last time. A couple days ago I did a firmware upgrade on one of my PoE switches which rebooted my wireless access points and just like that everything started working again. So I ask, have you tried rebooting your wireless access points yet?

mlohus93 · 2022-08-30T04:40:50Z

This is not a fix, but rather a means for survival while we wait for a real fix.

I have found that Gen1 light switches are generally more reliable than Gen2, but not exactly rock solid. I found that if I employed an old Belkin Wemo HomeKit Bridge (model F7C074), it picks up all the Gen1 switches... then by implementing the HomeKit Controller Integration in HA, it allows me to access the Gen1 Switches via that HomeKit Bridge. Why would I go thru this convoluted path? Because for whatever reason, either HomeKit or that Belkin Wemo HomeKit Bridge "seem" to reset devices which try to go offline and keep them online. I was able to pickup a bunch of Gen1 switches on eBay and have gone thru and replaced all the Gen2's I had except the 3-way switches. Unfortunately there is no Gen1 3-way and the 3-way switches wont connect to the Wemo HomeKit Bridge. Still working on a work-around there. If I can't find one, I may have to change products for the 3-ways. It is totally ridiculous, but it is so frustrating the switches keep failing.

johnnyanalog · 2022-11-16T05:25:49Z

This issue really sucks.

fharper · 2022-11-16T14:01:06Z

@johnnyanalog feel free to submit a PR!

kmnunley · 2023-01-18T05:05:45Z

I guess I'll also shout into the void that is this issue.
Getting this on one of my 3 Wemo devices.

2023-01-17 23:41:41.645 ERROR (SyncWorker_1) [pywemo.discovery] Device setup failed uuid:Lightswitch-2_0-M1BAA129N040A0 http://192.168.50.202:49154/setup.xml
Traceback (most recent call last):
  File "/usr/local/lib/python3.10/site-packages/pywemo/discovery.py", line 93, in device_from_uuid_and_location
    return LightSwitchLongPress(location)
  File "/usr/local/lib/python3.10/site-packages/pywemo/ouimeaux_device/__init__.py", line 132, in __init__
    service = Service(self, svc)
  File "/usr/local/lib/python3.10/site-packages/pywemo/ouimeaux_device/api/service.py", line 285, in __init__
    xml = device.session.get(url).content
  File "/usr/local/lib/python3.10/site-packages/pywemo/ouimeaux_device/api/service.py", line 138, in get
    return self.request('GET', url, **kwargs)
  File "/usr/local/lib/python3.10/site-packages/pywemo/ouimeaux_device/api/service.py", line 128, in request
    raise HTTPNotOkException(
pywemo.exceptions.HTTPNotOkException: Received status 404 for http://192.168.50.202:49154/rulesservice.xml

Attempting to access that xml does in fact 404, but accessing the setup.xml works just fine. Looks like there's been an open PR for this issue for two years now( #56972 ), and people are getting so desperate for a fix they're implementing code from that PR themselves.

esev · 2023-01-18T06:05:37Z

@kmnunley this looks like a different issue to me. Could you file an issue for pyWeMo? https://github.com/pywemo/pywemo/issues/new

I'd be curious to see the setup.xml file to know if it contains a reference to rulesservice.xml. [example].

It would be odd for a WeMo device to advertise the rulesservice.xml in setup.xml but not actually support it and return a 404 error. But maybe Belkin has created new ways to keep us on our toes. :)

Does the error persist after rebooting the WeMo switch? Any chance this issue started recently, like after a firmware update? Are there any obvious differences between the three devices that you think may be related?

issue-triage-workflows · 2023-04-18T18:16:29Z

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

probot-home-assistant bot added the integration: wemo label Dec 17, 2021

issue-triage-workflows bot added the stale label Apr 18, 2023

issue-triage-workflows bot closed this as not planned Won't fix, can't repro, duplicate, stale Apr 25, 2023

github-actions bot locked and limited conversation to collaborators May 25, 2023

marcelveldt closed this as completed in #56972 Jun 27, 2023

Uh oh!

Wemo switches unavailable in HASS but still controllable by mobile Wemo app #62224

Wemo switches unavailable in HASS but still controllable by mobile Wemo app #62224

Comments

Uh oh!

The problem

What version of Home Assistant Core has the issue?

What was the last working version of Home Assistant Core?

What type of installation are you running?

Integration causing the issue

Link to integration documentation on our website

Example YAML snippet

Anything in the logs that might be useful for us?

Additional information

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!