Ubisys J1 Calibration

deCONZ Bug reports
1

Hello,

I have a awning running with an Ubisys J1. I installed it in 2020 and calibrated it like described here: Add ubisys J1 calibration and switch configuration. by ma-ca · Pull Request #813 · dresden-elektronik/deconz-rest-plugin · GitHub. Works great since then.

Now I installed a new shader with a new Ubisys J1. I just wanted to calibrate it but the call does not work anymore:

$ curl -XPUT http://[...]/sensors/71 --data '{"windowcoveringtype" : 0}'
[{"error":{"address":"/sensors/71/windowcoveringtype","description":"parameter, windowcoveringtype, not available","type":6}}]%

It looks like the windowcoveringtype moved to config. So I tried

$ curl -XPUT http://[...]/sensors/71 --data '{ "config": {"windowcoveringtype" : 0} }'
[{"success":{"/sensors/71/config/windowcoveringtype":0}}]%

and the calibration started. It moved down a little bit, up and down til the end. But it looks like its not really calibrated.

This is my sensor:

{
  "config": {
    "group": "20001",
    "mode": "momentary",
    "on": true,
    "reachable": true,
    "windowcoveringtype": 0
  },
  "ep": 2,
  "etag": "60abe4984746c88f55a9c11831be3323",
  "lastannounced": null,
  "lastseen": "2023-03-15T08:28Z",
  "manufacturername": "ubisys",
  "mode": 1,
  "modelid": "J1 (5502)",
  "name": "Rolloschalter Wohnzimmer",
  "state": {
    "buttonevent": 2002,
    "lastupdated": "2023-03-15T08:21:19.490"
  },
  "type": "ZHASwitch",
  "uniqueid": "00:1f:ee:00:00:00:53:33-02-0102"
}

This is my “Light”

{
  "config": {
    "groups": []
  },
  "etag": "79f5fb7faea237f10a04268ac3e78379",
  "hascolor": false,
  "lastannounced": null,
  "lastseen": "2023-03-15T08:32Z",
  "manufacturername": "ubisys",
  "modelid": "J1 (5502)",
  "name": "Rollo Wohnzimmer",
  "state": {
    "bri": 648,
    "lift": 0,
    "on": false,
    "open": true,
    "reachable": true,
    "tilt": 0
  },
  "swversion": null,
  "type": "Window covering device",
  "uniqueid": "00:1f:ee:00:00:00:53:33-01"
}
2

I can’t get it to work.

Is there a way to confirm calibration was successful?

3

I tried to run the calibration steps on my own - but the clusters I have to write are read-only.

J1
J1889×665 108 KB

4

I just noticed this. Why is “Tuya Window Covering Setting” here? Is this correct…?

TUYA
TUYA533×780 44.2 KB

when I try to read the 3:

unsupported
unsupported402×562 21.6 KB

5

there are differences between the old awning and the new shader:

J1
J1430×739 84.3 KB

Bug in deCONZ?

6

I’m afraid you totally lost me on this one and you’re seeing “bugs” where there are none.

Is the device now working or not?

7

I have 2 devices. Awning and Shutter. The Awning was installed 2020, calibrated via POST request und works perfect since then. The shutter is new.

The device is working uncalibrated. So I dont have the state. But I can move up and down til the motos stops.

Calibration via POST (curl -XPUT […]/sensors/74/config --data ‘{“windowcoveringtype” : 2}’) starts but does not really follow the steps it should (it drived up, drives down a little bit, drives up again and nothing else). So after the POST calibration its like it was not calibrated at all.

I can start the calibration manually but either the “move down” or “move up” step do not finish (ends before the motor stops). After the manual calibration I have a state but its not correct. It’s a little bit erratic where is 0 % and where is 100 % - but i cant really open or close it.

According to https://www.ubisys.de/wp-content/uploads/ubisys-j1-technical-reference.pdf:

When calibration is complete attributes 0x10F2:0x1002 and 0x10F2:0x1004 are different from 0xFFFF
and hold the times that J1 has measured for your physical setup consisting of motor and blind. The
values can be close together (typically lift & tilt blinds match closely) or have significant differences
(down-to-up takes e.g. 100% longer than up-to-down due to gravity). Instead of auto-calibration you
can also write the values directly if you know them.

but I dont have the 1xxx clusters - see my screesnhots. They’re not visible at the Awning (which works fine), too. So this might be a bug in deCONZ (missing clusters?) - but I can see TUYA Clusters but when I try to read them they’re “unsupported”.

8

I have contact with a Ubisys employee. He said manufacture specific attributes need to be written.
I’ll look which attributes specifically. The technical-refrence.pdf is very detailed.
Perhaps they are not in the general.xml file. So they wouldn’t be in deCONZ.

Could also be the WindowCoveringType Attribute should be writeable. Then it would also be a bug in the general.xml

9

@jan666 I think you have to use the FC00 Cluster. Could you please share a Screenshot of that Cluster and Attributes.

10

FC00
FC00588×1336 83.4 KB

11

The J1 auto-calibrates just fine here :man_shrugging:

12

Can you see / write the clusters 0x10F2:0x1002 and 0x10F2:0x1004?

13

I have just seen in the webplugin c++ code and it is all there. the calibration and the attributes tha need to be written. Don’t know why it should not work anymore. I have never used this device. So i can’t say how the calibration should look like when it is finished.

In the deCONZ GUI the manufacturer specific attributes aren’t shown.
But the could be added to the GUI by editing the general.xml file.

14

According to https://www.ubisys.de/wp-content/uploads/ubisys-j1-technical-reference.pdf:

When calibration is complete attributes 0x10F2:0x1002 and 0x10F2:0x1004 are different from 0xFFFF
and hold the times that J1 has measured for your physical setup consisting of motor and blind. The
values can be close together (typically lift & tilt blinds match closely) or have significant differences
(down-to-up takes e.g. 100% longer than up-to-down due to gravity). Instead of auto-calibration you
can also write the values directly if you know them.

I could confirm this with my awning because thats calibrated. But the clusters aren’t shown. Can you tell me how to edit the general.xml to see the clusters?

Write attribute 0x10F2:0x0000 (“WindowCoveringType”) accordingly.
Write attribute 0x10F2:0x0010 (“InstalledOpenLimitLift”) as 0x0000 = 0cm.
Write attribute 0x10F2:0x0011 (“InstalledClosedLimitLift”) as 0x00F0 = 240cm.
Write attribute 0x10F2:0x0012 (“InstalledOpenLimitTilt”) as 0x0000 = 0°.
Write attribute 0x10F2:0x0013 (“InstalledClosedLimitTilt”) as 0x0384 = 90.0°.
Write attribute 0x10F2:0x1001 (“LiftToTiltTransitionSteps”) as 0xFFFF = invalid.
Write attribute 0x10F2:0x1002 (“TotalSteps”) as 0xFFFF = invalid.
Write attribute 0x10F2:0x1003 (“LiftToTiltTransitionSteps2”) as 0xFFFF = invalid.
Write attribute 0x10F2:0x1004 (“TotalSteps2”) as 0xFFFF = invalid.

These clusters should be rw but they’re just r.

15

These are attributes not cluster. They are manufacturer specific attributes which are read/writeable. in deCONZ only the standard attributes which are only readable are present. I try to add these here to the general.xml and then report back.

1 Like
16

Ok, so I’ve now completely reset my J1 just to see what’s going on here and it appears indeed that the auto-calibration is not fully working.

@jan666 Could you please file a bug report on Github for this?

@ChrisHae Unfortunately, adding the writable versions of the attributes through general.xml will not work properly, as the GUI has issues if the same attribute exists with AND without mfcode. Manup should know about that :slightly_smiling_face:

17
18

As this is now tracked on Github, i am moving this topic away to bug reports and lock it. Just to be sure we don;t have 2 discussions going on.

Thanks for report @jan666 :slight_smile:

19