"update": { "state": null } leads to template errors in Home Assistant

[mundschenk-at]

What happened?

One of my devices is a Iluminize 5112.80. I think the device theoretically support OTA but no firmware image has ever been made available. The firmware may also be buggy.

The state (reguarding updates) is reported as follows with both installed_version and latest_version missing:

    "update": {
        "state": null
    },
    "update_available": null

OTA checks for this device can not be triggered via the Z2M frontend (the device is simply not listed).

Despite this, the discovery topics for the update entity in Home Assistant are generated normally, which results in the logs getting spammed with template errors:

Template variable warning: 'dict object' has no attribute 'installed_version' when rendering '{{ value_json['update']['installed_version'] }}'
Template variable warning: 'dict object' has no attribute 'latest_version' when rendering '{{ value_json['update']['latest_version'] }}'

What did you expect to happen?

Either the latest_version and installed_version keys should be generated in the published state (possibly with bogus values) or the update entity should not be discoverable by Home Assistant.

How to reproduce it (minimal and precise)

Add an Iluminize 5112.80 to the network and enable HA discovery.

Zigbee2MQTT version

1.34.0-dev

Adapter firmware version

20231112

Adapter

zStack3x0

Debug log

No response

[Koenkk]

5112.80 doesn't support OTA and therefore shouldn't have an OTA entity, it also didn't support it in the past so I'm puzzled why this was discovered in the first place. When force removing and re-pairing this device, does the OTA sensor disappear?

[mundschenk-at]

I'll try. Reconfiguring alone did not change anything.

FWIW, it was shown as possible to update while paired with the Hue Bridge as well. Maybe different HW/SW revisions?

[mundschenk-at]

Re-pairing still has the broken update state. This is the information shown on the frontend:

There's also a genOta output cluster listed (I assume that has something to do with OTA update capabilities).

[Koenkk]

• Is the OTA sensor still discovered?
• Can you try to stop z2m, remove the update state manually from data/state.json and start z2m again?

[mundschenk-at]

Yes, it is still discovered. I'll try to manually edit the state file.

[mundschenk-at]

• Can you try to stop z2m, remove the update state manually from data/state.json and start z2m again?

There is no reference to the update state in data/state.json under the IEEE address of the Iluminize controller.

[Koenkk]

Yes, it is still discovered. I'll try to manually edit the state file.

Could you provide the debug log when force removing, and repairing this device?

See this on how to enable debug logging.

[mundschenk-at]

You mean zigbee-herdsman debug logging, right?

[Koenkk]

No, just the z2m one.

[mundschenk-at]

OK, I already had debug logging running. I have isolated the two relevant sections of the logfile, but I don't know what (if anything) is sensitive information in there.

Is there perhaps a more private channel to make that data available to you? I assume you are not interested in any messages that refer to other devices (because there is quite a bit of chatter between when the device was removed and when it finally rejoined - had to reset it with a Hue remote).

[mundschenk-at]

Well, these should be the relevant parts: iluminize-log-20231210-minimal.txt.zip

[Koenkk]

Found the issue, should be fixed now!

Thanks for reporting this, if this had gone to prod, every supported light would have an update sensor discovered for it 😆

Changes will be available in the dev branch in a few hours from now.

[mundschenk-at]

Thanks, looks good (I always update directly from GitHub)!