Open and closed wording on curtains

Configuration
1

I have curtains through two different integrations and they don't agree on the direction

image
image460×103 1.76 KB

these are actually the same device
So it seems like there is no agreement on which side is open or closed.

is there any way to flip the direction of bar so that it's the same as when I look at the curtain in real life

the entity has a motor direction but it does not work. Whatever you set it to it will flip back to unknown and it does not seem to have any effect on the actual curtain

image
image1051×859 75.5 KB

1 Like
2

A couple of things are tangled together here.

First, the root of the disagreement: you're running the same physical motor through two integrations, and each one interprets the position datapoint its own way (one treats 100 as open, the other as closed). Long term I'd pick one integration to control it, since two will also fight over state and commands. What you're seeing is a display/inversion thing, not the motor behaving two different ways.

On the Motor Direction reverting to "unknown" and doing nothing: that's a datapoint-mapping problem. The direction DP LocalTuya exposes isn't actually being reported or accepted by your motor (either mapped to the wrong DP, or this motor only accepts a direction change through its app calibration, not as a live-writable DP). Since it never echoes a value back, HA shows "unknown" and your writes have no effect. So don't rely on that control, set the direction in the app / re-run calibration or just correct it in software.

3

So currently have two integrations because I'm trying to get everything to work and firstly get off the cloud integration. I got everything working in the two local integrations but still I'm not able to reduce it down to one.

Is it realistic to only use one integration

4

TL;DR: yes, one integration is the goal and actually more stable than two. Pick the one that gives you a full cover entity, note your device_id/local_key, remove the device from both (and cloud), then re-add it once.

A single device should be owned by one integration. Running it through two is exactly what caused the open/closed direction disagreement you hit earlier: they each interpret the position datapoint their own way and fight over state.

It's also a bit forced by Tuya itself. The device has one local_key, and a lot of Tuya firmware only allows a small number of simultaneous local connections, so two local integrations both connecting can get flaky. So collapsing to one isn't just tidier, it's more reliable.

The reason it feels hard to reduce is usually that each integration gives you slightly different entities and you've wired things to both. For a curtain though, one integration should cover everything you actually need (open / close / stop / position). Pick based on the device:

  • Tuya Local if it has a profile that gives you a clean cover entity.
  • LocalTuya if you'd rather map the datapoints yourself, or no profile fits well.

Direction isn't a reason to keep both, by the way. That's a device-side calibration you set once in the Smart Life app (or via the motor's button), not something either integration controls reliably.

To consolidate without losing your work:

  1. Note the device's device_id, local_key, and protocol version.
  2. Remove the device from both local integrations (and the cloud one).
  3. Re-add it once, to the single integration you chose.
  4. Repoint any dashboard cards or automations to the new entity_ids.

Getting off the cloud integration is the right move for local control. Once your one local integration fully drives the curtain, you can drop cloud entirely.

5

Is not as simple as whether the display is pretty.

Google no longer works because open and close is opposite.