Main

‘Up to 100 Meters’ Indoors: Measuring Zigbee LQI and RSSI Through Walls and Learning What the Numbers Mean

October 1, 2026

“Up to 100 meters” is a marketing number. It describes a free-space, line-of-sight radio path between two devices with good antennas, no interference, and no walls. Your house is not that. The number you actually care about is the one your coordinator reports for each device right now, and whether it changes when the microwave runs or the door closes.

This article is about reading those numbers honestly. Zigbee link quality is not a single value, and the two values most stacks expose — RSSI and LQI — measure different things. Treating them as interchangeable is how people end up moving a repeater three times for no reason.

What RSSI and LQI actually are

RSSI (Received Signal Strength Indicator) is a measure of how much radio energy arrived at the receiver. It is usually reported in dBm, a logarithmic scale where more negative is weaker. A reading of −50 dBm is a strong signal; −90 dBm is near the noise floor for 2.4 GHz Zigbee in a typical home.

LQI (Link Quality Indicator) is not a signal-strength measurement in the same sense. In the IEEE 802.15.4 physical layer, LQI is derived from the received signal and is intended to indicate how cleanly a frame was demodulated. Different radio chipsets compute it differently, and different firmware maps it to different ranges. Some stacks report LQI on a 0–255 scale; others report 0–100. A value of 255 on one coordinator and 100 on another can mean the same thing.

This is the first trap: LQI is not portable across chipsets. If you compare a number from a Silicon Labs coordinator to a number from a Texas Instruments coordinator, you are comparing two different formulas. The Home Assistant ZHA documentation lists supported radio types including Silicon Labs EmberZNet (ezsp), Texas Instruments (znp), deCONZ, ZiGate, and XBee — each with its own stack underneath. Zigbee2MQTT similarly sits on top of zigbee-herdsman, which talks to the adapter through chipset-specific APIs.

RSSI is more comparable across hardware, but still not perfectly so. Antenna gain, cable loss, and receiver sensitivity vary. Use RSSI for relative comparisons on your own network, not as an absolute standard.

Where the numbers come from in your stack

In Zigbee2MQTT, link quality is exposed per device. The exact topic depends on your configuration, but the pattern is zigbee2mqtt/<friendly_name> for device state and zigbee2mqtt/bridge/devices for the device list. The bridge publishes device metadata including network address and type (Coordinator, Router, or End device). Link quality is typically published as an attribute on the device topic or available through the frontend. The Zigbee2MQTT MQTT topics documentation describes the base topic structure and the bridge/devices retained message that lists connected devices.

In ZHA, link quality is exposed as a diagnostic entity on each device. The ZHA integration documentation describes the network information page under Settings > Connectivity > Zigbee, which shows the channel, PAN ID, coordinator IEEE address, radio type, and serial port. That page is where you confirm which channel you are on before you start blaming walls.

Neither stack gives you a calibrated dBm reading by default in the UI. Zigbee2MQTT can expose RSSI if the device or adapter reports it, but many end devices do not. ZHA’s diagnostic entities vary by device and coordinator. If you need RSSI specifically, check whether your coordinator firmware exposes it and whether your integration surfaces it. If it does not, you are working with LQI alone, and you need to interpret it relative to your own baseline.

What walls actually do

2.4 GHz signals attenuate through building materials. The amount depends on material, thickness, moisture content, and angle. Drywall is relatively transparent. Brick, concrete, and stone are not. Metal lath, foil-backed insulation, and radiant barriers are close to blockers. Water — including people and houseplants — absorbs 2.4 GHz energy.

I have not seen a single authoritative table that covers every residential construction type, and I am not going to invent one. What I can say from the physics and from the way Zigbee mesh networks behave is this: a wall between coordinator and device costs you signal, and a second wall costs you more. The loss is not linear in a way you can predict from a floor plan. You measure it.

The practical consequence is that “up to 100 meters” might be 30 meters through two interior walls, or 8 meters through a brick wall and a metal door. The only way to know is to measure at the actual locations.

A repeatable measurement procedure

You need a baseline before you can diagnose anything. Here is a procedure that produces comparable numbers.

  1. Pick a fixed reference point. Put a mains-powered Zigbee device — a smart plug or a bulb — at a known location. This is your reference. Do not move it during the test.
  2. Record the coordinator’s reported LQI and RSSI for that device. In Zigbee2MQTT, check the device topic or the frontend. In ZHA, check the diagnostic entities. Write down the values and the time.
  3. Move the test device in steps. If you are testing a wall, place the device on one side, record, then move it to the other side at the same height and orientation. Record again.
  4. Wait for the mesh to settle. Zigbee devices do not report instantly. Battery devices may sleep for minutes or hours. Mains-powered devices report more often. Give the network at least a few minutes, and for battery devices, trigger them so they transmit.
  5. Repeat at different times of day. 2.4 GHz interference from Wi-Fi, microwave ovens, and cordless phones varies. A reading at 7 AM may not match one at 7 PM.
  6. Log the values. A spreadsheet is fine. A Home Assistant sensor that records LQI over time is better because it captures the trend.

The point of the procedure is not to get a perfect number. It is to get a comparable number so you can tell whether a change helped.

What the numbers mean in practice

There is no universal threshold. A link that works fine for a temperature sensor that reports every five minutes may fail for a light that needs to respond in under a second. The requirement depends on the device and the use case.

What you can do is establish your own thresholds from your own data:

  • Stable and responsive: The device reports on schedule, commands execute on the first try, and LQI does not swing wildly between readings.
  • Marginal: The device works most of the time but occasionally misses a report or needs a second command. LQI is lower than your stable devices and fluctuates.
  • Unusable: The device drops off the network, reports unavailable, or requires re-pairing. LQI is at or near the bottom of your observed range.

Record the LQI values you see in each category. Those are your thresholds. They will not match someone else’s, and that is fine.

One caveat: LQI can be high even when a link is unreliable, if the device is close to a router but the route to the coordinator is bad. Zigbee is a mesh. The link quality you see is often the last hop, not the whole path. Zigbee2MQTT’s network map request (zigbee2mqtt/bridge/request/networkmap) can show routes, but the documentation warns that during the scan the network will be less responsive, and recommends triggering it manually. Use it when you need to see the path, not as a continuous monitor.

Diagnosing a poor link

When a device reports poor LQI or keeps dropping, work through this in order:

  1. Confirm the device is actually on the network. Check zigbee2mqtt/bridge/devices or the ZHA device list. A device that has fallen off will not report meaningful LQI.
  2. Check the channel. In ZHA, go to Settings > Connectivity > Zigbee > Network information. In Zigbee2MQTT, check zigbee2mqtt/bridge/info for the network channel. If you are on a channel that overlaps with a strong Wi-Fi access point, that is a candidate cause. The ZHA documentation notes that the best practice is not to change the Zigbee channel from the default, and that the “Smart” channel selection is a one-time operation that does not continuously monitor.
  3. Look for a router nearby. Zigbee networks depend on mains-powered routers to extend coverage. The ZHA documentation states that Zigbee networks depend heavily on having multiple router devices to expand coverage and increase device capacity. If the device is far from any router, add one between it and the coordinator.
  4. Check the device’s last hop. If the device is connected to a router that is itself marginal, fixing the router’s link may fix the device. Use the network map to see the parent.
  5. Test with the device in a different location. If LQI improves dramatically when you move the device two meters, the problem is local attenuation or interference, not the network as a whole.
  6. Check for interference sources. Microwave ovens, 2.4 GHz cordless phones, baby monitors, and Wi-Fi access points on overlapping channels are common culprits. Turn them off one at a time and re-measure.

If none of that helps, the device may have a weak radio, a bad antenna, or a firmware issue. That is when you consider replacing it — not before.

Logging and alerting without a cloud

The whole point of a local-first stack is that you can see this data without a vendor’s app. In Home Assistant, you can create template sensors or use the integration’s diagnostic entities to record LQI over time. The recorder integration stores history locally. You can graph it with the built-in history panel or with a custom dashboard.

For alerting, a simple automation that triggers when a device’s LQI drops below your marginal threshold for more than a few minutes is enough to catch a developing problem. You do not need a cloud service for this. You need a sensor, a threshold, and a notification action.

If you want to log LQI from Zigbee2MQTT, you can subscribe to the device topic with an MQTT client and write the values to a file or a database. The MQTT topics documentation describes the message format. This is more work than using the frontend, but it gives you a permanent record.

Graceful degradation when the link fails

A Zigbee link that drops below usable levels should not leave your house in a bad state. The specific fallback depends on what the device controls.

For lights: a smart bulb that loses its Zigbee link is still a bulb. If the wall switch is on, it stays on. If you want a fallback, wire the circuit so that a plain switch can still control it. This is the same principle as any smart-home reliability plan: the dumb path should always work.

For locks: do not rely on Zigbee alone. A key still works. If you have a smart lock that fails closed when the network drops, that is a design choice you should know about before it happens.

For sensors: a sensor that stops reporting is not dangerous by itself, but an automation that depends on it may be. If a door sensor drops off, your “door left open” alert stops working. You can detect this by monitoring the sensor’s availability topic in Zigbee2MQTT (zigbee2mqtt/<friendly_name>/availability) or the equivalent in ZHA, and alerting when a device goes unavailable.

The ZHA documentation describes options for considering mains-powered and battery-powered devices unavailable after a timeout. Those settings are your first line of defense against silent failures. A battery sensor that normally reports every hour but has not reported in six hours is a candidate for investigation, not a device that is simply quiet.

For critical automations, build in a check: if the sensor has not reported in the expected window, treat the state as unknown rather than assuming the last known state is still true. This is more work than a simple trigger, but it is the difference between a system that fails safe and one that fails silently.

When a plain switch is the better answer

Not every light needs to be smart. If a closet light or a hallway light is in a location where Zigbee coverage is marginal and the only automation you want is “turn on when the door opens,” a mechanical timer or a plain switch with a motion sensor may be more reliable and cheaper. The tradeoff is real: you lose remote control and scheduling, but you gain a device that works without a network.

The same applies to any device where the smart feature is a convenience rather than a requirement. If the cost of a failed link is low, the cost of engineering around it may not be worth it.

Frequently asked questions

Can I compare LQI values between different Zigbee coordinators?

Not directly. LQI is computed differently by different radio chipsets and firmware. A value of 255 on one coordinator may not mean the same thing as 255 on another. Compare values within your own network, not across networks.

Is RSSI or LQI more useful for diagnosing range problems?

RSSI tells you how much signal arrived. LQI tells you how cleanly it was received. For range problems, RSSI is more directly interpretable because it is a physical measurement. For interference problems, LQI may degrade while RSSI stays high. Use both if your stack exposes them.

How often should I check link quality?

Check when you add a device, when you move a device, when you change your Wi-Fi configuration, and when a device starts behaving unreliably. Continuous monitoring is useful for catching trends, but it is not necessary for every device.

Will adding a repeater always improve LQI?

No. A repeater helps if it provides a better path to the coordinator. If the repeater itself is poorly placed or the device is already connected to a good router, adding another one may not help. Place the repeater between the device and the coordinator, and verify the device actually connects to it.

Does Zigbee channel matter for LQI?

Yes. If your Zigbee channel overlaps with a strong Wi-Fi signal, LQI can degrade even at close range. The ZHA documentation recommends not changing the channel from the default without reviewing interference avoidance guidance first.

What to do next

Pick one device that has been unreliable. Record its LQI and RSSI now. Move it one meter. Record again. Move it back. Record again. You now have a baseline and a sense of how much the number changes with position. That is more useful than any threshold table, because it is your house, your walls, and your interference.

If you want to audit the rest of your small systems while you are at it, the procedure in How to Audit the Small Systems That Quietly Run Your Week applies the same principle: measure what is actually happening, write it down, and only then decide what to change.