If you bought a cheap two-button Zigbee remote to trigger a couple of scenes and the box doesn’t say “Tuya” anywhere on it, that’s normal. The TS0042 is a battery-powered, two-button wireless scene switch that ships under a long list of storefront brand names, and the model string that actually identifies it only shows up once Zigbee2MQTT or ZHA interviews the device during pairing.
The good news is that identification is also where the hard part ends. TS0042 is natively supported in both Zigbee2MQTT and ZHA’s device-handler library, no external converter or custom quirk required, and it reaches Home Assistant without a Tuya account anywhere in the path. The setup itself is short. The parts worth spending time on are the two documented quirks that show up across GitHub issue trackers, because they’ll look like a broken pairing or a dead battery if you hit them without warning first.
What the TS0042 actually is
TS0042 is Tuya’s model string for a two-gang, battery-powered wireless scene switch. It’s rebranded and resold under names including Moes, Lonsonho, and plain generic “Tuya” listings, and a long list of distinct _TZ3000_ manufacturer IDs get reported against the same TS0042 model string in Zigbee2MQTT’s device database.
That manufacturer-ID sprawl is a real source of troubleshooting confusion. The reports in issue #6331, which tracks one of the quirks below, span several different _TZ3000_xxxxxxxx IDs against the same TS0042 model string — and the behavior being reported doesn’t turn up uniformly across them. If a forum thread references a manufacturer ID and yours doesn’t match, that’s not necessarily a different device. It’s the same model, possibly a different firmware batch.
It’s an end device, not a router. Like its sibling TS0043, it won’t extend your Zigbee mesh, and it shouldn’t be relied on to relay traffic for anything else on the network.
Because it’s a Zigbee device rather than a Wi-Fi one, the TS0042 also sidesteps the Tuya-cloud local-key requirement that trips people up on Tuya’s Wi-Fi plugs and switches. Pairing goes straight through your Zigbee2MQTT or ZHA coordinator, no Tuya IoT Platform account involved.
The TS0042 pairs natively in both Zigbee2MQTT and ZHA’s zha-device-handlers. No external converter or custom quirk file is needed for either stack, regardless of which `_TZ3000_` manufacturer ID your unit reports.
Pairing and what it exposes
Pairing follows the standard Zigbee join process for a battery device: put the coordinator into pairing mode, hold the button combination the box or included instructions specify (usually a long press on one button), and wait for the interview to complete.
Once paired, Zigbee2MQTT exposes three things: action (which button was pressed and how), battery (a percentage), and linkquality. Both buttons support three press types — a short press, a double press, and a hold.
That gives six possible action values, one per button-and-press-type combination: 1_single, 1_double, 1_hold, 2_single, 2_double, 2_hold. That’s the entire interaction surface — anything more elaborate, like multi-tap sequences or both buttons at once, has to be built in Home Assistant on top of those six raw events. The value is also report-only: it appears in the published state when a press happens, with no /get or /set, so nothing about this device can be queried or commanded on demand.
zigbee2mqtt/Living room switch
{
"battery": 87,
"linkquality": 60,
"action": "1_double"
}
Building automations from button presses
There’s no built-in TS0042 device card that turns button presses into scenes on its own. What exists instead is at least three separate Home Assistant Community blueprint threads, split between the Zigbee2MQTT and ZHA integration paths, each wrapping the same underlying mechanism into a reusable automation.
That mechanism is a Home Assistant device trigger of type action, fired whenever the switch reports a press. You don’t need a blueprint to use it. A standard device-based automation trigger works directly:
automation:
- alias: "Living room switch - button 1 short press"
trigger:
- platform: device
domain: mqtt
device_id: REPLACE_WITH_YOUR_DEVICE_ID
type: action
subtype: 1_single
action:
- service: scene.turn_on
target:
entity_id: scene.movie_night
The Home Assistant UI’s device-trigger picker lists the actual subtype values your paired device has reported, which is the quickest way to confirm the naming on your specific unit. Building it this way rather than templating on an entity’s state also turns out to be the more durable choice, for reasons the next section gets into. And if you’re mapping button presses to Home Assistant scenes rather than Zigbee2MQTT-native scenes, note that the two don’t behave identically.
The battery-reporting quirk
Battery percentage doesn’t behave consistently across TS0042 units, and it’s not a single bug with a single fix. Multiple long-running GitHub issues (including #6331, #21611, and #8500) track this as a variant-dependent hardware or firmware behavior rather than something Zigbee2MQTT can patch centrally. Some manufacturer-ID variants report a battery value on every button press. Others report null and effectively never update.
If your TS0042’s battery reading is stuck or shows null, don’t assume Zigbee2MQTT is broken or that the battery is dead. Multiple GitHub issues describe this as inconsistent across manufacturer-ID variants of the same model, unresolved as of the most recent activity on those threads. Check the device’s actual voltage before replacing a battery on the strength of the reported percentage alone.
The standard cell is CR2032. One community thread on a related Tuya switch project also lists CR2034 and CR2035 as physically fitting, while flagging that listings and compartments don’t always agree — so treat the spec printed inside your specific unit’s battery compartment as authoritative, not a generic spec sheet or a marketplace listing.
When there’s no action entity in Home Assistant
The second-most-reported TS0042 problem, after battery reporting, is that button presses appear to go nowhere: the device pairs, it shows up in Home Assistant, and there’s no action entity on it to build an automation from.
The obvious diagnosis — dead switch, failed pairing, weak mesh link — is usually the wrong one. In issue #23089, the reporter’s own MQTT payloads show 1_single and 2_single arriving normally: Zigbee2MQTT was receiving every press, and the gap was on the Home Assistant side, where no entity was being exposed for those events. That issue is closed as not planned. The same pattern shows up in issue #25948 and in the Home Assistant add-on repository’s threads covering TS0042, TS0043 and TS0044, along with community posts about action entities disappearing after an update — so it isn’t specific to one manufacturer ID or even to this model.
Check the Zigbee2MQTT side first. Open the device in the Z2M frontend and press a button: if an action value appears in its state, the switch, the battery and the mesh are all fine, and the problem is purely how the presses are surfaced in Home Assistant. Re-pairing a device that is already reporting correctly won’t fix that.
The fix that recurs in those threads is to enable event entities in Zigbee2MQTT’s Home Assistant integration settings, after which presses arrive as event entities rather than as a text action sensor. Device triggers are the other reason to prefer the automation pattern above: they’re published separately from the action sensor, so an automation built on a device trigger keeps working through this whole category of exposure changes, while one built on a sensor’s state doesn’t.
TS0042 vs. TS0043: which one to buy
The decision mostly comes down to how many distinct actions you need from one physical remote.
| TS0042 | TS0043 | |
|---|---|---|
| Buttons | 2 | 3 |
| Distinct action values | 6 (2 buttons x 3 press types) | 9 (3 buttons x 3 press types) |
| Zigbee2MQTT / ZHA support | Native, no converter needed | Native, no converter needed |
| Best for | A single room or a simple two-scene toggle (e.g. “movie mode” / “normal”) | Multi-scene rooms, or splitting control across more than two states |
If two clearly-defined states cover what you actually want to trigger, the TS0042 is the simpler physical object to mount and remember. If you find yourself wanting a third scene, the TS0043 covers that without changing the underlying setup pattern.
FAQ
Why is my TS0042’s battery stuck at 100% or not updating?
This is a known, variant-dependent reporting quirk tracked across several long-open GitHub issues, not necessarily a dead battery or a misconfigured integration. Check the device’s actual battery voltage before replacing it based on the reported percentage.
What’s the difference between the TS0042 and TS0043?
Button count, and therefore how many things one remote can trigger: two buttons and six action values versus three buttons and nine. Both support short, double, and hold presses on each button, and pairing and Zigbee2MQTT/ZHA support are otherwise the same pattern.
Does the TS0042 work as a Zigbee router or repeater?
No. It’s a battery-powered end device, the same device class as its sibling switches. It won’t extend Zigbee mesh range for other devices.
My TS0042 has no action entity in Home Assistant. Is it broken?
Probably not. In the GitHub issue most often cited for this, Zigbee2MQTT was receiving the button presses normally and only the Home Assistant entity was missing. Check whether an action value appears in the Z2M frontend when you press a button; if it does, the fix is on the Home Assistant exposure side — enabling event entities in Z2M’s Home Assistant integration settings is what resolves it in those threads — not re-pairing the switch.
Can I use the same automation blueprint for every TS0042, regardless of brand?
The blueprint threads are written against the Zigbee2MQTT or ZHA integration, not the storefront brand name, so a blueprint built for one Moes-branded unit should work against a generic-brand unit that Zigbee2MQTT or ZHA also identifies as TS0042. Blueprints are not portable between the two stacks, though — Zigbee2MQTT and ZHA surface this device through different mechanisms, and a blueprint written for one won’t run on the other.
What this piece verified
This is a research-synthesis piece. There’s no owned Tuya or Sonoff test-bench hardware behind this cluster yet, so nothing above was paired, tested, or run against a physical TS0042 for this article.
Sourced from Zigbee2MQTT’s TS0042 device reference page: native Zigbee2MQTT and ZHA support with no external converter needed, the action/battery/linkquality expose list, the six action values and their report-only nature, and the end-device (non-router) role. The manufacturer-ID sprawl and the battery-reporting inconsistency come from GitHub issues #6331, #21611 and #8500. The missing-action-entity behavior is from issue #23089 — closed as not planned — corroborated against issue #25948 and the Home Assistant add-on repository’s threads on the same symptom across TS0042, TS0043 and TS0044. The CR2032 battery spec and its compartment-confusion caveat come from a GitHub issue on a related Tuya Zigbee switch project.
What’s still unconfirmed: whether the event-entity setting resolves this for every affected setup, or only the configurations described in those threads — it’s the workaround that recurs, not a fix the project has committed to. The hold duration the device uses before reporting a _hold action isn’t documented on the device page either, so treat any specific figure you see quoted in a forum thread as that person’s unit rather than a spec. And whether Tuya ever standardizes battery reporting across manufacturer-ID variants isn’t something the current issue threads answer. Worth rechecking them before buying a batch of these for one project.