core: Wemo switches unavailable in HASS but still controllable by mobile Wemo app

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, if you were curious to know more about the device page improvements, I added a screenshot in this PR that shows what I’m planning. pywemo/pywemo#313 (comment)

NICE!

@mlohus93, if you were curious to know more about the device page improvements, I added a screenshot in this PR that shows what I’m planning. https://github.com/pywemo/pywemo/pull/313#issuecomment-1001224694

@kebel87 The solution is the same as this issue. Disabling the subscriptions will stop the errors but at the cost of Home Assistant not seeing button presses quickly.

The issue is different though. WeMo’s were not designed to work across subnets (likely for security-related reasons). They will refuse all subscriptions that don’t originate from the local subnet.

#56972, from early October, will add a button to disable the subscriptions. Just need to get that merged and released. I’ll make a few updates on that today and switch it from a feature request to a bug fix.

Thank you @esev for your help in improving our experience (and your patience).

Thank you @DavidRBailey for pursuing with the people at Belkin who just don’t get it, and for launching this ticket. It’s such a relief to find out it wasn’t just me having all these dropouts.

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)

@Rabman416https://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 GitHubhttps://github.com/home-assistant/core/issues/62224#issuecomment-1042965837, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AXUES27KJW6VYJ3IJ6UMWUDU3T34JANCNFSM5KJMP5WA. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://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: @.***>

yep @esev I just had one of my switches stop responding to the API, however this time the buttons switch button has not failed however the restart button still doesn’t seem to solve it, will try again today

Not sure if this has been said yet but I had this issue months ago, had to hard power cycle the switches, I thought it was gone after a firmware update, turns out its just extremely unreliable, but I can still control them in app https://www.reddit.com/r/WeMo/comments/pd4pei/local_api_gone/

More information on Belkin Wemo moving from WiFi to Matter’s Thread.

https://9to5mac.com/2022/01/04/belkin-homekit-wemo-smart-plug-light-dimmer-matter-thread-support/

This is interesting. I don’t think Belkin can join Matter and Thread without making their APIs accessible to multiple integrations/hubs. Matter allows multiple integrations without having to deregister and reregister devices between systems.

Just to make sure I understand correctly what you mean by “at the cost of Home Assistant not seeing button presses quickly.”, do you mean if I press the physical button on the Wemo device itself?

Thanks for asking. Yes, that’s what I mean.

I suspect there will be no impact to folks who have plugin devices, as it’s rare to press the button on those. Turning subscriptions off would primarily impact the motion sensor devices. It’ll be rare that a motion event happens to correspond to when Home Assistant polls. So it’ll seem like those devices no longer report motion detection at all. The same will be the case for the sensor input on the WeMo Maker.

Automations based on tapping the wall mounted switches/dimmers will be delayed by up to 30 seconds. Turning subscriptions off will also disable the ability for Home Assistant to receive long-press events from these devices (when you hold your finger on the button for more than two seconds).

Automations based on the coffee maker & humidifier states will also be delayed, the same as the switches/dimmers.

Some examples of things that won’t work as expected with subscriptions disabled:

• I have motion activated lighting, using the WeMo motion detector and WeMo maker. When Home Assistant receives the subscription event about the motion it first checks if it is dark (using state from solar panels) before turning on the light.

• I have an automation in my living room based on pressing the wall switch button for 2 seconds (long press). When Home Assistant receives this event, it turns off all the devices (including non-WeMo devices) in the room.

• I have a WeMo wall dimmer switch that isn’t connected to any light. Rather, when the dimmer button is tapped, or the brightness is changed, Home Assistant forwards those changes instantly to some WLED-based lighting in the room. The WLED lighting is the primary light source for the room, adding a noticeable delay here would make this automation impractical.

• Similarly I have a Zigbee light attached to the WeMo Bridge/Link. When I press a WeMo wall switch button to turn on/off a lamp, Home Assistant turns on/off the nearby Zigbee light at the same time.

@esev just an observation tonight, one which shows how little I understand about Docker I am sure.

I have been gone since early this morning, just arrived home to find about 5 of my V2 switches unavailable. I have done nothing to HA or my network since yesterday afternoon when I got everything working again. This was surprising to me. When I checked, one of the three instances of wemo_devices.py on my Debian 11 HA machine had become uncommented out for the three lines you had me previously comment out. I dont know why anything would have changed, but something did. I rebooted the switches and expect it will be happier.

@esev Not a lot to report tonight beyond what are likely self-inflicted injuries <sigh>

Out of curiosity late last night I turned on an Advanced Security feature of my Eero network to “prevent access to sites that host malicious content or viruses, botnets, phishing sites, and more.” When I got up this morning I was met with a laundry list of pretty much every wemo switch, wemo plug and wemo maker (V1, V2, everything) which had been flipping unavailable and back online all night long. Thinking that Eero “feature” caused it, I turned it back off (even though it claimed it hadn’t actually blocked any traffic/requests). Same problems continued. Rebooted network. The frenzy of problems slowed a bit but definitely continued. I noticed there was a core update to 2021.12.4 which I went ahead and applied (which naturally restarted HA). The problems continued. I rebooted every switch, plug, and maker in the house. Problems continued, again seemed to be slower occurring but still things were going up and down. Finally it dawned on me to check out the wemo_devices.py file and sure enough the three lines you had me comment out were back to normal (not commented out). I returned those to being commented out, restarted HA, and everything immediately settled down with no more unavailable bouncing. At that point I had one 3-way V2 switch (foyer lights) which didn’t return on it’s own so I rebooted it (a couple of times) and everything was up, stable, and happy again. I did get a chuckle out of the Foyer Lights error in HA “Error communicating with Foyer Lights after 3 attempts. Giving up.” I get that, I have felt that way myself lately.

Honestly wish I had checked the three lines in the py file first, I just didn’t think of that. I don’t know if something uncommented them last night, if the Eero security feature caused problems and the uncommenting happened as a result of the 2021.12.4 update, I don’t know. Not the grandest troubleshooting methodology; sorry about that. However since I got the world settled down, everything has been again 100% stable, nothing has gone unavailable.

Incidentally, I am likely going to revert to my HA Blue primary box tomorrow night… this Debian box doesnt have a Zigbee gateway “plug” so there are a couple things which are not working like an Aqara button on the Garage wall for opening/closing the garage door and a leak sensor… my wife would really appreciate once again being able to put up the door before she gets in the car. I will try again to find a way to get to the wemo_devices.py file in the HA Blue box; it is illusive… probably wouldn’t have gotten it if I had known how extremely restrictive it would be… but here we are.

Connectivity Standards Alliance (CSA) Matter shows that vendor lock-in is not the way of the future- interoperable, open standards are. I think Belkin/Wemo is cooking their goose.

When you get Apple, Google, Amazon, Samsung and the largest IoT chipmakers, smart home vendors and resellers all on the same page, it is the direction that industry is going. Belkin is going to lose out unless they join in that industry direction.

It’s sad to see things going this way. I bought mine before there was a cloud service specifically because of the UPnP local control. That was the “stand-out” feature that made me choose WeMo from the start.

The newer models of the plug-in switches are not very conforming to the UPnP standards already. And the most recent dimmers also dropped support for accessing the Long Press feature over UPnP.

I wish they were using an ESP chip so they could be flashed with ESPHome. Unfortunately I don’t see any other wifi-based switches/dimmers that have strong support for local control. ZWave/Zigbee seems to be the better / future-proof solution.

I’m planning to make a change soon to display the firmware version in Home Assistant (along with a few other debugging details like wifi signal strength & uptime). Then it’ll be easier to compare. FWIW my WLS040 & WLS0403 are on WeMo_WW_2.00.11563.PVT-OWRT-LIGHTV2

@esev this is an OUTSTANDING idea! Just the WiFi signal info alone would be huge (sorely missing from Wemos own app), but uptime and firmware info within HA would be great!.

Because nothing existed and I had a feeling this was a real problem, I have had a couple of automations in place since 10/31 for the purpose of tracking uptime (well, really downtime). After a Wemo (of any kind) goes “unavailable” for 3 minutes, HA sends me a push notification and logs (concatenates) the date/time/switch/status info in a file for later review. Likewise, when it comes back online (whether on its own or at my hand with a reboot of the wemo), I get a push and entry logged that is alive. This helped me figure out the problem isn’t in my head, it isn’t rare, and it wasn’t getting better. Your uptime mechanism would sure be welcomed.

@mlohus93 That’s great news. A while back, I made a PR so you can enable/disable the subscription through the integration configuration. That would make it so you no longer need to modify the files directly. It hasn’t been reviewed yet though. #56972. Let’s give it a few more days. If we can say conclusively that this fixes the issue, I’ll modify that PR so it is considered a bug fix. Might get more attention that way.

It’s good that we’ve potentially narrowed the issue down. I wonder what it is about the subscriptions that causes these switches to fail?

@mlohus93 Firmware changes could cause this too. Good call.

I’m planning to make a change soon to display the firmware version in Home Assistant (along with a few other debugging details like wifi signal strength & uptime). Then it’ll be easier to compare. FWIW my WLS040 & WLS0403 are on WeMo_WW_2.00.11563.PVT-OWRT-LIGHTV2

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)

@esev I couldn’t find the wemo_device.py on my HA Blue either, but shut it down and brought up my Debian 11 Supervised HA machine, restored it to the backup of HA Blue from last night, and commented out the three lines in the wemo_device.py file. I restarted my Debian 11 HA box and restarted all my V2 (1-way and 3-way) switches. Currently all switches are showing available. I will report back how my switches behave (or dont). Thanks!

Makes me think that maybe Alexa uses the same UPNP API as Home Assistant does?

@mlohus93 it totally does. In fact there are a few software libraries that emulate WeMo devices for exactly this reason. It allows those devices to be easily supported by Alexa.

I’m working on some unintended consequences of such emulators right now in #62259. 😃

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.

@esev and @DavidRBailey Something I have noticed… devices which go Unavailable in Home Assistant ALSO go unavailable in Alexa at the same time (whereas HomeKit and Wemo App remain fully operational to those same devices). So it’s a problem with one of the things they do support… Alexa. That said, allow me to clarify that I do not use the Wemo skill for Alexa, I let Alexa discover my Wemos on her own (which she does quite well) because I was getting duplicate Wemo entities in Alexa until I ditched the Alexa/Wemo skill.

Makes me think that maybe Alexa uses the same UPNP API as Home Assistant does?

Aha!

https://community.home-assistant.io/t/how-to-get-access-at-damn-host-system/96549/7

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

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

@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.

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