Qubino Flush Shutter DC venetian mode: switch CC instead of dimmer CC

[darkbasic]

da666d58.values.jsonl.txt da666d58.metadata.jsonl.txt da666d58.json.txt zwave-14363.log

openzwave: zwave-js:

The Qubino Flush Shutter DC in the default shutter mode has a single endpoint with a dimmer CC to show the vertical position. When setting the Qubino Flush Shutter DC in venetian mode you have unpair it and re-include it in order to show two additional endpoints: one for the vertical position and one for the slats tilting position. It still keeps around the original endpoint for the vertical position, but this one doesn't gets reports and thus its state falls out of sync pretty quickly. On the contrary both the additional endpoints receive reports. The strange thing is that while openzwave shows the original endpoint as a dimmer CC, zwave-js shows it as a switch CC (see pictures).

Apart from that I'm unsure about what we should do with it, since it doesn't get reports. Maybe hide it? What's its purpose? Firmware version is 7.2.

[petrovcicklemen]

Endpoint1 has the same functionality as the root endpoint, since this is mandated by the specs. When Venetian mode is enabled, the vertical position will be sent, in unsolicited messages, from endpoint1 in SWITCH_MULTILEVEL_REPORTs, while the tilt position will be sent from endpoint2, but the gateway must configure the multi channel lifeline, so that the unsolicited reports are sent correctly, multi channel, encapsulated. If the gateway would configure an ordinary lifeline, the reports would be sent non-multi channel encapsulated, meaning the vertical position reports and the tilt position reports would overwrite each other, with the last received value.

Some gateways don't create widgets for the root endpoint, if the device has multiple endpoints, some create widgets that are mapped to the root endpoint and endpoint1, while others create widgets for all endpoints separately, but those that belong to the root endpoint are not updated, like in this case. I'd leave the root widgets, since they are needed, just not in this configuration.

[AlCalzone]

Looking at the logs and the screenshot, zwave-js detects both the binary and the multilevel switch functionality of endpoint 1. As far as I can see, the widgets are also created (note that zwave-js exposes the value id for start/stop level change as a single boolean, which is displayed as a switch).

It also creates a multi channel lifeline in group 1:

{"k":"{\"nodeId\":11,\"commandClass\":142,\"endpoint\":0,\"property\":\"endpoints\",\"propertyKey\":1}","v":[{"nodeId":1,"endpoint":0}]}

but I can't tell what kind of unsolicited reports the device sends, since the log ends right after the interview.

[darkbasic]

@AlCalzone so zwave-js hides the multilevel switch from endpoint 0, right?

[AlCalzone]

Yup those are hidden by default if they mirror endpoint functionality. From what I've understood, this is the case here.

[darkbasic]

Good, I've always found it annoying to see them duplicated in openzwave, specially since endpoint 1 receives unsolicited reports while endpoint 0 doesn't (and thus falls out of sync).

[AlCalzone]

@darkbasic Is there any problem left unsolved? Tbh, I'm not sure anymore.

@petrovcicklemen has identified a few flaws in the zwavejs2mqtt dashboard that @robertsLando has solved yesterday as far as I know.

[AlCalzone]

I'm gonna close this for now. Feel free to reopen if necessary