Two people buy what looks like the same curtain motor. Same white plastic housing, same Zemismart or generic “Tuya Zigbee curtain motor” listing, same price. They pair both to Zigbee2MQTT and end up staring at two completely different device pages, with different entities, different config options, and no obvious explanation for why.
That’s not a bug in either setup. Tuya’s ecosystem is a licensing model, not a single product line, and curtain/blind motors sold under it split into at least three structurally different device families depending on which OEM built the actual hardware. This piece walks through the two you’re most likely to have — TS130F and TS0601_cover_1 — plus a third variant worth knowing about, how to pair and calibrate each, and the two problems that trip up almost everyone regardless of which one they got.
Why the Same-Looking Motor Shows Up Differently
Tuya doesn’t manufacture most of the hardware sold under its ecosystem. Brands like Zemismart, Moes, LoraTap, Binthen, and A-OK license Tuya’s Zigbee modules and firmware, then build their own motor housings around them. Two OEMs can ship visually identical units built on completely different Tuya reference designs, each reporting a different Zigbee modelID when it joins your network. That modelID, not the seller’s product photo, is what Zigbee2MQTT actually keys its device support on.
After pairing, check the device’s page in the Zigbee2MQTT frontend before assuming anything about your unit. That page, not the box or the listing title, tells you which section below applies to you.
TS130F: The Curtain/Blind Switch Module
TS130F is a switch-style controller module rather than an all-in-one motor unit, white-labeled among others as the LoraTap SC400. It exposes cover state (open/close/stop) and position on a 0-100 scale, plus a handful of binary options: a motor_reversal toggle, a calibration mode switch, indicator-LED mode, and a backlight toggle.
Pairing requires holding the module’s stop button for 10 seconds. Calibration is a manual sequence run around that calibration toggle. Fully open the curtain, enable calibration mode, fully close the curtain, then disable calibration mode. It’s a binary on/off toggle wrapped around a manual open-close cycle, not a numeric setting you dial in. The exact button presses (some variants add a pause step between each move) differ slightly by unit, which is another reason to read your device’s own frontend page rather than assume.
TS0601_cover_1: The All-in-One Motor
TS0601_cover_1 is a different device family entirely, an all-in-one motor rather than a separate switch module, white-labeled as Zemismart, Binthen, A-OK, and others. It also exposes cover state and position, but instead of TS130F’s separate binary toggles, it groups its configuration into a composite options object containing motor_speed (numeric, up to 255) and reverse_direction (boolean).
You set both through Zigbee2MQTT’s MQTT API rather than a calibration-mode toggle. Here’s the command that sets both at once.
mosquitto_pub -t zigbee2mqtt/living_room_curtain/set \
-m '{"options": {"motor_speed": 40, "reverse_direction": true}}'
The pairing button sequence for TS0601_cover_1 units isn’t consistent across sellers. Some units use a two-button sequence, others a single button, and the difference isn’t something the listing photos reliably show — so treat the seller’s instructions as the starting point and fall back to the Zigbee2MQTT device page if they don’t match.
A Third Variant to Know About: QS-Zigbee-C01
Beyond TS130F and TS0601_cover_1, a third curtain module, the QS-Zigbee-C01, is sold into the same market segment under its own branding and is discussed in isolation in Home Assistant Community threads, without ever being cross-referenced against the other two families. If your motor doesn’t match either device page above, this is worth checking before assuming Zigbee2MQTT doesn’t support your unit at all.
| Family | Product type | Common branding | Config style |
|---|---|---|---|
| TS130F | Switch/controller module | LoraTap SC400 and others | Binary toggles + manual open/close calibration |
| TS0601_cover_1 | All-in-one motor | Zemismart, Binthen, A-OK | Composite options object (motor_speed, reverse_direction) via MQTT set |
| QS-Zigbee-C01 | Curtain module | Sold under its own name | Documented separately, not consolidated with the above two anywhere |
Fixing the Two Problems Everyone Hits
Both families support an invert_cover Zigbee2MQTT device option, defaulting to false, that flips which end of the 0-100 position range maps to open versus closed. If your curtain opens when Home Assistant tells it to close, or reports 0% when the curtain is fully closed instead of fully open, this is almost always the fix rather than a hardware fault. Here’s what that looks like in your Zigbee2MQTT device configuration.
devices:
'0x00124b00aabbccdd':
friendly_name: living_room_curtain
invert_cover: true
Worth knowing: invert_cover behaves identically across both families in Zigbee2MQTT’s frontend, even though TS130F and TS0601_cover_1 are architecturally unrelated devices under the hood. It’s one of the few settings you don’t have to relearn when switching between them.
Calibration drift, the position slider slowly disagreeing with where the curtain physically is, is handled differently per family. TS130F needs the manual calibration-mode cycle described above run again. TS0601_cover_1 doesn’t expose a separate calibration mode the same way, so drift there is usually a motor_speed or physical obstruction issue rather than something a config toggle fixes on its own.
A bundled dongle-plus-motor kit pairing successfully does not confirm the motor itself is supported. Coordinator/adapter support and motor support are two separate checks, and buyers regularly miss the second one.
That warning isn’t hypothetical. A Home Assistant Community thread documents exactly this: a buyer with a bundled Zemismart dongle-and-motor kit couldn’t get the motor to pair at all, and the actual cause turned out not to be a settings problem. A community member clarified that the bundled coordinator being Zigbee2MQTT- or ZHA-supported says nothing about whether the motor itself appears on either project’s supported-device list. Those are independent facts you have to verify separately, and the thread never reaches a resolution for that specific buyer, which tells you how easy this mistake is to make.
What to Check Before You Buy
If you’re buying new and want a specific, known-working family rather than whatever modelID you happen to get, check the seller’s listing for a modelID or firmware reference before ordering; sellers that can answer “is this TS130F or TS0601?” directly are a good sign, and ones that can’t are a real risk. There’s no comprehensive SKU or batch-number cross-reference that lets you pin the device family down from a listing before the unit arrives, so this pre-sale check is really about seller responsiveness, not a lookup you can do yourself.
Either way, once the motor is paired directly to Zigbee2MQTT or ZHA, it bypasses the Tuya cloud entirely, the same way other Zigbee devices in the Tuya ecosystem do. Unlike Tuya’s Wi-Fi products, none of this requires extracting a local key. If you’re coming from a Tuya Zigbee gateway rather than buying fresh, the migration path to Zigbee2MQTT is a separate project worth reading before you start, since it changes how re-pairing and existing automations behave. And if your goal is confirming the whole setup stays usable with no outbound internet dependency at all, that’s covered directly here.
Zigbee2MQTT’s decision to key device pages off the raw Tuya modelID, rather than a friendlier product-family name, is the right call even though it’s exactly what causes this confusion. A marketing-friendly label would paper over the fact that two “Zemismart curtain motors” can be genuinely different devices underneath, and that distinction matters more than a tidy name would suggest.
For comparison, Aqara’s curtain motor line doesn’t have this multi-family ambiguity: each SKU maps to one device model, one calibration procedure, no guessing required after pairing. That consistency is one advantage of buying into a single-brand ecosystem instead of Tuya’s OEM-licensed one, even if it comes at a higher price point.
Common Questions
Why does my curtain motor show up as a different device model than my friend’s, even though they look identical? Different OEMs license Tuya’s Zigbee modules and build their own housings around them. The modelID your motor reports on pairing, not its appearance, determines which Zigbee2MQTT device page and config options apply.
Does my Tuya or Zemismart curtain motor need a local key like Tuya Wi-Fi devices do? No. Zigbee devices in the Tuya ecosystem pair directly to Zigbee2MQTT or ZHA and never touch the Tuya cloud or its local-key mechanism, unlike Tuya’s Wi-Fi products.
Why won’t my curtain motor pair even though the bundled dongle connected fine? Coordinator support and motor support are separate facts. Confirm your specific motor’s modelID appears on the Zigbee2MQTT or ZHA supported-device list independently of whether the dongle itself paired.
How do I fix a curtain motor that opens when it should close, or stops short of the end? Try the invert_cover device option first. If the position is drifting rather than simply inverted, TS130F needs its calibration cycle re-run, while TS0601_cover_1 drift is more often a motor_speed or physical-obstruction issue.
Can I tell which device family I have before buying? Not reliably from listing photos alone. Ask the seller for the modelID or check post-pairing against the Zigbee2MQTT device pages for TS130F and TS0601_cover_1.
What This Article Verified, and What It Didn’t
Everything above about exposed entities, config options, pairing sequences, and calibration steps comes directly from Zigbee2MQTT’s own device reference pages for TS130F and TS0601_cover_1, cross-checked against the Home Assistant Community threads documenting real pairing and calibration problems. No motor from this family has been paired or calibrated on this site’s own test bench, so treat the calibration steps as documented procedure rather than a confirmed walkthrough, and verify against your own device’s frontend page once it joins your network.
If you’re still not sure which family you’ve got after checking the frontend, that’s worth a comment with your exact modelID string. Whether a fourth Tuya curtain-motor family shows up in the wild is an open question. Given how fragmented this OEM landscape already is, it wouldn’t be a surprise.