leshi.curtain.v0001 stuck in opening state after close

[avbaga]

After i close curtains via AppleHomeApp they are became closed in real and in MiHome App. But in AppleHome they stuck in "opening" state. Curtains are closing until 0% and when the limit is reached, they make short move back about 1%. In homebridge it looks like: Current position = 0% Target position = 1% Current state = 1

In MiHome they looks Closed 0% at the same time.

Can you solve it? Do you need any logs?

[merdok]

I can have a look at it, but you would need to post some more details since i do not own the device. If you would tell what are the exact steps which you do and include some homebridge debug log of the whole process then it would be perfect.

[avbaga]

Thank you very much for you attention!

Step by step scenario is the following:

1. Start position - Curtains are open
2. In Apple Home App I move slider to close Curtains (21:58:34 - in log). It is one and only action i do.
3. Curtains are closed. in real but not in App.
4. in Homebridge and AppleHome they stuck in "oppening" state.

LOG homebridge.log.txt

[merdok]

Thanks for the info! From the log i can see that the target position jumps back to 85% after you set it for some reason and then the current position is at 0% and target position is at 85% which leads to the the "opening state", since target > current position. I also see that after your action the power is turned off, so maybe that is why it doe snot update anymore? I also saw that when you slide the slider 3 commands are send to the device to set the target position, can you try to just tip with your finger on the slider once so that one command is sent and check if that also leads to the issue?

[avbaga]

Thank you for your comment! I made several tests and have following results. It is doesn't matter how to move slider. Fast or slow. In any case i see in log several commands to set target position. Last target position from "Device properties updated" Event always doesn't met the last value from "set target_position property" request the one and the only case when current and target positions are met is the 100% (fully open)

In the attached log i made automation that close curtain on event. You can only one request to set position to 0. Target position 85 came from nowhere.

homebridge.log (3).txt

[merdok]

Honestly from the log everything looks correct till a certain point: a command was sent to the curtain to set the position to 0% (target position) and it was executed successfully on the device. Afterwards the device then changes that back to 85%, the current position jumps for a moment also to 85% and then goes back to 0% as it was requested. The problem here is that the device somehow sets the target position to 85% after the command and i cannot say why it is happening... Why is it exactly 85%, and why after executing the command the "power" property is set to false? The behavior is kind of strange...

[avbaga]

It os not always 85%. Sometimes it is 10% or 1% or somethind else. I think device update target position while closing. But device did not send last update of target position before stop. in a same time miHome always show correct state of curtains. maybe it is possible to ignore target position from device?

By the way. Power switch in Apple home always set to off after close command. And it is always on after open command.

[merdok]

Most of the curtains have a "status" property where it is exactly written what status the curtains have, but your does not have it so we need to calculate it based on target position and current position. But maybe the "power" property is what we should look at, so when is the "power" property true and when false? Is the "power" property true when the curtains are open and false when they are close? Or is the "power" property true when the curtains are moving no matter up or down, and false when they are not moving?

[avbaga]

If specification is correct: https://home.miot-spec.com/spec/leshi.curtain.v0001

in my case motor control=0 when curtains are open. in all other cases motor control = 1 or 2. Ad it is displayed as “off” in appleHome

[merdok]

Motor control is a write-only property. It cannot be read, so it cannot be used the get the device status.

[avbaga]

Maybe it is possible to make an option to ignore target position from device?

[merdok]

Again, i cannot ignore target position from the device since then i cannot tell what the current status is (whether it is opening, closing or stopped), since your device does not report the status directly...

[avbaga]

Thank you for your comment. I understand that in this case i'll loose ability to have statuses "opening" and "closing". But all other functions will work. I'm not a programmer. Unfortunately i can not make good patch. On my side i made following changes in CurtainAccessory.js getTargetPosition() { if (this.isMiotDeviceConnected()) { return this.getDevice().getCurrentPosition(); } return 0; }

Now my curtains do not stuck in opening or closing state. I lost "Opening" and "Closing" statuses. For me it is OK.

I found that MiHome for this Curtains also do not show correctly "opening" state. It seems what MiHome use predefined timeout for opening and closing states for this accessory.

Maybe it is possible for this accessory only make fix in getTargetPosition() function?

[merdok]

i think that the "power" property is the correct way to solve the issue with your curtain. You need to tell how exactly the "power" property changes depending on if the curtain is opening or closing and what is the value of it. Is it correct that the "power" property is set to true during movements (closing or opening) and false when there is no curtain movement?

[avbaga]

Hi, on this device power property have the following behavior: Curtains are closed 0% = power is off Curtains are open for any value from 1% to 100% = power is on

[merdok]

Oh, so when the curtains are open, does not matter if they are moving or not, the power property will always have the truevalue?

[avbaga]

exactly

[merdok]

Ah, that is not good since that will not help much about the issue 😞
Maybe the only solution would indeed be just to always use the current position but that would completely disable that status and it would always show as "stopped"

[avbaga]

From my point of view it’s better to have correct statuses "opened"/"closed" without "opening"/"closing", than current plugin behavior. I made quick fix as i wrote before and now my curtains doesn’t stuck in "opening" state. Animation for me is not so important. Now a have the ability to check if the curtains are closed or not from automation. Previously they are always been "Open" or "opening".

[merdok]

Can you try a different fix? Can you go to theleshi.curtain.v0001.js file and insert there the following code:

  getTargetPosition() {
    return this.getPropertyValue(Properties.CURRENT_POSITION);
  }

That should be a more cleaner solution which is only for your specific device and not for all curtains, if that works for you then i will add this fix. Please let me know.

[avbaga]

Hi, this is working solution. I turn back getTargetPosition() in CurtainAccessory.js and make recommended changes in leshi.curtain.v0001.js

Please, add fix into main repo.

[merdok]

Thanks for testing. I will add that fix in the next update!

[merdok]

Should now be fixed in version 0.9.18