AM43 / TZE200_zah67ekd blinds motor states reversed?

[tnowak]

Describe the question or issue you are having

According to API docs blinds motors should report "% closed ", so:

• for a fully closed blind lift / level should be 100% and "open" datapoint should be false
• for a fully open blind lift / level should be 0% and "open" should be true

I have Moes AM43 blind motors (TZE200_zah67ekd) and its exactly opposite.
Sure, I can't change motor move direction but still physical button UP will make open datapoint false, and button DOWN - open=true. This seems reversed to me.

Am I doing something wrong here....? Any ideas how to fix it?

Screenshots

Blind fully open:

Environment

Conbee II
Version 2.11.03 / 9.05.2021
Firmware 26680700

deCONZ Logs

No logs required I believe

Additional context

API accessed by ioBroker deCONZ adapter

[Smanar]

Hello, the problem is more when you have open and lift reversed.
If I m right you can install the motor on the right or on the left, but it will be reversed on a side, no ?

Sure, I can't change motor move direction but still physical button UP will make open datapoint false, and button DOWN - open=true. This seems reversed to me.

It mean if you change the move direction, Up will open but you will have open = false ?
If it s that, I think it s the better solution, some blind are naturaly reversed, what is your third app ? You have not an option to reverse covering in it ?

[tnowak]

Yes, whenever or not I change the move direction, when my blinds is open deConz says "open = false".
I handle it within my app now, but this seems to be an error with blind code in the deConz to be corrected.

[Smanar]

IDK, It's possible, but this device is not new #4806 and I have not see problem about direction.
So if I reverse it now, users that already use it will have their automation reversed.

I have never see this device, but it s possible to mount it on the other side ? and if I m right it will work in different side. It s for that there is the "reverse" command, but unfortunately the value returned by the device is the same, so it work if the motor is on the left but is reversed if the motor is on the right (ot the reverse ....)

It s for that, if open is reversed compared at lift, I correct the code immediatly, but if all is reversed and for this kind of device it s more sensible.
I m searching a way to add a parametre "reversed" on the device JSON, but not possible (yet) to add "config" parameter for light device.

[tnowak]

@Smanar , please forget for a minute about the motor rotation direction or motor mounting side. It doesn't matter because if you press button with arrow Up on the device, you expect the blind to open and the API to report the blind is Open=True. Now the latter is opposite. You press the button Up, blind motor does its job and moves the blind up and then API reports Open=False (meaning: Closed).

The only way to make API tell the truth would be.... Mounting the blind motor upside down, above the blind. Then button Up would point it's arrow down and it would mean it closes the blind.

[Smanar]

Like I have said, I can be wrong, I have realy no clue how is your device.
But no need to "upside down", just depend of your mounting side, it happen for 50% of users, it s for that the command "reverse" exist on the remote, but unfortunately this command only reverse the command, not the return.

I don't have the tuya app, but perhaps it have too a command to reverse the state, or the gateway can ask for attribute to know if the state is reversed or not and change the return value.

And there is some device naturaly reversed, it s for that there is as setting for that in almost all third app.

It's easy to reverse it using API code, but I m sorry for this kind of device I can't be sure it will work for 100% of users.
For a covering switch, it s easy, the "up" button can only open, and for all covering connected to it, but for a "mouting dependent" device it s more complicated.

The issue is open, will see if we have similar return for this device, but ATM I prefer waiting to be sure.

[tnowak]

I think this issue should be marked as a bug.

[Mimiix]

@Smanar is this a bug?

[Smanar]

Bug, improvement, or normal, I can't say.

[Mimiix]

@tnowak I suggest using the original issue to discuss with other users. Maybe it's a mounting dependant thing or indeed a bug. If smanar changes it, it could cause issues with others.
#4806 (comment)

[Smanar]

Yep, sorry, but I m shy to change it so suddently.

[github-actions]

As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.

[github-actions]

As there has not been any response in 28 days, this issue will be closed. @ OP: If this issue is solved post what fixed it for you. If it is not solved, request to get this opened again.

[raoulx24]

Hi there,

I can see that the req is closed, so, if I have to post another req, I can do it and my apologies for this.

I ordered 6 AM43, out of them 5 are _TZE200_rddyvrci and one is _TZE200_zah67ekd; I can confirm that on the build from @Smanar branch from #5238 the behavior for _TZE200_zah67ekd is reversed: up is moving down, down is up, the states are reversed.

I also tried the magical PATCH deconz.home/api/[api_key]/lights/43 with body { "reverse": true }, the device blinks blue three times, but to no avail, same bahaviour.

When it is all the way down, GET deconz.home/api/[api_key]/lights/43 returns the opposite (I removed the non essential info)

{
    "manufacturername": "_TZE200_zah67ekd",
    "modelid": "TS0601",
    "state": {
        "bri": 0,
        "lift": 0,
        "on": false,
        "open": true
    },
    "swversion": null,
    "type": "Window covering device"
}

LE: Because I said that I am on a branch, I also tested it on deconz:stable, and we have the same reversed behavior as described above.

[Smanar]

Yep, but it s not the same story here ^^.
On the _TZE200_rddyvrci , it was the first time the device was included in deconz (so we hve more liberty), and command was different (so realy need a patch)

If I m right, this device is mouting dependend ? If someone mount it at left, it will not go in same direction than a right mounting.

And on this device the tuya command don't work, but you have a manual procedure for that ? with pressing both button or somehing like that ?

[raoulx24]

During the tests, the device was reset to default; same behaviour. I did not do the 'change directions' steps, but anyway, it should work also in this case (as it works on _TZE200_rddyvrci).

I will try it tomorrow, but I do not think it is the solution, because the change of directions has its meaning; depending on the position of the roller and off its pull string, it is needed the change.

[Smanar]

During the tests, the device was reset to default; same behaviour

Yep, I can be wrong since the start. But even I have take the bad direction at start, it s the same result, 50% of users will have wrong direction (depending of mouting side). And this device is not new, so If I reverse it now, I will have same % but all users that already use it, will have their automation broked.

[raoulx24]

Yes, unfortunately (for me :-) ), I agree with you and I understand the problem you are facing.

Maybe, there is some sort of extra setting in Tuya Gateway that it is known only there and they are able to mitigate the situation. Or, another maybe, it is a product with a faulty FW, and they can mitigate it with an upgrade. Or, maybe something else.

I do not know what can be the solution for this... Maybe a 'soft' reverse, known only by deconz and that can be set via REST API? Maybe with the new version announced, we can tweak this kind of behaviors in external files?

I think the best solution (if any) can arrise if you, the devs, will talk about it and who knows what kind of solution you will find.

For the near future, because for me it is only one device out of 6, I will live with it (I modified the source code from your brach - 44 or something; the one that fixed for _TZE200_rddyvrci - and in my case it is ok. I will see waht next version will bring.

Thank you and take care

[Smanar]

I do not know what can be the solution for this... Maybe a 'soft' reverse, known only by deconz and that can be set via REST API? Maybe with the new version announced, we can tweak this kind of behaviors in external files?

Sure, and I will do all I can for that, seriously, every week I have the issue "covering reversed", and some week are the reverse of the previous.

ATM is not possible to add a parameter "reversed", because there is no "config" for light device (covering), but will be different with DDF files.

[raoulx24]

I became extremely interested in the device, so I ordered an tuya gateway. Maybe with a sniffer (or something) I will be able to see what is going on. If I will find something, I will let you know.

[Smanar]

But I don't think the device use a zigbee command for the "reverse" as in the documention it say to use the manual procedure.

[raoulx24]

I do not think the problem is from the "device programmable reverse". I will search for a sniffer (if you know one, do tell, and I'll order it), and I will compare the commands of tuya with yours too see if there is any difference.

The gateway is on its way, tomorrow it should arrive.

The first test will be, of course, with the device added, to see if up is up. Afterwards, the sniffer.

[Smanar]

Can use a conbee as sniffer (for conbee2 it s beta, and idk if it works fine) https://forum.phoscon.de/t/announcement-zshark-is-now-available-for-conbee-ii/207
But cheaper one are CCXXXXX device https://www.zigbee2mqtt.io/how_tos/how_to_sniff_zigbee_traffic.html

[raoulx24]

But I already have one conbee 2, beside the production conbee 1. I hope I will be able to extract somehow the network encryption key (Transport Key) from tuya. Finger crossed.