Tuya TS0202 PIR Motion Sensor: Zigbee2MQTT Setup & Variants

TS0202 is Tuya’s ubiquitous PIR motion module, sold under enough different storefront names that most buyers don’t realize they own the same hardware as someone posting a completely differently-branded sensor. Before writing this I went through Zigbee2MQTT’s device pages for the model, the current HA Community threads on TS0202 pairing and sensitivity, and the GitHub “new device support” issues that show up whenever a fresh manufacturer code lands.

Here’s the short version. Pairing is routine. What you get afterwards is not fixed: Zigbee2MQTT maintains several separate converters under the TS0202 model string, and which one your sensor lands on — decided by a manufacturer code printed nowhere on the box — determines whether you get sensitivity and keep-time controls or five read-only values and nothing to configure. Knowing that before you buy, or before you spend an evening hunting for a setting your unit’s converter doesn’t define, is the useful part of this guide.

What the TS0202 actually is

TS0202 is Tuya’s model string for a battery-powered Zigbee PIR motion sensor, not a single product from a single company. Zigbee2MQTT’s main TS0202 device page lists the Mercator Ikuü SMA02P, Tuya TY-ZPR06, and Tesla Smart TS0202 as white-label names sold on the same underlying hardware. If your box doesn’t say “Tuya” or “TS0202” anywhere on it, that alone doesn’t rule out this being the same module.

It also isn’t one entry in Zigbee2MQTT. The project maintains several device pages under this model string — TS0202 plus suffixed siblings such as TS0202_1 and TS0202_3 — because different manufacturer codes shipping the same sticker need different converters. The same split exists elsewhere in the Tuya range: the TS0041 button has a separate TS0041A page for the same reason. Which page describes your sensor isn’t something the packaging will tell you.

Pairing into Zigbee2MQTT

Pairing follows the standard join process for a battery-powered Zigbee device. Put Zigbee2MQTT into pairing mode, then trigger the sensor’s own join gesture, usually a button under the cover. Consult the instructions that shipped with your specific unit for the exact sequence, since Tuya doesn’t standardize this across white-label variants.

When Zigbee2MQTT recognizes the device, the interview sets up the reporting it needs on its own — there’s no manual binding step to perform for occupancy or battery. Once the interview finishes, the sensor appears under whatever friendly name you assign it, and the expose list you get is fixed at that moment by the manufacturer code it reported.

mosquitto_sub -h 192.168.10.20 -t 'zigbee2mqtt/#' -v

// then walk in front of the sensor — occupancy true should
// appear within about a second on zigbee2mqtt/<friendly_name>

If you’re new to how Zigbee2MQTT publishes device state, our guide to its MQTT topics and attribute output covers what these payloads are and where they come from.

What you actually get: the exposes table

Paired against Zigbee2MQTT’s base TS0202 converter, the sensor exposes five values plus linkquality, and every one of them is read-only. There’s no /set topic on that converter and nothing to configure from MQTT or Home Assistant.

That’s the entire interaction surface on the base converter — and it’s the list a lot of TS0202 owners end up with. Compare it to the TS0041 and TS0043 scene switches covered on this site and the pattern is familiar: cheap Tuya Zigbee devices tend to report state rather than accept configuration. The TS0202 is the interesting exception, because on this model it isn’t consistently true.

Sensitivity and keep-time: it depends on your variant

Search TS0202 listings and you’ll find product copy describing adjustable sensitivity and a configurable keep-time before the occupancy state clears. Whether you actually get those controls in Zigbee2MQTT depends on which converter your unit matched, and the answer is genuinely split.

Some TS0202 definitions do expose both as writable settings, with these values:

On those units the published MQTT state carries sensitivity and keep_time alongside occupancy, battery and tamper, and both are settable rather than read-only.

The base TS0202 device page carries neither, and a long line of GitHub reports comes from owners who expected them and found their unit on a converter without them. Issue #19839 covers _TZ3000_6ygjfyll specifically, and there are further reports for codes including _TZ3000_otvn3lne, where the settings are adjustable in Tuya’s own app but simply absent in Zigbee2MQTT. An HA Community thread on adjusting TS0202 sensitivity in ZHA reaches the same conclusion for that class of unit, with a reply confirming the limitation carries across to Zigbee2MQTT (“same for Z2M”) rather than being a ZHA-specific quirk.

So the honest answer to “can I adjust the sensitivity on my TS0202” is: read your own device’s page in Zigbee2MQTT before you go looking for the setting. If sensitivity and keep_time aren’t in the expose list there, no amount of MQTT will produce them, and the missing-exposes issue reports are the place to check whether anyone has already asked for your code.

The manufacturer-code variant problem

TS0202 ships under a long list of underlying manufacturer codes, among them _TZ3000_lf56vpxj, _TZ3000_mcxw5ehu, _TZ3040_bb6xaihh and _TZ3000_o4mkahkc. The model sticker says TS0202 on all of them. The code Zigbee2MQTT reads during the interview is what decides which converter, and therefore which expose list, you end up with.

The issue tracker shows the pattern directly. Issue #19105 asked Zigbee2MQTT to add support for _TZ3000_lf56vpxj; issue #9757 did the same for _TZ3000_mcxw5ehu — which is now one of the codes whose definition carries the sensitivity and keep-time settings. That arc is the normal one: a new code arrives unrecognised, someone files a support request, and it eventually lands on a converter, sometimes a richer one than the base definition. What you can’t assume is that a code you bought this month has already been through it.

If your unit joins but Zigbee2MQTT logs it as unsupported rather than exposing the entities above, that’s a converter-matching problem rather than faulty hardware. Our guide to the no converter available error covers the diagnosis, and writing your own external converter is the route if nobody has done it for your code yet. For readers who want more than stock firmware offers, Suxsem’s TS0202-PIR-Sensor-Zigbee-firmware project on GitHub is a third-party custom firmware for specific TS0202 hardware revisions, flashed over a Telink serial connection. It’s a niche path, not something most readers need, but worth knowing it exists.

Placement still does most of the work

Even on a variant that exposes sensitivity, the physical lever is the bigger one. Where you mount the sensor, and what its field of view actually covers, decides most of what a slider would otherwise be correcting for. A PIR module triggering too often is usually picking up a doorway, a vent, or a sunlit surface inside its cone, and moving it a few degrees or a few feet addresses the cause rather than desensitising the whole field. On a unit with no sensitivity expose it’s the only lever you have; on a unit that has one, it’s still the one to try first. My own view is that the missing control matters less than the listings imply — a repositioned sensor stays put, where a sensitivity setting is one more thing to re-tune every time false triggers creep back in.

Frequently asked questions

Why can’t I adjust the sensitivity on my Tuya TS0202 motion sensor? Most likely because your unit interviewed onto a Zigbee2MQTT converter that doesn’t define those controls. Some TS0202 definitions expose sensitivity and keep_time as writable settings; the base TS0202 converter exposes neither, and owners of codes such as _TZ3000_6ygjfyll and _TZ3000_otvn3lne have reported the same gap even where Tuya’s own app shows the setting. Check your device’s page in the Zigbee2MQTT frontend — if it isn’t in the expose list there, it isn’t reachable over MQTT.

Is TS0202 the same as other Tuya model strings like TS0201? No. TS0201 is Tuya’s model string for a temperature and humidity sensor, not a PIR. The TS0xxx codes identify a device class and its Zigbee profile, not a brand or a product line — which is why two sensors from unrelated sellers can both be TS0202, while TS0201 and TS0202 are different devices entirely.

What battery does the Tuya TS0202 use? There’s no single answer, and that’s the white-label problem rather than a documentation gap: the shells differ between sellers, and Zigbee2MQTT reports percentage and raw voltage without ever knowing the cell type. Open the case and read the cell before ordering spares. Expect the percentage to take up to 24 hours to populate after pairing, which is normal on Tuya battery devices and not a sign of a failed join.

Does TS0202 need a hub, or does it pair directly to Zigbee2MQTT or ZHA? It pairs directly to your Zigbee coordinator. It doesn’t need the Tuya Smart Life app, a Tuya IoT Platform account, or any hub in between for Zigbee2MQTT or ZHA to see it.

Why does Zigbee2MQTT show a different manufacturer name than the box says? Because TS0202 covers multiple underlying manufacturer codes and is resold under several white-label brand names on the same hardware. The manufacturer string Zigbee2MQTT reports comes from the device’s own Zigbee descriptor, not from the retail packaging.

What’s verified, what stays local, what to check yourself

The read-only expose list above, and the three white-label names, come from Zigbee2MQTT’s base TS0202 device reference page. The existence of variant converters carrying writable sensitivity and keep_time settings, and their value ranges, is sourced from Zigbee2MQTT’s own device documentation for the affected manufacturer codes and from the issue reports filed by owners who didn’t get them — not from a unit on a bench here. The manufacturer-code pattern and the two device-support requests come from Zigbee2MQTT’s GitHub tracker; I haven’t confirmed their current state or last activity, so treat the issue numbers as pointers to read rather than as a status report.

Everything described here runs over your local Zigbee network through Zigbee2MQTT. No Tuya cloud account, Smart Life app, or Tuya IoT Platform login is involved in pairing, occupancy reporting, or the automations you build on top of it — including on the variants that do expose settings, which are written over MQTT like any other Zigbee attribute.

Two things you can only settle on your own hardware: which converter your unit matched, which the device page in your Zigbee2MQTT frontend will tell you within a minute of pairing, and whether the cell in your particular shell is the one the seller listed. If sensitivity control is the reason you’re buying, buy somewhere that will accept a return.