Closed ilbambino closed 1 year ago
Please attach the debug dump file, and indicate which lights this concerns. Apart from the warning messages, do you actually experience any issue?
I have tried to add the value
noResponse
: true as what I could understand from the docs.
Where did you add it? And what docs?
I have a few lights that sometimes are completely unreachable (disconnected from a physical switch).
That’s generally a bad idea and not recommended. I know, your spouse is likely to disagree, and you might not have a choice.
I used to be using the hue plugin, now I've migrate to this new one.
Did you set wallSwitch
in Homebridge Hue? If so, you might want to set this in Homebridge deCONZ as well, only here it’s a dynamic setting per light, see the Wiki.
That’s generally a bad idea and not recommended. I know, your spouse is likely to disagree, and you might not have a choice.
🤣 do we all go through the same? I know it is not ideal, but partner complains, and I have some devices to install behind the switch, but installation is old and I need to do lots of wiring. It was working okish (except that of course if someone switches off from the wall, automations stop working)
Did you set wallSwitch in Homebridge Hue? If so, you might want to set this in Homebridge deCONZ as well, only here it’s a dynamic setting per light, see the Wiki.
I didn't do anything special in the old install. Deconz reports the lights as off. It is in hombebridge that the state is changed.
Please attach the debug dump file, and indicate which lights this concerns. Apart from the warning messages, do you actually experience any issue?
I read the docs from the wiki https://github.com/ebaauw/homebridge-deconz/wiki/Configuration
and I have added it in my json
{
…
"platforms": [
{
"name": "Config",
"port": 8581,
"platform": "config"
},
{
"name": "deCONZ",
"noResponse": true,
"platform": "deCONZ"
}
]
}
But there was no effect after adding that.
I have enabled the debug logs in home bridge
[4/18/2023, 3:34:56 PM] [deCONZ] phoscon: request 6484: PUT /lights/7/state {"ct":192}
[4/18/2023, 3:34:56 PM] [deCONZ] phoscon: request 6484: 200 OK
[4/18/2023, 3:34:56 PM] [deCONZ] phoscon: request 6484: PUT /lights/7/state {"ct":192}
[4/18/2023, 3:34:56 PM] [deCONZ] phoscon: warning: request 6484: /lights/7/state: api error 202: resource, /lights/7/state, is not modifiable. Device is not reachable.
There is not much more info in the logs. I don't know if there is another way to add more info in the logs. I couldn't find how in the wiki.
All the lights are IKEA.
And after testing a little more, it happens not only with Adaptive Lights. It happens with all lights that get fully disconnected (by a physical switch). Only the adaptive lights are more visible in the logs as the color is being updated frequently
Deconz reports the lights as off. It is in hombebridge that the state is changed.
If the deCONZ API reports the light as off, Homebridge deCONZ forwards that state to HomeKit. Is there a discrepancy between the state as reported by deCONZ vs the state in HomeKit?
If the light was on while cutting power, deCONZ continues to report it as on, and so will HomeKit. deCONZ cannot tell the difference between radio interference vs the light's power being cut, and it assumes the light is still on. The wallSwitch
setting forces the light to be reported as off to HomeKit, when deCONZ reports it as unreachable.
it happens not only with Adaptive Lights. It happens with all lights that get fully disconnected
If you try and control a light that's unreachable, the warning with API error 202 is expected
Again: apart from the warning message, do you experience any issue? If so, what is not working?
All the lights are IKEA.
Not helpful. Which light types, and in particular: do they carry Execute If Off? Hence my question for the dump file. I changed the Adaptive Lighting logic in Homebridge deCONZ from Homebridge Hue to continue to update colour temperature while the light is off, for lights with Execute If Off. But this new logic doesn't take into account whether the light is reachable. Not sure if I can do so, without breaking other stuff.
I have tried to add the value
noResponse
: true as what I could understand from the docs. But still the result is the same. I read the docs from the wiki https://github.com/ebaauw/homebridge-deconz/wiki/Configuration
Ah, I forgot about that page. I wanted to copy that setting from Homebridge Hue, but it is not yet implemented. Even if it were, it wouldn't change your situation. Basically, it's a poor attempt at reporting unreachable Zigbee devices as No Response in HomeKit. Unfortunately, that state cannot be set or cleared from the accessory (i.c. Homebridge); for that, you need to refresh the accessory state from Home, or another HomeKit app.
I used to be using the
hue
plugin, now I've migrate to this new one. First of all thanks a lot!!!I have a few lights that sometimes are completely unreachable (disconnected from a physical switch).
Some of those are detected/configured with the adaptive lightning. When that combination is on, those lights report as
on
when they are unreachable. In the logs I can seeI have tried to add the value
noResponse: true
as what I could understand from the docs. But still the result is the same.I don't know if a bug or a miss-configuration on my side.
I am using
homebridge-deconz v0.1.13