ebaauw / homebridge-deconz

Homebridge plugin for deCONZ
Apache License 2.0
135 stars 7 forks source link

Device is not reachable #155

Closed MSL-DA closed 12 months ago

MSL-DA commented 12 months ago

I get quite a few error messages like these on 2 out of 38 light units. It concerns two devices from Signify and only these two. I have tried removing them and adding them again. But the error occurs sporadically

homebridge-deconz v1.0.0

ZigbeeGW: warning: request 575: /lights/3/state: api error 202: resource, /lights/3/state, is not modifiable. Device is not reachable.

ZigbeeGW: warning: request 586: /lights/3/state/ct: api error 201: parameter, ct, is not modifiable. Device is set to off.

{
    "capabilities": {
        "alerts": [
            "none",
            "select",
            "lselect",
            "blink",
            "breathe",
            "okay",
            "channelchange",
            "finish",
            "stop"
        ],
        "bri": {
            "min_dim_level": 0.2
        },
        "color": {
            "ct": {
                "max": 454,
                "min": 153
            },
            "modes": [
                "ct"
            ]
        }
    },
    "colorcapabilities": 16,
    "config": {
        "bri": {
            "execute_if_off": false,
            "startup": "previous"
        },
        "color": {
            "ct": {
                "startup": 336
            },
            "execute_if_off": false
        },
        "groups": [],
        "on": {
            "startup": "previous"
        }
    },
    "ctmax": 454,
    "ctmin": 153,
    "etag": "39aab761fb42aa8e7b5a09e73304ee66",
    "hascolor": true,
    "lastannounced": null,
    "lastseen": "2023-08-21T16:53Z",
    "manufacturername": "Signify Netherlands B.V.",
    "modelid": "LTG002",
    "name": "HL1",
    "productid": "Philips-LTG002-3-GU10CTv2",
    "productname": "Hue ambiance spot",
    "state": {
        "alert": "none",
        "bri": 152,
        "colormode": "ct",
        "ct": 334,
        "effect": "none",
        "on": false,
        "reachable": true
    },
    "swconfigid": "87D6EF03",
    "swversion": "1.93.11",
    "type": "Color temperature light",
    "uniqueid": "00:17:88:01:09:70:8a:25-0b"
}
ebaauw commented 12 months ago

These are API errors returned by deCONZ; Homebridge deCONZ just logs these.

The 202 is a typical case of sh*t happens: due to interference (or the light being powered off) deCONZ marks it as unreachable. I think it still should send the Zigbee message, so the light might react, despite the API error.

The 201 could happen if you manage to change the colour temperature from HomeKit while the light is off. Most HomeKit apps will try and turn the light on first, when changing the colour temperature while the light is off. This shouldn’t happen due to adaptive lighting, as Homebridge deCONZ (should) only send the ct when config/color/execute_if_off is enabled. It should enable this, when adaptive lighting is enabled, but I’ve seen sometimes that deCONZ doesn’t take this, see https://github.com/dresden-elektronik/deconz-rest-plugin/issues/6710. In that case, best enable execute_if_off manually (through the deCONZ API, or from the deCONZ GUI).

MSL-DA commented 12 months ago

Many thanks for the explanation.

The 202 is a typical case of sh*t happens: due to interference (or the light being powered off) deCONZ marks it as unreachable. I think it still should send the Zigbee message, so the light might react, despite the API error .

When I think about it, it is a phenomenon that has occurred after I have changed the Zigbee channel to 25. Does that sound plausible?

I just never experienced the light not responding, so thought it was the Homebridge deCONZ

ebaauw commented 12 months ago

When I think about it, it is a phenomenon that has occurred after I have changed the Zigbee channel to 25. Does that sound plausible?

Very much so. The light could have missed the channel change (e.g. because it was powered off or due to interference) and still try to communicate on the old channel. Changing the channel of an existing Zigbee network is not a good idea, I’m my experience. Resetting and re-pairing the light should make it reachable again.

I just never experienced the light not responding

I have. Most common situations are (I think in order): cutting power to the light, interference (mostly USB-3), bugs in the light firmware, routing issues on large Zigbee network with devices from different (Zigbee stack) vendors.