Ubisys J1 calibration is not working (anymore)

[jan666]

Describe the bug

The Ubisys J1 needs to be calibrated before it's fully usable. This is (like described here: #813) done via REST-API call PUT /sensors/xx/config {"windowcoveringtype" : 0}.

When I installed my first J1 in 2020 this worked perfect (see #3147).

No I installed my second J1 and it's not working anymore (confirmed here: https://forum.phoscon.de/t/ubisys-j1-calibration/3386 by @SwoopX)

Steps to reproduce the behavior

0. Reset the J1 if its already calibrated
1. send the PUT /sensors/xx/config {"windowcoveringtype" : 0} to your J1-ZHASwitch-Sensor

Expected behavior

The J1 should drive a little bit down, drive completely up, completely down, completely up again to and be calibrated.

Screenshots

Environment

• Host system: Raspberry Pi
• Running method: Raspbian
• Firmware version: 26780700
• deCONZ version: 2.20.01 / 19.9.2022
• Device: ConBee II
• Do you use an USB extension cable: yes
• Is there any other USB or serial devices connected to the host system? Yes, a "Technische Alternative" D-LOGG

deCONZ Logs

Additional context

See here: https://forum.phoscon.de/t/ubisys-j1-calibration/3386

[SwoopX]

Tiny root cause with a large effect if the device has not been previously calibrated. Attribute 0x000A from the window covering cluster is not read or more precisely, updated values cannot be handled in the current state using a DDF. That value is used to control a rudimentary state machine. The lack of value updates makes the code assume everything's going really fast and doesn't let the calibration activities finish, leading to a hickup in the process.

Checking the sniffer and also deconz log shows that the calibration steps are followed as expected, but they're rushed through.

[jan666]

What about the unwritable attributes?