Core: Wemo dimmer keeps changing entity domain

[petrfaitl]

Home Assistant release with the issue:

0.85.0

Last working Home Assistant release (if known):
0.84.6

Operating environment (Hass.io/Docker/Windows/etc.):

hassio
Component/platform:

https://www.home-assistant.io/components/light.wemo/

Description of problem:

On each restart of home assistant the discovery service discovers Wemo dimmer switches either as light.entityname or as switch.entityname. Even when deleting old info from ./storage/core.entity_registry the issue keeps recurring.

Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

from core.entity_registry.

{
                "config_entry_id": null,
                "device_id": null,
                "disabled_by": null,
                "entity_id": "light.entrance_light",
                "name": null,
                "platform": "wemo",
                "unique_id": "241717K15XXXX"
            },
{
                "config_entry_id": null,
                "device_id": null,
                "disabled_by": null,
                "entity_id": "switch.entrance_light",
                "name": null,
                "platform": "wemo",
                "unique_id": "241717K15XXXX"
            }

Traceback (if applicable):

Additional information:
Other Wemo (non-dimmer) light switches are not affected.

[callifo]

Same issue for the Wemo Motion (motion sensor), it alternates on boot between switch and binary_sensor. I have two of them and sometimes one is binary_sensor and one is switch, or both switch, or both binary_sensors.

I need to reboot a few times to get both of them back to binary_sensor.

[MartinHjelmare]

CC @sqldiablo.

[sqldiablo]

This is related to #19808, which is still under investigation.

[sqldiablo]

Thanks for the information, @callifo & @petrfaitl. Could you turn on debug logging for me and share the logs via e-mail ([email protected])? I'm curious to see what Home Assistant and pywemo are reporting when the devices are discovered/setup. The logs will also help us figure out how to get the setup XML for the devices having the issue, which would be useful as well.

# Example config to enable debug logging:
logger:
  default: warning
  logs:
    homeassistant.components.discovery: debug
    homeassistant.components.wemo: debug
    pywemo: debug

[callifo]

Email sent.

That other bug I did experience in previous builds, but it was different, that only triggered the wrong switch after a HA reboot. Had to reboot the switches to fix it.

[elmigbot]

My Dimmers ONLY identify as switches now. Restarting HA doesn't seem to change it.

PyWemo seems to know better: [pywemo.subscribe] Resubscribe for <WeMo Dimmer "Dining Room">

[parsons256]

I can second elmigbot's issue. After updating from 0.84.6 to 0.85 my Weemo dimmers are being identified as switches.

[sqldiablo]

Thanks, all. I'm working with @petrfaitl to debug this right now. I think I know what the issue is, I just need to confirm it with some help from Petr, and then I can get a PR together with the fix.

[sqldiablo]

Hi guys, anyone else interested in helping me debug this, please do the following:

If you're running version 0.85.0 or newer, edit file homeassistant/components/wemo.py, and replace the section from line 109 to line 127, which looks like this:

    def discovery_dispatch(service, discovery_info):
        """Dispatcher for incoming WeMo discovery events."""
        # name, model, location, mac
        device_type = discovery_info.get('device_type')
        serial = discovery_info.get('serial')

        # Only register a device once
        if serial in KNOWN_DEVICES:
            _LOGGER.debug('Ignoring known device %s %s',
                          service, discovery_info)
            return

        _LOGGER.debug('Discovered unique WeMo device: %s', serial)
        KNOWN_DEVICES.append(serial)

        component = WEMO_DEVICE_TYPE_DISPATCH.get(device_type, 'switch')

        discovery.load_platform(hass, component, DOMAIN,
                                discovery_info, config)

with this:

    def discovery_dispatch(service, discovery_info):
        """Dispatcher for incoming WeMo discovery events."""
        # name, model, location, mac
        device_type = discovery_info.get('device_type')
        serial = discovery_info.get('serial')
        ssdp_description = discovery_info.get('ssdp_description')

        # Only register a device once
        if serial in KNOWN_DEVICES:
            _LOGGER.debug('Ignoring known device %s %s',
                          service, discovery_info)
            return

        _LOGGER.debug('Discovered WeMo device: %s (%s) at %s',
                      serial, device_type, ssdp_description)

        KNOWN_DEVICES.append(serial)

        component = WEMO_DEVICE_TYPE_DISPATCH.get(device_type, 'switch')

        _LOGGER.debug('Setting up WeMo device: %s (%s) at %s as component %s',
                      serial, device_type, ssdp_description, component)

        discovery.load_platform(hass, component, DOMAIN,
                                discovery_info, config)

This just expands on some of the logging to help me track things down. Once you've replaced the code, restart home assistant with debug logging for discovery, wemo, and pywemo enabled (see below), and send me the log file (you can use the e-mail address in my profile).

Debug logging entry for configuration.yaml:

logger:
  default: warning
  logs:
    homeassistant.components.discovery: debug
    homeassistant.components.wemo: debug
    pywemo: debug

[callifo]

Mine didnt like that, all the wemo devices stopped be detected; it repeats this message for each wemo device:

2019-01-17 21:15:27 ERROR (MainThread) [homeassistant.core] Error doing job: Future exception was never retrieved
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/concurrent/futures/thread.py", line 57, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/components/wemo.py", line 117, in discovery_dispatch
    if serial in hass.data[WEMO_DATA_KEY][WEMO_KNOWN_DEVICES_KEY]:
NameError: name 'WEMO_DATA_KEY' is not defined

[sqldiablo]

Sorry about that, @callifo. I accidentally grabbed an in-flight change along with the added logging. I've updated my post above to correct my mistake. Please replace the code again and give it another try.

[meatheadmike]

So it looks like my dimmers are getting detected, it's just they are getting detected as switches instead of dimmers just like elmigbot reported :(

[meatheadmike]

I emailed you my logs separately. Thanks for looking in to this.

[callifo]

Still waiting for this to reoccur, rebooting it a few times a day and its not done the same thing again so far. It was 50;50 previously.

I was having some other network issues with the Pi that I've now fixed; this was causing some other funky stuff to occur on the network so I wonder if this perhaps had something that made the issue worse.

[sqldiablo]

Thanks for the updates, guys, @meatheadmike, I sent you a reply. I think the custom wemo component you're running may be impacting my ability to troubleshoot the stock component. Let's try just the stock component for now.

I received another log from someone else, but he needs to fix some indenting with the code he replaced, and then he should be able to test it and send me logs again.

[smcallis77]

I have this problem as well. I will add the code and see if I can capture some logs. I haven't rebooted for quite a while so I don't know whether I have the 50:50 situation being reported or not.

[smcallis77]

@sqldiablo I will send you the logs I have, but, I'm not sure it is going to give you what you expected. Since the restart of homeassistant only two out of five wemo devices are being detected. However, there is much other wemo related strangeness going on that I will elaborate on in my email.

[sqldiablo]

Thanks to @smcallis77, I was able to identify the issue. The issue is here:

https://github.com/home-assistant/home-assistant/blob/d39784906b26d4322c9ed72f073eb0967f8f6470/homeassistant/components/wemo.py#L168

This seems to be a python issue where __class__.__name__ returns a None instead of the class name. I'll PR a change to go back to the old method of identifying devices.