I have found following [Device Support Request] Aqara Roller Shade Driver E1 · Issue #1181 · zigpy/zha-device-handlers · GitHub in zigbee library github. So we have probably to wait, till this will be finished and merged into Home Assistant. Some of other comments (Aqara roller shutter - ZigBee - ZHA status problem) propose creation of template sensor, but still on my side it is not working. If I manually set position somewhere between 0 - 100, I’m able to start both opening and closing directions, but because position is not correctly updated, it runs till you stop it 
That’s good news, so the issue is with the device after all owing to the incorrect entity and not the ZHA?
Mine is still in a box after trying it out (i can’t let it keep rolling), but I could use the E1 Hub that came with it, but wanted it to managed in Home Assistant and not another Hub to play with 
Mine approach is pretty same I’m now going to play with GitHub - mdeweerd/zha_custom: "zha_custom" component for Home Assistant. Zigpy commands service wrapper, which was recommended as possible workaround to read status/position of cover. If anything useful will result from that test, I’ll post it.
A fix is under way… but it still needs work
I’m still waiting for one of the developers to approve the pull request. So far the fixes I made will fix the light entity showing up and it will add extra clusters for showing if the device is charging or not. I still need help adding battery status (I tried but couldn’t get any valid values) and remap the attribute that shows how far the tilt is (I know what to do… just don’t know how to code it).
Good news, both the cover and battery percentage is working now with my latest PR update. There are still some minor weirdness problems like initial usage and using the analog entity. But it works.
Curious if it’s working for you guys yet after you update to the latest HA version. Let me know else I’ll need to investigate why it’s not working.
I got the battery percentage coming through.
The cover still doesn’t respond to up or down commands from HA though. The icon changes but the motor doesn’t actually move.
Analog output value updates on manual press of the buttons on the controller and it appears to update to the correct value when you stop the blind mid open or close.
However prior to update to 2022.2 I could at least get the blind to move up or down by setting the analog output value.
Now the blind doesn’t respond to change the value (although HA icon on the cover changes to indicate that HA thinks it’s moving similar to pressing up or down on the cover entity).
Is this pointing to the right quirk?
"manufacturer": "LUMI",
"model": "lumi.curtain.acn002",
"class": "zhaquirks.xiaomi.aqara.roller_curtain_e1.RollerE1AQ"
Full signature here;
{
"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"
It’s pointing towards the correct quirk. I did notice one time that I had to (for initial setup) set the manual input thing (the other entity besides the cover) to 0 and 100. Even though It did nothing, It did make the cover entity respond correctly. It’s one of those minor weirdness things that need to be ironed out.
Also don’t forget to set a min and max to your rollers (by pressing the manual button up and down button 3 times) else it won’t work.
So I’ve set the min and max.
I’ve deleted and readded with the blind at both the min and max position.
The blind is added at the max position and ready to go.
Setting the analog input to 0 makes the window covering act like it’s moving (down button no longer pressable just stop) but the blind does not move.
The same if the down button is pressed. No movement.
If you press the physical buttons the blind moves and the analog input goes straight to zero if you press down but then updates to a range value if you press physical button and stop the blind.
Before 2022.2 I could use the analog to set a value and make the blind move. Now I can’t.
Of note I’ve my motor set to the reverse motor direction compared to how it arrived. Have tested with it back as standard and same issue.
Is there an extra line in my in clusters Vs what I’ve seen on GitHub?
I have one shade that’s also reversed and all three of my shades are working fine here…
What firmware are the shades running? If not mistaken, you can read it by using the basiccluster and than date_code. Mine read 05-18-2021. Which I think translates to it running firmware 1425.
There’s a new firmware called 1427 but the problem is that without a gateway we can’t get it until somebody finds the url by sniffing packets.
Do note though, the analog_output at the moment can’t be used anymore (but it’s still required to be present, can be disabled though). Only the cover should work. This is still something that needs to be fixed.
Can you also check the XiaomiAqaraRollerE1 cluster and see what positions stored says?
That returns Bool.true
This is a fresh delivery from Amazon UK so it is possible it has the updated firmware…
I’ve 11 items in my list of in clusters. That GitHub page above lists 10.
I appear to have 0x0001 as extra.
I have zero clue if that makes a difference!
Edit: My device type is 0x0202 vs 0x0100 in the link too
The quirk does add an extra cluster and does indeed change the type. That’s what it’s suppose todo. To explain; without quirk the device shows up as a light. Now it shows as a cover.
Can you check the firmware I asked you in previous post by checking the basic cluster and then date_code?
Also did you update your firmware of your USB zigbee receiver?
The date code returns 11-24-2021
I updated the firmware on my deconz adapter within the last month or so. That should be ok no?
Well there’s “the problem”… I’m running on an older version (05-18-2021) and apparently newer versions (11-24-2021) have breaking changes in the way it’s reporting things.
As long as nobody uploads the firmware or provides a link there’s no way for me to upgrade my roller shades and test what the problems are. Also don’t feel like buying a Aqara gateway.
It’s plausible you can downgrade if you really want it to work (I’m getting more reports from people who are running 05-18-2021 that’s it working) or migrate to Zigbee2MQTT or Deconz.
Ok.
But given it was working with 2021.12 (albeit with just adjusting the analog output value to make the blind move) surely there’s an avenue to get it working? Is there a way to revert to the old quirk?
I don’t know python but I can code so happy to test command sending (I’d assume there’s a cluster command in somewhere that was updating the analog output level which it responded to).
No inclination to buying a hub myself. I moved to HA to get away from hubs. My heating system is the one exception but it’s fully integrated with HA and sits alongside the pi and even that there’s a long term temptation to get rid of that hub…
Only thing I can look at is trying to make the manual input thing work again and make the cover entity also work… however I tried and didn’t get far. So I’m going to need to help there.
I think in the long the best solution would be a firmware upgrade so that it works for everyone. In this reply somebody already found the problem (in Deconz) https://github.com/dresden-elektronik/deconz-rest-plugin/issues/5330#issuecomment-1002789810. So it’s just a matter of time to get the firmware and update the code.
Is there anything I can do to help (testing commands to send etc)?
We’ll all have the same firmware eventually I guess.
I have two Aqara roller shades. I’m using ZHA with a sonoff zigbee bridge and after updating my HA to 2022.2 just one of the two is working with my analog output automations.
I think one is with the older firmware and the other is with the newest.
The previous quirk worked just fine for my purposes.
Any solution to use the previous quirk?
Latest update of the quirk I made should work for 1425 and 1427 firmware. Testes myself and other community members with both firmwares. See github of zigpy device handlers if you can’t wait for the latest HA release.
See Aqara Roller Shade Driver E1 - #28 by pathia
It all works (up and down buttons as well as current position)
