Why Do My Zigbee Devices Stop Reporting Battery Levels After Enabling Matter Multi-Admin?

Introduction

You’ve been running your smart home smoothly for months. Your Zigbee door sensors, motion detectors, and temperature sensors have been faithfully reporting their battery levels in Home Assistant, SmartThings, or whatever platform you trust. Then you decide to enable Matter multi-admin — because who doesn’t want their devices accessible across multiple ecosystems, right?

And suddenly, something strange happens.

Your Zigbee devices stop reporting battery percentages. Some show “unknown.” Others freeze at the last known value and never update again. You start wondering if your batteries actually died, or if something deeper broke in your setup.

I’ve been there. And after spending hours digging through logs, community forums, and testing different configurations, I can tell you — you’re not alone, and this problem has real, fixable causes.

In this article, I’m going to walk you through exactly why this happens, what’s going on technically behind the scenes, and — most importantly — how to fix it without breaking your entire smart home setup.

[📷 Image suggestion: A screenshot showing Zigbee devices with “unknown” or stale battery levels in Home Assistant or SmartThings dashboard after Matter was enabled]

Understanding the Basics: How Zigbee Battery Reporting Works

Before we jump into the problem, let’s quickly understand how Zigbee devices report battery levels in the first place.

How Zigbee Devices Communicate Battery Data

Zigbee devices — especially battery-powered ones like door/window sensors, motion sensors, and leak detectors — are designed to be sleepy end devices. This means they spend most of their time in a low-power sleep state and only wake up periodically to:

Report sensor data (motion detected, door opened, temperature reading)
Send battery cluster reports (usually every few hours)
Check in with the coordinator to confirm they’re still connected

The battery level is reported through what’s called the Power Configuration Cluster (Cluster 0x0001) in the Zigbee specification. This cluster includes attributes like:

Battery Voltage (measured in units of 100mV)
Battery Percentage Remaining (0–200, representing 0–100%)
Battery Alarm State

Most Zigbee coordinators (like ZHA, Zigbee2MQTT, or the SmartThings hub) are configured to listen for these periodic reports and update your dashboard accordingly.

Why This Matters for the Problem at Hand

The key thing to understand is that battery reporting depends on a stable, uninterrupted communication path between the Zigbee device and its coordinator. Anything that disrupts this path — or confuses the coordinator about which device is talking to it — can cause battery reports to stop showing up.

And that’s exactly where Matter multi-admin enters the picture.

[📷 Image suggestion: A simple diagram showing a Zigbee sleepy end device communicating battery data through a Zigbee coordinator to the smart home platform]

What Is Matter Multi-Admin and Why Does It Cause Problems?

Matter Multi-Admin Explained Simply

Matter is a universal smart home protocol developed by the Connectivity Standards Alliance (CSA). One of its most exciting features is multi-admin — the ability for a single device (or bridge) to be controlled by multiple ecosystems simultaneously.

For example, with Matter multi-admin enabled, your Zigbee devices (exposed through a bridge like a SmartThings hub or Home Assistant’s Matter server) could be controlled by:

Apple HomeKit
Google Home
Amazon Alexa
Home Assistant
All at the same time

Sounds amazing. But here’s the catch.

The Bridge Conflict Problem

When you enable Matter multi-admin on a hub that also serves as your Zigbee coordinator, you’re essentially asking that hub to do double duty:

Manage the Zigbee mesh network — including handling periodic check-ins and battery reports from sleepy devices
Serve as a Matter bridge — responding to fabric commissioning, multi-admin subscriptions, and data requests from multiple ecosystems

This creates a resource and priority conflict. The hub’s processing power, memory, and radio scheduling now have to juggle two demanding protocols. And unfortunately, battery reports from sleepy Zigbee devices are often the first casualty.

Why Battery Reports Specifically?

Here’s why battery levels are disproportionately affected compared to other sensor data:

Data Type	Report Frequency	Priority Level	Impact When Missed
Motion detected	Immediate (event-driven)	High	Noticeable instantly
Door open/close	Immediate (event-driven)	High	Noticeable instantly
Temperature	Every 30–60 min	Medium	Slow to notice
Battery level	Every 4–12 hours	Low	Takes days to notice

Battery reports are infrequent and low-priority. When the coordinator is under extra load from Matter operations, these low-priority, periodic reports are the most likely to be:

Dropped silently
Not processed in time before the device goes back to sleep
Lost in the coordinator’s message queue

[📷 Image suggestion: A comparison table or infographic showing the priority levels of different Zigbee data types and how Matter multi-admin affects each one]

Real-World Scenarios: What Users Are Actually Experiencing

Scenario 1: The SmartThings Hub User

Michael runs a SmartThings v3 hub with 23 Zigbee devices. Everything worked perfectly until he enabled Matter and paired his hub with both Google Home and Apple Home.

Within a week, he noticed:

8 of his Aqara door sensors showed battery as “unavailable”
His Sonoff motion sensor’s battery was stuck at 78% — the same value it showed before Matter was enabled
Event-based reporting (doors opening, motion detected) still worked fine

What happened: The SmartThings hub was overwhelmed by constant Matter subscription updates from two additional ecosystems. The hub’s internal scheduler started deprioritizing Zigbee battery attribute polling.

Scenario 2: The Home Assistant + Zigbee2MQTT User

Sarah runs Home Assistant with Zigbee2MQTT on a Sonoff Zigbee 3.0 dongle. She enabled the Matter integration in Home Assistant and used multi-admin to share devices with Google Home.

She noticed:

Battery levels for her IKEA TRÅDFRI sensors stopped updating
The Zigbee2MQTT log showed occasional ZCL frame parsing failed errors
Restarting Zigbee2MQTT temporarily fixed the issue, but it came back within 24–48 hours

What happened: Home Assistant’s Matter server was consuming significant system resources, causing slight timing delays in Zigbee2MQTT’s ability to process incoming reports from sleepy devices during their brief wake windows.

Scenario 3: The Apple HomePod + Eve User

David had Eve door sensors (Thread/Zigbee) and used his HomePod Mini as the Matter controller. After adding his devices to Samsung SmartThings via Matter multi-admin, battery reporting became inconsistent across all platforms.

What happened: The multi-admin configuration created conflicting subscription intervals. Each ecosystem was polling for battery data at different rates, and the device firmware couldn’t handle the overlapping requests properly.

[📷 Image suggestion: A real screenshot from a Home Assistant dashboard showing multiple Zigbee sensors with stale or “unavailable” battery readings]

The Technical Root Causes (Deep Dive)

Let me break down the specific technical reasons this happens. Understanding these will help you choose the right fix for your situation.

Cause 1: Coordinator Resource Exhaustion

When Matter multi-admin is active, your coordinator (hub or dongle) has to maintain:

The Zigbee mesh routing tables
Matter fabric credentials for each ecosystem
Active subscriptions for every shared device from every ecosystem
Periodic keep-alive messages for all Matter connections

This puts significant strain on coordinators with limited RAM and processing power — which includes most consumer hubs.

Result: The coordinator’s message queue fills up, and low-priority messages (like battery reports) are dropped before they can be processed.

Cause 2: Timing Window Misalignment

Sleepy Zigbee devices have very narrow wake windows — typically 5–15 milliseconds. During this window, the device:

Wakes up
Sends its queued reports (including battery data)
Checks for any pending commands from the coordinator
Goes back to sleep

If the coordinator is busy processing Matter-related traffic during this tiny window, it may miss the battery report entirely. The device doesn’t know its message was lost — it simply goes back to sleep and won’t try again until the next scheduled report (hours later).

Cause 3: Attribute Subscription Conflicts

Matter uses a subscription model for device attributes. When multiple ecosystems subscribe to the same device’s attributes through multi-admin, the bridge has to manage multiple subscription intervals.

Here’s where it gets tricky: the bridge may try to actively poll the Zigbee device for fresh battery data to satisfy a Matter subscription — but sleepy Zigbee devices cannot be polled on demand. They can only report data when they wake up on their own schedule.

This creates a mismatch:

Matter ecosystems expect data on their subscription schedule
Zigbee devices only provide data on their own wake schedule
The bridge gets confused and may stop correctly relaying battery data to any ecosystem

Cause 4: Firmware Bugs in Bridge Implementations

Let’s be honest — Matter is still relatively young. Many hub manufacturers are still ironing out bugs in their Matter bridge implementations. Some known issues include:

SmartThings: Battery cluster data not being correctly mapped to the Matter PowerSource cluster in early firmware versions
Home Assistant Matter Server: Memory leaks when handling large numbers of multi-admin subscriptions
Aqara Hub M2: Complete loss of battery reporting for child Zigbee devices when Matter is enabled

[📷 Image suggestion: A flowchart showing the path of a battery report from a Zigbee sleepy device through the coordinator/bridge to multiple Matter ecosystems, highlighting where failures can occur]

How to Fix Zigbee Battery Reporting After Enabling Matter Multi-Admin

Now for the part you’ve been waiting for — the solutions. I’ve organized these from simplest to most involved.

Fix 1: Restart Your Coordinator and Re-Interview Devices

Difficulty: Easy | Time: 10–20 minutes

Sometimes the simplest fix works. A restart clears the coordinator’s message queue and forces sleepy devices to re-establish their reporting schedules.

Steps:

Open your smart home platform (Home Assistant, SmartThings, etc.)
Restart the Zigbee coordinator/integration (not just the hub — specifically the Zigbee service)
Wait 15 minutes for sleepy devices to check in
For devices still showing stale battery data, re-interview them:
- ZHA: Go to the device page → click “Reconfigure Device”
- Zigbee2MQTT: Go to the device page → click “Interview”
- SmartThings: Remove and re-add the device
Wait 12–24 hours for a full battery report cycle

Why this works: Re-interviewing forces the coordinator to re-read all clusters, including the Power Configuration Cluster, and re-establish the reporting configuration.

Fix 2: Adjust Battery Reporting Intervals

Difficulty: Medium | Time: 15–30 minutes

You can configure Zigbee devices to report battery levels more frequently, which increases the chances of at least some reports getting through despite the Matter-related load.

In Zigbee2MQTT:

YAML# configuration.yaml for Zigbee2MQTT
devices:
  '0x00158d0004235612':
    friendly_name: 'front_door_sensor'
    reporting:
      1:  # Endpoint
        genPowerCfg:  # Power Configuration Cluster
          - attribute: batteryPercentageRemaining
            minimumReportInterval: 3600    # Report at least every 1 hour
            maximumReportInterval: 7200    # Report at most every 2 hours
            reportableChange: 2            # Report if battery changes by 1%

In ZHA (Home Assistant):

Go to Settings → Devices & Services → ZHA
Find your device
Click “Manage Clusters”
Select Cluster: Power Configuration (0x0001)
Set “Configure Reporting” with:
- Min interval: 3600 seconds
- Max interval: 7200 seconds
- Reportable change: 2

Important note: More frequent reporting will slightly reduce battery life. A report every 1–2 hours instead of every 6–12 hours is a reasonable trade-off.

[📷 Image suggestion: A screenshot showing the ZHA cluster configuration page in Home Assistant with the Power Configuration cluster selected and reporting intervals being configured]

Fix 3: Reduce Matter Multi-Admin Fabrics

Difficulty: Easy | Time: 5–10 minutes

Every Matter fabric (ecosystem) you add increases the load on your bridge. If you’ve added your devices to Google Home, Apple Home, Amazon Alexa, AND another Home Assistant instance, that’s four fabrics all requesting data simultaneously.

The practical approach:

Identify which ecosystems you actually use regularly for viewing battery data
Remove unnecessary Matter fabrics:
- In Home Assistant: Settings → Devices & Services → Matter → Remove fabric
- In SmartThings: App → Device → Connected Services → Disconnect
Keep only 1–2 ecosystems connected via Matter multi-admin

My recommendation: Use a maximum of 2 Matter fabrics alongside your primary Zigbee coordinator. This has proven to be the sweet spot where battery reporting remains reliable for most users.

Fix 4: Separate Your Zigbee Coordinator From Your Matter Bridge

Difficulty: Advanced | Time: 1–2 hours

This is the most effective long-term solution. Instead of making your Zigbee coordinator also serve as the Matter bridge, separate these responsibilities.

Architecture change:

Before (problematic):

textZigbee Devices → [Hub acting as BOTH Coordinator + Matter Bridge] → Multiple Ecosystems

After (recommended):

textZigbee Devices → [Dedicated Zigbee Coordinator] → Home Assistant → [Separate Matter Server] → Multiple Ecosystems

How to implement this in Home Assistant:

Use a dedicated Zigbee dongle (like SONOFF Zigbee 3.0 USB Dongle Plus) exclusively for Zigbee coordination
Run Zigbee2MQTT or ZHA on this dongle
Enable the Matter Server add-on separately in Home Assistant
Expose devices to other ecosystems through the Matter Server — which now doesn’t interfere with the Zigbee radio at all

Why this works: The Zigbee coordinator can focus 100% on managing the Zigbee mesh and processing reports from sleepy devices. The Matter bridge runs as a separate software process with its own resources.

[📷 Image suggestion: A before/after architecture diagram showing the combined setup vs. the separated coordinator/bridge setup]

Fix 5: Update All Firmware

Difficulty: Easy–Medium | Time: Varies

Many of the issues with battery reporting and Matter multi-admin have been addressed in firmware updates throughout 2024 and early 2025.

Check for updates on:

Component	Where to Update
SmartThings Hub	SmartThings App → Hub → Firmware Update
Home Assistant	Settings → System → Updates
Zigbee2MQTT	Add-on Store → Zigbee2MQTT → Update
ZHA / Zigbee coordinator firmware	Check manufacturer’s GitHub (e.g., Koenkk for CC2652, Nabu Casa for SkyConnect)
Individual Zigbee device firmware	Via OTA in Zigbee2MQTT or manufacturer’s app
Matter Server	Home Assistant Add-on Store → Matter Server → Update

Specific firmware fixes to look for:

SmartThings Hub firmware 48+: Fixed Matter bridge battery attribute mapping
Zigbee2MQTT 1.35+: Improved handling of sleepy device reports under high load
Home Assistant Matter Server 5.0+: Reduced memory usage and improved subscription management

Fix 6: Create a Battery Monitoring Automation

Difficulty: Medium | Time: 20–30 minutes

While you’re fixing the root cause, you can create an automation that actively monitors battery levels and alerts you when they become stale.

Home Assistant automation example:

YAMLautomation:
  - alias: "Alert on Stale Zigbee Battery Reports"
    trigger:
      - platform: time
        at: "09:00:00"
    condition: []
    action:
      - service: notify.mobile_app_your_phone
        data:
          title: "⚠️ Stale Battery Reports Detected"
          message: >
            The following devices haven't updated battery in 24+ hours:
            {% set threshold = 86400 %}
            {% for state in states.sensor 
              if 'battery' in state.entity_id 
              and state.state not in ['unavailable', 'unknown']
              and (as_timestamp(now()) - as_timestamp(state.last_updated)) > threshold %}
            - {{ state.name }}: {{ state.state }}% (last updated {{ relative_time(state.last_updated) }} ago)
            {% endfor %}

This automation checks every morning and alerts you if any battery sensor hasn’t updated in over 24 hours — giving you early warning before a device silently dies.

[📷 Image suggestion: A screenshot of a Home Assistant notification on a phone showing the stale battery alert with device names and last update times]

Prevention Tips: Keeping Battery Reporting Healthy Long-Term

Based on my experience and the experience of hundreds of smart home users, here are the best practices to prevent this issue from recurring:

1. Build a Strong Zigbee Mesh

Sleepy end devices depend on their parent routers to buffer and forward their messages. If your Zigbee mesh is weak, battery reports are more likely to be lost — especially under the additional load from Matter.

Add dedicated Zigbee routers (smart plugs, in-wall switches) near clusters of battery devices
Aim for a ratio of at least 1 router for every 4–5 sleepy devices
Use IKEA TRÅDFRI smart plugs or Sonoff Zigbee smart plugs as affordable, reliable routers

2. Monitor Coordinator CPU and Memory

If you’re running Home Assistant on a Raspberry Pi, the combination of Zigbee coordination + Matter server + other integrations may push your hardware to its limits.

Check your system resources:

Go to Settings → System → Hardware in Home Assistant
If CPU usage regularly exceeds 80% or RAM is consistently above 85%, consider upgrading to more powerful hardware (like a mini PC with an Intel N100 processor)

3. Don’t Over-Share Devices via Matter

Not every device needs to be shared with every ecosystem. Be selective:

Share lights and switches for voice control across ecosystems
Keep battery-powered sensors primarily in your main platform
Only share sensors via Matter if you genuinely need them in another ecosystem

4. Schedule Regular Coordinator Restarts

A weekly restart of your Zigbee coordinator can prevent queue buildup:

YAMLautomation:
  - alias: "Weekly Zigbee Coordinator Restart"
    trigger:
      - platform: time
        at: "03:00:00"
    condition:
      - condition: time
        weekday:
          - sun
    action:
      - service: zha.restart

[📷 Image suggestion: A Zigbee network map visualization (from Zigbee2MQTT or ZHA) showing a healthy mesh with routers positioned near sleepy end devices]

Frequently Asked Questions (FAQ)

Will disabling Matter multi-admin immediately restore battery reporting?

In most cases, yes. Once you remove the additional Matter fabrics, your coordinator’s workload decreases, and battery reports typically resume within 12–24 hours as devices complete their next reporting cycle. However, some devices may need to be re-interviewed or power-cycled (remove and re-insert the battery) to fully restore normal reporting.

Does this problem affect all Zigbee devices equally?

No. Devices from different manufacturers handle battery reporting differently. In my experience:

Aqara devices are most susceptible because they have very short wake windows
IKEA TRÅDFRI devices are moderately affected
Philips Hue sensors tend to be more resilient because they have longer wake windows and more robust retry mechanisms

Can I use Thread devices instead to avoid this problem?

Partially. Thread-based Matter devices don’t rely on a Zigbee coordinator, so they’re not affected by the coordinator resource exhaustion issue. However, Thread devices with Matter multi-admin can still experience subscription conflicts. The problem is less severe, but not eliminated entirely.

Is this a bug that will be fixed in future Matter updates?

Likely yes, at least partially. The Matter specification is being actively improved, and bridge implementations are getting more efficient with each update. Matter 1.3 and 1.4 introduced better subscription management, which should reduce the impact on Zigbee battery reporting. However, the fundamental hardware limitations of budget coordinators won’t change — separating your coordinator and bridge remains the most future-proof solution.

Does this only happen with battery levels, or are other Zigbee attributes affected too?

Battery levels are the most visibly affected because they update so infrequently. But in severe cases, you may also notice:

Temperature and humidity reports becoming less frequent
LQI (Link Quality Indicator) values not updating
Illuminance sensor readings becoming stale

Event-based reports (motion, door open/close) are usually the last to be affected because they’re triggered immediately and have higher priority.

How do I know if my coordinator is overwhelmed?

Look for these signs:

Zigbee2MQTT or ZHA logs showing delivery failed or timeout errors
Devices occasionally falling off the network and rejoining
Increased latency when controlling Zigbee devices (lights responding slowly)
Battery reports not updating for multiple devices simultaneously

My Personal Recommendation

After testing multiple configurations across different hardware setups, here’s what I recommend for the most reliable setup when using both Zigbee and Matter multi-admin:

Use a dedicated Zigbee coordinator (USB dongle) — don’t rely on a hub that’s also acting as a Matter bridge
Run Home Assistant on capable hardware — at minimum a Raspberry Pi 4 with 4GB RAM, ideally a mini PC
Limit Matter fabrics to 2 — your primary platform plus one additional ecosystem
Don’t share battery sensors via Matter unless you absolutely need to
Update everything regularly — coordinator firmware, integration software, and device firmware
Monitor battery report freshness using the automation I shared above

This setup has given me zero issues with battery reporting across 30+ Zigbee devices while maintaining Matter multi-admin with Google Home.

[📷 Image suggestion: A photo of a recommended hardware setup showing a mini PC running Home Assistant with a dedicated Zigbee USB coordinator dongle plugged in, and a phone showing healthy battery levels for all devices]

Final Thoughts

The loss of Zigbee battery reporting after enabling Matter multi-admin is a frustrating but solvable problem. It’s not a fundamental incompatibility between the protocols — it’s a resource management issue that stems from asking hardware to do more than it was originally designed for.

The good news is that the smart home ecosystem is maturing rapidly. Every firmware update, every Matter specification revision, and every coordinator hardware refresh brings us closer to a world where multi-protocol homes “just work.”

In the meantime, use the fixes in this guide to get your battery reporting back on track. Start with the simple solutions (restart, re-interview, reduce fabrics) and work your way up to the architectural separation if needed.

Your smart home should give you peace of mind — and knowing your sensor batteries aren’t silently dying is a big part of that.

Have you experienced this issue with a specific hub or device combination? I’d love to hear about your experience and what worked for you.