search

dresden-elektronik / deconz-rest-plugin

deCONZ REST-API plugin to control ZigBee devices
BSD 3-Clause "New" or "Revised" License
1.9k stars 503 forks source link

Philips Hue White Ambiance (LTW001) change state to „on“ automatically #7551

Closed FlatTV closed 9 months ago

FlatTV commented 9 months ago

Does the issue really belong here?

Is there already an existing issue for this?

Describe the bug

After switching off the lamp using the Deconz API, the status in the API changes back to “On” after a few seconds. In reality the lamp is still off.

Steps to reproduce the behavior

  1. Switch lamp to „off“ in deconz-API
  2. The lamp switch to „off“ and the state in deconz-API switch to „off“.
  3. wait and do nothing…
  4. The deconz API state switch to „on“ but the lamp is still „off“.

Expected behavior

just nothing

Screenshots

https://forum.phoscon.de/t/ltw001-light-shows-on-after-vew-seconds-in-deconz-api-but-the-real-state-is-off/4378

Environment

deCONZ Logs

No response

Additional context

No response

SwoopX commented 9 months ago

Hm, interesting case. Could you please fetch some debug logs?

Option 1:

To get debug logs in a GUI installation, open deCONZ and click Help. After that, click Debug View. The following debug levels need to be enabled for proper logging: INFO, INFO_L2, ERROR, ERROR_L2, APS, APS_L2. Please note that in the HA Addon and Docker webVNC, you can't copy paste. You need to use a Native VNC Client. HA Addon How-To, Docker Environment Vars.

Option 2:

To get debug logs in a headless installation / ssh session, use the following commands:

sudo systemctl stop deconz-gui
sudo systemctl stop deconz
/usr/bin/deCONZ -platform minimal --dbg-aps=2 --dbg-info=2 --dbg-error=2 | tee debug.txt

When done, exit the process with CTRL+C. You can now start the systemctl service again. Your logs will be printed in the console, as well as saved to a file named debug.txt in the current directory. Be sure to capture at least a few minutes worth of logs. When sharing these logs, DO NOT attempt to paste them into a channel. Instead use a pastebin service such as this or this.

Afterwards, don't forget to disable logging. This is especially important when running off an SD card, as the debug logging will cause unnessecary writes, and might shorten the life of your media.

FlatTV commented 9 months ago

Log: Lamp “WZ_Schranklicht” has the status “On”, then I switch it to “Off” via API. https://pastebin.com/pfuwTs37

SwoopX commented 9 months ago

Thanks!

@ebaauw This might be one for you. I assume line 2767 may give the answer, at least the status seems to change only through cluster 0xfc03.

ebaauw commented 9 months ago

With the DDFs I created for the Hue ZB3 lights, deCONZ shouldn't be polling the On/Off cluster. The DDF should setup attribute reporting for 0xFC03, with polling of that cluster as fallback. Hue ZLL lights, like the LTW001, don't support attribute reporting (as per the ZLL spec), but the DDF still should only poll the 0xFC03 cluster.

Is the bulb on the latest firmware?

Last time I checked, the Hue bridge still doesn't setup nor use attribute reporting, and also polls On/Off, Level Control, and Color Control. The attributes from these clusters should still reflect the light state (and even support attribute reporting on ZB3 lights).

FlatTV commented 9 months ago

LTW001 has FW 67.88.1, that’s the last version I think

ebaauw commented 9 months ago

I think not, see https://www.philips-hue.com/en-us/support/release-notes/lamps

FlatTV commented 9 months ago

LTW001 now has 67.108.5 with same effect.

ebaauw commented 9 months ago

Does the faulty on state disappear:

After turning the light off through the API, does the state change:

We assumed the LTW001 would behave like the LTW010 and LTW012, but it does have adifferent firmware image (0x0104) from the other two (0x010C). Maybe the LTW001 implements the Hue Effects cluster (0xFC03) differently? Do you see any errors or warning when turning on DDF and JavaScript debugging?

ebaauw commented 9 months ago

I'm having a hard time dissecting the log. I take it the NWK address of the LTW001 is 0x1E51?

14:46:04:842 APS-DATA.indication srcAddr: 0x1E51, srcEp: 0x0B dstAddrMode: 2, profile: 0x0104, cluster: 0xFC03, lqi: 255, rssi: -67
14:46:04:842    asdu: 1c0b1033010200004106070000fec601

This looks like an as yet unsupported mode, 0x0700, carrying on, bri, and ct.

               attr st dt  l mode on br   ct
1c 0b 10 18 01 0200 00 41 06 0700 00 fe c601
                                 off 254 454

Not sure of I missed this before, or if Signify changed this in later firmware. Previously, I saw mode 0x000F, carrying on, bri, ct, anf xy (computed from ct).

Normally, the script would ignore this unknown mode, but since it won't set any item, the (legacy?) code might decide to fallback to polling the On/Off cluster?

The good news: I'm also seeing the mode on my Hue Color Temperature and Extended Color lights (both ZLL and ZB3), after Move to Color Temperature. I'll update fc03_state.js to handle this. Still not sure if that actually causes your issue, though. EDIT The script probably just returns the value of the last assignment, which is non-zero, causing the JS wrapper to set state/on to true (since the javascript was invoked from that item).

FlatTV commented 9 months ago

This commit fix the problem https://github.com/dresden-elektronik/deconz-rest-plugin/commit/b8cb3b3ebeb05c031efee58e2aefaa66c095877a