v2.13 - Credential-based zwave-js-ui login

Authenticating no longer means handling a token yourself.

If your zwave-js-ui has authentication enabled, you previously had to fetch a JWT out of band, paste it into an environment variable, and repeat that whenever it expired. The script was offloading its own problem, and a scheduled run would quietly start failing weeks later with an error that reads like a regression.

Log in instead

.\Rename-Domoticz-From-ZwaveJSON.ps1 -ZwaveJsUrl "https://zwave-host:8091" `
    -ZwaveJsCredential (Get-Credential) -DbPath "domoticz.db" -DryRun

Get-Credential prompts for the username and password without either reaching your shell history or the process list. The script exchanges them for a session token itself, so you never obtain or store one, and expiry stops mattering because every run logs in fresh.

For an unattended run, save the credential once:

Get-Credential | Export-CliXml ./zwave.cred      # once, interactively

.\Rename-Domoticz-From-ZwaveJSON.ps1 -ZwaveJsUrl "https://zwave-host:8091" `
    -ZwaveJsCredential (Import-CliXml ./zwave.cred) -DbPath "domoticz.db"

Export-CliXml encrypts the password so only the same user on the same machine can read it back. Keep that file out of version control.

How the secret is handled

The password stays in a SecureString and is converted to plaintext only for the login request body. It is never returned, logged, or written to any output file.

Sending a password over http:// warns more sharply than sending a token did, and deliberately so: a captured token expires, a captured password works until you change it. As before, the script warns rather than refusing, because a trusted LAN or localhost is a common and reasonable case.

Compatibility

-ZwaveJsToken is unchanged and still works. Supplying both a credential and a token is an error rather than a silent preference, so a script that sets both gets told rather than guessed at.

Nothing else in this release changes how devices are selected or renamed.