eMotion Air (LinknLink) - action values don't map to distinct button presses, illuminance readings seem far too low

What happened?

Repository: Koenkk/zigbee-herdsman-converters (device definition issue, not zigbee2mqtt core or herdsman itself)
Device: Linkind eMotion Air (mmWave presence + temperature/humidity/illuminance sensor with single button)
Zigbee2MQTT device page: https://www.zigbee2mqtt.io/devices/eMotion_Air.html

Describe the bug

This device has a single physical button, but the documented action values (on, off, toggle, brightness_move_to_level, brightness_move_up, brightness_move_down, brightness_step_up, brightness_step_down, brightness_stop) appear to originate from a light-switch-remote profile with multiple physical buttons/rockers. With only one physical button available, I cannot find a consistent mapping between number of presses (single/double/triple) and a specific action value.

Steps I tried:

• 1x press → toggle
• 2x press → on
• 3x press → off
• Long press (held ~10-15s) → no distinct action fires; the action sensor simply falls back to unknown after a delay

The mapping between press count and action value is not consistent across repeated tests - the same press pattern doesn't reliably reproduce the same action. This makes it impossible to build reliable automations distinguishing single/double/triple click.

Additionally, brightness_move_up appeared once in testing but I never saw a corresponding brightness_move_down, brightness_step_up, or brightness_step_down despite repeated testing - these documented values may not be reachable at all with this device's single-button hardware.

Illuminance readings seem implausibly low

With illuminance_raw enabled, I get:

• Finger covering the sensor: raw = 0
• Held directly in front of a bright white monitor screen (close range): raw = 21336 → converted to 136 lx

The conversion itself checks out against the standard Zigbee illuminance formula (10^((raw-1)/10000) = 136.0), so the Z2M-side conversion is not the issue. However, 136 lx directly in front of a bright monitor at close range seems far too low - I'd expect several hundred lx in that situation. This suggests either:

• a hardware sensitivity/calibration issue on the device itself, or
• the sensor being physically obstructed/dampened by the enclosure

I have not yet cross-verified against a dedicated lux meter or phone app, but wanted to flag this in case others see the same pattern.

Context

• This is a newly-shipped Kickstarter device; multiple backers report receiving units within the last 1-2 days (as of writing) and several have mentioned similarly odd behavior (slow mmWave reaction time ~30-45s, no sensitivity/range configuration option, inconsistent button actions).
• Firmware was updated to the latest available version via Z2M OTA before testing.
• No sensitivity/detection_range type option currently exists in the device's exposes, unlike many other mmWave sensors - not sure if this is planned.

What I expected

Either:

1. A documented, consistent mapping for single/double/triple click and long-press for this specific single-button variant, or
2. Confirmation that this is a firmware limitation on Linkind's side (in which case, happy to close this if that's confirmed)

Happy to provide debug logs / raw Zigbee frames if that helps narrow this down.

What did you expect to happen?

No response

How to reproduce it (minimal and precise)

No response

Zigbee2MQTT version

2.13.0

Adapter firmware version

20260310

Adapter

SLZB-06

Setup

Add-On in Home Assistant OS in Proxmox on an Intel NUC

Device database.db entry

No response

Debug log

No response

Notes

No response

Start with the eMotion Air device definition in zigbee-herdsman-converters and inspect its action mapping and illuminance exposes. Reproduce the button presses with debug logs or raw Zigbee frames, then compare the observed values with the converter behavior. Done means either correcting a confirmed converter mapping or documenting that the behavior is caused by firmware or hardware.