ubisys J1 returns pct = 0 since update to version v2.15.1-beta

[Rolf56]

Describe the bug

ubisys J1 returns pct = 0 when covering device is not fully open and pct = 100 when covering device is open. There is no other value between returned. The only value returning is "bri". This happens since update to version v2.15.1-beta. When sending a pct value to the covering device, it moves to the right position.

Steps to reproduce the behavior

The problem occures all the time, also on a second device installed.

Expected behavior

Screenshots

In Postman there is an attribut 'lift' what coresponds with 'Current Position Lift Percentage' (pct) in the cluster info!

Environment

• Host system: PC
• Running method: Windows
• Firmware version: 26400500
• deCONZ version: 2.15.01
• Device: ConBee I
• Do you use an USB extension cable: no
• Is there any other USB or serial devices connected to the host system? If so: Which? non

deCONZ Logs

Additional context

[SwoopX]

This is not a bug and has nothing to do with deconz. Rubbing my crystal ball, your device has lost position awareness either by a power loss or by rebooting itself for whatever reason (see ubisys technical reference).

When cover is opened, move it down and then immediately up, that should restore it.

[Rolf56]

Hi SwoopX Thank you for your answer. I do not agree with you. The value 'Current Position Lift Percentage', what I think is the pct value, corresponds with the cover position in deCONZ UI.

But the pct value is missing in the REST interface! It is also not defined in the file j1_5502.json! The DDF for J1 was changed in version v2.15.1-beta and exact since then it does not work anymore correctly!

Yes, I moved the cover down and up, also in configuration mode. This changed nothing. Maybee you can rubbing your crystal ball again, to find out what happen with this release v2.15.1-beta https://github.com/dresden-elektronik/deconz-rest-plugin/pull/5894

[SwoopX]

Well, apparently, rubbing the crystal ball is not such a good fortune teller after all, q.e.d.

Now back to the topic and allow me to set your expectations right.

But the pct value is missing in the REST interface! It is also not defined in the file j1_5502.json!

Deconz does not expose a pct parameter and never has, however, your perception of Current position lift percentage is correct, but it maps to lift (raw value) and bri (with a calculation behind it). Now I know the HUE device perl module never picked up the lift values (at least not with the version I checked last time about 9 months ago), but is doing some magic on bri to deduce the pct value you mean. Will have a look if the bri calculation remained identical while purging it from the code (and moving it to the DDF).

In Phoscon, when you go to Help -> API Information, then select lights and choose your cover and finally click on events, you see what deconz sends towards FHEM.

That's what my cover sends over:

{
    "10:27:37:779": {
        "e": "changed",
        "id": "12",
        "r": "lights",
        "state": {
            "bri": 13,
            "lift": 5
        },
        "t": "event",
        "uniqueid": "00:1f:ee:00:00:xx:xx:xx-01"
    },
    "10:27:39:311": {
        "e": "changed",
        "id": "12",
        "r": "lights",
        "state": {
            "bri": 20,
            "lift": 8
        },
        "t": "event",
        "uniqueid": "00:1f:ee:00:00:xx:xx:xx-01"
    },
    "10:27:40:307": {
        "e": "changed",
        "id": "12",
        "r": "lights",
        "state": {
            "bri": 0,
            "lift": 0
        },
        "t": "event",
        "uniqueid": "00:1f:ee:00:00:xx:xx:xx-01"
    },
    "10:27:42:990": {
        "e": "changed",
        "id": "12",
        "r": "lights",
        "state": {
            "bri": 13,
            "lift": 5
        },
        "t": "event",
        "uniqueid": "00:1f:ee:00:00:xx:xx:xx-01"
    },
    "10:27:44:43": {
        "e": "changed",
        "id": "12",
        "r": "lights",
        "state": {
            "bri": 28,
            "lift": 11
        },
        "t": "event",
        "uniqueid": "00:1f:ee:00:00:xx:xx:xx-01"
    },
    "10:27:45:197": {
        "e": "changed",
        "id": "12",
        "r": "lights",
        "state": {
            "bri": 43,
            "lift": 17
        },
        "t": "event",
        "uniqueid": "00:1f:ee:00:00:xx:xx:xx-01"
    },
    "10:27:46:66": {
        "e": "changed",
        "id": "12",
        "r": "lights",
        "state": {
            "bri": 58,
            "lift": 23
        },
        "t": "event",
        "uniqueid": "00:1f:ee:00:00:xx:xx:xx-01"
    },
    "10:27:47:596": {
        "e": "changed",
        "id": "12",
        "r": "lights",
        "state": {
            "bri": 71,
            "lift": 28
        },
        "t": "event",
        "uniqueid": "00:1f:ee:00:00:xx:xx:xx-01"
    },
    "10:28:01:839": {
        "attr": {
            "lastseen": "2022-05-07T08:27Z"
        },
        "e": "changed",
        "id": "12",
        "r": "lights",
        "t": "event",
        "uniqueid": "00:1f:ee:00:00:xx:xx:xx-01"
    }
}

And FHEM updates fine:

Now, to be fair, I'm using a completely self written perl module here which is tailored just for deconz' REST API, only processing lift for cover position (while mapping it to pct for legacy reasons). A bit like comparing apples and pears. Regardless, I'll double check the bri calculation.

[SwoopX]

I assume the subtype in the attributes is (still) blind?

From a code perspective, I cannot see any difference (DDF left, legacy code right)

[Rolf56]

Hi SwoopX

Thank you for your Information. Too bad that pct isn't work anymore. In this case I have to change my conditions from pct to bri.

Regards, Rolf

[Mimiix]

Hi there, Can you please translate to English? Thanks :)!