Problem
A user set matter-server host to `http://jobs2.local:8176\` (scheme + port baked into the host field). The plugin builds its connect URL by concatenation (`matter_client.py:70`):
```
ws://{host}:{port}{path} → ws://http://jobs2.local:8176:5580/ws
```
That URL is unparseable, so macOS name resolution fails and the only feedback is a cryptic runtime warning buried in the event log:
```
matter-server connection lost: [Errno 8] nodename nor servname provided, or not known
```
The error surfaces at connect time in the log, not at the moment the user is editing the field — so it reads as a connection failure rather than a config typo.
Why it's worth fixing
- High-probability user error (host-only fields invite a pasted URL).
- There is currently no `validatePrefsConfigUi` on the plugin — only `closedPrefsConfigUi` (`plugin.py:193`). Nothing inspects the host before it's concatenated.
- A clear pattern to copy already exists: `validateDeviceConfigUi` (`plugin.py:201`) fails fast with a human-readable `showAlertText`.
Proposed fix
Add `validatePrefsConfigUi` that fails fast at save time (~15 lines, mirroring the existing device validator):
- trim whitespace on the host
- reject if the host contains `://`, `/`, or `:` → message e.g. "Enter only the hostname or IP here (e.g. `127.0.0.1`). Leave out `ws://`/`http://`, the port, and the path — those have their own fields below."
- while there, validate the port is an integer
Deliberately NOT doing: silently normalising bad input (auto-stripping the scheme, auto-splitting `host:port` into the two fields). Silent magic would happily connect a fat-fingered `:8176` to the wrong place with no feedback. Reject and tell the user instead — fail loud, fail early.
Optional belt-and-braces: also strip a leading `ws://`/`http://` scheme defensively inside `matter_client.py` when building the URI, so a host set via API/import (not the dialog) can't produce a double-scheme URL. The validator is the 90% fix.
Notes
- Patch-level version bump (reliability, not a user-facing feature).
- Add a unit test for the validator covering: bare host (ok), `http://host\` (reject), `host:port` (reject), non-integer port (reject).
Problem
A user set matter-server host to `http://jobs2.local:8176\` (scheme + port baked into the host field). The plugin builds its connect URL by concatenation (`matter_client.py:70`):
```
ws://{host}:{port}{path} → ws://http://jobs2.local:8176:5580/ws
```
That URL is unparseable, so macOS name resolution fails and the only feedback is a cryptic runtime warning buried in the event log:
```
matter-server connection lost: [Errno 8] nodename nor servname provided, or not known
```
The error surfaces at connect time in the log, not at the moment the user is editing the field — so it reads as a connection failure rather than a config typo.
Why it's worth fixing
Proposed fix
Add `validatePrefsConfigUi` that fails fast at save time (~15 lines, mirroring the existing device validator):
Deliberately NOT doing: silently normalising bad input (auto-stripping the scheme, auto-splitting `host:port` into the two fields). Silent magic would happily connect a fat-fingered `:8176` to the wrong place with no feedback. Reject and tell the user instead — fail loud, fail early.
Optional belt-and-braces: also strip a leading `ws://`/`http://` scheme defensively inside `matter_client.py` when building the URI, so a host set via API/import (not the dialog) can't produce a double-scheme URL. The validator is the 90% fix.
Notes