The Sonoff SNZB-04P is the newer revision of Sonoff’s Zigbee door and window contact sensor, and the thing that separates it from the plain SNZB-04 is a tamper-detection input the older model doesn’t have. It pairs directly into Zigbee2MQTT or ZHA as a standard Zigbee end device, no Sonoff bridge and no eWeLink account required for local operation.
Two things to settle before you buy or start pairing. Sonoff has since shipped an SNZB-04PR2, a physically different sensor that takes different batteries, so check which one you actually have. And the tamper switch, the entire reason to pick the “P” over the base model, currently misbehaves on both major local integrations in different ways. This is a research-synthesis guide built from vendor and Zigbee2MQTT documentation and named issue reports. No physical unit was paired for it, and the verification section at the end says exactly what that does and doesn’t cover.
What the “P” adds over the plain SNZB-04
| Expose | SNZB-04 | SNZB-04P |
|---|---|---|
contact |
Yes | Yes |
battery |
Yes | Yes |
battery_low |
Yes | Yes |
voltage |
Yes | Yes |
tamper |
No | Yes |
Per Zigbee2MQTT’s device pages for the SNZB-04P and the base SNZB-04, the tamper input is the entire delta. It’s an extra binary signal you can use to trigger an alert if someone pries the sensor off its mounting rather than opening the door normally.
Pairing into Zigbee2MQTT or ZHA, no eWeLink account needed
The SNZB-04P joins a Zigbee2MQTT or ZHA network the same way any standard Zigbee end device does. Put your coordinator into pairing mode, then trigger pairing on the sensor itself (check the unit for the button or reset-pinhole sequence). Nothing in that process touches eWeLink or a Sonoff cloud account. Once the interview completes, Zigbee2MQTT assigns it a friendly name and starts publishing state under that name. The device is Zigbee 3.0 and its Zigbee2MQTT page lists OTA support, so firmware updates also stay on your own network rather than routing through a vendor app.
What it publishes over MQTT
Zigbee2MQTT’s converter for the SNZB-04P exposes contact, battery, battery_low, tamper, and voltage under the device’s state topic, alongside the standard linkquality every Zigbee2MQTT device reports. A payload for a device named front_door_sensor looks structurally like this (values below are illustrative, not a captured reading):
{
"contact": true,
"battery": 100,
"battery_low": false,
"tamper": false,
"voltage": 3000,
"linkquality": 132
}
One detail is worth being precise about. contact: true means the circuit is closed, which is the door or window shut, and contact: false means open. Home Assistant’s door and window binary sensors use the opposite convention, where on means open, so Zigbee2MQTT’s discovery config inverts the value on the way through. It’s a common inversion to get backwards when writing automations, so check which layer you’re reading from before wiring up a trigger. Our guide to Zigbee2MQTT’s MQTT topics and attribute output covers how these topics and payloads are structured generally.
All five of these are read-only. Nothing on this device accepts a /set, which matters more than it sounds for tamper specifically, as the next section covers.
Battery: CR2477 on the SNZB-04P, AAA on the R2
Sonoff’s own product page states the SNZB-04P runs on a CR2477 coin cell, rated for roughly five years of typical use. That’s the figure this guide treats as primary, since it comes from the vendor’s own spec sheet rather than a secondhand source.
If you open your sensor and find something that isn’t a CR2477, the likeliest explanation isn’t a mislabelled coin cell. It’s that you have the SNZB-04PR2, which Sonoff markets as the SenseGuard DW Gen2. Sonoff’s own side-by-side puts the R2 on two AAA cells rated for about three years rather than a CR2477 rated for five, in a longer and slimmer body (90 x 26 x 13.5mm against the SNZB-04P’s 50.5 x 32 x 21.9mm), with horizontal, vertical, and magnet-only mounting options the older shape doesn’t offer. It’s a separate device in Zigbee2MQTT too, with its own device page rather than sharing the SNZB-04P’s.
Fewer years on paper, but AAA cells are the format you can buy at any corner shop, which is a real convenience if you’re running several sensors. Separately, and unresolved: a third-party manual listing describes what it calls the “SNZB-04P” as using a CR1632 with a roughly two-year rating. That matches neither the SNZB-04P’s CR2477 nor the R2’s AAA cells, and this guide doesn’t explain it. Trust the cell marking in your own unit over any listing.
The tamper entity: broken on ZHA, awkward on Zigbee2MQTT
The tamper switch is the only thing the “P” adds over the base SNZB-04, and it has a documented problem on both local integrations. On ZHA it frequently doesn’t produce a working entity at all. On Zigbee2MQTT the entity works but is read-only, so a tamper that trips during mounting can’t be cleared from Zigbee2MQTT. Budget for this before buying the “P” specifically for tamper alerts.
The two problems are different sizes, and it’s worth separating them.
On ZHA, users report the tamper switch producing a second, duplicate or non-functional binary-sensor entity instead of a working tamper entity. This one is genuinely ZHA-specific. The report comes from a Home Assistant Community thread titled “Sonoff SNZB-04P strangeness”, open and not marked solved as of this writing. The mechanism is that the SNZB-04P reports tamper on a Sonoff manufacturer-specific cluster, 0xFC11, attribute 0x2000, rather than through a standard ZCL cluster. Without a quirk telling it how to read that, ZHA has nothing to map to a proper entity. A manual, community-authored quirk exists as an interim workaround, and a native fix is tracked as zigpy/zha-device-handlers PR #3665, alongside an older device support request, issue #3308. That PR appears not to have merged as far as could be confirmed here, so check the zigpy project’s current state rather than treating this as permanent. Notably, the newer R2 has its own separate tamper quirk PR (#5131), so the two revisions are on independent support tracks.
On Zigbee2MQTT, the picture is better but not clean. The converter does read that manufacturer cluster, so tamper shows up as a working, reporting entity, which is the meaningful advantage over ZHA today. What it won’t do is let you reset it. Zigbee2MQTT’s device page documents tamper as read-only, and issue #25069, “Sonoff SNZB-04P: Can’t reset tamper”, is a user stuck in the tampered state with the error Cluster with name '64529' does not exist. That number is worth recognising, because it’s the same cluster in a different base: 64529 in decimal is 0xFC11 in hex. The issue was opened in December 2024 and closed as not planned.
I think that’s a fair knock against the pace of platform support rather than against the hardware. Sonoff shipped a genuinely useful revision, but a tamper switch that lands on a proprietary cluster without matching day-one coverage on either major local integration is exactly the kind of rough edge that makes people distrust a “new revision” until it’s had time to settle.
How it compares to Aqara’s door/window sensors
If you’re deciding between ecosystems rather than committing to Sonoff, our breakdown of Aqara’s door/window sensor generations covers the same category from the other major brand this site tracks. Tamper isn’t the Sonoff advantage it might look like from the spec sheet: Aqara’s P1 (MCCGQ13LM) has tamper detection too, and adds a configurable detection_distance of 10, 20, or 30mm that the SNZB-04P has no equivalent for, since its installation gap is a fixed sub-20mm. If you’re fighting false opens on a door that doesn’t sit flush, that adjustable distance is the more useful feature of the two, and it’s an Aqara-side one.
For a sense of Sonoff’s broader Zigbee lineup, this site’s SNZB-01 wireless button guide and our Sonoff TRVZB radiator valve guide both follow the same no-bridge, no-eWeLink pairing pattern described above. And if the no-cloud angle matters to you beyond this one device, what eWeLink actually collects is worth a read separately, since it applies to Sonoff’s app-based products generally rather than this Zigbee sensor.
FAQ
What’s the difference between the Sonoff SNZB-04 and SNZB-04P? The SNZB-04P adds a tamper expose that the base SNZB-04 doesn’t have. Contact, battery, battery_low, and voltage reporting are identical between the two per Zigbee2MQTT’s device pages.
What is the SNZB-04PR2, and is it the same thing? No, it’s a separate, newer sensor Sonoff markets as the SenseGuard DW Gen2. It runs on two AAA cells rated around three years instead of the SNZB-04P’s CR2477 rated around five, uses a longer and slimmer body, adds horizontal, vertical and magnet-only mounting, and has its own Zigbee2MQTT device page and its own ZHA quirk work.
Does the SNZB-04P work with Zigbee2MQTT without the eWeLink app? Yes. It pairs as a standard Zigbee device directly to your Zigbee2MQTT coordinator. No eWeLink account or Sonoff bridge is involved in local operation.
What battery does the Sonoff SNZB-04P use? Sonoff’s own product page states a CR2477 coin cell, rated for roughly five years. If your unit takes AAA cells instead, it’s an SNZB-04PR2, not an SNZB-04P. A third-party listing separately describes a CR1632 with a two-year rating for what it calls the same model, which matches neither device and isn’t resolved here.
Why isn’t the tamper sensor working on my SNZB-04P in Home Assistant? If you’re on ZHA, missing native quirk support for the device’s manufacturer-specific cluster (0xFC11) can produce a duplicate or non-functional entity. A community quirk workaround exists and PR #3665 tracks a native fix. If you’re on Zigbee2MQTT the entity should report normally, but it’s read-only, so a tamper you trip while mounting can’t be cleared from Zigbee2MQTT (issue #25069, closed as not planned).
Is the SNZB-04P better than Aqara’s door and window sensors? Both do the core contact-sensing job over Zigbee. Tamper isn’t a deciding factor, since Aqara’s P1 has it as well, and the P1 additionally offers an adjustable detection distance the SNZB-04P doesn’t. Our generation comparison covers the Aqara side in detail.
What this verified, what stays local, what to check yourself
The exposes for both the SNZB-04P and the base SNZB-04, the fact that tamper is new to the “P” revision, and that all of them are read-only come from Zigbee2MQTT’s official device pages. The CR2477 figure is Sonoff’s own stated spec, as are the SNZB-04PR2’s AAA cells and dimensions. The conflicting CR1632 claim is flagged, not resolved. The ZHA tamper gap is sourced to one named, open Home Assistant Community thread. The Zigbee2MQTT reset limitation is sourced to Zigbee2MQTT issue #25069, closed as not planned. Whether zigpy PR #3665 has since merged could not be confirmed, so treat the ZHA situation as a snapshot. No physical SNZB-04P was paired, tested, or run for this piece.
Everything described above, pairing, the exposed entities, OTA updates, and the MQTT payload structure, operates over your local Zigbee network through Zigbee2MQTT or ZHA. None of it depends on the eWeLink app or a Sonoff cloud account. Two things are worth checking yourself before you commit: which revision you’re actually holding, since the R2 is a different sensor with different batteries, and the current state of PR #3665 if you’re on ZHA and want tamper to work without hand-installing a quirk.