Add ubisys J1 to lights with states on and bri.

[ma-ca]

Add ubisys J1 to /lights with states on and bri. Sending PUT { "on": true/false } triggers J1 to moveDown/Up. Sending PUT { "bri": "stop" } triggers a stop. Sending PUT { "bri": <value> } triggers move to lift percentage. The moving to lift percentage only works for calibrated J1. Moving up/down/stop always works.

The J1 is a shuttering device (window covering). Adding the J1 device to lights is just a temporary workaroud and will be fixed later when generic endpoint devices becomes available.

[ebaauw]

I think it would make more sense to send {"bri_inc": 0} to stop the movement. Not sure if the J1 supports relative lift, but that could also be supported through bri_inc.

Just to double-check: lift percentage 0 should match off (which means closed?), so setting {"bri": 0} would have the same effect as setting {"on" false}.

[ma-ca]

I have added { "bri_inc": 0 } to trigger stop command.

Sending { "on": false } will move up/open because bri = 0 translates to tilt percentage = 0% meaning fully open. But I have to admit that this is confusing.

Together with homebridge-hue the J1 is shown in HomeKit always being switched off. Pressing the button would therefore close the shutter. The brightness level allows to move to tilt percentage. For now a usable workaround.

[ebaauw]

I’ll see if I can expose the J1 as a HomeKit shutter or something in homebridge-hue.
ebaauw/homebridge-hue#367

[ebaauw]

HomeKit distinguishes between current position and target position of the shade. I suppose with the right attribute reporting settings, the J1 reports back the actual position during movement? At least, that's what my D1 does while dimming slowly.

@ma-ca can you check with dc_eventlog that, when the shutter is closed, PUTting {"on": false} to open the shutter results in a series of web socket events for state.bri that trace the current state of the shutter?

[ma-ca]

@ebaauw, the J1 does, when configured accordingly, continuously report the lift percentage during movement. Cluster 0x0102 attribute 0x0008 type 0x20 unsigned 8-bit int with range 0 to 100 (hex 0x00 - 0x64).
But this PR #727 did only implement sending commands to J1 when PUTting on or bri values. Handling ZCL reporting values from 0x0102 cluster attribute 0x0008 and translating to bri has not been implemented yet. I can add another PR if that is needed for HomeKit to work.

So the dc_eventlog command does not show anything when the shutter is moving.

[ebaauw]

I can add another PR if that is needed for HomeKit to work.

I think it's needed. The alternative would be to configure a timeout and assume the motion has ended when the timeout occurs. I have no clue how to determine the length for this timeout, as it will depend on the height of the shutters and the speed of the motor.

Is state.bri updated immediately after you PUT it, or only when the J1 is next polled? In the first case, you would need to make sure that state.bri reflects the actual state and prevent the update of the value on PUT. For homebridge-hue, it would be enough if you configure the reporting manually. If you don't, it will only be updated when deCONZ polls the J1, causing HomeKit to report the shutter is moving until then.

[ma-ca]

Then I will create a new PR that updates the state.bri value, because in the current implementation that value is always 0.

At the moment, no matter what the current position is, in HomeKit the commands "Hey Siri, on / off / 70%" does move the shutter to the positions fully closed/open/70% just like any dimmable light. A second later in HomeKit the J1 is shown off 0% still while the shutter is moving to the desired position.

[felixstorm]

@ma-ca, @ebaauw - thanks for your work! If you have a chance, it would be very helpful if also tilt state could be implemented somehow in the temporary REST API (setting and attribute reporting), but as the other light attributes (hue, sat, xy, ct) seem to all interact with each other somehow, there might not be a simple solution for that.

Unfortunately, my time is very limited at the moment (and my CPP knowledge also far from great), so I won't have a chance to contribute much here currently (apart maybe from testing).
Therefore I will probably still have to stay with my custom zha cover component in Home Assistant mentioned in #534 (comment) for now, but it is still great to see progress here.