Window Cover Device - "Open" in Home vs. "Open" via TRADFRI open/close remote

[jan666]

I have 2 Ubisys J1 devices and 2 TRADFRI open/close remote.

I have a HomeKit automation to open the Ubisys devices every morning. Sometimes they say "closed" a few centimeters. That might be because the time to open them completely differs, I dont really know.

I also use the TRADFRI open/close remotes (I did a binding in deCONZ) to open and close them sometimes. When opening with the remote I never had that phenomenon that they stay open for a few cm.

It might be coincidence but it's worth a question: is it possible that homebridge-deconz acts differently than the remote when just "open" is sent?

[ebaauw]

Homebridge deCONZ doesn't interact with the J1; it just sends an API request to deCONZ. It is conceivable that deCONZ would interact differently with the J1 than the Trådfri open/close remote. I don't know the Ubisys J1 first hand, but, in my experience, different Window Covering devices might react differently to the same commands.

The Trådfri open/close remote sends Open or Close to the Window Covering cluster. It used to be able to send groupcasts, but with recent firmware, it only sends unicasts. I suppose, being an end device, it doesn't expect any default response to the unicast, and, consequently doesn't employ any re-send logic.

Depending on how the J1 is implemented in deCONZ, I would guess deCONZ sends unicast Open and Close commands as well. But it will ask for a default response, and likely re-send the command in case it doesn't receive any. You would need to sniff the Zigbee trafftc to confirm. If the J1 is anything like the IKEA blinds, a second Open or Close will actually stop the movement (in violation of the ZIgbee standard, as far as I understand). To confirm, you could try sending two successive Open or Close commands to the J1 from the deCONZ GUI to see if the second command actually stops the movement.

I assume you double-checked the Homebridge log, making sure Homebridge deCONZ receives only one update from HomeKit, and sends only one API call to deCONZ to change the state of the J1.

[jan666]

sending /state --data '{"open": true} } opens, another sending does not interupt the opening.

I think I missed that initially: the J1 thinks it is fully opened, and so does Homekit. "lift": 0 and "open": true.

Maybe this is because how the J1 does the calibration. I thought maybe homebride-deconz sends "go to lift 0" and the remote sends "open" and maybe the J1 stops the motor too early when "go to 0" is sent (but thinks it was fully opened) and just gives the motor power until it stops on "open".

This is not really a big problem btw, just wanted to make sure this is not something that could be worked around easily

[ebaauw]

the J1 thinks it is fully opened

Did you double-check Current Position Lift Percentage of the Windows Covering cluster in the GUI?

I think I misunderstood: the blind doesn't open a little and then stops, but it stops just shy of being fully open? But it does report being fully open? That would be an issue with the device, possibly related to calibration, but could also be the physical mechanics. There is some logic in Homebridge deCONZ to round the position to the next 5% when checking whether the target position has been reached. In my experience, devices don't set the position accurately to the percentage. If you can configure the speed, setting a slower speed might make the device a bit more precise.

I double-checked the code: indeed Homebridge deCONZ sends {"lift": 0} instead of {"open": true}. This is because HomeKit exposes Current Position and Target Position as percentage, and doesn't provide a separate characteristic for open or close. deCONZ typically translates this to a Go to Lift Percentage command to the device, which is indeed different from Open. I haven't seen any different behaviour between these two commands of any of my window covering devices. though.

[jan666]

Ah true, I did not check the Cluster. Will do this the next time this happens (currently the window is covered in snow and the blind does not move at all...).

Yes, it opens and stops a little bit before its fully closed, Homebridge reports it as fully closed. Sorry for my confusing description.

I have 4 of these J1 devices. One is my awning, one is a window in the facade and two are blinds of roof windows. I never saw this behaviour at the awning or the facade window. But on both roof window blinds. The awning is 3 years old, the facade window 1 year, the roof windows just 2 month.

From the U1 specs:

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.

My wild guess: sometimes it moves slower, so "lift": 0 is not fully closed in time but the J1 cuts the power. And maybe "open": true just lets the motor run until it stops.

[ebaauw]

The J1 manual does state that Open and Close work without calibration, where Move to Lift Percentage only works after calibration. So I suppose it handles these commands differently, unlike my window covering devices. I’ll see if I can make Homebridge deCONZ send {"open": true} (or {"open": false}) instead of {"lift": 0} ({"lift": 100}), so deCONZ will send Open (Close) instead of Move to Lift Percentage.

[ebaauw]

In v1.0.8.

[Monofin]

1.08 has flipped the direction of my Zemismart ZM79E-DT, and now reports Open when requested to close, and close when requested to open. (My AM73 Roller blind drivers work just fine :-) I'll try a few fixes at this end on the device and report back.

[Monofin]

Zemismart ZM79E-DT required reversing the motor direction on its local remote, but everything works now :-) Thanks for all the work!