Core: Wemo switch state when turning on [0.112.3]

[gmarlow]

The problem

Turning on a wemo switch makes the state go from on to off for a few seconds, then on again. Turning off works as expected. This issue was originally reported as issue #36632, but the related PR did not fix the issue. This issue has been observed on both Wemo Mini Smart Plugs and Wemo 3-Way Wall Switches.

Environment

Attribute | Description
-- | --
arch | x86_64
dev | false
docker | true
hassio | false
installation_type | Home Assistant Container
os_name | Linux
os_version | 4.4.59+
python_version | 3.7.7
timezone | America/Los_Angeles
version | 0.112.3
virtualenv | false

• Home Assistant Core release with the issue: 0.112.3
• Last working Home Assistant Core release (if known): 0.110.7
• Operating environment (OS/Container/Supervised/Core): Docker
• Integration causing this issue: Wemo Belkin
• Link to integration documentation on our website: https://www.home-assistant.io/integrations/wemo/

Problem-relevant configuration.yaml

Configured via UI

Traceback/Error logs

No Errors

Additional information

Although this issue doesn't seem to be affecting the physical performance of the wemo switches, its reeking havoc on button state UIs.

[probot-home-assistant[bot]]

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

[lishan89uc]

Same issue and thank you @gmarlow you saved me the trouble of creating the ticket.

[miguelcaravantes]

yea same issue

[ThomYoung]

I've had related issue with my Wemo motion sensor only occasionally triggering. Rolled back to 0.110.7 and all works fine again.

[matt8707]

As a temporary fix for latest hass, run latest working wemo integration as a custom component

#configuration.yaml
wemo_custom:
  discovery: false
  static: !secret wemo_static

#secrets.yaml
wemo_static: 
  - 192.168.0.1
  - 192.168.0.2
  - 192.168.0.3

• pull 7faba60e836e0e01ddb564fc0e737b1416b7c9b1
• copy folder homeassistant/components/wemo
• paste as config/custom_components/wemo_custom
• replace domain wemo with wemo_custom in both const.py and manifest.json
• remove wemo integration from ui (:8123/config/integrations)
• restart home assistant
• may have to remove appended number on entities, e.g. wemo.switch_2 (:8123/config/entities)
• no more state bounce

[gmarlow]

As a temporary fix for latest hass, run latest working wemo integration as a custom component

#configuration.yaml
wemo_custom:
  discovery: false
  static: !secret wemo_static

#secrets.yaml
wemo_static: 
  - 192.168.0.1
  - 192.168.0.2
  - 192.168.0.3

Great idea! Thanks for the information! Do you know if this will be fixed in 0.103.0? Doesn’t look like this issue is at the top of anybody’s list...

[miguelcaravantes]

*

Will this fix be delivered as part of 0.103.0?

until i can see this is not really a fix, it is only a way to use a old version (Apr 28) of wemo integration in the recent version of HA

[matt8707]

Do you know if this will be fixed in 0.103.0

Doesn't look like it no. But at least we're not stuck at 0.110.7

until i can see this is not really a fix

That's why I said temporary. This will work like before, until something other breaks it down the line

[miguelcaravantes]

Do you know if this will be fixed in 0.103.0

Doesn't look like it no. But at least we're not stuck at 0.110.7

until i can see this is not really a fix

That's why I said temporary. This will work like before, until something other breaks it down the line

Yea that is why i clarified to gmarlow, since he thought it is the real fix

[lishan89uc]

Great idea! Thanks for the information! Do you know if this will be fixed in 0.103.0? Doesn’t look like this issue is at the top of anybody’s list...

I think you mean by 0.113.0.

Do you know if this will be fixed in 0.103.0

Doesn't look like it no. But at least we're not stuck at 0.110.7

Why was this broken in the first place? Do you happen to know what was the objective? If so how can we fix it more permanently?

[ThomYoung]

This temporary fix manged to solve this issues I was facing in this issue too. #37544

[esev]

I've encountered a similar issue with the three way switch, the light switch, and the newly released WiFi Smart Plug. I wonder if this would be fixed by https://github.com/pavoni/pywemo/pull/157

The newer Wemo devices, like the three way switch, the light switch, and the newly released WiFi Smart Plug give a state change notification that is currently incompatible with pywemo. When pywemo receives the notification from the wemo device, it defaults to 'off' because the state cannot be parsed. Later, when Home Assistant polls the wemo device, it will see that the device is 'on'. This sounds very similar to the behavior that is being described in this issue (first reporting the 'off' state and then later reporting 'on'). And is the behavior I am hoping to have fixed in that PR.

[lishan89uc]

@esev my wifi light switch is over 5 years old and i have this issue as well. New firmware? Maybe but i have not updated firmware in a while already. Also if you take the wemo component from 0.110.7 and install it as custom component. It works flawlessly. If it is the device issue then these shouldn’t happen correct?

[esev]

@lishan89uc I think there are three things that happen with the action of turning on the light.

1. The wemo component turns the light on
2. The light responds back with a notification indicating BinaryState 1
3. The wemo component polls for the state of the light

Prior to https://github.com/home-assistant/core/commit/fe03c9da689e2ee08c7896c17b7b7e9c1bf18eac#diff-c0b98884bb8d327455ae5b99d154bef2 it looked like the state wasn't updated till either the notification was received (2) from the wemo or the periodic polling updated the state (3). Now the state is changed as soon as the action is taken in HA (1).

Now with the new version:

1. When the wemo component turns the light on it also updates it's state to on (this is the new behavior).
2. The light responds back with a notification indicating BinaryState 1 (1 is not handled in pywemo right now and results in the state changing to off).
3. The wemo component polls for the state of the light (this sets the state back to on)

With the old version:

1. The wemo component turns the light on (but it doesn't update its state to 'on')
2. The light responds back with a notification indicating BinaryState 1 (1 is not handled in pywemo right now and results in the state staying in the original 'off' state)
3. The wemo component polls for the state of the light (this sets the state to on)

If you have a moment, could you test https://github.com/esev/pywemo/commit/3df7bfe31b94d754bc7f39744059420b3db4bf5d?

Edit: What I described for the old version wasn't correct. At step 2, in 0.110.7, the device was polled immediately to find its state. 2 & 3 used to happen at the same time. More details in the comment below.

[esev]

I originally stumbled on this issue because I wanted to detect when the light switch had been physically toggled on & off quickly (within 1.5 seconds). I noticed that this wasn't possible because HA would take a long time before updating the state when I physically turned the switch on. But the state would update quickly when I turned the light off. That was the issue I was aiming to fix, and it sounds like this issue may have the same root cause. pywemo isn't handling BinaryState value in the notifications from the light correctly.

[esev]

I've tested that https://github.com/esev/pywemo/commit/3df7bfe31b94d754bc7f39744059420b3db4bf5d fixes the issue for the following Wemo devices.

1. WLS040 Smart Light Switch
2. WLS0403 Smart Light Switch 3-Way
3. F7C059 Smart Dimmer
4. WSP080 Smart Plug
5. F7C029 Insight Smart Plug

There is some evidence in https://github.com/home-assistant/core/issues/37544 that the fix works for the Wemo motion sensor (testing ongoing).

If anyone has other Wemo devices it'd be great if you could test https://github.com/esev/pywemo/commit/3df7bfe31b94d754bc7f39744059420b3db4bf5d and let me know if it works. I'd really like to confirm that it works on these:

1. F7C027 Switch
2. F7C063 Mini Smart Plug
3. F7C030 Smart Light Switch

If it's working as intended https://github.com/esev/pywemo/commit/3df7bfe31b94d754bc7f39744059420b3db4bf5d should solve this issue (state switching on-off-on when turning the device on within HA) as well as updating the entity state in HA much quicker when the device is manually operated too.

[lishan89uc]

lets say it does work perfectly will this be included into 0.114 or possible later releases of 0.113?

[esev]

@lishan89uc the short answer is that I don't know what to expect in terms of timelines. I'm willing to send PRs for the necessary fixes and address review feedback. But I have no say over the direction of pywemo or the HA Wemo component. I'm also pretty new to HA and pywemo in general so I may be missing how things work. These are the steps I plan to take. Please let me know if there is a better way or an alternative long term fix.

1. As long as things are working well, I'll update https://github.com/pavoni/pywemo/pull/157 tomorrow with these changes.
2. Then we'll need to see if the changes are okay with the pywemo owners. I'll try to address any feedback that they have so the PR can be merged.
3. The pywemo owners will need to create a new release.
4. I can then send a PR to update the HA Wemo component to use the new release of pywemo.
5. I'll need to wait for and address any feedback on that PR so that it can be merged.
6. We'll then have to wait for the next HA release.

I tested the fix by editing pywemo with the Docker version of HA. Depending on which version you are running, the file to modify is /usr/local/lib/python3.8/site-packages/pywemo/ouimeaux_device/__init__.py or /usr/local/lib/python3.7/site-packages/pywemo/ouimeaux_device/__init__.py (whichever one exists - I'm not sure where the file exists on non-Docker platforms). Add return {'state': params.split('|')[0]} just inside the parse_basic_state method, so that it is executed before anything else in that method. Then stop and start HA. This worked for me on HA 0.111.4, 0.112.3, 0.113.0, and 0.113.1.

[lishan89uc]

it seems that i am unable to use to for Home Assistant on Raspberry Pi. I might be doing this wrong. I new to this as well. The version I a using is vastly different than the __init__.py you have editted.

What you have said makes complete sense though for the wemo component in HA 0.112.0-0.113.1. However I am using wemo component from 0.110.7 right now. and i don't see your
https://github.com/lishan89uc/wemo_old/blob/master/custom_components/wemo_old/__init__.py
I am sorry if i was not of more help. This is out of knowledge range. Oh however i can assure you:

Prior to fe03c9d#diff-c0b98884bb8d327455ae5b99d154bef2 it looked like the state wasn't updated till either the notification was received (2) from the wemo or the periodic polling updated the state (3). Now the state is changed as soon as the action is taken in HA (1).

If it is changing state with polling it wouldn't be this quick to react when i press the physical button on the device.

[esev]

@lishan89uc, @smcallis77 added some better testing instructions in https://github.com/home-assistant/core/issues/37544

If it is changing state with polling it wouldn't be this quick to react when i press the physical button on the device.

I agree, it shouldn't be quick if only polling is used. It's entirely possible that more changed since 0.110.7 than I am aware of. I started with 0.111.4, so I'm not aware of how the Wemo integration worked prior to that. Do you know of a good way to see all the diffs between 0.110.7 & 0.111.4?

[lishan89uc]

Short of downloading and comparing the 2 components i don't however i'll do that and see what i find out. in case you curious on how quick 0.110.7 is here's a video:
https://youtu.be/W87FWWHZKh8

[lishan89uc]

After comparing it seems the __init__.py was not changed at all from 0.110.7 to 0.111.4 but rather the switch.py,light.py, fan.py, binary_sensor.py were the ones with major changes. I downloaded both files
https://github.com/home-assistant/core/releases/tag/0.111.4
https://github.com/home-assistant/core/releases/tag/0.110.7
and extracted the wemo component from both at
core-0.110.7.zip\core-0.110.7\homeassistant\components\wemo
core-0.111.4.zip\core-0.111.4\homeassistant\components\wemo
then compared each file using notepad ++ addon: compare

[esev]

Thanks for the video. There must have been something that changed in pywemo that caused this.

@lishan89uc could you enable info logging? Having the log message that begins with INFO (Wemo HTTP Thread) [pywemo.subscribe] Received event from would be very helpful.

Edit: In the older version it was a DEBUG log.

[esev]

Ah ha! I spotted it. It was https://github.com/home-assistant/core/pull/35693 that caused this issue.

Here is the relevant pywemo file for the older (0.4.34) version: https://github.com/pavoni/pywemo/blob/4f25c3875070c5f32ad635152d590a327b97546a/pywemo/ouimeaux_device/__init__.py

The key difference is that there are two subscription_update methods. One that returns True for parsing BinaryState and one that always returns False. Since the one that returns False appears later in the file, it'll be the one that is actually used. Returning False from the subscription_update method will cause HA to immediately poll the device for it's current state. And that explains why the state update was both fast and correct in 0.110.7. After https://github.com/home-assistant/core/pull/35693 the behavior is as I described, with the bug in parse_basic_state that I'm aiming to have fixed.

[lishan89uc]

@esev I believe the logs were already posted by someone in #36632

[lishan89uc]

@esev THAT makes so much sense. is there anyone i can get a component out of the code you fixed? I would be more than willing to test a component. it is just that i have no idea how the pywemo code you fix turns into a home assistant component that we normally use.

[esev]

Unfortunately the bug isn't in the HA wemo component. It is in the pywemo dependency that the HA wemo component depends on.

There is something you could do in the HA wemo component though to work around the issue. In switch.py, change the _subscription_callback method to look like this:

    def _subscription_callback(self, _device, _type, _params):
        """Update the state by the Wemo device."""
        _LOGGER.info("Subscription update for %s", self.name)
        if _type == "BinaryState":
            try:
                _device._state = int(_params.split('|')[0])
                updated = True
            except ValueError as e:
                _LOGGER.error("Could not parse BinaryState: %s (%s)", _params, e)
                updated = False
        else:
            updated = self.wemo.subscription_update(_type, _params)
        self.hass.add_job(self._async_locked_subscription_callback(not updated))

[lishan89uc]

ah ic so i guess its the waiting game now to wait for pywemo to update and get bumped?

[esev]

I've updated https://github.com/pavoni/pywemo/pull/157 to update pywemo. Let's see how that goes.