Aqara RTCZCGQ11LM + Zigbee2MQTT + Home Assistant = has no attribute 'presence'

[garry0garry]

What happened?

RTCZCGQ11LM (Aqara Presence sensor FP1) Coordinator EZSP v8 v6.10.3.0 (Sonoff Zigbee 3.0 USB Dongle Plus V2” (model "ZBDongle-E") ) Zigbee2MQTT v1.35.3

{
    "approach_distance": "far",
    "device_temperature": -16,
    "last_seen": "2024-02-11T21:37:47+03:00",
    "linkquality": 104,
    "monitoring_mode": "undirected",
    "motion_sensitivity": "high",
    "power_outage_count": 70,
    "presence_event": "leave",
    "update": {
        "installed_version": 58,
        "latest_version": 58,
        "state": "idle"
    },
    "action": null,
    "update_available": null
}

Home Assistant v2024.2.1 I constantly receive the following warning in Home Assistant:

Logger: homeassistant.helpers.template
Source: helpers/template.py:2345
First occurred: 11:03:27 (120 occurrences)
Last logged: 21:37:47

Template variable warning: 'dict object' has no attribute 'presence' when rendering '{{ value_json.presence }}'

Why? presence_event != presence? Do I understand correctly that there was a name change? If so, why is there no device_class: presence for presence_event?

What did you expect to happen?

No response

How to reproduce it (minimal and precise)

No response

Zigbee2MQTT version

1.35.3

Adapter firmware version

6.10.3.0

Adapter

ZBDongle-E

Setup

Docker

Debug log

No response

[rccoleman]

I've started seeing this as well. I've seen the presence key appear and disappear, and sometimes change to null like

I see that there's been a lot of refactoring of the Aqara/Lumi devices in the past couple of weeks and perhaps something was missed. I tried the latest dev build and it's still not properly reporting the presence key to MQTT.

[rccoleman]

I've been running the latest dev version, updating a few times over the weekend, and I've stopped seeing this. I'm currently on this version: 1.35.3-dev commit: 5766bf4

[garry0garry]

Zigbee2MQTT v1.36.1

After turning off and on the FP1 device, the status of the Presence sensor is always N/A..

{
    "approach_distance": "medium",
    "device_temperature": 17,
    "last_seen": "2024-04-04T18:51:01+03:00",
    "linkquality": 80,
    "monitoring_mode": "undirected",
    "motion_sensitivity": "high",
    "power_outage_count": 1,
    "presence_event": "leave",
    "update": {
        "installed_version": 58,
        "latest_version": 54,
        "state": "idle"
    },
    "action": null,
    "update_available": null
}

https://github.com/Koenkk/zigbee2mqtt/issues/17643 https://github.com/Koenkk/zigbee2mqtt/issues/16724

[rccoleman]

I'm pretty sure I understand the problem now. The device sometimes returns 255 as the value for the presence property, which is turned into null here. When the getfromLookup function retrieves null from the dict, it then ends up returning the defaultValue from here, which is undefined. Later, I believe that the payload is turned into a string for publishing via JSON.stringify(), as it is in the debug line, which drops the key when the value is undefined as this explains. The end result is that the existing discovered binary_sensor entity in HA that uses {{ value_json.presence }} as its state template cannot find the property when the device returns 255 as its presence value.

One possible solution is to provide a defaultValue of null to avoid getfromLookup returning undefined, or do what's done elsewhere in the file and avoid the getFromLookup function entirely and just return null, as is done here. The exact same problem will happen with presence_event if the device returns 255 based on this.

[Koenkk]

@rccoleman undefined is removed from the JSON payload indeed. Would ignoring 255 be the correct solution here?

[rccoleman]

I don't know what 255 is supposed to mean for the presence value, but maybe 'I don't know' or it hasn't been initialized either way in the device. The problem is that once MQTT discovery happens for the binary_sensor, it will continue to look for that tag in every update and log a warning if it doesn't find it (one that's hard to track down if you don't know what to look for). null may be the best 'unknown' value, and I think that HA will use 'unknown' as the state.

If we just ignore it, that will also remove the key from the update, right?

[Koenkk]

This should fix the issue https://github.com/Koenkk/zigbee-herdsman-converters/commit/1d71b43ab6c04303e765787a6ff477401f806f5c

Changes will be available in the dev branch tomorrow.