New device support request - SR-ZG9080A

[cgiraldo]

SR-ZG9080A is a window cover control by Sunricher.

2432 Added support for this device, but with the incorrect open/close logic:

Current deCONZ API integration set state.bri 0 when fully closed, AND state.bri is 254 when fully open.

Level Cluster attributes when fully closed: Level Cluster attributes when fully open:

[Smanar]

Hello, Have you tried with the last version > 76 ? Or have you this problem since the new version > 76 ?

The good result is

    In fact you can close the shutter with :

        bri = 255
        on = true
        open = false

[SwoopX]

@Smanar with the version he's currently running, it doesn't seem to work as no sensor has been created yet. The device name has still it's NWK.

[cgiraldo]

I was trying with version 75. I installed last version (77) and the result is the same. with

bri = 255
on = true
open = false

The shutter opens.

[cgiraldo]

I have modify open/close logic of SR-ZG9080A.

Now to close the shutter:

bri = 255
on = true
open = false

To open the shutter:

on = false

[SHxKM]

@cgiraldo is it working for you? What is your experience with this integration?

[cgiraldo]

I test a unit with deconz plugin in home-assistant. The open/close/stop orders worked, however the given position was not correct.

I will install four units in my home next week and I am going to perform more detailled tests.

[SHxKM]

I test a unit with deconz plugin in home-assistant. The open/close/stop orders worked, however the given position was not correct.

I will install four units in my home next week and I am going to perform more detailled tests.

Thanks. Please keep me/us posted!

[cgiraldo]

Hi, I have make some tests. Open {"on":false}, Close {"on":true} and stop {"on": true,"bri_inc": 0} shutter is working. Manually set position also works: for example, to have the shutter nearly close: { "on": true, "bri": 240} or nealy open: {"on":true, "bri": 10}

However the state of the shutter is not correct, for example, after setting {"bri": 40}, the state is:

 "state": {
        "bri": 215,
        "lift": 0,
        "on": false,
        "open": false,
        "reachable": true
    },

I will try to modify deconz code to swipe the state value, but some help is appreciated since I don't have too much experience with deconz source code.

[cgiraldo]

Update.

I have check that the problem was with the wiring. The current integration is ok.

I use it with home-assistant (HA) and the deconz integration. However I had a problem with the curtain position in HA, It is always 100. After manually reading the Window Covering Cluster Attributes in Deconz App, It seems to be solved.

I have another problem with these devices, but I think maybe is related with its firmware or hardware. Several times, when I press the physical button or give the order in HA to open (or close the curtain), the curtain starts moving but stops before arriving to the end position. Sometimes I have to press multiple times to reach the end.

I calibrate the device but does not seem to solve the problem.

[dimitripb]

It's an old topic but I have the same problem. In Home Assistant I can open the curtain, close the curtain and set the curtain to a specified position but HA does not know the current position. What did you mean by "After manually reading the Window Covering Cluster Attributes in Deconz App, It seems to be solved"? I can find the position in the Deconz app but how to get this value in Home Assistant? Does the rest API not support it? Can HA only send a desired position to Deconz but cannot read it from Deconz?

[Smanar]

After manually reading the Window Covering Cluster Attributes in Deconz App, It seems to be solved

On deconz

• select the covering cluster 0x0102
• it open the cluster panel
• click on the "read" button
• it will update the attribute list

I can find the position in the Deconz app but how to get this value in Home Assistant? Does the rest API not support it? Can HA only send a desired position to Deconz but cannot read it from Deconz?

Lol, lot of question but to resume, if you can set a specified position, you need to have it too in the API so in HA, else its an issue.

You can check direclty the API in phoscon / help / API information / light then your device ID, look at the "state/lift" value. For me it 's a bind/report issue, can be solved by a new inclusion (no need to delete the previous one, just re-include)

[dimitripb]

Thanks for your answer. I made a mistake. I cannot set the cover to a specific position in HA. I set up everything half a year ago and did not remember it right. I do now understand the whole thing. You have to read the lift value manually in Deconz and then it will be read correctly in Phoscon. But how to make this usable? I don't want to open Deconz every time to read manually the lift value first.

[Smanar]

I cannot set the cover to a specific position in HA

But it work using deconz direclty ?

But how to make this usable?

For me it s a binding issue, but I have another issue almost like you https://github.com/dresden-elektronik/deconz-rest-plugin/issues/6283

As this device have too the 2 clusters set, if you can share to me the DDF created for your device I can edit it to try something.

[dimitripb]

Yes, within Deconz it's working. I am using the Deconz add on in Home Assistant so cannot reach the DDF files easily. I have to configure the debug possibilities in HA first. I am leaving for a holiday now so I will post the DDF in about 10 days. Thanks for your help!

[Smanar]

Sure, else can try this DDF

{
  "schema": "devcap1.schema.json",
  "manufacturername": "Sunricher",
  "modelid": "Motor Controller",
  "product": "SR-ZG9080A",
  "sleeper": false,
  "status": "Gold",
  "subdevices": [
    {
      "type": "$TYPE_WINDOW_COVERING_DEVICE",
      "restapi": "/lights",
      "uuid": [
        "$address.ext",
        "0x01"
      ],
      "items": [
        {
          "name": "attr/id"
        },
        {
          "name": "attr/lastannounced"
        },
        {
          "name": "attr/lastseen"
        },
        {
          "name": "attr/manufacturername"
        },
        {
          "name": "attr/modelid"
        },
        {
          "name": "attr/name"
        },
        {
          "name": "attr/swversion"
        },
        {
          "name": "attr/type"
        },
        {
          "name": "attr/uniqueid"
        },
        {
          "name": "state/lift"
        },
        {
          "name": "state/open"
        },
        {
          "name": "state/reachable"
        }
      ]
    }
  ],
  "bindings": [
    {
      "bind": "unicast",
      "src.ep": 1,
      "dst.ep": 1,
      "cl": "0x0102",
      "report": [
        {
          "at": "0x0008",
          "dt": "0x20",
          "min": 1,
          "max": 300,
          "change": "0x00000001"
        }
      ]
    }
  ]
}

But this one is not working yet on the other issue (no idea why )

[dimitripb]

I am back. This is my current config: GNU nano 3.2 h2l-zbph-rs.json

GNU nano 3.2 h2l-zbph-rs.json

{
  "schema": "devcap1.schema.json",
  "manufacturername": "$MF_PHILIPS",
  "modelid": "H2L-ZBPH-RS",
  "product": "H2L-ZBPH-RS",
  "sleeper": false,
  "status": "Draft",
  "path": "/devices/h2l-zbph-rs.json",
  "subdevices": [
    {
      "type": "$TYPE_DIMMABLE_LIGHT",
      "restapi": "/lights",
      "uuid": [
        "$address.ext",
        "0x01"
      ],
      "items": [
        {
          "name": "attr/id"
        },
        {
          "name": "attr/lastannounced"
        },
        {
          "name": "attr/lastseen"
        },
        {
          "name": "attr/manufacturername"
        },
        {
          "name": "attr/modelid"
        },
        {
          "name": "attr/name"
        },
        {
          "name": "attr/swversion"
        },
        {
          "name": "attr/type"
        },
        {
          "name": "attr/uniqueid"
        },
        {
          "name": "state/bri",
          "description": "The current brightness.",
          "refresh.interval": 5
        },
        {
          "name": "state/lift",
          "description": "The lift state of a roller blind.",
          "refresh.interval": 300,
          "default": 0
        },
        {
          "name": "state/on",
          "description": "True when device is on; false when off.",
          "refresh.interval": 5
        },
        {
          "name": "state/open",
          "description": "True when open is detected."
        },
        {
          "name": "state/reachable"
        }
      ]
    }
  ]
}

[dimitripb]

@Smanar I tried to add the bindings from your file to my file (mine is a Philips but the device is the same). I put it in: /data/.local/share/dresden-elektronik/deCONZ/devices Then I opened it in DDF-editor and clicked Hot Reload. When I open the DDF-editor again the device seems not to be using the edited file. Am I missing something?

[dimitripb]

Now the DDF-file is working. The device is using is (I don't know what changed...), but the cover position is still not working. I still have to press "read" manually to read the cover position. I am using this DDF now:

{
  "schema": "devcap1.schema.json",
  "manufacturername": "$MF_PHILIPS",
  "modelid": "H2L-ZBPH-RS",
  "product": "H2L-ZBPH-RS",
  "sleeper": false,
  "status": "Gold",
  "path": "/devices/h2l-zbph-rs.json",
  "subdevices": [
    {
      "type": "$TYPE_WINDOW_COVERING_DEVICE",
      "restapi": "/lights",
      "uuid": [
        "$address.ext",
        "0x01"
      ],
      "items": [
        {
          "name": "attr/id"
        },
        {
          "name": "attr/lastannounced"
        },
        {
          "name": "attr/lastseen"
        },
        {
          "name": "attr/manufacturername"
        },
        {
          "name": "attr/modelid"
        },
        {
          "name": "attr/name"
        },
        {
          "name": "attr/swversion"
        },
        {
          "name": "attr/type"
        },
        {
          "name": "attr/uniqueid"
        },
        {
          "name": "state/bri",
          "description": "The current brightness.",
          "refresh.interval": 5
        },
        {
          "name": "state/lift",
          "description": "The lift state of a roller blind.",
          "refresh.interval": 300,
          "default": 0
        },
        {
          "name": "state/on",
          "description": "True when device is on; false when off.",
          "refresh.interval": 5
        },
        {
          "name": "state/open",
          "description": "True when open is detected."
        },
        {
          "name": "state/reachable"
        }
      ]
    }
  ],
  "bindings": [
    {
      "bind": "unicast",
      "src.ep": 1,
      "dst.ep": 1,
      "cl": "0x0102",
      "report": [
        {
          "at": "0x0008",
          "dt": "0x20",
          "min": 1,
          "max": 300,
          "change": "0x00000001"
        }
      ]
    }
  ]
}

[Smanar]

You can remove the state/on and state/bri part, not usefull for covering. And the binding see fine for me. Can try to make a poll (test for 60s)

               {
                    "name": "state/lift",
                    "parse": {"cl": "0x0102", "at": "0x0008", "eval": "Item.val = Attr.val"},
                    "read": {"cl": "0x0102", "at": "0x0008"},
                    "refresh.interval": 60
                },
                {
                  "name": "state/open",
                  "parse": {"cl": "0x0102", "at": "0x0008", "eval": "Item.val = Attr.val < 100"},
                  "refresh.interval": 60
                },

But I have a doubt, perhaps the device don't use the covering cluster but the on/off and setlevel one, I don't found your device on other zigbee project.

Do you know how to make bind manualy using deconz ?

[dimitripb]

My device does use the covering cluster 0102. In Deconz I can use that cluster to go to the right position and read the current position. I read about creating bindings in Deconz. You have to drag a cluster to the bindings windows but that's not possible with the VNC view of Deconz in the add on. Now the DDF looks like this but it is not opening. Something should be wrong. Is "type": "$TYPE_WINDOW_COVERING_DEVICE" important? In the original DDF it's $TYPE_DIMMABLE_LIGHT

{
  "schema": "devcap1.schema.json",
  "manufacturername": "$MF_PHILIPS",
  "modelid": "H2L-ZBPH-RS",
  "product": "H2L-ZBPH-RS",
  "sleeper": false,
  "status": "Gold",
  "path": "/devices/h2l-zbph-rs.json",
  "subdevices": [
    {
      "type": "$TYPE_WINDOW_COVERING_DEVICE",
      "restapi": "/lights",
      "uuid": [
        "$address.ext",
        "0x01"
      ],
      "items": [
        {
          "name": "attr/id"
        },
        {
          "name": "attr/lastannounced"
        },
        {
          "name": "attr/lastseen"
        },
        {
          "name": "attr/manufacturername"
        },
        {
          "name": "attr/modelid"
        },
        {
          "name": "attr/name"
        },
        {
          "name": "attr/swversion"
        },
        {
          "name": "attr/type"
        },
        {
          "name": "attr/uniqueid"
        },
        {
          "name": "state/reachable"
        }
        {
          "name": "state/lift",
          "parse": {"cl": "0x0102", "at": "0x0008", "eval": "Item.val = Attr.val"},
          "read": {"cl": "0x0102", "at": "0x0008"},
          "refresh.interval": 60
        },
        {
          "name": "state/open",
          "parse": {"cl": "0x0102", "at": "0x0008", "eval": "Item.val = Attr.val < 100"},
          "refresh.interval": 60
        },
      ]
    }
  ],
  "bindings": [
    {
      "bind": "unicast",
      "src.ep": 1,
      "dst.ep": 1,
      "cl": "0x0102",
      "report": [
        {
          "at": "0x0008",
          "dt": "0x20",
          "min": 1,
          "max": 300,
          "change": "0x00000001"
        }
      ]
    }
  ]
}

[dimitripb]

Here is cluster 0102:

[dimitripb]

It's working! Thanks for your help! In the binding I used 0x0003 instead of 0x0008 (position instead of percentage). In HA I see a cover WITH position slider now! Finally! I wonder why the device won't be configured like this during installation. Al lot of people won't get it to work I think.

[Smanar]

In the binding I used 0x0003 instead of 0x0008

Haaa, nice to know, not something usual, I can't see on your capture, but the attribute 0x0008 is enabled or not ? And yes the type is important for third app can reconize the device.

If all is working can you make a PR with the final one ? https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/How-to-create-a-pull-request-to-submit-a-new-Device-Description-File

Else share the final DDF for I make it.

[dimitripb]

Yes 0x0008 is enabled too. I will do some more tests. This is new matter for me so maybe I did something coincidentally. It could be possible that only changing the type did already the job. 0x0008 is updating too now although I only configured 0x0003 in the bindings. When I have solid DDF I wil create a pull request.

Can you explain this to me: "eval": "Item.val = Attr.val < 100" ? Is the < 100 meant as a condition to use the value as a percentage? 0x0003 has a maximum value of 452. Should I use "eval": "Item.val = Attr.val < 452" then?

[Smanar]

Ha yes, probably need to edit the "eval" too But ATM

        {
          "name": "state/lift",
          "parse": {"cl": "0x0102", "at": "0x0008", "eval": "Item.val = Attr.val"},
          "read": {"cl": "0x0102", "at": "0x0008"},
          "refresh.interval": 60
        },
        {
          "name": "state/open",
          "parse": {"cl": "0x0102", "at": "0x0008", "eval": "Item.val = Attr.val < 100"},
          "refresh.interval": 60
        },

Value are looking for attribute 0x0008, so you are using 0x0003 ATM ? I m trying to understand of it work

Note57: "M" designates that the related attributes are required to be mandatory only if Closed Loop control is enabled and Lift/Tilt actions are correspondingly supported, i.e. the CurrentPositionLiftPercentage attribute SHALL be mandatory only if Closed Loop control and Lift actions are supported; and the CurrentPositionTiltPercentage attribute SHALL be mandatory only if Closed Loop control and Tilt actions are supported.

Ok, I have give up ^^, But I m affraid the attribute 0x0003 is covering dependant, no reason to have 452 as max value.

And yes need to use "eval": "Item.val = Attr.val < 452" but I think you can have less than 452 on another covering.

But if 0x0008 is working again, better to use this one, a percent is more stable.

[dimitripb]

I have set it back to percentage. That's working correctly. There is only one problem left. In Home Assistant open and close are reverted. The wiring is correct, because within Deconz everything is alright. In Home Assistant a value of 0% (when totally open) is showed but in Deconz the value is 100% when totally open. I don't know whether the firmware in the controller is wrong or the DDF needs to be edited for this or I need to invert the value in HA.

[Smanar]

If only the return is reversed, and if you are using a DDF, it easy to correct. For exemple

        {
          "name": "state/lift",
          "parse": {"cl": "0x0102", "at": "0x0008", "eval": "Item.val = Attr.val"},
          "read": {"cl": "0x0102", "at": "0x0008"},
          "refresh.interval": 60
        },

replaced by

        {
          "name": "state/lift",
          "parse": {"cl": "0x0102", "at": "0x0008", "eval": "Item.val = 100- Attr.val"},
          "read": {"cl": "0x0102", "at": "0x0008"},
          "refresh.interval": 60
        },

[dimitripb]

Yes, I already tried that and it’s working, but the another problem occurs. The “Goto lift percentage” function should also be inverted, actually the received value from the rest-API should be inverted. I tried to solve this myself. Without success… Can you please help me once more? Thank you in advance!

[Smanar]

Ha, you need too reverse the value in the "send request" ? This is not possible ATM, I have started a code to add this feature in the "DDF" but I can't found tester.

Else it's possible with adding 2 lines in the c++ code, but need to recompile too to test.

Edit: There is too a zigbee request to reverse a device, you can see it in deconz on the covering cluster, but generaly it reverse only the return, not the action.

[dimitripb]

I read about it in the DDF documentation: Command. But it was not implemented yet. To let it work correctly inverting the action is necessary. According the device 100% is open and 0% is closed. If you invert it 100% is closed and 0% is open. When I close it for 10% (eg. from HA) the device needs to receive a value of 90, otherwise it will close for 90%. The percentages are absolute positions and not differences. I created two pull requests (one for the Philips and one for the Sunricher; they are the same devices) and left out the inversion. This device is known to have an uncommon percentage value for open and closed. So it's better to leave it that way for now. I will fix the inversion within HA.

If I can test something, please let me know, but this stuff is quite beyond my knowledge. I have learned a lot from your posts anyway. Thanks!

[Smanar]

As you want, there is a hudge code to test to see if my code to add the "reverse" is working with DDF, or can just make a fast edition in deconz to reverse the device, but not sure the second solution will be valided my manup.

Both modifications need to recompile the code, and it's not something easy on HA OS.