Missing lights after update to 2.22.02

deCONZ General Support
1

I just updated to 2.22.02 and now I have many lights missing:

[
  {
    "error": {
      "address": "/lights/6",
      "description": "resource, /lights/6, not available",
      "type": 3
    }
  }
]

Whats happening?

2

Have you ever operated the lamps after the update? Also a disconnect from the power and reconnect can remedy the situation. We have not been able to reproduce such behavior so far.

3

Yes. I even tried search for new lights without success. I dont know exactly how many lights were missing but at least 10.

I ended up restoring my deconz backup from before the update to the updated version. After that only one last light was missing. I re-paired it and now they’re all back.

4

Strange, there was no change for loading devices from the database.
Can you please share from which version you updated and the operating system platform you have.

On Linux:

uname -a
5

Linux raspberrypi 5.10.103-v7+ #1529 SMP Tue Mar 8 12:21:37 GMT 2022 armv7l GNU/Linux

I updated from stable to stable

6

Thanks this helps, I’ll make some tests. If possible can you please also send us the backup to support@dresden-elektronik.de with that I can run the exact same setup in the debugger.

7

email sent

8

Thanks a lot, I did a test running your backup first with v2.21.2 and saving the output of REST-API /lights call. Then did the same with v2.22.2 and compared the JSON files, and see also the missing devices.

After digging a little deeper the problem seems to be when we introduce a DDF for lights which was formerly handled by C++ code (like some Ikea lights in latest release) the loading from DB is skipped, which is normally the right thing but should only be done for the very first load until all DDF based database items are created.

I’m creating a hotfix now, fortunately the legacy database entries are all still in the database so update to new version is sufficient.

Side note: this is issue is present in all prior versions too.

2 Likes
9

Interestingly, the code does already “self heal” and create the correct devices, but it takes a couple of minutes initially, until the required data is fetched from the light (modelid and manufacturer name).

I think this is also the proper way to be sure we use the fresh values right from the light instead of relying on database entries which the legacy code might have created based on some assumptions like “Philips” vs “Signify”. So the real open task here is to speed this process up during warmup phase.