A Zigbee sensor in a metal mailbox (and a home zone 523 m off)
I measured about 18 dB of signal loss through the metal enclosure and outdoor distance, found the real problem was a mesh with zero routers, and my home zone turned out to be 523 m from the house.
I wanted to test an old SmartThings multipurpose sensor, CentraLite 3321-S, in a metal curb mailbox about 20 feet from the front door and still have it report via Zigbee. The sensor has a door contact and accelerometer, which ZHA exposes via a device quirk, so it should be enough to alert me to mail. My first attempt didn’t go well: I paired the sensor to ZHA and it worked fine on the bench two floors from the coordinator, but it went unavailable 6 minutes after I put it in the mailbox and stayed dark overnight. I suspected the box was eating the signal.
The internet consensus seemed to be “metal mailbox is a Faraday cage, give up, mount the sensor on the outside”. I didn’t want to accept that without a number, though.. surely the box was costing me some signal, not all of it? How much, and was something else interfering?
Before I started measuring the box, I looked at my mesh and got a first surprise: since commissioning, my ZHA network consisted of the SONOFF ZBDongle-E coordinator in the basement and one end device, with zero routers. I hadn’t noticed because everything worked, but of course a router-less mesh looks healthy until you try to add a device at the edge. My Sengled bulbs are end devices and never route, and my Hue bulbs only route on the Hue Bridge’s own network (invisible to ZHA).
I started by changing my setup: I added three Third Reality 3RSP02064Z plugs as my first routers, placing them in the living room (indoor), the office (indoor), and in the driveway (one with line of sight to the mailbox). Then I did a research pass and found 29 sources (mostly forum threads and zigbee2mqtt issues) that predicted: a steel box will cause 20-30 dB of signal loss; thin aluminium might be 10-15 dB; anything inside the box is a coin flip. Every long-running success story involved mounting the electronics outside the box, from this SmartThings accelerometer mailbox thread to this r/homeassistant question about a metal mailbox.
The first reading with the indoor plugs was a puzzle: -85 dBm inside the box, vs -83 dBm with no routers. Turns out end devices pick a parent once and never roam, so it was still using the indoor parent through the metal. I pulled the battery with the sensor in its final spot (lid open, because a rejoin scan from inside sealed metal backs off for minutes) and let it pick again. Tricky to catch because ZHA’s “via device” still showed the coordinator after it moved to the plug (it records that at join time), and the topology tables only refresh on scan.
One conclusion I drew mid-process was wrong and influenced subsequent readings. In a Claude Code session, I saw the LQI jump from 68 to 136 and assumed the plugs were working. The reading was accurate, but the conclusion was flawed.. I’d also brought the sensor indoors, so I’d changed two variables and only named one. From that point on, every measurement was taken with the sensor in its mounted position inside the box.
Once I had both of those nailed down, the readings looked like this:
| Sensor position and mesh | LQI | RSSI |
|---|---|---|
| Bench indoors | 136 | -67 dBm |
| In the box, no routers | 68 | -83 dBm |
| In the box, still on its indoor parent | 60 | -85 dBm |
| In the box, driveway plug only | 160 | -60 dBm |
I measured the cost of the metal enclosure and outdoor distance at about 18 dB, a bit less than the 20-30 dB for steel in the literature. I did a trial with the driveway plug as the only router, the sensor sealed in the closed box, and nine open/close cycles plus knock tests. The result was 18 of 18 transitions caught, zero drops. Very satisfying, and I cancelled the planned trials (each indoor plug alone, the spot under the porch). A side effect of isolating the driveway plug was that it unstuck the stalled firmware update, so now all three plugs are on the same version. I suspect the stalled Zigbee OTA and the unresolved route are the same fact.
What this means is that the metal was a cost, not a wall, and the blocker was the empty mesh. A mesh with no routers looks healthy until you put a device at the edge. I built on this a mailbox notification triggered by the door contact OR the accelerometer, with a 10-minute cooldown, attaching a front-door camera snapshot (the mailbox is at the left edge of the frame). I fire-tested it via the States API. It also fires when we check the mail ourselves, which is correct by design: nothing in this hardware can tell who opened the box, and the camera sees someone, not who. Ring motion is snapshot context only, never a trigger or condition.
The home zone 523 m from home
The same day I nailed down the second long guess: presence had been broken for months. I blamed the phone twice: the companion app seemed dead, then location permissions. Not the phone. My home zone was 523 m from where the phones rest at night, with a 100 m radius, so the house was 423 m outside its own zone and location reports lacked a zone. I measured the median of five consecutive overnight GPS fixes, 2.1-2.3 m accuracy, on the assumption that nobody is half a km from home at 3 am for twenty minutes. I validated that against a second phone in the house, registered independently the same day, which landed 0.5 m from the median. After fixing that, both people read home.
Two traps: reloading core config updated the API value but not the home zone itself (which is built at startup), and reloading zones only rebuilds those defined in YAML, so it needed a full restart.. (if I’d only checked the API, the reload would have looked like a success). Also, adding a person and registering their phone are separate steps, and Home Assistant didn’t link the new tracker to the person automatically. Once I had presence working, I could define a “someone home” sensor that’s on if any phone’s GPS or home Wi-Fi says so, and use it to pause hot-water recirculation when the house is empty, as I wrote up in Hot water at the tap with Home Assistant.
The box had more to show me
Eighteen of eighteen in a single trial means I got signal in one session, not multi-day reliability.. and the box still had more to show me. Over the next three days the sensor lost its parent three times counting the first night, offline 8 to 17 hours each time. When it was connected, signal was -64 to -70 dBm and LQI 112 to 144.. so signal strength wasn’t the issue. Two of the rejoins gave fake “mailbox opened” pages at 4-5 a.m.: contact on for 0.2 to 1 second, no accelerometer event. A real opening had the contact and accelerometer events about 110 ms apart, and a real delivery held the door open for 7 seconds. The trial went well, but for the purposes of resiliency and accuracy I opted to move the sensors to the exterior of the box.
I moved the sensor to the exterior back of the box, vibration only now. I removed the contact trigger from the notification and hid the contact entity (it stays open forever). I pulled the battery again in the new position, enclosure open, so the Zigbee parent was chosen from the real location. The 18 dB figure stands, and the research advice won on reliability. We’ll see if vibration alone pages on wind or a passing truck. The only test so far was a person shaking the box, 15 events over nine minutes. The silicone seal waits until the mount proves itself.
Edited on 2026-10-03 to link Hot water at the tap with Home Assistant.