Aqara WSDCGQ12LM Pressure Reads Null? Z2M Fix + Calibration

I run an Aqara WSDCGQ12LM in my own setup, and the first thing that bit me was a null value on the pressure entity right after pairing. The sensor wasn’t broken. It was a Zigbee2MQTT parsing bug, and the fix takes about thirty seconds.

This guide covers the null-pressure fix, then the calibration choices you’ll want to make once readings come through. Pairing and entity basics are covered in my Aqara T1 temperature sensor setup guide, so I won’t repeat those here at length.

No Aqara hub. No cloud account. Standard Zigbee2MQTT or ZHA via a USB coordinator. The pillar guide on running Aqara Zigbee devices in Home Assistant without the hub walks through coordinator and Z2M setup if you’re starting from zero.

Which model is this article about

There are two Aqara temperature/humidity/pressure sensors that frequently get confused, both stamped with similar-looking model codes.

WSDCGQ11LM is the original. Round-puck appearance in most retail photos, ships with a CR2032, reports temperature, humidity, and atmospheric pressure on Zigbee2MQTT.

WSDCGQ12LM is the T1 revision. Same 36 mm footprint, same three measurement entities, same CR2032. The T1 reports battery as a percentage out of the box where the older WSDCGQ11LM often reports voltage only.

The model code is printed on the back of the device, under the battery cover if it’s not visible on the outside. Trust the printed code over the shape — Aqara has shipped both pucks and rounded-rectangle revisions under similar product names.

This article is about the T1 (WSDCGQ12LM). If you’re on the older model, almost everything below still applies — the null-pressure Z2M bug is specific to the WSDCGQ12LM, but the calibration and altitude-correction sections work identically.

What the sensor reports in Zigbee2MQTT

Once paired and interviewed, the WSDCGQ12LM exposes these entities to Home Assistant via MQTT.

A few things worth flagging.

device_temperature measures the sensor’s internal chip, not the room. On a freshly-paired device it can read a few degrees higher than ambient. Don’t build automations against it. Use temperature instead.

pressure reports absolute atmospheric pressure at the sensor’s physical location. At altitude, this reads lower than the sea-level-equivalent pressure your local weather service reports. The calibration section below covers the correction.

All entities are read-only. There are no writable controls on this device.

Why pressure reads null (and how to fix it)

This is the main reason people land on this article. Temperature and humidity show up cleanly after pairing, then the pressure entity sits at null or unavailable indefinitely.

It’s a known Zigbee2MQTT parsing issue on first pair, tracked in zigbee2mqtt issue #20740. On older Z2M builds the device’s attribute discovery completed without resolving the pressure cluster, so the entity stayed empty even though the hardware was reporting normally. Fixed in a later Z2M release.

The fix has two parts.

First, update Zigbee2MQTT to a current release. The bug is parse-side, so simply moving to a build past the fix resolves it for new pairs.

Second, re-trigger device interview so the existing pair re-discovers the pressure attribute. In the Z2M web UI, open the device page for your WSDCGQ12LM, then click “Re-interview” (or the equivalent refresh-and-re-interview button in your Z2M version). Wait for the interview to complete. The device will cycle through its attribute discovery again, and the pressure entity should populate with a real value within a minute or two.

If pressure still reads null after a clean re-interview on a current Z2M, the next step is a full re-pair. Remove the device from Z2M, factory-reset the sensor by holding the reset pinhole for about 5 seconds until the LED blinks three times rapidly, then pair again from the Z2M web UI.

The Z2M device page for the WSDCGQ12LM lists the minimum coordinator firmware versions worth checking if a full re-pair also fails. Adapter firmware that predates the device’s release in 2023 can also produce a similar null-attribute symptom.

Calibrating temperature, humidity, and pressure

Zigbee2MQTT exposes calibration offsets for all three measurement entities directly in the device settings UI. There’s no YAML editing required. The fields are form inputs labeled temperature_calibration, humidity_calibration, and pressure_calibration.

For temperature and humidity, compare the sensor against a reference thermometer or hygrometer and note the delta. Enter the offset value in the matching field, positive to increase the reported value, negative to decrease. The change applies to all subsequent reports.

For pressure, the pressure_calibration field is the right place to correct against a known-good reference at the same location. It is not the right place to derive sea-level-equivalent pressure from your altitude. Those are different operations, and conflating them will give you wrong readings under either interpretation.

Absolute pressure vs. sea-level pressure

The sensor reports the actual air pressure at its physical location. At sea level that’s roughly 1013 hPa on an average day, give or take with weather. At 80 m altitude, the same weather conditions give you about 1003-1004 hPa absolute. Local weather services almost always publish sea-level-equivalent pressure, so a direct comparison of your sensor against weather.com or a barometer app will look “off” by exactly the altitude correction.

If you want to compare apples to apples, derive sea-level pressure from your absolute reading using the standard barometric approximation.

P_sea_level = P_absolute / (1 - altitude_m / 44330) ^ 5.255

A Home Assistant template sensor handles this cleanly without touching the Z2M calibration field. Leave the raw pressure entity as the true absolute reading. Create a derived sensor for the sea-level comparison.

template:
  - sensor:
      - name: "Pressure (Sea Level)"
        unit_of_measurement: "hPa"
        state: >
          {% set p = states('sensor.wsdcgq12lm_pressure') | float(0) %}
          {% set alt = 80 %}
          {{ (p / ((1 - alt / 44330) ** 5.255)) | round(1) }}
        device_class: atmospheric_pressure

Replace sensor.wsdcgq12lm_pressure with your actual entity ID and 80 with your altitude in metres. You then have both readings available — the raw absolute pressure for tracking incoming weather systems, and the sea-level-corrected value for sanity-checking against any weather integration.

Z2M also lets you reduce reported precision (0 to 3 decimal places) for any entity if you want cleaner numbers in your history graphs. You can’t increase precision beyond what the sensor natively outputs.

Adjusting reporting frequency

By default, the WSDCGQ12LM reports on change rather than on a fixed interval. In a stable indoor environment with consistent temperature and HVAC off, that can mean no update for several hours. That’s normal behaviour, not a sensor fault.

If you want more frequent updates — for example, to catch gradual overnight temperature drift — adjust the reporting configuration in Z2M’s Reporting tab on the device page. You can set minimum and maximum reporting intervals per attribute. A maximum interval of 300 seconds forces a report at least every 5 minutes regardless of whether the value changed.

More frequent reports cost battery life. For most monitoring use cases, a 15-30 minute maximum interval is a reasonable compromise between freshness and longevity.

Routing and dropout prevention

Aqara Zigbee devices have well-documented non-compliance with parts of the Zigbee specification, which causes dropout issues when they route through certain third-party Zigbee router devices. Brands cited in Z2M’s compatibility notes as known-bad for Aqara routing are Centralite, GE, and Ledvance/OSRAM.

The WSDCGQ12LM is a Zigbee end device. It doesn’t route traffic for other devices. But its own connection upstream still relies on finding a reliable router, so the routing-compatibility issue matters indirectly.

Practical steps to avoid dropouts.

Pair the sensor in its intended final location, or as close to it as you can get. Pairing near the coordinator and then moving it causes the device to try to reassociate through a different path, which sometimes fails.

Check the LQI (Link Quality Indicator) on the device’s Z2M page. Below 20 LQI is likely to cause intermittent disconnects. Move the sensor closer to a reliable router, or add a mains-powered Zigbee router device on the path between sensor and coordinator.

Battery voltage can be deceptive. A nearly-depleted CR2032 sometimes reports as partially charged while causing unreliable transmission. If a sensor is dropping messages, swap the battery before debugging network topology.

Using the sensor in Home Assistant

Once Zigbee2MQTT is integrated with Home Assistant via the MQTT integration, the sensor entities appear automatically under the device. Default entity IDs follow the pattern sensor.<device_name>_temperature, sensor.<device_name>_humidity, and sensor.<device_name>_pressure.

A few things I’ve found useful.

History graphs. All three measurement entities work natively with HA’s history and statistics dashboards. The raw absolute pressure entity can be charted alongside the altitude-corrected template sensor if you want both values visible.

Automation triggers. The temperature and humidity entities are well-suited as automation triggers. Pressure changes more slowly and is less useful as a trigger, but it works well as a condition or as data for a weather dashboard.

Statistics sensor for long-term averaging. If you want daily min/max/mean values, the statistics platform works with any of the three measurement entities.

sensor:
  - platform: statistics
    name: "Temperature daily mean"
    entity_id: sensor.wsdcgq12lm_temperature
    state_characteristic: mean
    sampling_size: 144
    max_age:
      hours: 24

ZHA note. If you’re running ZHA instead of Zigbee2MQTT, the pressure entity is reportedly present, but calibration offset configuration isn’t exposed in the ZHA UI the same way Z2M does it. You’d handle any correction via a template sensor instead. The altitude-correction template above works equally well in either integration.

Pairing the sensor with other air-quality monitoring

The WSDCGQ12LM covers temperature, humidity, and atmospheric pressure. It does not cover VOCs, CO2-equivalent, or particulate matter. If you want a fuller indoor-air picture, the Aqara TVOC monitor adds VOC and CO2e readings without needing a hub or cloud account. I covered that setup in the Aqara TVOC air quality monitor guide.

Pairing a WSDCGQ12LM with a TVOC sensor in the same room gives you a reasonably complete view of indoor air conditions — temperature, humidity, pressure, and air quality — all local, no cloud accounts, no hub dependencies.

The pressure reading is the differentiator of this sensor over a plain temperature/humidity unit, and it earns its place once you have it altitude-corrected and lined up against an outdoor weather source. Watching indoor absolute pressure track an approaching front is one of those small things that starts as a curiosity and ends up being a dashboard tile you actually glance at.