Aqara's Support Changed My Mind. Their Engineers Fixed My FP2.

One of my Aqara FP2 presence sensors died in August, 33 months into a 12-month warranty. It took two months, several different diagnoses from Aqara, and shipping the dead unit to Hong Kong before I got the full story. The sensor wasn't broken beyond repair after all. According to Aqara, its engineers fixed it in their lab, and they've since worked out a way to recover sensors stuck the same way remotely, for any owner who qualifies, in or out of warranty. But nothing I had access to could have done either. Along the way I also got the best support I've ever had from a smart home company. I didn't expect to be writing all of that in the same article, but here we are.

If you haven't used one, a presence sensor is not a motion sensor. A regular motion sensor only notices you while you're moving, so if you sit still on the couch long enough, the room decides it's empty and the lights go off. The FP2 uses millimeter-wave radar to detect people even when they're sitting perfectly still, and it can split a room into zones, so it knows whether you're at the desk, on the couch, or in the doorway.

I bought this one new in November 2023. Around August 21, 2026 it stopped working. Thirty-three months old, twelve-month warranty. I knew going in that I wasn't owed anything.

What I could see was a firmware update that wouldn't finish. The app kept offering an update, and every single attempt climbed to about 80 percent and then died with Unknown error (993012).

The weird part is that through every one of those update attempts, the sensor stayed online. It kept reporting Wi-Fi signal and light levels like nothing was wrong. It showed up in the app. It just wouldn't detect a single person, and it wouldn't take the firmware that might have fixed it.

I should explain why I cared this much about one sensor. The FP2s in my house drive a 3D floorplan in Home Assistant, where little figures for each person move from room to room based on which zone reports presence. As long as the room's sensor says it's occupied, the figure stays put.

I haven't found anything else that does positional zone presence quite like it. So this wasn't a spare motion sensor in a hallway. It was a load-bearing part of how my house knows where people are, and that's why this turned into two months of digging instead of just ordering a new one.

When something in my system misbehaves, I tend to treat it less like "this product stopped working" and more like a problem to isolate and figure out. So before and during the support case, I did a lot of testing. The full details, with the API calls and the numbers, are in the appendix at the end for anyone who wants them. Here's what it came down to.

I ruled out the obvious stuff. Factory reset, re-pairing, different networks, different power adapters, strong Wi-Fi signal. Nothing changed. About 80 percent, then 993012, every time.

I had a second, working FP2 to compare against. I bought the two fifteen days apart from the same seller, and they live in the same house, on the same account and the same network. One worked. One didn't. That turned a lot of guesswork into side-by-side comparisons.

I got the same failure without the phone app. Aqara has a developer platform with a documented API. I got access, triggered the update directly through Aqara's own system, and watched it climb to 80 percent and fail exactly the way the app did. So the problem wasn't confined to my phone or the app, and switching networks hadn't helped either.

Settings changes on the broken sensor never showed up. When I changed a setting on the working sensor, the new value showed up almost immediately. On the broken one, the change was accepted, but the new value never appeared in what the sensor reported back, every time.

Some of my tests didn't prove what they seemed to. A walk test looked like a slam dunk at first (zero position reports from the broken sensor, 71 from the working one), but a setting difference between the two sensors means I can't say how much of that gap was the radar. The case for the radar failing comes from Aqara's own analysis, not from my walk test.

The hardware explains how it could be online but blind. According to community reverse-engineering work, the FP2 is really two computers in one box. One part handles Wi-Fi and the connection to Aqara's cloud. A separate part, the radar, does the actual job of detecting people. Each runs its own firmware. That's how the sensor could stay online and keep reporting light levels while the part that senses people had stopped responding. That same work, combined with Aqara's own firmware catalog, suggested the firmware version the sensor reported had the radar's version baked into it, and the radar half was reading as zero.

That was the evidence I gathered as the support case unfolded.

Aqara's explanation went through six stages over two months, counting the warranty reply at the start. Each one was more specific than the last, and every one of them came after I asked again.

1. Aug 21Sensor stops detecting people
2. Aug 29I open a support case
3. Sep 2Closed: out of warranty
4. Sep 3Developers call it an unrecoverable storage failure
5. Sep 7New analysis: the radar stopped responding first
6. Sep 10Replacement application complete
7. Sep 12Return shipment to Hong Kong planned
8. Sep 16Aqara confirms the replacements shipped
9. Sep 28Aqara confirms it arrived
10. Sep 29Both replacements received by this date
11. Oct 16Repaired in the lab
12. Oct 21Teardown explanation points to a power loss
13. Oct 26Bench finding: FLASH verification failing
14. Oct 30I learn it was repaired, after asking again
15. Nov 2Remote recovery confirmed for other owners

One: the warranty answer

Stage 1 of 6The warranty answer came before the diagnosis

I opened the case on August 29 with the symptoms, everything I'd already tried, and the working sensor for comparison. Support asked for access to the device logs, I gave it to them, and they confirmed they were looking.

On September 2, before I heard anything about the logs, the case was closed:

From Aqara

We're sorry that we can't offer a replacement for free cuz the one-year warranty has expired. You may consider buying a new device.

That was a fair answer to the replacement question. My warranty had expired, and I'd asked them to consider a goodwill replacement if the logs pointed to hardware or flash-memory failure. But the reply didn't tell me what the logs showed. That was the answer I still wanted.

Two: "an unrecoverable storage-level failure"

Stage 2 of 6Specific, confident, and later overturned

I wrote back and split the two questions apart. The warranty call is yours, and I'm not arguing with it, but you offered to look at the logs and I'd like to know what you found. I also sent them my API reproduction.

The next day, the answer came back from their development team:

From Aqara

This conclusion is based on anomalies identified in the device logs during the firmware writing phase, which point to an unrecoverable failure at the underlying storage level. Remote methods cannot bypass or repair this issue.

And this part stood out:

From Aqara

It should be made clear that this determination is not based on warranty status, but on technical facts.

That was the answer I'd been trying to get for a week. It also matched what I'd already decided: some kind of storage problem in the area that holds firmware during an update.

I was wrong, and so, partly, were they. That "unrecoverable" assessment didn't survive the investigation that came after it.

Three: the radar stopped responding first

Stage 3 of 6The turning point

I sent Aqara a draft of this article to check the facts, and made it clear publication didn't depend on their response. They went back to the development team for a closer look, and on September 7 the story changed a lot:

From Aqara

On August 21, the device was running firmware version 1.3.6_0003.0099, with the radar module operating normally. Shortly thereafter, the device began experiencing repeated restarts and subsequent disconnections... The radar module appeared to enter a non-responsive state, triggering a system-level reset by the main controller. This led to a series of failed upgrade attempts... The radar module was unable to respond to any further commands, which also prevented the system from retrieving the correct radar firmware version...

That, they said, is why it showed 0000 instead of 0099.

That flips the whole thing around.

The sensor was on 0099 and working. Then the radar stopped responding. Since nothing could talk to the radar, the system couldn't read its firmware version and showed 0000 instead. The cloud saw 0000 and sent 0098 as the next step. Aqara said directly that step is required because of network protocol changes, which also explains a "required" flag I'd found on that version in their firmware catalog. And those updates failed because the part they were aimed at was already unresponsive.

So the update failure I'd spent days documenting, the 80 percent wall, the error code in my subject line, all of it was a symptom, not the cause. The real failure happened before any of that, and there was no way to see it from the app. I walked right into that one.

It looked exactly like an update problem, so I treated it like one.

One thing that looks like a contradiction but isn't: nothing in the history I could pull through the API recorded a reboot or an offline transition during the update, but Aqara describes the device going offline right after booting. Both are true. They're describing different weeks. The reboot cycling happened around the original failure on August 21. By the time I was testing in September, the sensor had settled into a steady broken state, which fits what the teardown found later.

Four: the teardown

Stage 4 of 6The wording that read like blame

Then Aqara asked for the sensor back so they could physically take it apart, and they sent me an international prepaid label.

Before it went back, I should say what I'd done to it. After the September 3 message called the failure unrecoverable, I opened the case and photographed the board, thinking I might try to read the memory myself. I didn't go further than that. I never attached anything to the board, and I never tested the sensor after opening it. I told Aqara that in writing on September 7, before I shipped it. Their engineers later noticed the case had been opened, and said it didn't affect their diagnosis or the replacement decision. They also pointed out, fairly, that opening a device still under warranty is better left until you've talked to support.

The return shipment was planned for September 12. They confirmed they had it on September 28 and handed it off to a developer.

Their conclusion came on October 21:

From Aqara

The FP2 firmware is rather special. It is composed of multiple installation mode files and models merged together. If there is an abnormal power loss during the upgrade process, the device may mistakenly consider the firmware checksum valid; some program files may already be permitted to start but fail to run properly, and the device can only fall back to the bootloader for re-upgrade. For your situation, we recommend taking care not to cut power arbitrarily during the upgrade process.

That answer didn't sit right with me, and the only reason it got better is that I asked about it instead of just accepting it.

The October explanation started in a different place than the September one. September said the radar failed first and the update failures came after. October started with power getting cut during an update, and it ended with advice not to cut power during updates, which read like they were describing something I did.

I didn't do that. The sensor was plugged into a wall adapter the whole time, it had been running 0099 normally for months, and on August 21 it started rebooting on its own with no update running.

The wording also bugged me. The bootloader is the small piece of startup software that runs before everything else, and on a lot of devices it's how you reload firmware when the main firmware is broken. "Can only fall back to the bootloader for re-upgrade" sounds like there's a way to recover it, but back in September they'd said nothing remote could fix it. Both could be true if the bootloader route only works on a bench with the case open. I just couldn't tell.

So I wrote back the same day with four questions. Was the power loss supposed to point at the earlier update that installed 0099, and not at anything recent? Did the teardown find something specific on my unit, or did the conclusion come from logs and a known failure pattern? Is the bootloader route something an owner can get to, or only a lab? And did any of this change their view that my case is different from what other people have reported?

Support forwarded all four questions to the developers. On October 26, Aqara shared its bench findings but left the bootloader recovery question open.

Five: what the bench found

Stage 5 of 6Closer, but still no answer on recovery

From Aqara

After receiving the returned device, the developer disassembled it in the lab and connected it locally to check the logs, and found that the device had mistakenly entered a state of waiting in a loop for an upgrade.

Two terms are about to come up. FLASH is the memory that keeps the sensor's firmware when the power is off, and verification is the check the sensor runs at startup to confirm that firmware is intact before running it.

And on how that fits with the earlier remote analysis:

From Aqara

The previous analysis result was based on online logs. After the device was returned, the analysis showed that the firmware could not start normally, and the only possibility is that the FLASH verification could not pass. The highest probability is that this was triggered by a power loss during the upgrade process. However, if it was not in the upgrade state at that time, then the very brief online-to-offline (power-off restart) shown in the logs at that time most likely caused a failure in some sectors of the FLASH, which is inconsistent with cases reported by other users previously.

I'd told them the sensor wasn't updating when it failed. Instead of repeating the power-loss-during-update explanation, they offered a second one that fit what happened: if it wasn't updating, the restart cycling itself most likely damaged the FLASH sectors. That answered how it failed. It still didn't answer my bootloader question.

Six: they had fixed it

Stage 6 of 6Repair confirmed

I sent them the full draft on October 27 and asked two things directly: what started the failure, and whether the bootloader route was something an owner could reach. On October 30 the answer came back from their R&D team, and it changed the ending of this article.

From Aqara

After you sent the device back, our engineers connected it to a local debugging line in the lab and successfully repaired it via a local upgrade (it was tested and working normally). Furthermore, regarding the specific issue where the radar abnormally enters a loop waiting for an upgrade, our reproduction analysis confirmed that this can indeed be resolved by a remote firmware recovery procedure.

Those are two separate things, and it's worth keeping them apart. My unit was repaired locally, on a bench, with a debugging cable attached. Separately, Aqara says that working on my unit is what let them develop a remote procedure for this same stuck state. Aqara kept the original unit, and I hadn't expected it back. I'd already received both replacements.

On why my bootloader question had gone unanswered:

From Aqara

When you previously asked about the Bootloader recovery path, we couldn't disclose details because it involves the underlying system security of the device. Publicizing such a mechanism poses a risk of malicious exploitation and firmware tampering. Therefore, this recovery procedure can currently only be executed by official backend support and cannot be released as a public tool for users to operate themselves.

On why remote recovery wasn't mentioned earlier:

From Aqara

We did not initially mention remote recovery because, based on past experience, standard remote methods cannot resolve this type of underlying failure. However, the teardown analysis of your specific device allowed us to master the solution for this particular state.

And on what the bench actually showed:

From Aqara

It wasn't until we connected the debugging line and saw the serial data that the radar was continuously reporting 'C' (waiting for an upgrade) that we fully confirmed: this device was not physically damaged. Instead, a momentary, extremely rare abnormal offline event accidentally caused data corruption in certain FLASH sectors, which led to a firmware verification failure and got stuck in a wait-for-upgrade loop.

That "C" detail lines up with something I could check independently. The community project's notes say the radar takes firmware over a transfer protocol called XMODEM, and an XMODEM receiver signals it's ready by sending exactly that "C." So a radar repeating "C" is consistent with a radar sitting in its startup software, waiting for a firmware transfer. That supports the "stuck waiting for an update" part of their account. It doesn't tell me why the data got corrupted, or what caused the first restart.

On November 2 they filled in two more details. The corrupted memory belonged to the radar, not the main chip:

From Aqara

To be precise, the damaged FLASH is the storage space externally mounted to the radar module. This is exactly why the main controller chip (responsible for Wi-Fi and network connectivity) remained online, while the radar system failed to work...

The radar, in their words, "could not read the complete firmware from its corrupted storage." And on why every update died at about 80 percent:

From Aqara

When the main controller sends down the firmware (such as 0098) and attempts to run the normal upgrade process, the radar fails to provide the correct handshake response. As a result, when the firmware file reaches a specific step (around 80%) during writing, it fails the verification, causing the entire process to time out and abort.

That closes the loop on the 80 percent wall I spent so long documenting.

Back in that October 30 reply, they also cleared up the wording that had bothered me most. Their engineer's phrasing was imprecise, they said, and the logs clearly showed no update was running:

From Aqara

When our engineer mentioned "power loss," they were referring to the brief online-to-offline event (reboot) that the device experienced by itself during the anomaly.

That settles the discrepancy from October 21 without anyone having to win an argument about it.

And in the same October 30 reply, on the replacements:

From Aqara

Considering your device was already past its warranty and you had been delayed for eight weeks, we ultimately decided to directly provide you with two brand-new replacement devices, rather than having you go through the complex recovery process or return the old unit.

For the record, the replacements had already arrived by then. The agent handling my case started the request on September 4, Aqara said the application was complete on September 10, and both sensors reached me by September 29, weeks before the lab repair.

What this changes

This is a much better outcome than the earlier drafts of this article described, and their engineers deserve real credit for it. They didn't just examine a failed sensor. According to their account, they repaired it, figured out what state it was stuck in, and turned that into a recovery procedure for the next one.

It also means two earlier conclusions didn't hold up. The September 3 assessment that "remote methods cannot bypass or repair this issue" was superseded by what the teardown taught them. Aqara's October 30 explanation is that, based on past cases, the remote logs pointed to something "highly likely due to irreversible hardware failure," and that "remote logs are not comprehensive enough" to settle it, which is why they asked for the unit back. And my own conclusion, that this sensor had no way back, was wrong. By October 30, Aqara had repaired it and reported a remote procedure for the same stuck state. Neither was something I could have done myself.

The timing is the one part that still sits a little oddly. Aqara confirmed it had arrived on September 28. When I asked, Aqara told me it was restored in their lab on October 16, and that the remote procedure has been available since then. That means both the October 21 and October 26 answers came after the repair, and neither mentioned it. I heard about it on October 30, after I asked the bootloader question again. Their security reason explains why they wouldn't publish the details of the recovery mechanism. On the repair itself, Aqara acknowledged "a gap in our communication timeline" and said no more than that. That's an acknowledgment, not an explanation of why two replies after the repair didn't mention it, and I'm not going to guess at why. The dates are what they are, and they ultimately answered all four of my final questions.

What we still don't know

Aqara now says plainly that this was data corruption, not physical damage. That's a substantial finding. But the mechanism behind it is still their best explanation, in their words "most likely," and "extremely rare" is their characterization. They didn't give numbers, and I have no way to check it.

What caused that first brief offline event is still unknown. It may not be something the logs can ever answer, and Aqara hasn't claimed otherwise.

This is probably the most useful part of the whole article for most people, so I'll keep it simple.

From the outside, my failure looked exactly like what other FP2 owners have posted about: error 993012, dying around 80 percent, firmware reading 0000. That's exactly why I decided it was a storage or firmware-write problem. Aqara's teardown showed I had the right part for the wrong reason. FLASH was involved, but as corrupted data that left the radar stuck waiting for an update, not as physically damaged chips.

Aqara's position is that my case is not the same as the FLASH update problems some other users have reported, even though the symptoms look the same. They asked me to make that clear when I wrote this up, and I think that's a fair ask.

So, if you're seeing this:

• Other owners have reported FP2 firmware updates failing (Home Assistant community, Aqara forum), and it's easy to assume you've got the same known issue
• In my case, Aqara found the radar stuck waiting for an update after a firmware verification failure, and they see that as different from what other users have reported
• Ask support for a log analysis instead of assuming your case matches mine
• Check whether your sensor matches the symptoms Aqara describes below, and contact support if it does
• Don't open the case first. The unofficial routes in the appendix replace Aqara's firmware, and Aqara's official procedure is run by their support

Here is how Aqara described who qualifies, in their November 2 reply:

From Aqara

Symptom Characteristics: The device connects to the network normally, and light sensing works, but the radar detection suddenly stopped working, and the reported radar version number is 0000.

Preconditions: The device has not been subjected to any manual intervention during this period, such as being in the middle of an upgrade, experiencing frequent power cycles (plugging/unplugging), no water entered the device, or physical drops.

How to proceed: Users who meet these conditions can contact Aqara Support and provide their account and Device ID information. As long as our remote diagnosis confirms it is the exact same case, we can restore it directly via remote means.

And on warranty:

From Aqara

Even if the device is out of warranty, as long as it meets the criteria, we will assist with the troubleshooting and recovery.

In plain terms, Aqara is describing two things.

The symptoms

• The sensor is online and shows up in the app
• It still reports light levels
• It has stopped detecting people
• The firmware version ends in 0000

The conditions

The failure shouldn't trace back to something done to the device: an update interrupted partway through, a lot of plugging and unplugging, water getting in, or a drop.

One thing their wording doesn't settle is whether restarting a sensor after it has already failed counts against you. I restarted mine over and over while troubleshooting. Don't assume that rules you out. Tell support exactly what happened before and after it stopped working, and let their remote diagnosis decide.

That's a lot more useful than "my sensor broke."

A diagnosis you inherit from somebody else's forum post is a guess wearing a lab coat.

Almost all of this was one person, a support agent who asked not to be named. She picked up my case on day one and still had it two months later. I was never handed off, never had to explain everything to someone new, and never got asked to resend something I'd already sent.

This is the part I really didn't see coming. Aqara's support on this case was the best I've dealt with from any smart home company, and it wasn't close.

Here's what that actually looked like.

They answered fast, and kept answering. Over two months and about four dozen messages, I usually heard back within about a day, often within a few hours. The longest stretch without a case update ran from late September to October 21. China's National Day holiday, which they told me about ahead of time, covered the first week of it. I checked in once, after the holiday, to make sure the case hadn't gotten lost, and heard back about a day later.

They escalated instead of brushing me off. The case went back to the developers six times: when I asked what the logs showed, when I pushed on the technical details, for the teardown, when I questioned the teardown conclusion, and twice more for my final rounds of questions. More than once the new analysis changed the one before it, and they sent it to me anyway.

They acknowledged a mistake when I raised it. Their September analysis cited error 993021. I asked if that was a different code or a typo, since the app always showed 993012. They came back the next day and said it was a typo on their end. They could have waved it off or explained it away. They didn't.

They paid to investigate a sensor they'd already written off. International prepaid shipping from California to Hong Kong, for a 33-month-old sensor they had no obligation to look at, because they wanted to know what actually happened to it. Then they fixed it.

They respected my editorial judgment. I sent them drafts before publishing. They asked for factual corrections, some of them important, but never asked me to change my conclusions, and told me they trusted my judgment on how to tell the story. The one thing they asked was that I be clear about the error code so other owners wouldn't assume their case matched mine. That was reasonable, and it made the article better.

And she was always courteous. That sounds minor. It isn't. Two months of technical back and forth with someone patient, who writes clearly and actually engages with your troubleshooting, is a completely different experience than two months of templates and canned apologies.

One more thing I only found out partway through. I offered to write to her manager, since feedback that reaches someone's boss is worth more than a thank-you in their inbox. She told me it had already been raised internally. The support manager and the R&D team had held a meeting specifically about my case, the manager had been following it the whole time, and that meeting is where both the request to send the unit back and the replacement decision came from.

So this wasn't one unusually dedicated person quietly working around a slow system. The people behind her were paying attention too.

A note about the person who handled my case

That list makes her sound like a process. She wasn't.

I never once felt like I was talking to a ticket queue. At one point I sent her a ninety-second clip of the 3D floorplan these sensors drive, and told her no reply was needed. She replied anyway to say she'd passed it to the team, and that she hadn't forgotten the open issues on my end.

She gave me bad news straight, too, including the original denial and a heads-up that the replacement units might take several weeks.

And when I pushed back on a conclusion her own development team had just sent, she took it back to them instead of just repeating it. That's the rarest thing on this list. Most people defend the answer they already gave.

If anyone at Aqara reads this: she's the reason this isn't the article I expected to write.

I'm saying all of this in the same article where I say the full answer took several rounds of questions and two months to arrive. Both things are true. Good support and a slow-arriving answer can exist at the same time, and a review that only reports one of them isn't a review.

Warranty and goodwill aren't the same thing

A warranty is a contract. It says who pays if something fails before a certain date. Mine was twelve months, my sensor was 33 months old, and saying no wasn't unreasonable. A support team can't treat every out-of-warranty failure as proof the product was defective.

Goodwill is different. It's optional, nobody owes it to you, and no amount of documentation forces a company to offer it.

Aqara ended up approving two replacement FP2s. The agent handling my case started the request in early September, and Aqara later told me a meeting between her manager and the R&D team decided both the return and the replacement.

This also wasn't the first time. An Aqara air quality monitor of mine died earlier this year, also out of warranty, also denied at first, and also replaced in the end as a courtesy. That time, I provided a prepaid label so Aqara could ship the replacement to me. This time they paid for all the shipping themselves.

What I wouldn't take from this is that you're entitled to the same thing. Which leads to the next point.

Documentation buys escalation, not entitlement

If there's one practical thing to take from this, it's this: documenting everything doesn't force a company to do anything. What it does is give them something concrete to look at instead of a description.

Every time my case moved forward, it was right after I handed over something specific. The side-by-side with the working sensor got them to reread the logs. The API reproduction got it to the development team. Asking two separate questions, what failed and what you're willing to do about it, got me a real technical answer that the warranty decision would otherwise have buried. And asking the bootloader question a second time, in writing, is what finally got me the answer that it had been fixed.

You don't need a developer account or an API client for this, and most people shouldn't bother. The goal is just to turn "it stopped working" into something another person can actually evaluate:

• Reproduce it, and write down what changes the behavior and what doesn't
• Write down firmware versions, error codes, and times
• If you have a second identical device, compare them and write down both results
• Ask what failed and what the company will do about it as two separate questions, and don't let an answer to one count as an answer to the other
• If an answer leaves something out, ask again, specifically

Separating those two questions did more for me than all the API testing combined.

I'm not going to tell anyone to buy their sensors in pairs just in case. But if you already have two of something, the working one turns into a diagnostic tool the minute the other one starts acting up.

The official fix runs through Aqara

When this sensor died, there was no recovery route I could use myself. No firmware file to download, no documented reflash process, no bootloader route published for owners.

As of October 30, the official fix exists, but it runs only through Aqara's backend support, for the security reason they gave in their own words above. That's a reasonable explanation, but I have no way to test whether a public tool would actually be unsafe.

So the question this article set out to answer, whether my sensor could be fixed, has a better answer than I expected: yes. Aqara has also answered the access question. Owners whose sensor matches this failure can ask support for the remote recovery, including out of warranty, as long as their remote diagnosis confirms it's the same case. That's a real commitment. It's still a recovery that runs through Aqara rather than the owner: you contact support, and their diagnosis has to confirm it's the same failure. That's why I've spelled out the symptoms above, so you can describe the problem clearly.

The community has documented unofficial ways to write firmware to the FP2 directly, and I've covered them in the appendix. They mean opening the case and soldering, they mostly replace Aqara's firmware with community firmware rather than restore it, and I haven't found evidence they could bring back a unit that failed the way mine did.

That's not unique to Aqara, and I don't think it's a scandal. Some smart home devices let you download the firmware yourself, or even build it from scratch, and when those fail you have more moves available. They aren't automatically better products, and plenty of them are worse. They just fail differently.

Both of these things are true: a repaired sensor and two free replacements, and an official recovery that runs through Aqara rather than the owner. A review that only reported the first would leave out the part that matters to the next person whose FP2 gets stuck.

Aqara answered my last questions on November 2. The one thing still unexplained is what caused that first brief offline event, and Aqara hasn't claimed to know. If they ever say more, I'll add it here.