Aqara Roller Shade Driver E1

hastime commented 2 years ago

Device

Product name: Roller Shade Driver E1
Manufacturer: LUMI
Model identifier: lumi.curtain.acn002
Device type : Please remove all unrelated device types.
- Other: Battery Powered roller shade driver

Screenshots

Basic

Identify

Alarms

Device Temperature

Groups

Scenes

On/Off

Level Control

Color Control

Simple Metering

Diagnostics

Other clusters that are not mentioned above

Pete1979 commented 2 years ago

@Pete1979 ZHA != deconz. you need deCONZ for this.

I know, thats why im thinking of migrating back to deCONZ, since i could not get the roller working in ZHA.

Arjan-21 commented 2 years ago

@Pete1979 Yes just update to a 2.13.4 (Beta) and now it works with the lift command

sanderlv commented 2 years ago

Mine broke after update

[s6-init] making user provided files available at /var/run/s6/etc...exited 0. [s6-init] ensuring user provided files have correct perms...exited 0. [fix-attrs.d] applying ownership & permissions fixes... [fix-attrs.d] done. [cont-init.d] executing container initialization scripts... [cont-init.d] firmware.sh: executing... [15:35:34] INFO: GCFFlasher V3_17 (c) dresden elektronik ingenieurtechnik gmbh Path | Vendor | Product | Serial | Type -----------------+--------+---------+------------+------- /dev/ttyACM0 | 0x1CF1 | 0x0030 | DE2194613 | ConBee II /dev/ttyACM1 | 0x1CF1 | 0x0030 | | ConBee II /dev/ttyUSB0 | 0x0403 | 0x6001 | AO3RXEHS | Generic FTDI [cont-init.d] firmware.sh: exited 0. [cont-init.d] nginx.sh: executing... [cont-init.d] nginx.sh: exited 0. [cont-init.d] novnc.sh: executing... [cont-init.d] novnc.sh: exited 0. [cont-init.d] done. [services.d] starting services [services.d] done. [15:35:34] INFO: Websockify waiting for VNC to start [15:35:34] INFO: Running the OSRAM LEdvance OTA updater... [15:35:34] INFO: Running the IKEA OTA updater... [15:35:34] INFO: Running the deCONZ OTA updater... [15:35:34] WARNING: Your direct VNC access is not protected! [15:35:34] INFO: Starting VNC server (local/no)... [15:35:34] INFO: Starting websockify... WebSocket server settings: - Listen on 127.0.0.1:5901 - Flash security policy server - Web server. Web root: /usr/share/novnc - No SSL/TLS support (no cert file) - proxying from 127.0.0.1:5901 to 127.0.0.1:5900 [15:35:37] INFO: deCONZ waiting for VNC to start [15:35:37] INFO: Starting the deCONZ gateway... libpng warning: iCCP: known incorrect sRGB profile libpng warning: iCCP: known incorrect sRGB profile [15:35:38] INFO: Starting Nginx... 2021/12/20 15:35:38 [notice] 314#314: using the "epoll" event method 2021/12/20 15:35:38 [notice] 314#314: nginx/1.14.2 2021/12/20 15:35:38 [notice] 314#314: OS: Linux 5.10.83 2021/12/20 15:35:38 [notice] 314#314: getrlimit(RLIMIT_NOFILE): 1048576:1048576 2021/12/20 15:35:38 [notice] 314#314: start worker processes 2021/12/20 15:35:38 [notice] 314#314: start worker process 1457 15:35:37:841 HTTP Server listen on address 0.0.0.0, port: 40850, root: /usr/share/deCONZ/webapp/ 15:35:37:854 COM: use stable device path /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2194613-if00 15:35:37:864 COM: /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2194613-if00 / serialno: DE2194613, ConBee II 15:35:37:864 ZCLDB init file /data/.local/share/dresden-elektronik/deCONZ/zcldb.txt 15:35:37:890 found node plugin: libde_signal_plugin.so - Signal Monitor Plugin 15:35:39:804 found node plugin: libstd_otau_plugin.so - STD OTAU Plugin 15:35:40:826 COM: /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2194613-if00 / serialno: DE2194613, ConBee II 15:35:42:292 Device firmware version 0x26720700 ConBee II 15:35:42:301 unlocked max nodes: 512 15:35:42:414 Device protocol version: 0x010E 15:35:42:496 Current channel 15 15:35:42:524 CTRL ANT_CTRL 0x03 15:35:42:528 CTRL ZDP_RESPONSE handler 0x0001 15:35:42:567 Device protocol version: 0x010E 15:35:42:671 CTRL ANT_CTRL 0x03 15:35:42:674 CTRL ZDP_RESPONSE handler 0x0001 parse error: Invalid numeric literal at line 1, column 34 15:36:37:812 Device TTL 4789 s flags: 0x7 15:37:37:810 Device TTL 4729 s flags: 0x7 15:38:37:812 Device TTL 4669 s flags: 0x7 15:39:37:814 Device TTL 4608 s flags: 0x7

Mimiix commented 2 years ago

@sanderlv this is not the place to post that kind of stuff.

sanderlv commented 2 years ago

I don't know since I am the OP and wanted to say that for me this update broke it.

EDIT: oops, you're right! wrong topic. but nevertheless... updating to 6.11.0 deCONZ 2.13.4 broke mine.

AlmightyCZ commented 2 years ago

I'm sorry to write here, but I'm not sure where to ask, as I'm not sure if it's a bug. And I also have some features related questions.

I have deCONZ 2.13.4 and the device pairs as a Dimmable light, is this the usual way how are blinds appearing in the deCONZ?

I can still control the device through window covering cluster (lift percentage only), however the device is not reporting current position (always 0). Is it not supported by the device, or is this a bug?

There is also an option for Window Covering mode, but it's read only and set to Drapes. The original aqara app supports some device mode for window blinds, with tilt up/down button, these do a micro movement up or down in order to change the tilt of blinds blades. Is this possible to achieve through API? Or does it has to be done with a up/down+pause+stop? I suppose the tilt options of the Window Covering cluster are not supported as this method of tilting depends on the previous blind movements and has no "tilt level" feedback, right?

ebaauw commented 2 years ago

Got myself an Aqara Roller Shade Driver E1 (I suppose the EU version) in another attempt to automate my venetian blinds. I think we can improve on the current support:

The device advertises as an On/Off Light, but the API exposes it as Dimmable Light? I think the API should expose it with a type of Window covering device. The On/Off cluster doesn't do anything.
The Window Covering commands Open, Close, Stop, and Go to Lift Percentage all seem to work (with percentage meaning: percentage open). Even the Reversed bit in Mode seems to work. Indeed the Current Position Lift Percentage doesn't do anything. The API doesn't issue any of these commands, though. It does configure attribute reporting on Current Position Lift Percentage though.
The percentage is reported as Present Value in the Analog Output cluster. The report also includes attribute 0xF000 (u32) with value 0. Haven't seen any other values, yet. Writing Present Value makes the device move; this is what the API issues on setting state.lift or state.open.
The actual device state is reported as Present Value in the Multistate Output cluster: 2 for stopped; 0 for moving downwards; and 1 for moving upwards. This report also includes the 0xF000 (u32) attribute, with different value. Not sure what these represent. It doesn't seem to report the position while moving.
The device supports the Identify commands, but the API doesn't expose state.alert.
The Lumi specific cluster looks interesting. When setting Device Operation Mode to 0, the device no longer reports Analog Output nor Multistate Output. Various reviews online mention that the device supports different modes in the app (amongst which one for Venetian blinds), I suppose that's some magic setting in this cluster. Maybe there's a magic value to enable Current Position Lift Percentage or Current Position Tilt Percentage, depending on the configuration?
No Power Configuration cluster, as we've come to expect from Xiaomi devices. It doesn't report the Power Descriptor either. I did capture some special attribute report for 0xFCC0/0x00F7, with octec string (0x41) value: 03:28:64:05:21:08:00:09:21:00:01:0a:21:00:00:0b:20:00:0c:20:01:0d:23:19:0e:00:00:11:23:01:00:00:00:64:20:00:65:20:65:66:20:80:67:20:04:69:20:02:6a:21:f9:1f:6b:20:00. That looks suspiciously familiar; will try and decode that later. I suppose battery voltage and/or percentage is in there, as well as charging state. Battery should be exposed as a separate ZHABattery resoirce; we'll have to think of something to report the charging state.
Also captured an attribute report for 0xFCC0/0x00EE with u32 value of 3609 (0x00000e19). No clue what that means.
I haven't seen any traffic from the (client) Time cluster. I don't think the device supports on-device schedules, so I was wondering what that cluster is doing here.
The OTAU cluster seems functional, but without an actual firmware image we cannot know for sure.

ebaauw commented 2 years ago

Here's my understanding of the special attribute report:

                                            1                        2                        3                        4                         5
                     1 2  3  4 5  6 7  8 9  0 1  2 3  4 5  6 7  8  9 0  1  2 3  4 5 6 7  8 9  0 1 2 3  4 5  6  7 8  9  0 1  2  3 4  5  6 7  8  9 0  1 2  3 4  5
         attr tp  l    temp   RSSI dB              parent       ?       ?             ?             ?    lift       ?       ?       ?       ?         ?       ?
         ---- -- -- ------- --------- --------- --------- ------- ------- ------------- ------------- ------- ------- ------- ------- ------- --------- -------
         00f7 41 37 0328 19 0521 0800 0921 0001 0a21 0000 0b20 00 0c20 01 0d23 190e0000 1123 01000000 6420 00 6520 62 6620 80 6720 04 6920 02 6a21 f51f 6b20 00
e1:              55    25°C  u16       u16       u16        u8      u8     u32           u32            u8      u8      u8      u8      u8     u16        u8

It is already parsed by the REST API plugin, although not yet fully understood:

Dec 28 12:32:17 pi5 deCONZ[22342]: 12:32:16:344 APS-DATA.indication srcAddr: 0x4564, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0xFCC0, lqi: 255, rssi: -44 
Dec 28 12:32:17 pi5 deCONZ[22342]: 12:32:16:345         asdu: 1c5f11e00af700413703281905210800092100010a2100000b20000c20010d23190e00001123010000006420006520626620806720046920026a21f51f6b2000
Dec 28 12:32:17 pi5 deCONZ[22342]: 12:32:16:345 APS-DATA.indication from child 0x4564
Dec 28 12:32:17 pi5 deCONZ[22342]: 12:32:16:346 Node data 0x54ef44100033af31 profileId: 0x0104, clusterId: 0xFCC0
Dec 28 12:32:17 pi5 deCONZ[22342]: 12:32:16:348 0x54EF44100033AF31 extract Xiaomi special attribute 0x00F7
Dec 28 12:32:17 pi5 deCONZ[22342]: 12:32:16:348         03 Device temperature 25 °C
Dec 28 12:32:17 pi5 deCONZ[22342]: 12:32:16:349         05 RSSI dB (?) 8 (0x0008)
Dec 28 12:32:17 pi5 deCONZ[22342]: 12:32:16:349         09 unknown 256 (0x0100)
Dec 28 12:32:17 pi5 deCONZ[22342]: 12:32:16:350         0a Parent NWK 0 (0x0000)
Dec 28 12:32:17 pi5 deCONZ[22342]: 12:32:16:350         0b unknown 0 (0x00)
Dec 28 12:32:17 pi5 deCONZ[22342]: 12:32:16:351         0c unknown 1 (0x01)
Dec 28 12:32:17 pi5 deCONZ[22342]: 12:32:16:351         0d unknown 3609 (0x00000E19)
Dec 28 12:32:17 pi5 deCONZ[22342]: 12:32:16:352         11 unsupported tag (data type 0x23)
Dec 28 12:32:17 pi5 deCONZ[22342]: 12:32:16:352         64 lift 0 (100%)
Dec 28 12:32:17 pi5 deCONZ[22342]: 12:32:16:353         64 smoke/gas density 0 (0x00)
Dec 28 12:32:17 pi5 deCONZ[22342]: 12:32:16:353         65 unknown 98 (0x62) 
Dec 28 12:32:17 pi5 deCONZ[22342]: 12:32:16:353         66 unknown 128 (0x80) 
Dec 28 12:32:17 pi5 deCONZ[22342]: 12:32:16:354         67 unsupported tag (data type 0x20)
Dec 28 12:32:17 pi5 deCONZ[22342]: 12:32:16:354         69 unsupported tag (data type 0x20)
Dec 28 12:32:17 pi5 deCONZ[22342]: 12:32:16:355         6A unsupported tag (data type 0x21)
Dec 28 12:32:17 pi5 deCONZ[22342]: 12:32:16:355         6B unsupported tag (data type 0x20)

When providing power to the USB-C port, the device sends a report for 0xFCC0/0x0409 with u8 value 0x01. When disconnecting the power, or when charging has finished (as witnessed by the light turning off), it sends value 0x02. I think this corresponds to tag 69 in the special attribute report.

According to https://notenoughtech.com/home-automation/aqara-roller-shade-driver-e1-zigbee2mqtt/, the device contains a 7.4V 1000mAh battery. Typically Xiaomi reports battery voltage using tag 01 with a u16 value in mV. The only value that comes close would be tag 6A, suggesting 8.247V for a fully charged battery. Seems a bit high, but I'll monitor it for a couple of days. Good thing: you can force a special attribute report by briefly pressing the reset button.

ebaauw commented 2 years ago

Also captured an attribute report for 0xFCC0/0x00EE with u32 value of 3609 (0x00000e19). No clue what that means.

Which corresponds to tag 0d.

ebaauw commented 2 years ago

Now exposed as:

{
  "etag": "59623a4d756f6ef0be4838cce5cecf5f",
  "hascolor": false,
  "lastannounced": null,
  "lastseen": "2021-12-29T14:02Z",
  "manufacturername": "LUMI",
  "modelid": "lumi.curtain.acn002",
  "name": "Window covering device 18",
  "state": {
    "lift": 39,
    "open": true,
    "reachable": true
  },
  "swversion": "05-18-2021",
  "type": "Window covering device",
  "uniqueid": "54:ef:44:10:00:33:af:31-01"
}

and a separate ZHABattery:

{
  "config": {
    "on": true,
    "reachable": true,
    "temperature": 2000
  },
  "ep": 1,
  "etag": "fe80f76fef44e9d7e8778e55fc20d31a",
  "lastannounced": null,
  "lastseen": "2021-12-29T14:02Z",
  "manufacturername": "LUMI",
  "modelid": "lumi.curtain.acn002",
  "name": "Battery 34",
  "state": {
    "battery": 100,
    "charging": false,
    "lastupdated": "2021-12-29T14:02:33.289"
  },
  "swversion": "05-18-2021",
  "type": "ZHABattery",
  "uniqueid": "54:ef:44:10:00:33:af:31-01-fcc0"
}

Still todo: figure out battery voltage or percentage.

I ordered a Xiaomi hub, hoping to be able to sniff its interaction with the E1.

ebaauw commented 2 years ago

A bit late for Xmas, but got my Aqara M1 hub today. My sniffer is now working overtime ;-)

Aqara app uses Present Value on Multistate Output cluster to send commands:

On Stop it writes value 2 (which we already saw reported when the driver stopped moving;
On Rotate Up (step up), it writes value 6. On Rotate Down, it writes value 5. The driver response with a Write Attributes Response (obviously), followed by a Report Attributes of Multistate Output's Present Value with the value just written, followed by Report Attributes of Multistate Output's Present Value with value 2, followed by a _Report Attribute_s of Analog Output's Present Value with the new position.

This calls for write-only up and down commands (cf. stop). Or maybe lift_inc?

Changing the Curtain Type in the app doesn't do anything. This is veneer only in the app.

Setting Reverse direction writes bool attribute 0xFCC0/0x0400. Not much value to expose this over the API, as you would only set this on installation. Tag 66 changes value from 0x80 to 0xC0 when reversed is set. This also inverts the current position. Smells like a bitmap.

Setting positions:

On clearing the current position, it writes false to bool attribute 0xFCC0/0x0402;
On setting the highest position, it writes 1 to u8 attribute 0xFCC0/0x0407;
On setting the lowest position, it writes 2 to u8 attribute 0xFCC0/0x0407;

Again, you would only set these on installation, not much value exposing this over the API. Damn those heretics that don't run the GUI.

Adjusting the speed writes u8 attribute 0xFFC0/0x0408. 2 = High, 1 = Medium, 0 = Low. This doesn't seem to be reflected in the special attribute. Could make sense to expose over the API (e.g. slower = less sound at night), preferably through a config.speed, but /lights resources have no config object.

The app reports battery percentage and charging state. Battery now reports 99% after some playing around. Latest special attribute value is:

03:28:14:05:21:01:00:09:21:00:01:0a:21:00:00:0b:20:00:0c:20:01:0d:23:19:0e:00:00:11:23:01:00:00:00:64:20:64:65:20:63:66:20:80:67:20:09:69:20:02:6a:21:f5:1f:6b:20:00

During charging, it's, still 99%:

03:28:14:05:21:01:00:09:21:00:01:0a:21:00:00:0b:20:00:0c:20:01:0d:23:19:0e:00:00:11:23:01:00:00:00:64:20:64:65:20:63:66:20:80:67:20:09:69:20:01:6a:21:f5:1f:6b:20:00

As the charging light goes off, the app reports 100% and the driver sends:

03:28:14:05:21:01:00:09:21:00:01:0a:21:00:00:0b:20:00:0c:20:01:0d:23:19:0e:00:00:11:23:01:00:00:00:64:20:64:65:20:64:66:20:80:67:20:09:69:20:01:6a:21:7c:20:6b:20:00

This looks too good to be true, but it would seem tag 65 is the battery percentage! No voltage to percentage conversion needed. 6a also changes value - still thinking this might be the battery voltage, but with 65 reporting the percentage, we don't care.

ebaauw commented 2 years ago

And the device supports OTA firmware upgrades. The Aqara Home app is upgrading it from 0.0.0_1425 to 0.0.0_1427. Not sure where they got the firmware file from, or how the version is reported over Zigbee. EDIT The image version is 0x00000E1B, which corresponds to byte values [00, 00, 14, 27]. This matches tag 0d.

The hub sends image blocks of size 48, as requested by the driver.

ebaauw commented 2 years ago

Hm. looks like the new firmware no longer reacts to the Window Covering commands. It does send a Deafult Response with status Success, but nothing happens.

ebaauw commented 2 years ago

The GUI now shows the Lumi Specific cluster as:

This allows the follwoing actions from the GUI, not supported by the REST API:

To reverse the direction, write true to 0x0400
To set the upper and lower positions from the GUI:
- Write false to 0x0402;
- Move to the upper position;
- Write 1 to 0x0407;
- Move to the lower position;
- Write 2 to 0x0407.
To change the motor speed: write to 0x0408.

ebaauw commented 2 years ago

Some implementation specifics:

The Present Value attribute of the Analog Output cluster is used to report and set the position. Note that the API uses lift as percentage closed, whereas Present Value reports percentage open.

Value	Meaning	API
0	Fully Down (Closed)	`"lift": 100`
50	Half way	`"lift": 50`
100	Fully Up (Open)	`"lift": 0`

Note that the reported value for open is derived from lift; it's true when open != 100.

The Present Value attribute of the Multistate Output is used to report current movement (which the API ignores) and for special actions (most of which the API supports):

Value	Meaning	API
0	Move Down	`"open": false`
1	Move Up	`"open" : true`
2	Stop	`"stop": true` `"lift_inc: 0"`
3	Toggle	n/a
4	Unknown	n/a
5	Step Down	`"lift_inc": 1`
6	Step Up	`"lift_inc": -1`

Note that the driver will only report these attributes, after the upper and lower limits have been set. These settings do survive a leave/re-join (i.e. when deleting the node from deCONZ), but are cleared on factory reset (holding the reset button for >5 seconds).

ebaauw commented 2 years ago

Added alert and speed to the /lights resource:

{
  "etag": "fb1e47f362b32af731053500d0b29310",
  "hascolor": false,
  "lastannounced": null,
  "lastseen": "2021-12-30T15:42Z",
  "manufacturername": "LUMI",
  "modelid": "lumi.curtain.acn002",
  "name": "Window covering device 17",
  "state": {
    "alert": "none",
    "lift": 50,
    "open": true,
    "reachable": true,
    "speed": 0
  },
  "swversion": "11-24-2021",
  "type": "Window covering device",
  "uniqueid": "54:ef:44:10:00:33:aa:87-01"
}

alert accepts values "select" (to blink the driver led) and "none".

speed is linked to Speed (0x0408) on the Lumi specific cluster. It accepts values 0 (low), 1 (medium), and 2 (high). We should probably expose a speedmax, cf sensitivitymax, so clients don't have to whitelist the modelid.

dennisgranasen commented 2 years ago

And the device supports OTA firmware upgrades. The Aqara Home app is upgrading it from 0.0.0_1425 to 0.0.0_1427. Not sure where they got the firmware file from, or how the version is reported over Zigbee. EDIT The image version is 0x00000E1B, which corresponds to byte values [00, 00, 14, 27]. This matches tag 0d.

The hub sends image blocks of size 48, as requested by the driver.

Did you manage to download the 1427 firmware? I figure if I download it to deconz I can update the fw through its OTAU system. Anyway, I can't seem to find the file, but someone with the gateway should be able to sniff the url quite easily.

FWIW the old (1425) firmware is available on: https://cdn.aqara.com/cdn/opencloud-product/mainland/product-firmware/prd/lumi.curtain.acn002/20211018181955_OTA_lumi.curtain.acn002_0.0.0_1425_20210519_3B6D0A.ota

ebaauw commented 2 years ago

No, and didn’t even try, I’m afraid. I was focusing on the Zigbee traffic, and the upgrade started before I realised and could setup sniffing the Internet traffic.

L0rz commented 2 years ago

I added your General.xml and Reconnect the device and i don´t see the lumi specific cluster. it stil show as window covering device

Mimiix commented 2 years ago

@L0rz what's stick firmware your on? Make sure your on the latest. 267xx

skank01 commented 2 years ago

Doubting to get these as well. Are they stable now and worth buying? Still problems with it?

Mimiix commented 2 years ago

@skank01 this is not the place to ask for advice. That should go on discord or the forums.

L0rz commented 2 years ago

thx i have RaspBee II with 26720700. i will ask in discord.

ebaauw commented 2 years ago

I added your General.xml and Reconnect the device and i don´t see the lumi specific cluster.

The E1 no longer advertises this cluster with the latest firmware. It still carries the cluster, but it's missing from the Simple Descriptor. The GUI should show the cluster, as soon as it sees a message from it. However, you need to write an attribute on that cluster to get the device in the right mode, so it reports to the gateway. And the REST API plugin won't write the attribute, because it hasn't seen the cluster...

My PR has no resolution yet to this brilliant catch-22. As workaround, I manually patched the database, adding the cluster to the device fingerprint. After that, my PR exposes the E1 without any issues. Manu thinks the attribute can be written through a DDF, regardless of the Simple Descriptor. He's reviewing the PR, combining it with a skeleton DDF.

schwickster commented 2 years ago

@ebaauw Maybe a silly idea.. don't know if it's possible. But could you maybe downgrade using https://cdn.aqara.com/cdn/opencloud-product/mainland/product-firmware/prd/lumi.curtain.acn002/20211018181955_OTA_lumi.curtain.acn002_0.0.0_1425_20210519_3B6D0A.ota and than upgrade using the gateway? Than sniff the latest firmware url. That way more people can upgrade who don't have a gateway.

ebaauw commented 2 years ago

Don't know whether that file is corrupt, encrypted, or whether the E1 simply won't downgrade. The file looks structurally OK, but it doesn't work. The update starts, but jumps to over 95% almost immediately and finishes a couple of seconds later. Never seen this behaviour before. After that, the E1 still reports version 0x00000e1b.

schwickster commented 2 years ago

@ebaauw I'm in the process of buying the gateway myself to update the roller shades. Could you tell me how I can sniff the firmware URL from the gateway ones it sees an update? Are you using Wireshark or Fiddler?

ebaauw commented 2 years ago

I use the packet trace feature of my Fritz!Box (internet router) on the WAN interface, and WireShark to view the file. This worked for the Hue bridge, because the firmware files are downloaded over plain HTTP. I haven't tried this for the Aqara hub.

schwickster commented 2 years ago

Good news, I sniffed the download URL for 1427. It can be found here https://github.com/Koenkk/zigbee-OTA/pull/97/files

hastime commented 2 years ago

Hi all,

The work that has been done here is amazing and made for an excellent read!

I have been playing around with DDF file and have managed to get this device to respond in HA to a position slider (although slightly temperamental, and had it close using HA device GUI, the only problems I am having is that it is reporting state 'closed' whether open or closed and I don't seem to have the ability to open the blind from the UI only 'set position' if it's either fully open or fully closed (I assume this is because I haven't got the state reporting correct).

Has anyone managed to create a working DDF for this yet and if so any tips or a link to the json? ;)

... And if not do we have an update regarding its inclusion into a future release? I know that new device additions are paused whilst DDF is being worked on so I know it could be a while.

Also I have only so far found a couple of resources which explain parts of DDF setup and creation and one short video, does anyone know of any good resources?

Thanks for everyone's input!

Kind regards

pponce commented 2 years ago

This is all amazing work! I ordered 6 of these and 2 just arrived. So far I've gotten it recognized in deconz. I can set reverse and upper and lower positions. In deconz-gui it's still showing up with a name "dimmable light XX" and not as "window covering XX". I'm running the latest stable firmware for ConBee II and am running the latest beta of deconz. 2.15.00.

Everything works well in Homekit when exposed via Homebridge-hue. It's recognized as a window covering and works perfectly. So this is not a big issue just calling out it's still discovered and shows up named "dimmable light xx".

santaklon commented 2 years ago

Hey everybody, thanks for bringing these devices to Deconz! I ordered 6 of them thinking i would now be able to integrate them into my Deconz/Nodered-Setup. However after trying for days i cant figured it out how:

With the v2.15.0-beta the Roller shades are still displayed as Dimmable Lights in de Phoscon GUI, but in Deconz they show up as "Window Covering devices" and are also exposed accordingly to NodeRed. All good so far. However no matter what command I try sending from NodeRed i get an error. Has anyone managed to activate these from within NodeRed? I suppose one would have to send a JASON command, since there is no native open/close or up/down command exposed by Phoscon?

I have read around the 2.15 documentation for the roller shutters but i'm not knowledgabel enought to fabricate my own JASON-code out of that is written there.

I tried injecting {"state": "on"} and {"state": "open"} into the device node, but NodeRed gives me the debug-message "deconz-out ERROR: parameter, state, not available"

Any ideas anyone?

EDIT: Solved it at last. Here is the NR-Snipplet

[{"id":"b6302fe7.c8ec7","type":"deconz-output","z":"822afcf4.d37ac","name":"","server":"5df02e6e.9abef","device":"54:ef:44:10:00:32:9e:1f-01","device_name":"shade_bedroom : Window covering device","command":"json","commandType":"object","payload":"payload","payloadType":"msg","transitionTime":"","x":1590,"y":260,"wires":[]},{"id":"994adead.38984","type":"inject","z":"822afcf4.d37ac","name":"","props":[{"p":"payload"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"{\"open\": false}","payloadType":"json","x":1250,"y":280,"wires":[["b6302fe7.c8ec7"]]},{"id":"138a33b6.fa25cc","type":"inject","z":"822afcf4.d37ac","name":"","props":[{"p":"payload"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"{\"open\": true}","payloadType":"json","x":1250,"y":220,"wires":[["b6302fe7.c8ec7"]]},{"id":"5df02e6e.9abef","type":"deconz-server","name":"Raspbee","ip":"192.168.2.75","port":"80","apikey":"5B6EFDA413","ws_port":"443","secure":false,"polling":"15"}]

kvanisterdael commented 2 years ago

Hi, same here: I have beta 2.15.02 but my E1 roller shade still appears as a dimmable light. I can control it via the REST API by acting on the lift state without issue, so that works fine.

I had another question: is it possible to make the engine stop moving at the current position? For example: I send "open": true and after 5 seconds, I want to stop at that position. Is there a command for this? Via deCONZ it's possible to send the STOP command: is this also possible via the REST api?

enkama commented 2 years ago

Any Update on this?

enkama commented 2 years ago

Ah. Using it with Home-Assistant. Add it via Phoscon Gui. Then its added as a dimmable light in Home-Assistant. After restarting Home-Assistant it's recognized as a cover!

EloB commented 1 year ago

Anyone have a problem that they lose connection after awhile? I can pair them and they work but after some hours they stop working and then I need to make a new repair.

pponce commented 8 months ago

I have 6 of these and all have rock solid connections. Have not had any connection issues.

dresden-elektronik / deconz-rest-plugin