The Tuya TS0043 is a battery-powered, 3-button Zigbee remote that ships under at least four brand names: Tuya-branded, Smart9 S9TSZGB, Lonsonho TS0043, and LoraTap SS600ZB. Same silicon, same modelID on the Zigbee network, different box on the shelf — and, per Zigbee2MQTT’s own device page, at least two documented cases where the physical pairing procedure differs depending on which box yours came in.
Once it’s paired, this one runs entirely on Zigbee2MQTT or ZHA. No cloud account, no companion app, no bridge to phone home to. The friction that actually trips people up is elsewhere: figuring out which pairing method your specific unit uses, understanding that the action entity isn’t a switch you can toggle from a dashboard, and not assuming pairing failed when the battery reading sits at “unavailable” for most of a day.
What the TS0043 actually is (and its many aliases)
On the Zigbee network, the TS0043 is a battery-powered end device — Zigbee2MQTT’s device page is explicit about this. It cannot act as a router and cannot extend mesh range for anything else on the network, which matters for placement: put it near a mains-powered router-capable device (a plug, a bulb, a relay module) rather than at the far edge of your mesh, since a weak end-device link shows up as delayed or dropped button presses rather than a dramatic failure. Our routers vs. end devices explainer covers end-device vs. router placement in more depth if this is new territory.
The TS0043 hardware is sold as Tuya-branded, Smart9 S9TSZGB, Lonsonho TS0043, and LoraTap SS600ZB — at minimum. If your listing doesn’t mention any of these names, check the modelID after pairing before assuming it’s a different device.
This kind of rebrand sprawl isn’t unique to this device. Zigbee-side Tuya hardware generally skips the local-key dance that Tuya’s Wi-Fi devices require — why Tuya’s Zigbee devices skip the local key goes into why that split exists — but it does mean the same product turns up under names that don’t obviously connect to each other in search results or on marketplace listings.
Verified specs and exposed entities
Per the Zigbee2MQTT device page, the TS0043 exposes exactly two entities:
battery— numeric, 0-100%, percentage unitaction— enum, report-only
Neither entity supports a /get or /set operation over MQTT. Both are report-only, which is worth sitting with for a second: this device tells Zigbee2MQTT what happened, but nothing about it can be commanded or queried on demand. There’s no “check current battery now” call and no way to simulate a button press from Home Assistant’s side.
The action entity has exactly nine possible values, one per button-and-interaction-type combination: 1_single, 1_double, 1_hold, 2_single, 2_double, 2_hold, 3_single, 3_double, 3_hold. That’s the entire interaction surface. Anything more complex — multi-tap sequences, combined button presses — has to be built in Home Assistant automation logic on top of these nine raw events, not expected from the device itself.
Pairing — why the procedure differs by brand
This is where the rebrand situation stops being a labeling curiosity and starts affecting whether you can pair the thing at all. Zigbee2MQTT’s device page documents two different physical pairing procedures for two of the known rebrands.
| Brand / model | Pairing procedure |
|---|---|
| LoraTap SS600ZB | Open the shell and hold the PCB pairing button for 5-10 seconds until the LED flashes yellow |
| Lonsonho TS0043 | Hold the touch button (no disassembly) for 10 seconds |
| Tuya-branded, Smart9 S9TSZGB | Not separately documented on the same page — try the touch-hold method first, since it doesn’t require opening the case |
If you hold the wrong control for the wrong duration on the wrong variant, you won’t get an error, you’ll just get nothing. Before spending ten minutes convinced your coordinator is broken, check the shell for any brand markings and try the procedure that matches. If there are none, the touch-and-hold method is the one that doesn’t require you to crack the case open first.
Wiring it into Home Assistant: action events, not a switch entity
Since action is report-only and enum-typed, it never shows up in Home Assistant as something you click. It’s not a switch or light entity — it’s closer to a doorbell event. Every button press produces a state change on a sensor entity, and that state change is what an automation trigger listens for.
automation:
- alias: "Scene switch - button 1 single press"
trigger:
- platform: state
entity_id: sensor.scene_switch_action
to: "1_single"
action:
- service: light.turn_on
target:
entity_id: light.living_room
Swap sensor.scene_switch_action for your device’s actual entity ID and repeat the block for each of the nine action values you want to wire up — single, double, and hold, per button, mapped to whatever the automation should do.
Both Zigbee2MQTT and ZHA can run this device, and both ecosystems have independently maintained community automation blueprints for it, which is a reasonable signal that neither path is a dead end. That said, the blueprints aren’t interchangeable.
Zigbee2MQTT and ZHA expose this device through completely different mechanisms — MQTT `action` state changes versus ZHA’s own device-trigger system. A blueprint built for one platform will not import or run correctly on the other, even though both target the same hardware.
If you’re coming from a Zigbee2MQTT-focused blueprint thread while running ZHA (or the reverse), you’re looking at the wrong repo, not a broken one. Our Zigbee2MQTT groups vs. scenes guide is a useful companion read here — this switch is the physical trigger side of exactly that groups-vs-scenes distinction, since a single button press is a natural fit for firing a scene rather than toggling individual entities one by one.
The 24-hour battery delay (and why it’s not a fault)
Per the Zigbee2MQTT device page’s own battery documentation, the percentage reading “can take up to 24 hours” to populate after initial pairing. If sensor.scene_switch_battery shows “unavailable” on day one, that’s the documented behavior, not a sign that pairing failed or the entity is broken.
Worth knowing: this delay is specific to the battery report, not the action entity. Button presses should register immediately after pairing completes — if those aren’t working either, the battery gap isn’t the explanation, and it’s worth checking mesh placement or re-running the pairing procedure for your specific variant instead. Our Zigbee2MQTT ghost-device fix covers the broader category of devices that pair but don’t behave, if the button presses themselves are the problem.
TS0043 vs TS0044 — don’t confuse the two
The TS0044 is a related but separate 4-button product, and it has its own distinct community discussion (a Zigbee2MQTT GitHub issue) about single-tap-only behavior reported on some units. If your search results are turning up fixes that don’t match what you’re seeing, check the button count on the physical device against the model number you’re searching for. A 3-button unit is a TS0043; a 4-button unit in the same product family is a TS0044, and the two have separate firmware behaviors and separate community threads.
FAQ
Why does the TS0043 pairing button location differ between brands?
Because the same Zigbee radio and modelID are packaged into physically different enclosures by different brand licensees (LoraTap, Lonsonho, Smart9, and generic Tuya-branded units). Zigbee2MQTT documents the pairing method per rebrand where that information is available, rather than assuming one universal procedure.
Why is my battery sensor showing “unavailable” right after pairing?
This is documented, expected behavior — the battery percentage can take up to 24 hours to populate. It’s not a sign of failed pairing.
Can I use the TS0043’s buttons to control a light directly, or do I need an automation?
You need an automation. The action entity is report-only and isn’t modeled as a switch, so nothing happens on a button press until you build a trigger for it.
Is the TS0043 the same as the TS0044 4-button switch?
No. They’re related products in the same family but are distinct modelIDs with separate community-reported quirks. Match the button count on your physical unit to the model number before troubleshooting.
Does this device work as a Zigbee repeater/router?
No. It’s a battery-powered end device by design and can’t extend mesh coverage for other devices.
What this setup actually verifies
Everything above comes from Zigbee2MQTT’s official TS0043 device page plus two independently maintained Home Assistant Community blueprint threads — one built for Zigbee2MQTT, one for ZHA on the same hardware under a different rebrand. No unit from this family has been paired or bench-tested for this article; the cluster doesn’t have owned Tuya/Sonoff hardware yet, so treat the pairing steps as documented rather than hands-on-confirmed until you’ve run them yourself.
I think the nine-value action enum is the right design call for a device this cheap — it keeps the Zigbee payload small and pushes the actual automation logic to Home Assistant, where it belongs, rather than trying to bake scene behavior into the device itself.
What’s still open: whether the Tuya-branded and Smart9 variants pair the same way as the two documented rebrands, or whether either brand has quietly changed the procedure on newer production runs. If you own one of those and it doesn’t match the touch-and-hold method, that’s worth flagging in the comments so future readers have a confirmed answer.