Aqara LED bulbs (lumi.light.aqcn02) unavailable after deCONZ restart

[bcutter]

Does the issue really belong here?

• I definitively want to report a bug within deCONZ or its REST-API

Is there already an existing issue for this?

• I have searched the existing issues and there is none for the bug at hand

Describe the bug

Nearly 100 % similar to the bug described #4545 and solved in 2021, I experience this for all those lumi.light.aqcn02 bulbs for a few weeks/months.

Not sure when this got introduced again.

Manually reading the basic cluster fixes this. This is of course a very annoying workaround.

Waiting for ~ 60 minutes (like for passive devices) does not help here, they stay in this state like forever (not fully tested cause the house relies on those bulbs so... 2 to 3 hours roughly was tested once).

Steps to reproduce the behavior

1. Check all Aqara lights are okay
2. Restart deCONZ
3. Discover they are unavailable

Expected behavior

Bulbs shall be available as all other (active) devices. Basic cluster should be read automatically.

Screenshots

Phoscon after deCONZ restart:

HA after deCONZ restart:

Basic cluster bulb one before read manually:

Basic cluster bulb one after read manually:

Basic cluster bulb two before read manually:

Basic cluster bulb two after read manually:

Environment

• Host system: Raspberry Pi
• Running method: Home Assistent deCONZ Add-on
• Firmware version: 26720700
• deCONZ version (not Home assistant Addon version!): 2.31.2
• Device: ConBee II
• Do you use an USB extension cable: yes
• Is there any other USB or serial devices connected to the host system? If so: Which?

deCONZ Logs

No response

Additional context

Just see #4545 as a kick start. Maybe the fix solving it that time got reverted in the last couple of deCONZ releases.

[bcutter]

Is anyone interested in this? If software updates break things - okay, this could happen - but then after pointing to such a bug by filing an issue, a response after 2 weeks would be great at least.

[github-actions]

As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.

[bcutter]

https://nostalebots.xyz

I wonder why no one is picking this up. In my naive theory fixing this should be quite low-level and as easy as reading basic clusters once during deCONZ startup / devices initialization ...which seems to have been the case in earlier releases and somehow got removed.

Pardon me for directly pinging @Smanar.

[SwoopX]

Is this a device already covered by DDF? Do you have the opportunity to make changes to the generic resource items?

[Smanar]

How look the node in the editor ? connected or not ? have you tried to use the GUI to send a on/off order ? It's not possible using Phoscon or HA because the API don't send order if the device is "unavailable" for IT, but the GUI can.

Can try to take a look in logs with flags "error"+"error_l2" + "info"+ "info_l2"

Edit:
Yes https://github.com/dresden-elektronik/deconz-rest-plugin/blob/master/devices/xiaomi/xiaomi_lumi.light.aqcn02_TunableWhite_Bulb.json

[bcutter]

Yes of course this device is quite old and well-known, working flawlessly with deCONZ for years. It's just that after deCONZ restarts it does not get initialized ANYMORE.

Do you need anything additional from me? Let me precisely know what I need to check or provide.

[SwoopX]

I wouldn't go that far and call the device "well-known", but anyway...

Before proposing a potential fix, I'd like to understand if the basic cluster MUST be read or if it can be an arbitrary cluster. Other cluster's attributes are already polled, so not a high chance that any other cluster will do. Presumably, issuing any API commands do not yield any reaction?

I'd propose to make a slight change on the DDF to see it that resolves the responsiveness issue at hand. The part

        {
          "name": "attr/manufacturername"
        },

should be changed to

        {
          "name": "attr/manufacturername",
          "read": {
            "fn": "zcl:attr",
            "ep": 1,
            "cl": "0x0000",
            "at": ["0x0004", "0x0005"]
          },
          "refresh.interval": 300
        },

This should basically enable polling of the basic cluster attributes manufacturername and modelid. If it works, the device should come back latest 5 mins after restart.