The TS0041 is the smallest member of Tuya’s battery-powered Zigbee scene switch family: one button, three press types, nothing to control on the device itself. If you’ve bought one under a Smart9, Lonsonho, or Benexmart label and want it in Home Assistant without ever opening the Smart Life app, the setup is short and stays entirely on your local Zigbee network. Two things are worth knowing before you start, because both look like a failed pairing and neither is: the battery entity is unreliable on this model in two separate documented ways, and Home Assistant won’t offer you a button-press trigger until you’ve physically pressed the button first.
What the TS0041 actually is
TS0041 is Tuya’s model string for a single-button, battery-powered Zigbee wireless switch. Like the rest of this button family, it’s resold under a long list of storefront names rather than “Tuya” on the box. Zigbee2MQTT’s device page names Smart9 S9TSZGB, Lonsonho TS0041, and Benexmart ZM-sui1 as known white-label variants, so if none of those match your packaging, don’t assume Zigbee2MQTT won’t recognize the device. The pairing interview identifies it by the model string, not the storefront brand.
One exception: Zigbee2MQTT maintains a separate page for a TS0041A model string, so if your switch interviews as that, read its expose list instead of this one.
It’s natively supported in Zigbee2MQTT: no external converter, no custom quirk file. That puts it in the same category as its siblings, the two-button TS0042 and three-button TS0043, rather than the TS0601-family devices on this site that need a converter to work at all.
Being a Zigbee device, it also sidesteps the Tuya-cloud local-key requirement that trips people up on Tuya’s Wi-Fi plugs: pairing goes through your coordinator directly. Our guide to why Tuya Zigbee devices don’t need a local key covers that split in more detail — and if you actually own a Wi-Fi Tuya switch, LocalTuya vs Tuya-Local is the comparison you want instead.
Pairing into Zigbee2MQTT
Pairing follows the standard Zigbee join process for a battery device: put Zigbee2MQTT into pairing mode, then trigger the switch’s own pairing gesture. Check the instructions that shipped with your unit for the exact button sequence — Tuya doesn’t standardize it across white-label variants and it isn’t in Zigbee2MQTT’s device reference. Once the interview completes, the switch shows up under whatever friendly name you assign.
The frontend is the normal place to confirm a join. To watch the broker directly instead, subscribe and press the button once — that checks the join and the events together.
// noisy on a large network; narrow to zigbee2mqtt/<friendly name> once you know it mosquitto_sub -h 192.168.10.20 -t 'zigbee2mqtt/#' -v
What it exposes: battery and action, nothing to control
Once paired, Zigbee2MQTT exposes battery (0–100%, remaining capacity), action (which press type just happened), and the standard linkquality metric. Neither battery nor action supports a /get or a /set: you can’t query them on demand and there’s nothing to command. It’s a pure event source, not a controllable entity.
zigbee2mqtt/Entry switch
{
"battery": 91,
"action": "single"
}
The button supports three press types: single, double, and hold. That’s the entire interaction surface. Anything more elaborate has to be built in Home Assistant on top of those three raw events.
One detail to carry into your automations: with only one button, the values are bare — single, not the endpoint-prefixed 1_single the TS0042 and TS0043 use. An automation or blueprint copied from a sibling guide won’t match until you strip the prefix.
Battery: which cell, the 24-hour delay, and units that never report
The TS0041 uses a CR2032 coin cell as its standard battery. Getting a percentage out of it is the less predictable part, and it fails in two different ways that both look like a broken pairing. The first is documented and harmless.
Battery percentage can take up to 24 hours after pairing to populate with a real reading, per Zigbee2MQTT’s own device documentation. Give it a day before treating an empty battery value as a fault.
The second is variant-dependent and doesn’t resolve with time. Zigbee2MQTT issue threads #8500 (“Missing Battery information for TS0041”) and #6180 (“Tuya TS0041 — no battery percentage and voltage”) track units that never report a percentage at all. The behaviour follows the _TZ3000_-style manufacturer ID hiding behind the shared TS0041 model string rather than the model itself: some variants send a battery value with every button press, others report null indefinitely. The same split is documented across the family in our TS0042 guide.
If the battery entity is still empty or null well past the first day, the likeliest explanation is your unit’s manufacturer variant, not a pairing fault — and it isn’t something Zigbee2MQTT can patch centrally. Check the cell’s actual voltage with a meter before replacing it on the strength of a reported percentage, in either direction.
There’s one more battery note worth a caveat rather than a recommendation. A personal troubleshooting post describing a ZHA-specific case reported a CR2032 that wouldn’t pair while a CR2025 worked immediately in the same unit. That’s a single data point, not corroborated on the Zigbee2MQTT side or reflected in any spec, so treat “try a CR2025” as a cheap thing to attempt if a brand-new unit refuses to join on a fresh CR2032 — not as a general requirement.
Automating single, double, and hold presses
There’s no built-in device card that turns a TS0041 press into an action. What exists is a Home Assistant device trigger of type action, fired whenever the switch reports one of its three press types. A standard device-based automation works directly, without needing a blueprint:
automation:
- alias: "Entry switch - single press"
trigger:
- platform: device
domain: mqtt
device_id: REPLACE_WITH_YOUR_DEVICE_ID
type: action
subtype: single
action:
- service: light.toggle
target:
entity_id: light.entryway
Zigbee2MQTT only discovers a device trigger in Home Assistant after that exact action has fired at least once, so a freshly paired switch looks like it supports nothing. Press it single, double, and hold once each before you go looking in the automation editor — otherwise only the subtypes you’ve already triggered will be selectable. Tracked in Zigbee2MQTT issue #29667. Once discovered, device triggers work against either exposure mechanism below without you needing to know which one is active — which is why Zigbee2MQTT’s own Home Assistant documentation recommends them for now.
Two Home Assistant Community blueprint threads cover this device, built on different mechanisms. The older one uses the classic action state approach — a text sensor whose value changes on each press, which automations trigger on or template against. The newer one requires enabling experimental_event_entities: true in your Zigbee2MQTT configuration, which switches presses over to Home Assistant’s native event entities instead. That option is still flagged experimental in Zigbee2MQTT 2.x, and the two aren’t interchangeable: a blueprint written against event entities won’t fire correctly on an instance still using the classic action-state model, and vice versa. Check which mechanism a blueprint assumes before importing it.
If no action entity appears at all, that’s a family-wide problem rather than a TS0041 fault — the TS0042 guide covers diagnosing it from the Zigbee2MQTT side.
Where it fits against the TS0042 and TS0043
| TS0041 | TS0042 | TS0043 | |
|---|---|---|---|
| Buttons | 1 | 2 | 3 |
| Distinct action values | 3 (single/double/hold) | 6 (1_single…2_hold) | 9 (1_single…3_hold) |
| Zigbee2MQTT support | Native, no converter | Native, no converter | Native, no converter |
| Best for | One toggle, one scene, or a single doorbell-style action | A simple two-state switch (e.g. movie mode / normal) | Multi-scene rooms needing more than two states |
Honestly, for a lot of the single-purpose triggers people reach for these switches for — a doorbell chime, one scene toggle by an entryway — the TS0041 is the right amount of device. Buying the TS0042 or TS0043 “for future flexibility” often just means two or three buttons you never map to anything.
FAQ
What battery does the Tuya TS0041 use? CR2032 is the standard cell. One reported case found a CR2025 fixed a pairing failure a CR2032 hadn’t. Worth trying if a new unit won’t pair, but not a documented general requirement.
Does the Tuya TS0041 work with Zigbee2MQTT without the Smart Life app? Yes. It’s natively supported with no external converter, and pairing goes through your Zigbee2MQTT coordinator with no Tuya account or Smart Life app step involved.
Why is my TS0041 battery percentage not showing after pairing? Battery reporting on this device can take up to 24 hours to populate after the initial pair, which covers most cases. If it’s still empty after that, some manufacturer variants of the TS0041 are reported never to send a percentage at all — check the cell’s voltage with a meter rather than trusting the entity.
What single-press, double-press, and long-press actions does the TS0041 expose? Three action values off the one button: single, double, and hold — no endpoint prefix, unlike the multi-button siblings. That’s the full interaction surface. Nothing on the device is controllable, only these events.
My TS0041 won’t pair — what should I try? Confirm Zigbee2MQTT is in pairing mode and retry the switch’s join gesture. If a fresh CR2032 still won’t complete pairing, the CR2025 substitution above is a cheap single-source workaround to test.
What’s verified, what stays local, what to check yourself
The model identity, white-label names, native Zigbee2MQTT support, the battery/action/linkquality expose list, the absence of /get and /set, the three unprefixed action values, and the up-to-24-hour battery delay all come from Zigbee2MQTT’s TS0041 device reference page. The variant-dependent case where a unit never reports battery is from issues #8500 and #6180, and matches what’s documented for the TS0042. The device-trigger discovery behaviour is from Zigbee2MQTT’s Home Assistant integration docs and issue #29667; the blueprint fork and event entities’ still-experimental status are from the community thread and the configuration docs. The CR2032/CR2025 anecdote comes from a single personal troubleshooting post about a ZHA-specific case, is not corroborated anywhere else, and is presented as a workaround to try rather than a hardware requirement. No TS0041 has been paired or bench-tested for this article, and everything above runs over your local Zigbee network — no cloud account or app is involved in pairing, reading presses, or automating them.
What isn’t settled: whether the CR2025 substitution generalizes beyond the one reported unit, which manufacturer IDs report battery reliably and which don’t (the issue threads don’t produce a clean list), and how long the classic action-sensor mechanism stays supported as event entities mature. Check the blueprint thread’s comments against your own Zigbee2MQTT version before importing either blueprint.