Have you tested this with the latest versions of HA? This was working for me, but setting the number now fails due to the problem I posted above
Yes it still works for me.
I am on Home Asistant 2022.5.4 and the maximum value for my number.lumi_lumi_curtain_acn002_analog_output entity is falsely reported as 1023 not like in your case as 0.
As I have added another abstraction level (template cover entity), that prevents moving the shade if the windows behind it are open this false maximum does not affect me, but it would be annoying otherwise.
Silly question here.
I have setup the calibration no issues. Setup in HA via zha
However, I cant seem to control the open shut… how is everyone else doing this?
I had the same problem where the up and down buttons were not working and greyed out. It did work with the analog control option, but I wasn’t happy with that.
I upgraded my Conbee 2 stick with the latest firmware, then removed the device and re-added it in the ZHA integration and it worked immediately.
I followed this guide and I flashed deCONZ_ConBeeII_0x26780700.bin
Hope this helps some of you.
Does updating the firmware of the Conbee 2 delete the stored ZigBee network?
I just tried updating the firmware of the Conbee 2. It does not delete the stored network. Unfortunately, removing and readding the E1 did not change anything… up and down arrows still greyed out
I did fix the incorrect max value issue, or at least find a workaround. See my comment on the Github issue here: Aqara Roller Shade Driver E1: analog_output max is 0, should be 100 - number error [ZHA] · Issue #71849 · home-assistant/core · GitHub
Strange…
Did you follow the calibration steps of the unit ? >>> does pressing the physical down and up buttons on the device once stop automatically at the desired positions?
I have recently bought 2 additional E1 to the previous 4 I already use and I’ve noticed something new after pairing in ZHA.
For all 4 previous E1 I’ve created the virtual cover as described in this thread. They work, but none of them exposes battery level obviously.
Now, after pairing one of the new E1 I got more sensors for the device and one of them is battery. I’ve checked the E1 is using quirks: “zhaquirks.xiaomi.aqara.roller_curtain_e1.RollerE1AQ” and it works correctly without the need for virtual cover.
However, when I paired the second new E1 it behaved as the previous ones. No battery sensor and steering doesn’t work. I also re-paired one of the older E1 and there is no change.
So my question is what could be the reason that one od E1 is configured with the above quirks and how to make the other E1 use them as well?
EDIT: Both E1 have the same firmware and I also updated one for the older units but still only one E1 is with mentioned quirks.
absolute legend. that blind analogue thing has been driving me crazy.
I have 2 of these working perfectly and 2 newer ones with the problem mentioned above. the ones that work report firmware 0x00000e19 and the newer ones are reporting 0x00000e1b in home assistant.
Updated the conbee firmware and tried unpairing and re pairing but i cant get them working at all.
I’m curious where I can find this firmware version. Can you give me some hints where I can check mine?
It was showing in the device page in home assistant. I have switched these devices to zigbee2mqtt as they perform far better with that integration.
Same Issue.
Its not possible to change Max Value to 100.0 with ZHA and Sonos Zigbee Stick
Thank you, I hunted around for this info for ages!
I’m having the same issue. I currently have the Mosquitto broker installed, do I need to to remove that and install zigbee2mqtt? Thanks.
No, the Mosquitto broker is the prerequisite for Zigbee2MQTT.
I got one of these ages ago, it connected and even operated just fine but would set it’s opening in reverse (i.e. to open it 30% I would have to command it to open 70%). Which I got around with a template after struggling to work out the quirks. In case it’s helpful to anyone:
cover:
- platform: template
covers:
back_blind:
friendly_name: "Back Blind"
position_template: "{{ (state_attr('cover.reversed_og_blind', 'current_position') | int) }}"
open_cover:
service: cover.open_cover
data: {}
target:
entity_id: cover.reversed_og_blind
close_cover:
service: cover.close_cover
data: {}
target:
entity_id: cover.reversed_og_blind
stop_cover:
service: cover.stop_cover
data: {}
target:
entity_id: cover.reversed_og_blind
set_cover_position:
service: cover.set_cover_position
data:
position: "{{100-position}}"
entity_id: cover.reversed_og_blind
icon_template: >-
{% if is_state('cover.back_blind', 'open') %}
mdi:blinds-open
{% else %}
mdi:blinds
{% endif %}
device_class: blind
recently bought a second for a different room. It really struggles to connect unless very close to the coordinator but then wouldn’t respond to anything anyway. After an embarrassingly long time of trying different things,… I discovered that they are on different firmwares!
The working one says: 0x00000e18
The new one says: 0x00000e1b
Does anyone know if it’s possible to change the new one’s firmware to 0x00000e18? Not certain if it’s an upgrade or a downgrade but it’s the only difference I can see and therefore the only cause of the issue that I can work out!
Thank you this worked for me also and nothing lost in firmware update.
Hi All.
I’m having (almost) the same issue…
Zigbee2mqtt, Sonoff Zigbee 3.0 (P).
Limits setup went fairly smoothly.
Paired fine… LQI 120.
I immediately noticed some of the state values were not healthy.
device_temperature, motor_state, running were all null and position was 0 even though the blind was fully open.
I could drive it fine from the Zigbee2mqtt dashboard, sending Open/Close/Position commands.
The reported position never changed from 0.
In home assistant the cover entity only allows stop and open (close is greyed out in my case).
I figured this might be related to the fact that the reported position was 0 (close greyed out when fully closed kinda makes sense).
Possibly, the position state is the command state (not actual position)… but still, you would expect it to change after sending 50% from the zigbee2mqtt dashboard.
Interestingly, zigbee2mqtt told me there was a firmware update for the blind controller…
I figured that might help and so proceeded (first time for me… most of my stuff is zwave).
It went smoothly… and now reports a build date of 10-09-2022)
But still no joy.
Seeing some had had success with a coordinator update, I investigated the options…
I flashed the Zigbee dongle with latest coordinator firmware (CC2652RB_coordinator_20220219 from Koenkk).
Everything came back fine… but still… no joy.
All symptoms the same.
I removed the device from the Zigbee network and repaired… remaining joyless.
So… it does work, I guess… I can use the TessyPowder solution (thanks).
But it seems odd to me that this device works fully for some and not others.
I would really like it if it reported all its state values and especially if the actual position was reported rather than 0 (regardless of last position command).