zwave-js / certification-backlog Goto Github PK

Here, a report with temperature scale 2 was received, °F is scale 1:

Z-Wave JS exposes two semi-duplicate values for the Door/Window state notification value:

Unfortunately it is impossible to detect whether a device supports the "open in ... position" states, or just supports the CC version that includes them. As a result, the 4-state sensor is exposed as 3 or 4 binary sensor in HA, in addition to the 2-state sensor which adds another binary sensor.

This should be simplified into two binary sensors: open / close and tilted / not tilted.

It must be possible to start and stop a color transition (e.g. fade from the current color to red). We may decide that doing this with a service call is good enough, but it is not intuitive at all:

Allow the user to GET/SET a custom configuration value for a device.
The device configuration panel needs to be expanded, as well as the websocket.

From core created by AlCalzone: home-assistant/core#94530

During certification tests where I end up factory resetting the controller a lot, I noticed that after just including a device, the logbook on the device page was showing old entries from the device that previously used to have the same node ID.

It does not seem to matter if the device is the same or not, because this also reproduces after including an entirely different device.
All these entries are from a different controller I used for certification tests:

After factory resetting the controller (new home ID) and including a multisensor, HA now attributes all the state changes to the multisensor, although it wasn't part of the network at that time. The only thing that is the same is the node ID 2.

Diagnostics information

This is after replacing:

zwave_js-50da63f28934190600d0d68b43b2d834-Node 2-e308902a081a661262ba2565c42bdde0.json.txt

From #17, it would be nice to provide users with button entities to reset the Meter CC instead of a service

If a device reports support for resetting meters, the end user must be able to perform this action. The driver exposes a writeonly value in this case, see node diagnostics.

For now, the user can reset a meter using a service call, which is sufficient for passing certification.

In the long run, we should add additional button entities, similar to PING or the planned IDENTIFY (Indicator CC).

Transferred issue from AlCalzone

As I'm going through the certification tests, I got stuck on the same issue that was reported in home-assistant/core#80445 previously.
A test device in the certification test suite uses Binary Switch CC + Color Switch CC, so On/Off + tunable color. In this case, the end user is not able to change the color, as there is only an On/Off toggle.

From core created by AlCalzone: home-assistant/core#92799

The problem

If a device reports support for resetting meters, the end user must be able to perform this action. The driver exposes a writeonly value in this case, see node diagnostics.

We should add additional button entities, similar to PING or the planned IDENTIFY (Indicator CC).

• Button to reset all meters
• (optionally) buttons to reset individual meters

Diagnostics information

zwave_js-f0926e113c178046d0d249fcdc42964a-Node 58-24fb445b526b3d5d614f25141d6cc278.json.txt

The problem

Problem 1:

I am unable to do this via the UI:

Please set the Setpoint of the emulated Thermostat Setpoint device to '22 °C' for the 'Cooling' Setpoint Type

Problem 2:

I also can't do this:

Please set the Setpoint for type 'FullPower' to 150 °C

Problem 3:

I am unable to do this via the UI (same check as above, different device):

Please set the Setpoint of the emulated Thermostat Setpoint device to '22 °C' for the 'Cooling' Setpoint Type

What version of Home Assistant Core has the issue?

core-2023.6.0.dev20230503

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Z-Wave JS

Link to integration documentation on our website

No response

Diagnostics information

Node diagnostics for problems 1-2:
zwave_js-f0926e113c178046d0d249fcdc42964a-Node 68-6c05e6136d5df1f37b82d089e6893a74.json.txt

Node diagnostics for problem 3:
zwave_js-f0926e113c178046d0d249fcdc42964a-Node 69-64741301612ea804321abbab07756732.json.txt

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

The Thermostat Setback CC allows overriding a thermostat setpoint (the way I understand it without affecting the original setpoint setting), either temporarily (e.g. on a timer) or permanently.

There is no way to use/set this in HA, except using the invoke_cc_api service call.

Diagnostics information

zwave_js-f0926e113c178046d0d249fcdc42964a-Node 67-7180da6f98ebab1058d1cfaa753baaeb.json.txt

Problem 1:
I am unable to do this via the UI:

Please set the Setpoint of the emulated Thermostat Setpoint device to '22 °C' for the 'Cooling' Setpoint Type

Problem 2:
I also can't do this:

Please set the Setpoint for type 'FullPower' to 150 °C

Problem 3:
I am unable to do this via the UI (same check as above, different device):

Please set the Setpoint of the emulated Thermostat Setpoint device to '22 °C' for the 'Cooling' Setpoint Type

device diagnostics:

https://github.com/home-assistant/core/files/11422222/zwave_js-f0926e113c178046d0d249fcdc42964a-Node.68-6c05e6136d5df1f37b82d089e6893a74.json.txt

https://github.com/home-assistant/core/files/11422258/zwave_js-f0926e113c178046d0d249fcdc42964a-Node.69-64741301612ea804321abbab07756732.json.txt

This device, which is a leak sensor, provides a Basic switch after the recent changes to Zwave JS. I tried going through the reinterview process and now I have 2 Basic switches

Originally created by AlCalzone: home-assistant/core#94115

The problem

I've made a video:

Since the PIN timeout is 4 minutes, the driver will wait that long before aborting the inclusion process, which means the inclusion UI is unavailable for that long after a single misclick.

Either clicking the backdrop should not close that dialog, or it should abort the process

From core created by AlCalzone: home-assistant/core#94067

The problem

A controller providing control of the SmartStart functionality MUST:

• Provide a method for the end user to view the Node Provisioning List entries with their network status (included/ not included or failed) --> double check!

• Provide a method for the end user to manually add and remove entries in the Node Provisioning List.

• Provide a method for the end user to edit available settings for each entry in the Node Provisioning List. (e.g., Inclusion setting, Advanced joining)

• Support S2 inclusion with authentication using the DSK PIN code.

• If a user removes a node from the Node Provisioning List and the node is still included in the Z-Wave network, the controller MUST inform the end user that the node will stay in the network and requires to be excluded manually or reset to factory default in order to leave the Z-Wave Network.

• A controller MUST inform the end user that S2 only (non-SmartStart) nodes present in the Provisioning List require to perform a classic inclusion to add them into the Z-Wave network. Problem avoided, see comments below

Currently there's no such UI in Home Assistant.

• When done, this also needs to be added to the documentation/manual.

Advanced joining = selecting which keys shall be granted (optional)

What version of Home Assistant Core has the issue?

core-2023.7.0.dev20230605

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

No response

Link to integration documentation on our website

No response

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

When clicking "how do you want to add your device", one is greeted with a dialog containing this option:

This looks like it does the same as the default inclusion, but it allows the user to manually deselect security keys. IMO this should be at least mentioned, because it isn't obvious. And it is a feature that is asked for during certification tests.

Steps to reproduce the issue

1. ADD Z-Wave device
2. Select "how do you want to include the device"

A recommendation (not requirement) is this one:

A controlling node SHOULD have a UI allowing the end user to see the following properties:
• Last known configured color or color components values

While there is a way to see the current color...

...I don't see a way to know which color that is. Would it be useful to be able to show the HEX or RGB values for that color?

This is obvious in the case of "red", but not in this case:

Is the current level of color component 'Blue' (ID = 4) set to 130 in the DUT's UI according to Requirement Number CL:0033.01.42.01.1?

Light off:

Light on:

The recent changes to Basic CC exposed an issue where devices that "support" Basic CC, but cannot actually be controlled, appear as a light entity. The next version of node-zwave-js only exposes currentValue in this case.

This needs a change in the discovery scheme, so that currentValue without targetValue is considered a sensor and not a light/actor.

After hard resetting the Z-Wave controller, e.g. by sending

{ "command": "driver.hard_reset" }

to zwave-js-server, the integration page shows "no devices or entities" for that instance, although the controller should be listed as a device.

The information does not come back when reloading the integration.
It does however come back when:

• reloading the browser window
• disabling and re-enabling the integration

Describe the behavior you expected

The device information should be up to date after reconnecting to zwave-js-server.

Steps to reproduce the issue

1. Have an instance of zwave-js-server running in a way that you can send it custom commands, ideally from the repository on a dev machine.
2. Set up a Z-Wave integration, do not use the supervisor addon, enter the path to your dev machine in the following dialog
3. Make sure it shows the devices in the integration overview
4. Send { "command": "driver.hard_reset" } to the server, e.g. by putting this file in the zwave-js-server repo as src/bin/hard_reset.ts, then execute it using ts-node src/bin/hard_reset.ts.

Specifically this requirement:

CL:005B.01.41.01.1 The controlling node MUST have a UI allowing the end user to see how many Scenes ID (or buttons)
and key attributes are supported by a node.

However the scenes are only "visible" to the end user once triggered:

... but not before that has happened.

Diagnostics information

zwave_js-f0926e113c178046d0d249fcdc42964a-Node 51-fc16e3b6c7d5b4fc655796a78d0657cd.json.txt

The UI must allow the user to configure the keypad (key cache size and timeout), and it must show the received notifications (event type and data).

Diagnostics information

zwave_js-50da63f28934190600d0d68b43b2d834-Node 5-dcb862dd8eddb8517fa31416e7ecb10a.json.txt

The end user MUST be able to play the default tone, play a selected tone or stop playing a tone.

The UI for siren control doesn't seem to allow selecting a specific tone, but it shows a weird dropdown with some attributes:

Diagnostics information

zwave_js-f0926e113c178046d0d249fcdc42964a-Node 65-69bfeb31c9b5eca03be46337ae416f51.json.txt

from home-assistant/core#94539

The problem

Certification require:

A controlling node MUST have a UI allowing the end user to see the received Notification Reports (Notification Type and event/state) regarding to Requirement Number CL:0071.01.41.01.1

This works for some notifications (I assume the ones that can be auto-detected during the interview), but dynamically created ones (Notification CC v2) are hidden and disabled initially:

When the certification tests ask questions like this...

Does the DUT display a 'SystemHardwareFailure (0x01)' event for the notification type 'System'?

...we'll have to expect that the testers will answer NO unless we explicitly explain in the documentation for testers that they:

• have to show hidden entities
• have to enable them after receiving the notification for the first time
• have to wait 30s for the actual status to be shown

I'm not sure though if this will be accepted.

What version of Home Assistant Core has the issue?

core-2023.7.0.dev20230613

From core created by AlCalzone: home-assistant/core#92789

The problem

Some devices only support Basic CC, and no other actuator CC like Binary Switch, etc.
For those devices, the specs require that users can use the Basic CC to interact with the device and view the current status.

However, the Basic CC entities are hidden by default and have to be enabled manually:

While this is usually fine, this shouldn't be done if Basic CC is the only way to control the device. I think HA should rely on the information by the driver and show the Basic CC values by default. The node-zwave-js driver already hides Basic CC from applications, unless:

• no other actuator CC is supported
• the "Basic event" value is enabled via a config file

Also, it is currently not possible to send an "ON" command (255). Basic CC has the same value range as Multilevel Switch CC (0-99, 255). The value slider only allows setting 0-99

but sending a 255 is a check in the certification test suite.

Diagnostics information

zwave_js-f0926e113c178046d0d249fcdc42964a-Node 48-d2b1f1f13b9c6bab2d0d79efbc1d3724.json.txt

home-assistant/core#90248 added support for identifying nodes.
Apparently identifying is also a certification requirement for controllers, although I fail to see how it makes sense for us, given that we have a full-blown UI. Also I'm unclear how this identification must be done, since the specs are only referring to "nodes" and recommend that they blink an LED.
On the other hand, the certification test asks "Did the DUT blink 5 times?" 🤷‍♂️

Anyways, the next node-zwave-js release will add a controller event "identify", which HA probably needs to capture and show some sort of identification as a result. Ideally keep in mind that something may have to blink a configurable amount of times.

We're going to write an architecture discussion about this. HA is missing some window covering scenarios.

Z-Wave specification:
https://github.com/zwave-js/specs/blob/master/Z-Wave%20Specification%20AWG%20V3.0.pdf

page 525

Update 25th april 2024

• Cover platform needs to be revisited as a whole, account for all these variations. Take this up with the product team.
• For now, check what certification really is going to test and see if we can fit that in
• Dominic is going to check what is going to be tested and pastes that here

From core created by AlCalzone: home-assistant/core#94543

The problem

16:20:31.009 Please trigger a Alarm Get using the DUT's UI!
16:20:31.009
16:20:31.009 *******************************************************************
16:20:31.009 Timeout for Test sequence is 5 min, waiting for following events:
16:20:31.009 * NOTIFICATION_GET (ALARM_GET) for Notification Type 0x09
16:20:31.010 *******************************************************************

The only way to do this currently is this service call, which requires looking up Z-Wave JS source code to know what to put there:

Controller MUST have a UI allowing the end user to see the following properties:
• Number of supported User Codes
• The list of last known set User Codes
• The current keypad mode, if the supporting node supports more than one (v2)
• The current set Admin Code, if the supporting node supports a Admin Code (v2)

Note that Admin Code was renamed from Master Code in the latest spec revision. Z-Wave JS hasn't renamed it yet.

Several compliance tests require performing a hard reset of the controller. Currently the only way to do this is via Z-Wave JS UI.

From core created by AlCalzone: home-assistant/core#86955

The problem

(the mentioned operation types mean constant 0x01 and timed 0x02, V4+ adds additional ones)

I could not find any way to configure the operation type of a lock, so this will need to be added before certification.

Also setting the lock mode (Locked, Unlocked, and several timed modes) must be available to the user if supported by the lock:

What version of Home Assistant Core has the issue?

2023.1.7

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Z-Wave JS

Link to integration documentation on our website

No response

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

The specifications mandate this:

A controlling node receiving the Device Reset Locally Notification Command MUST indicate to the
end user that the node has been reset and left the Z-Wave network.

To accomodate, v11 of node-zwave-js has added a parameter that indicates why a node was removed:
https://zwave-js.github.io/node-zwave-js/#/api/controller?id=quotnode-removedquot

When this reason is RemoveNodeReason.Reset, HA must notify the user. Other reasons, like ProxyExcluded or ProxyReplaced may be interesting too, but not mandatory.