[Device Support Request] Aqara Roller Shade Driver E1

[PeteCondliffe]

Is your feature request related to a problem? Please describe. The cover entity in HA will control the roller but does not update its position so it is always 100 Looking at the WindowCovering cluster current_position_lift_percentage, always reports 0

Describe the solution you'd like Someone way smarter than me who would be so kind to fix it. I cannot get my head around creating a quirk

Device signature - this can be acquired by removing the device from ZHA and pairing it again from the add devices screen. Be sure to add the entire content of the log panel after pairing the device to a code block below this line.

{
  "node_descriptor": "NodeDescriptor(logical_type=<LogicalType.EndDevice: 2>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress: 128>, manufacturer_code=4447, maximum_buffer_size=127, maximum_incoming_transfer_size=100, server_mask=11264, maximum_outgoing_transfer_size=100, descriptor_capability_field=<DescriptorCapability.NONE: 0>, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=True, *is_full_function_device=False, *is_mains_powered=False, *is_receiver_on_when_idle=False, *is_router=False, *is_security_capable=False)",
  "endpoints": {
    "1": {
      "profile_id": 260,
      "device_type": "0x0100",
      "in_clusters": [
        "0x0000",
        "0x0002",
        "0x0003",
        "0x0004",
        "0x0005",
        "0x0006",
        "0x0009",
        "0x000d",
        "0x0013",
        "0x0102"
      ],
      "out_clusters": [
        "0x000a",
        "0x0019"
      ]
    },
    "242": {
      "profile_id": 41440,
      "device_type": "0x0061",
      "in_clusters": [],
      "out_clusters": [
        "0x0021"
      ]
    }
  },
  "manufacturer": "LUMI",
  "model": "lumi.curtain.acn002",
  "class": "zigpy.device.Device"
}

Additional context There is a number entity, AnalongOutput cluster. This seems to update when controlling the roller via its physical buttons or the cover entity.

Bonus: make the device report battery state - I believe it reports in the official app although im not sure this is possable because I cannot see it in any of the clusters that makes any sense to me.

There is also a switch, which apears to do nothing and is always in an of state

[joelmenezes]

Set it up with ZHA and have the same issues. Except I can only move the blinds down and stop. Cannot move it up

[PeteCondliffe]

As a workarround you can use the AnalongOutput entity in HA. Obviously you don't have the up and down buttons unless you create some. it works just fine with automations with 0 as closed and 100 as open

[TrixieMango]

Sorry if this is a stupid question because I imagine it’s probably not difficult to do (but I can’t seem to find anything about it anywhere):

I use the entity in HomeKit (through HA’s integration) and it works pretty well except the % are the wrong way round for opened/closed. (I.e. if I set it to 10% open, it actually goes to 10% closed, yet does then jump to report it correctly as 90% open).

So how can I set it to invert the numbers?

[Pete1979]

I have this issue as well. Trying to figure out the workaround with analog output. But i cant get the roller to move. @PeteCondliffe Would you mind explaining?

[PeteCondliffe]

Under the device in HA there are 3 entities cover - The one we all expect to be working but need the quirk for light - I have absolutly no idea what this is for number - This is the analog output and seems to work as percentage open with 0 being closed and 100 being open

I have been using this number entity for automations and using slider-entity-row in HA since my original post and the only issue ive found is it does not always update if you operate the blinds manualy. hope this helps

[schwickster]

I got the same problem. I got these today. I'll look one of these days into creating a start of a quirk for this device.

[schwickster]

I identified one of the problems. https://github.com/home-assistant/core/blob/487fa0a90518aac1fdb4d94f6fac251330d65f5c/homeassistant/components/zha/cover.py there we can see "current_position_lift_percentage" is being used. The device always reports value 0. We need to use AnalogOutput > present_value.

I tried to remap using a quirk but didn't get far. This ticket also contains some findings https://github.com/dresden-elektronik/deconz-rest-plugin/issues/5330

[schwickster]

For now I'll throw in my towel in the ring. My pull request (https://github.com/zigpy/zha-device-handlers/pull/1242) brings the following:

• Quirk identifies the roller shade from Aqara
• Fixes the device being identified as a light instead of a windowcover
• Removes a switch that doesn't do anything
• Added state to cluster which shows if the device is charging or not

Still todo:

• Add battery state (Adding XiaomiPowerConfiguration reports unknown in Home Assistant)
• Remap current_position_lift_percentage to AnalogOutput > present_value.

[schwickster]

Any help with the last 3 todo's?

[schwickster]

I can see a remapping example in this https://github.com/zigpy/zha-device-handlers/blob/2f9b0c33e08dfbddb703e44ce017e0a0a9315562/zhaquirks/plaid/soil.py However as far as I an see that example remaps one attribute to another attribute in the same cluster. I need a solution which remaps to a different cluster and attribute.

What needs to happen: Cluster 0x0102 (WindowCovering) with attribute 0x0008 (current_position_lift_percentage) Needs to be remapped to: Cluster 0x000D (AnalogOutput) with attribute 0x0055 (present_value)

@dmulcahey Any idea how to accomplish this?

[zviratkos]

Hello,

thanx for you effort! I have inspected with ZHA custom HACS plugin to see all available endpoints in Aqara E1 Rollers. But unfortunatelly, even when I move (either manually or via HA) covers, not even AnalogOutput (0x000D / 0x0055) changed, this value is updated only when I change slider in HA. Does that worked on your side, is that value updated on your system?

Thanx Jarda

[schwickster]

Hey Jarda,

yes, only slider works for me. Granted it's a workable method for me. The reason the other entity is not working is because HA uses another attribute that the e1 is not using.

I tracked down the problem, I just don't know how to code this within zha quirks. Some help from other developers would be nice.

so far my PR is a start, but it still needs work.

[schwickster]

Almost there! I got the window_covering attribute working. The present value is now getting passed onto current_position_lift_percentage. Both the button and the slider of the attribute seem to work. Also in nodered all the commands seem to work.

Only problem is that doing so I wrecked the analog output from doing any opening and closing the blinds... granted.. it's an output.... so... working as intended?

I'll creat a pull request. Can anyone test it out if it's working for them? See https://github.com/zigpy/zha-device-handlers/pull/1242/files

Still todo:

• Figure out what to do with analog output
• Battery reporting

[schwickster]

Good news everyone. Battery state is working! In my latest pull request commit it's there.

I tried to get rid off the analog output. Problem is that as soon as I do.. the window cover is no longer working. I also tried to tweak to maybe get it to be read-only.. no luck so far. I think for now we can leave it as is. It gives some weird janky results if you use that entity... but for now I'll leave it as is. Maybe somebody more experienced than me can take a look at it.

Also after initial repair it's possible you need to move up the covers or use the slider to get the initial readings correctly for the cover. Not sure what's causing it... But it's only a minor annoyance.

[1800Zeta]

Just adding my vote to this. I cannot see the battery state (hopefully fixed by @schwickster ) but I noticed I can only move the motor one way, assumed it was because I hadn't calibrated the unit to the window yet (it's still on my desk)

[MichaelDepner]

Hi @schwickster. I've updated to HA 2022.2, but it looks like my lumi.curtain.acn002 devices are not being recognised by the new quirk. I was looking forward to trying it out, and I'm wondering if there's anything else I need to do on my end.

My device signature is the same as the first post in this issue, so I think it should be recognised. I hope there's something obvious that I am missing:

  "node_descriptor": "NodeDescriptor(logical_type=<LogicalType.EndDevice: 2>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress: 128>, manufacturer_code=4447, maximum_buffer_size=127, maximum_incoming_transfer_size=100, server_mask=11264, maximum_outgoing_transfer_size=100, descriptor_capability_field=<DescriptorCapability.NONE: 0>, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=True, *is_full_function_device=False, *is_mains_powered=False, *is_receiver_on_when_idle=False, *is_router=False, *is_security_capable=False)",
  "endpoints": {
    "1": {
      "profile_id": 260,
      "device_type": "0x0100",
      "in_clusters": [
        "0x0000",
        "0x0002",
        "0x0003",
        "0x0004",
        "0x0005",
        "0x0006",
        "0x0009",
        "0x000d",
        "0x0013",
        "0x0102"
      ],
      "out_clusters": [
        "0x000a",
        "0x0019"
      ]
    },
    "242": {
      "profile_id": 41440,
      "device_type": "0x0061",
      "in_clusters": [],
      "out_clusters": [
        "0x0021"
      ]
    }
  },
  "manufacturer": "LUMI",
  "model": "lumi.curtain.acn002",
  "class": "zigpy.device.Device"
}

[schwickster]

Weird, I just updated and it's working for me. Try a repair by deleting the device.

[chriskyte]

Hi All,

I have the same issue on 1 of my 4 devices. From my investigation (using my very limited knowledge) I can see that on the 3 devices where the quirk is being applied the device signatures contain the below in_cluster attribute which is missing from the device that is not working. It is also missing from the device signatures posted by @PeteCondliffe @MichaelDepner above .

_"inclusters": [ "0xfcc0"

Checking the device firmware date (using Zigbee2MQTT) I can see the non working device has firmware date of 05-18-2021 where as the working devices have a firmware date of 11-24-2021. I am not able to update the firmware on the device as I do not have an Aqara Hub so cannot test if a firmware update would resolve this.

[schwickster]

0xfcc0 is the aqara specific cluster. You could try downloading the firmware from this page https://github.com/Koenkk/zigbee-OTA/blob/master/index.json (search for lumi.curtain.acn002) and enable OTA in ZHA https://www.home-assistant.io/integrations/zha/#ota-firmware-updates

I've been using that method for hue devices and it works great. For Aqara.. I haven't tried yet because there was no need to update because my devices came packaged with stable firmware.

In the Deconz issue ticket surrounding this device somebody noticed that if you are using the gateway from aqara, it will download a newer firmware than the one hosted in the github I listed above. Sadly the person couldn't capture where it was downloaded from.

[schwickster]

I've looked into my firmware version. And according to the date_code in the basic cluster it reads 05-18-2021. Can you check the XiaomiAqaraRollerE1 cluster and see what positions stored says?

[MichaelDepner]

Thanks for the responses. It took me a couple of hours, but I figured it out! I got the ZHA OTA update check to work with some tinkering, but the device responded "update not needed". I'm not sure if that was missing configuration on my part, or because the ota file is the same version my roller is on.

@schwickster Looking at your latest message, I checked the date_code in the basic cluster, and mine also reads 05-18-2021. Hm.

And of course, the XiaomiAqaraRollerE1 cluster did not exist, as @chriskyte pointed out.

In the end my problem was that my ConBee II stick was running old firmware. I updated it to the most recent release, deleted my roller and re-paired it, and now everything looks to be working.

Thanks for the help! 👍

[smiba]

Since the latest update the analog output is no longer working, it receives updates but isn't able to modify this value.

Any idea? I already re-paired it.

[schwickster]

@smiba at the moment it's working as intended. You need to use the cover attribute. The analog input is only used to relay numbers. I tried removing the attribute but than the cover won't work.

[smiba]

@schwickster None work, the cover attribute does nothing, the analog input does nothing. I can no longer control the driver.

Again it used to work just fine by setting a value 0-100% before this update. I already tried to pair the driver again but that didn't fix it either.

Right now it does receive updates, but it doesn't successfully signal the driver to roll to a certain position.

I have a date_code of 11-24-2021

EDIT: And even if the cover attribute works, not being able to set it to half or quarter height entirely ruins my use case, which is slowly letting some light in in the morning to help me wake up

EDIT2: If it's of any help, this is how my zigbee device signature looks like:

{
  "node_descriptor": "NodeDescriptor(logical_type=<LogicalType.EndDevice: 2>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress: 128>, manufacturer_code=4447, maximum_buffer_size=127, maximum_incoming_transfer_size=100, server_mask=11264, maximum_outgoing_transfer_size=100, descriptor_capability_field=<DescriptorCapability.NONE: 0>, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=True, *is_full_function_device=False, *is_mains_powered=False, *is_receiver_on_when_idle=False, *is_router=False, *is_security_capable=False)",
  "endpoints": {
    "1": {
      "profile_id": 260,
      "device_type": "0x0202",
      "in_clusters": [
        "0x0000",
        "0x0001",
        "0x0002",
        "0x0003",
        "0x0004",
        "0x0005",
        "0x0009",
        "0x000d",
        "0x0013",
        "0x0102",
        "0xfcc0"
      ],
      "out_clusters": [
        "0x000a",
        "0x0019"
      ]
    },
    "242": {
      "profile_id": 41440,
      "device_type": "0x0061",
      "in_clusters": [],
      "out_clusters": [
        "0x0021"
      ]
    }
  },
  "manufacturer": "LUMI",
  "model": "lumi.curtain.acn002",
  "class": "zhaquirks.xiaomi.aqara.roller_curtain_e1.RollerE1AQ"
}

[schwickster]

@smiba I had the same discussion over on the Home Assistant forums. The problem is that people are running various firmwares (in your case 11-24-2021, in my case 05-18-2021). My "fixes" work for firmware 05-18-2021 but not the latest. This is also the case over on the Deconz side where it was reported on the old firmware it works.. after updating it didn't (and was fixed later). Problem is that currently there's any way to update to the latest firmware if you don't have a gateway.

If I have the latest firmware I could try an OTA update and see what the problem is. But sadly the only avaiable firmware open to the public is 05-18-2021. So we either need to wait until somebody network sniffs the URL for the latest firmware (and hope it works using the OTA method) or Aqara needs to open up the URL. Over on the Deconz side somebody tried to downgrade in order to download the latest firmware and sniff the network.. but no luck there seeing as the downgrade process won't work for him. Also reached out to Aqara in the slim hope they'll provide the URL's.. but doubt they will do so.

So in the mean time either somebody needs to step up and make changes to the quirk who has the latest firmware.. or wait until I got the latest firmware applied and make changes.

[smiba]

Is there a way in the meanwhile for me to unlink this quirk from my roller shade driver? Previously it worked just fine for my purposes :)

[schwickster]

You could delete the quirk for each upgrade of Home Assistant you do using this method https://github.com/zigpy/zha-device-handlers#testing-quirks-in-development-in-docker-based-install

Not sure how that works for Hass.

[schwickster]

@smiba I ordered the E1 hub in the hope to sniff the ota file out by tracking the traffic. Also I´ll be testing out the firmware myself in the hope to track down the problem with the latest firmware. With any luck I'll fix the problem or point towards the problem.

[schwickster]

I successfully sniffed out the download URL for the latest firmware. It can be found here https://github.com/Koenkk/zigbee-OTA/pull/97/files

In the coming days I'll try to find the problem and try to fix it.

[schwickster]

So initial findings is that the Zigbee server commands for the window cover are all gone since the new update. Home Assistant uses commands like up_open, down_close, stop, etc. This can be found here: https://github.com/zigpy/zigpy/blob/dev/zigpy/zcl/clusters/closures.py https://github.com/home-assistant/core/blob/eafece36515b1c2206b031f79d138e03eb98121e/homeassistant/components/zha/cover.py

Example of up_open command working pre-1427: service: zha.issue_zigbee_cluster_command data: ieee: 54:ef:44:10:00:33:ab:c1 command: 0 cluster_id: 258 command_type: server endpoint_id: 1

I tried using ZHA toolkit to try and sniff if there are new commands.. but nothing is showing up. https://github.com/mdeweerd/zha-toolkit

[schwickster]

Good news, first fix is on the way. The analogOutput now works again (on both 1425 and 1427). I'll create a pull request soon. If you can't wait, try this code yourself https://github.com/schwickster/zha-device-handlers/commit/b7275faf913b46267cbb8d381f3d6cbc1eb7590e

[schwickster]

Hm.. I really don't get it. So I wrote some code that replaces the commands (which don't work anymore since 1427) and simply sets either values 100 (up), 0 (down) or a percentage given depending on the command activated.

  if command_id == GO_TO_LIFT_PERCENTAGE:
        self.endpoint.device.analog_bus.listener_event("handle_positions", args[0])
    elif command_id == UP_OPEN:
        self.endpoint.device.analog_bus.listener_event("handle_positions", 100)
    elif command_id == DOWN_CLOSE:
        self.endpoint.device.analog_bus.listener_event("handle_positions", 0)

Visually I see the numbers go up or down inside the analog_output field (which is tied to present_value from analogOutput )... yet nothing happens (device wise). When I read the value from analogOutput present_value it simply reverts back to the old value.

While with the same code when I manually type something in the analog output field.. it works...

[lkucytowski]

@schwickster thanks for that custom quirk. I just got the shade driver and while all fields were populated including position, I couldn't operate it. With you quirk I can at least control it using the analog output value.

[PedroDiogo]

As others have noted, I can't change the value of my blinds through Home Assistant. I was able to debug this and now I have it working. Reason? The quirk was not being applied. The quirk's signature is different to my blinds'. This signature works for me - so commenting out XiaomiAqaraRollerE1:

    signature = {
        MODELS_INFO: [(LUMI, "lumi.curtain.acn002")],
        ENDPOINTS: {
            # <SizePrefixedSimpleDescriptor endpoint=1 profile=260 device_type=256
            # device_version=1
            # input_clusters=[0, 2, 3, 4, 5, 6, 9, 64704, 13, 19, 258]
            # output_clusters=[10, 25]>
            1: {
                PROFILE_ID: zha.PROFILE_ID,
                DEVICE_TYPE: zha.DeviceType.ON_OFF_LIGHT,
                INPUT_CLUSTERS: [
                    Alarms.cluster_id,
                    AnalogOutput.cluster_id,
                    Basic.cluster_id,
                    DeviceTemperature.cluster_id,
                    Groups.cluster_id,
                    Identify.cluster_id,
                    # XiaomiAqaraRollerE1.cluster_id,
                    MultistateOutput.cluster_id,
                    OnOff.cluster_id,
                    Scenes.cluster_id,
                    WindowCovering.cluster_id,
                ],
                OUTPUT_CLUSTERS: [
                    Ota.cluster_id,
                    Time.cluster_id,
                ],
            },
            # <SizePrefixedSimpleDescriptor endpoint=242 profile=41440 device_type=97
            # device_version=0,
            # input_clusters=[]
            # output_clusters=[33]>
            242: {
                PROFILE_ID: 41440,
                DEVICE_TYPE: 0x0061,
                INPUT_CLUSTERS: [],
                OUTPUT_CLUSTERS: [
                    GreenPowerProxy.cluster_id,
                ],
            },
        },
    }

Other info:

• Firmware version: 11-24-2021
• Applied https://github.com/schwickster/zha-device-handlers/commit/b7275faf913b46267cbb8d381f3d6cbc1eb7590e as a custom quirk
• Conbee II updated tonight to the latest version

Here's what works:

• Battery level
• Device temperature - 20C now, 3C before.

Here's what does not work:

• Cover entity
• Adjusting blind position to 0 or 100 via the analog entity worked at some point. Stopped working after a few mins?

[schwickster]

I'm pretty sure you need the XiaomiAqaraRollerE1 cluster because that's the 64704 input cluster needed to identify the quirk. I got no problems at the moment of it stopping with working after a few minutes.

I'm still trying to figure out a way to fix the cover entity problem. No luck so far. I'm still stuck on the cover entity being updated by the analog attribute. However the cover entity updating the analog attribute visually works.. but no still no reaction.

Currently looking into Zigbee debugging if I can find a pattern what the problem is.

[iandarbey]

@schwickster thank you very much for your work on this. It has restored control using the analog output numeric input for me.

To clarify is the cover entity a seperate control the blind advertises that isn't responding unless it gets a stonecutters esque command from an Aqara hub? If so is it possible to ignore it and create a wrapper for the analog output that functions like a cover entity?

Just trying to understand the logic of the issue.

[schwickster]

@iandarbey Home Assistant uses the WindowCovering cluster where as Aqara uses the analog output cluster. So the thing we need to do is map present_value inside analog output cluster to current_position_lift_percentage inside WindowCovering cluster. Using current_position_lift_percentage makes the cover entity work.

So what I succeeded in is that present_value is mapped to current_position_lift_percentage. For people running the 1425 firmware this solution works. This because in 1425 the commands still work which make the motors go up and down.

For people running the 1427 firmware Aqara made the up, down, gotopercentage and stop commands to always return true and yet do nothing.

So what I am now working is to capture the commands and make the commands update the present_value. IE: up = 100, down = 0, gotopercentage is set the value... stop.. no clue yet..). This also works.. however this only works on the visual side of things in Home Assistant. The motor itself doesn't respond.. to make things worse when I manually lookup the cluster attribute of present_value it still reports the old values.

In other words it looks like the cluster attribute isn't updated for the device.

Simply said the following works:

• Pressing the buttons on the device updates both the cover and output attribute
• Filling in a value in the output attribute updates the cover attribute (which make the up and down buttons set a status)

What doesn't work:

• While the cover does update the output attribute it does not trigger the device nor is the cluster updated.

Things I tried:

• The code down below
• Uses write_attributes("present_value", numberhere) does nothing. Visually it's not updating the present_value nor is it setting any data.
• Using a bus to call the cluster
• Calling directly the cluster

This is how the code looks like at the moment that in theory should work for 1425 and 1427.

PRESENT_VALUE = 0x0055 CURRENT_POSITION_LIFT_PERCENTAGE = 0x0008 GO_TO_LIFT_PERCENTAGE = 0x0005 DOWN_CLOSE = 0x0001 UP_OPEN = 0x0000

class WindowCoveringRollerE1(WindowCovering): """Window covering cluster to receive reports that are sent to the AnalogOutput cluster."""

cluster_id = WindowCovering.cluster_id

def __init__(self, *args, **kwargs):
    """Init."""
    super().__init__(*args, **kwargs)

async def command(
    self, command_id, *args, manufacturer=None, expect_reply=True, tsn=None
):
    if command_id == UP_OPEN:
        self.endpoint.analog_output._update_attribute(PRESENT_VALUE, 100)
    elif command_id == DOWN_CLOSE:
        self.endpoint.analog_output._update_attribute(PRESENT_VALUE, 0)
    elif command_id == GO_TO_LIFT_PERCENTAGE:
        self.endpoint.analog_output._update_attribute(
            PRESENT_VALUE, (100 - args[0])
        )

    return await super().command(
        command_id,
        *args,
        manufacturer=manufacturer,
        expect_reply=expect_reply,
        tsn=tsn
    )

[puddly]

Cluster._update_attribute only "sets" the attribute value within zigpy, it doesn't actually write anything.

Replace it with calls to write_attributes (code untested, I don't have the device):

class WindowCoveringRollerE1(WindowCovering):
    """Window covering cluster that sends commands via the AnalogOutput cluster."""

    # TODO: does the roller also send attribute reports on the `AnalogOutput` cluster
    #       that should be remapped to `WindowCoveringRollerE1` attribute reports?

    async def command(
        self, command_id, *args, manufacturer=None, expect_reply=True, tsn=None
    ):
        if command_id == UP_OPEN:
            self.endpoint.analog_output.write_attributes({PRESENT_VALUE: 100})
            # TODO: what is the expected return value for this command?
        elif command_id == DOWN_CLOSE:
            self.endpoint.analog_output.write_attributes({PRESENT_VALUE: 0})
            # TODO: what is the expected return value for this command?
        elif command_id == GO_TO_LIFT_PERCENTAGE:
            self.endpoint.analog_output.write_attributes({
                PRESENT_VALUE: (100 - args[0])
            })
            # TODO: what is the expected return value for this command?
        else:
            # Since the commands do nothing, you probably don't want to send them if
            # they are already handled by one of the above attribute writes
            return await super().command(
                command_id,
                *args,
                manufacturer=manufacturer,
                expect_reply=expect_reply,
                tsn=tsn
            )

[schwickster]

Thanks to the help of @puddly and @dmulcahey I managed to make the quirk work with firmware 1427. The commands up, down and go to lift percentage now work by replacing them and setting values to present_value in analogOutput. At least it works for me.... @iandarbey @PedroDiogo @lkucytowski can you test out https://github.com/schwickster/zha-device-handlers/blob/dev/zhaquirks/xiaomi/aqara/roller_curtain_e1.py ?

I do know the stop command in its current form doesn't actually stop, it reverts back to the old value.. so still have to figure out how to simulate a stop command... ideas are welcome!

Once I got that sorted out I'll make a pull request and hopefully the code will be in the next HA release :)

Also good to know, the solution new commands work for both 1425 and 1427.

[iandarbey]

Will check it out and let you know.

In terms of ideas - Does an up command stop a down and vice versa? As in if you send command up while it's moving down will it just stop or will it also change direction?

[schwickster]

@iandarbey It will simply change direction. My hope was that by reading the attribute mid process it would read the most current value of the motor.. however the value only gets updated once the motor stops. So I doubt I can get it the stop command to work.

[iandarbey]

Up, down and set position all appear to work.

Using the cover slider to set a position seems to not fully work. For example I put cover all the way down. Then set it via slider to 50. Blind moves to position but the cover entity controls don't update (so the if it's moving up it the icon stays in the moving up icon and the up button is grey out).

Stays like the below.

[iandarbey]

To be clear it does physically move to position correctly just doesn't update the cover entity when it finishes moving.

[schwickster]

@iandarbey: yes.. I do see the problem indeed... Home Assistant isn't aware of the state that the motor is done and thus doesn't update the state (you can see the icons stays up or down). I'll see what I can do to manipulate the state. In theory we can update the state once the cover cluster gets updated. I'll look into it soon. Thanks!

[iandarbey]

@schwickster It's tremendous work so far. You've brought it from "I think I need to send this back" to "I'll buy 2 or 3 more next time it gets reduced". Using the set position, up and down will be enough for most automations etc I have in mind. It just would be great to have the stop work too.

[schwickster]

The real MVP is ebaauw on the deconz side. I learned a lot from him about this device. Anyway, glad to help.

I pushed a new commit that should fix the bug you reported @iandarbey. Feel free to try it out.

[PedroDiogo]

Great work, thanks @schwickster!

I have just tested and:

• Cover entity. Up and down buttons work. Stopping the curtain midway makes it go back to the start position. The position is updated when the movement finishes.
• Adjusting the curtain to a midpoint via the cover slider works.
• No longer need to comment the Xiomi input cluster in the input signature

The only improvement would be the stop command but that is a known at this point.

Didn't test the analog value as everything works in the cover entity.

[lkucytowski]

Thanks @schwickster for all the work you have done, ability to adjust by analog output was all I needed to be honest, but now we have a fully working product!

[schwickster]

And thanks to @dmulcahey we finally got the stop command! Committed and PR is created.

[hastime]

Hi all,

Sorry to jump in, I just wanted to thank you all for the hard work, it's awesome!

I'm new to ZHA, moved over from Deconz, can I ask, do I need to wait for an update or can I update manually to get these awesome additions and functionality, if so how?

Kind regards,