Ubisys J1 DDF: "lift" / "bri" after a power cycle

DDF-Library
1

Quoting from https://www.ubisys.de/wp-content/uploads/ubisys-j1-technical-reference.pdf (page 7):

Notice: When the device is power-cycled, it does not have knowledge of the shutter’s current position.
It has to reach the top or bottom limit once after a power-cycle to learn the current position; then it is
able to maintain positioning using ubisys’ unique WaveStep™ technology. For safety reasons the
device will not start moving after a power-cycle in order to seek the top or bottom position. Instead, it
will wait for any command that instigates motion, and if necessary, will try to find the upper bound as a
reference point first, before moving to the requested target position.

After a power cycle of the J1 the Current Position - Lift is set to 65535 (max 16 bit int).

image
image402×561 18.9 KB

The old bri reporting reports 648 via REST API. But “lift” is just “0”:

{
  "config": {
    "groups": [
      "0"
    ]
  },
  "etag": "8692c7d1f70af1e8c13253dc54b3a4ca",
  "hascolor": false,
  "lastannounced": null,
  "lastseen": "2023-10-09T08:26Z",
  "manufacturername": "ubisys",
  "modelid": "J1 (5502)",
  "name": "Markise",
  "state": {
    "bri": 648,
    "lift": 0,
    "on": false,
    "open": true,
    "reachable": true,
    "tilt": 0
  },
  "swversion": "2.3.0",
  "type": "Window covering device",
  "uniqueid": "00:1f:ee:00:00:00:51:4a-01"
}

I use(d) the "bri": 648 to detect ther was a power outtage of the device and do a manual close/open to get the correct state. bri is deprecated so I guess it will be removed someday. Is is possible to add a special value to lift when Current Position - Lift is set to 65535? Maybe just something like -1.

2

Have to say it took me a while to comprehend where that bri value came from due to the fact, that it is larger than 256 and the value you stated above.

As a matter of fact, current position lift percentage is the value which is taken and then the math is making sense ((255 * 254) / 100 = 648). Based on that, I assume the uncalibrated value is 0xff. Maybe you could modify the DDF regarding bri or lift calculation as to your liking?

3

I guess I could do so. But I prefer to have “stock” DDF to get the latest and greatest updates to it. IMHO it would make sense to add this to the stock DDF. Maybe its even possible to add “uncalibrated” as special value? Just something so other systems can detect that. AFAIK homekit can set devices to “Störung”. Maybe thats something that could be added to homekit-deconz…

4

Well, we could make it stock, as this is apparently an edge case which got forgotten. Get me something that works and then I can double check over here.

However, by definition, only positive integers up to 255 are allowed and valid values. So, I’d probably already go for the 255 then.

5

Hm, wanted to give it a try today, but some inadequate value restrictions within deconz requiring a code change prohibits usage/testing on state/lift. Took me a while to find out why this doesn’t work at all.

EDIT
Finally managed to fiddle it together. Indeed a too tight max value. Amending it gives the desired result

grafik

1 Like