Add SmartStart provisioning support to zwave_js WS API

[raman325]

Proposed change

In this PR we update add_node and replace_failed_node commands to accept the new inputs. We also add the following commands:

• provision_smart_start_node - Pre-provision smart start node
• unprovision_smart_start_node - Remove pre-provisioned smart start node from provisioning list
• get_provisioning_entries- gets all registered provisioning entries
• parse_qr_code_string - Parses string from a QR code into provisioning information
• supports_feature - Returns whether controller supports a feature (Smart Start is the only feature to check at the moment)

And update remove_node to accept the optional unprovision parameter (also new)

The lib also has get_provisioning_entry but I am not sure that it would serve a purpose here unless we want to do something with it on the device info page for a node that was already added but the entry remains.

Dependent on home-assistant-libs/zwave-js-server-python#315 and zwave-js/zwave-js-server#432

Will be in draft for a bit while things get reviewed and released upstream, but I wanted to share this so that we could discuss any required changes to the model and plan the frontend work.

CC @MartinHjelmare

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New integration (thank you!)
• New feature (which adds functionality to an existing integration)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue:
• Link to documentation pull request:

Checklist

• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• The code has been formatted using Black (black --fast homeassistant tests)
• Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.
• Untested files have been added to .coveragerc.

The integration reached or maintains the following Integration Quality Scale:

• No score or internal
• 🥈 Silver
• 🥇 Gold
• 🏆 Platinum

To help with the load of incoming pull requests:

• I have reviewed two other open pull requests in this repository.

[probot-home-assistant]

Hey there @home-assistant/z-wave, mind taking a look at this pull request as it has been labeled with an integration (zwave_js) you are listed as a code owner for? Thanks!
_{^{(message by CodeOwnersMention)}}

[MartinHjelmare]

We can rebase here now since we've bumped the library.

[MartinHjelmare]

Looks good!

The frontend team should approve before we merge.

CC @bramkragten

[raman325]

FYI I will be moving most of the validation logic into the lib since we have to bump the schema anyway. That should shorten this PR by quite a bit

[MartinHjelmare]

@raman325 I changed the provision info schema to allow None values for the optional values. It was the most simple fix I saw to make it working.

I'm testing this with Bram's frontend branch now. I managed to provision a test device.

We'd like to add the device to the device registry when provisioning a device to have it show in the device list in the frontend with provisioned status. What do you think? Can you add that?

[raman325]

@raman325 I changed the provision info schema to allow None values for the optional values. It was the most simple fix I saw to make it working.

I'm testing this with Bram's frontend branch now. I managed to provision a test device.

We'd like to add the device to the device registry when provisioning a device to have it show in the device list in the frontend with provisioned status. What do you think? Can you add that?

Are you talking specifically about Smart Start nodes? So register the device when provisionSmartStartNode is called? When you say the device is in provisioned status, how are you envisioning that be reflected?

[MartinHjelmare]

Yeah, if the provision succeeds, we add the device to the device registry. Is there a way to tell if the provision succeeds or fails?

We're also discussing how to guard against duplicate provisions since the controller doesn't seem to guard against that.

We could add provisioned as a device status enum item, at least in the frontend.

[MartinHjelmare]

Bram can handle the frontend work, if any, that's needed here. But I'd like your opinion about the architecture design if this makes sense.

[raman325]

it definitely adds complexity. The device identifier is currently <home ID>-<node ID>. If the node ID is preselected, then we can create the device during provisioning and it will be picked up later when the node publishes a node ready event as long as its node ID is the same. If the node ID is not pre-selected, we would have to introduce some logic to check existing devices in a provisioned state and to update that device before continuing with the rest of the logic. I think the only thing that makes the provisioning entries unique is the DSK, but the DSK Is only known to the driver before the device is provisioned. Once the device has been provisioned, I don't think we have access to the DSK, so I'm not sure how we'd match the provisioned device entry to the node ready node.

[bramkragten]

Ok, let's just make a new view then in the zwave js panel with a list of provisioned devices.

[MartinHjelmare]

Ok, yeah there needs to be some identifier that is the same in both the provisioned device and the added device to be able to map them. Let's go with a separate list of provisioned devices for now then.

[balloob]

Let's leave any complexity for future us.

[bramkragten]

Adding of devices with QR is done now in home-assistant/frontend#10726

Will make another PR for listing provisioned devices