search

home-assistant / core

:house_with_garden: Open source home automation that puts local control and privacy first.
https://www.home-assistant.io
Apache License 2.0
73.79k stars 30.89k forks source link

HUE 3rd party device has a wrong reachability status #61692

Closed erkr closed 2 years ago

erkr commented 2 years ago

The problem

Thanks for the GREAT job, I have a large HUE eco system and most parts migrated flawlessly!!!! But I ran into a strange issue that one 3rd party device (YSRSAI) that is not powered is reported as reachable in Home Assistant. See additional info for details retrieved from the debug/clip interface. Regards Eric

What version of Home Assistant Core has the issue?

core-2021.12.1

What was the last working version of Home Assistant Core?

core-2021-11.5

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Philips Hue

Link to integration documentation on our website

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

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

I checked directly on the bridge, and there the status of the YSRSAI device is correct (not reachable): 

{
    "state": {
        "on": false,
        "bri": 254,
        "alert": "select",
        "mode": "homeautomation",
        "reachable": false
    },
    "swupdate": {
        "state": "notupdatable",
        "lastinstall": "2021-12-08T17:54:12"
    },
    "type": "Dimmable light",
    "name": "Dimmable light",
    "modelid": "ZB-DL01",
    "manufacturername": "YSRSAI",
    "productname": "Dimmable light",
    "capabilities": {
        "certified": false,
        "control": {},
        "streaming": {
            "renderer": false,
            "proxy": false
        }
    },
    "config": {
        "archetype": "classicbulb",
        "function": "functional",
        "direction": "omnidirectional"
    },
    "uniqueid": "00:12:4b:00:22:fd:3c:5f-01",
    "swversion": "1.0.11"
}

It is this specific 3rd party device (YSRSAI). I have several other devices that are not reachable, like this one that have the correct state (grayed out) in Home Assistant:

{
    "state": {
        "on": false,
        "bri": 234,
        "alert": "select",
        "mode": "homeautomation",
        "reachable": false
    },
    "swupdate": {
        "state": "transferring",
        "lastinstall": "2021-08-10T10:13:50"
    },
    "type": "Dimmable light",
    "name": "Fietsenhok",
    "modelid": "LWA001",
    "manufacturername": "Signify Netherlands B.V.",
    "productname": "Hue white lamp",
    "capabilities": {
        "certified": true,
        "control": {
            "mindimlevel": 5000,
            "maxlumen": 800
        },
        "streaming": {
            "renderer": false,
            "proxy": false
        }
    },
    "config": {
        "archetype": "pendantround",
        "function": "functional",
        "direction": "omnidirectional",
        "startup": {
            "mode": "safety",
            "configured": true
        }
    },
    "uniqueid": "00:17:88:01:06:b2:ed:6e-0b",
    "swversion": "1.90.1",
    "swconfigid": "57F72628",
    "productid": "Philips-LWA001-1-A19DLv5"
}

Two differences (maybe relevant); The YSRSAI is 3rd party Chinese device, not part of any zigbee group. The second is a Philips bulb, part of a zigbee group But several other devices, also not powered, not Philips and also not part of any group report correctly again. Like this one (an old Living Whites) :

{
    "state": {
        "on": false,
        "bri": 1,
        "alert": "select",
        "mode": "homeautomation",
        "reachable": false
    },
    "swupdate": {
        "state": "notupdatable",
        "lastinstall": "2020-01-25T12:24:04"
    },
    "type": "Dimmable plug-in unit",
    "name": "LW plug2",
    "modelid": "LWL001",
    "manufacturername": "Signify Netherlands B.V.",
    "productname": "LivingWhites Plug",
    "capabilities": {
        "certified": true,
        "control": {},
        "streaming": {
            "renderer": false,
            "proxy": false
        }
    },
    "config": {
        "archetype": "plug",
        "function": "functional",
        "direction": "omnidirectional"
    },
    "uniqueid": "00:17:88:01:00:2f:06:45-0c",
    "swversion": "1.0.1.4591"
}

If you want me to do some experiment, just let me know! Regards Eric

probot-home-assistant[bot] commented 2 years ago

hue documentation hue source (message by IssueLinks)

probot-home-assistant[bot] commented 2 years ago

Hey there @balloob, @marcelveldt, mind taking a look at this issue as it has been labeled with an integration (hue) you are listed as a code owner for? Thanks! (message by CodeOwnersMention)

marcelveldt commented 2 years ago

Haha, this is actually intended. Non official Signify devices report their state very badly so literally yesterday we've added a workaround that a light will not go to unavailable if it's not a Philips/Signify light. We had several reports from users that had lights set to unavailable while they were in fact alive.

If you need to know the actual zigbee state of a light we've added some (default disabled) sensors with the actual state of the zigbee control.

Settings --> Integrations --> Hue --> devices --> Pick a light --> Look for disabled entities --> enable the zigbee sensor

marcelveldt commented 2 years ago

As a reference: https://github.com/home-assistant/core/pull/61603/files

erkr commented 2 years ago

Thanks for explaining! I have a lot of 3rd party devices on my HUE bridge (e.g. IKEA, innr, muller, sunricher, Chinese unknowns and old living whites) I understand others have devices that work fine although reported as not reachable. Not my experience. When my 3rd party devices report to be unreachable in the Philips app, they actually have connection problems (intermittently not responding). Would it be an option to select the desired behavior in de config part of the Hue integration?! PS: I removed all OSRAM devices from my ecosystem years ago because they messed up the mesh

marcelveldt commented 2 years ago

I understand what you mean. I believe the reported malfunctioning devices were Osram and Lidl if I remember correctly. What we could do is create some sort of blacklist of the misbehaving lights and only bypass the availability check for those blacklisted lights.

erkr commented 2 years ago

Hi, My two cents: Black listing probably won't improve compared to just ignore the reachability flags for any type of lights! Some explanation: My experience is that 3rd party devices like OSRAM and some Tuya's, simply don't route properly (dropping traffic). In my case these devices where causing also reachability issue for other devices (incl Philips) that where further away from the bridge. So I would propose to simplify the approach, instead of adding blacklists. Just make a configuration option to either ignore the reachable flag or respect them, and simply do that for all devices. Reasoning: these 3rd party devices can cause connection issues for all type of lights incl Philips. My preference would be to respect the flag, as I removed all malfunctioning devices to create a stable mesh (important for the WAF factor đŸ¤“) Best Regards Eric

marcelveldt commented 2 years ago

I totally get what you mean. I experienced the same issues on my setup a few years ago. Adding a configuration option is additional complexity/confusion we don't want but you have a valid point that this should not be blindly ignored, users should fix their faulty hardware.

Maybe we should log whenever a light gets blacklisted. That way it can still be controlled but users will at least get some (nagging) notification in the logs that something is wrong and we ignored it.

majkers commented 2 years ago

The idea of automatically blacklisting bulbs is no good for me sorry. I have IKEA/Philips bulbs connected to hue bridge that are most of the time during the day switched off by a wall switch. So if I restart my home assistant during that time my IKEA bulbs will be blacklisted automatically. And later, when turned on and after some time turned off by a wall switch again they will not be unavailable but stay on as for Home assistant. Yes I know I might write an automation to automatically turn it off relaying on zigbee sensor but what if there are connection issues? My automation will turn off my lights even though it should not....

marcelveldt commented 2 years ago

I get what you mean. I have a small improvement in mind. If the light actually reports its availability state through the zigbee sensor (good functioning bulbs will actually do, bad ones won't), the blacklist will be removed. Also, the blacklist doesn't apply at Signify/Official bulbs at all.

majkers commented 2 years ago

I think it would be better to blacklist by default but add an option in config to whitelist by the user.

marcelveldt commented 2 years ago

That's additional complexity we'd like to prevent (if possible). So looking for a solution that works by default. So either hold a static list of all misbehaving lights (not easy as it also depends on firmware version) or have a device level configuration option. Perhaps a switch entity of type configuration to override the behavior. I'll think on it a bit.

majkers commented 2 years ago

OK thanks. In the meantime I wrote some automation relying on new zigbee status sensor