Add additional enhancements available on at least some panels/firmware

[peternewman]

• Add additional variables available on at least some panels/firmware
• Support variables within fields when setting IP config
• Fix a bug when trying to set two IPs back to back/ever

[maxajbarlow]

Thorough enhancement PR. Covers a lot of ground - new variables, feedbacks, actions, and presets. Here's a detailed review:

---

What's good:

1. Variable expansion support in IP config (useVariables: true + context.parseVariablesInString()) - This is a great addition. Users can now template IP addresses from other variables, which is useful in multi-panel setups.

2. Regex.IP usage - Replacing inline regex strings with the built-in Regex.IP constant from @companion-module/base is the right move. Cleaner and consistent with other modules.

3. Expansion1 interface support - Extending network status/link queries to include Expansion1 shows real-world testing on hardware that has this interface.

4. Identify actions/feedbacks/presets - Complete implementation: enable/disable/toggle/fetch + feedback + 4 presets. Follows the established pattern for other toggle features (NMOS, Control Panel).

5. NetworkStatusChanged handler - Reactive data refresh when the panel reports network changes. Good for keeping variables current without polling.

6. Network settings invalidation (this.networkSettings = null after update) - Smart fix. Prevents stale cached settings from being used after an update.

7. Artist connection status - Useful for intercom integration monitoring.

---

Issues to address:

1. typescript-eslint in dependencies (not devDependencies) - Same as noted in #17. This is a dev/lint tool and shouldn't ship as a runtime dependency. Should be moved to devDependencies.

2. Commented-out code in MediaPortAssignment handler:

// this.interfaceLinkStatuses.set(interfaceId, linkStatus)
// this.checkFeedbacks('interfaceLinkStatus')

These look like copy-paste artifacts. Should be removed rather than left commented.

3. enableIdentify / disableIdentify use setTimeout for status refresh:

public enableIdentify(): void {
    this.sendMessage('/Identify/Enable', {})
    setTimeout(() => this.fetchIdentifyStatus(), 500)
}

There's also a StatusChanged handler (/Identify/StatusChanged) that calls fetchIdentifyStatus(). So the setTimeout is redundant - the panel will notify via WebSocket when the state changes. The timeout creates a race condition where the polled fetch could arrive before the actual state change. Consider removing the setTimeout and relying solely on the StatusChanged notification, or at minimum documenting why both are needed (e.g., if some firmware versions don't send StatusChanged).

4. Full JSON debug logging of every message:

this.log('debug', `Received: ` + JSON.stringify(data))

Same concern as in #14 - this will dump the full body of every WebS message. On panels that send frequent updates (network status, PTP, etc.), this could flood logs. Consider either:

• Removing it (the topic-level log is usually sufficient)
• Only logging the body for unhandled topics (you already log those at info level)

5. artistConnectionStatus feedbacks referenced but not defined:

this.checkFeedbacks('artistConnectionStatus', 'artistConnectionStatusDisplay')

These feedback IDs are checked in main.ts but I don't see them defined in the feedbacks.ts diff. If they're not yet implemented, this will silently do nothing (which is fine), but it suggests incomplete feature work. Either add the feedback definitions or remove the checkFeedbacks call.

6. artist_connection_status variable default missing:
The variable definition and getDefaultVariableValues for artist_connection_status is present in variables.ts, but I don't see artist_name being exposed as a variable even though fetchIntercomArtistName() is called. Is the artist name response handler missing from main.ts?

---

Nits (non-blocking):

• The README variable table update is thorough and matches the code. Well done.
• Preset colour constants (GREEN, RED, BLUE, etc.) - good reuse of existing constants.
• NetworkSettings interface extension with optional fields (dnsServer1?, dnsServer2?, linkOperationalState?) is forward-compatible.

---

Summary:

This is a substantial and well-structured enhancement. The core functionality (link status, identify, media port assignment, Artist integration, variable support in IP config) all follows established patterns. The issues above are mostly minor - the setTimeout vs StatusChanged question (#3) and the missing Artist feedback/variable handling (#5/#6) are the most worth addressing. Happy to approve once those are clarified.

[peternewman]

Issues to address:

1. typescript-eslint in dependencies (not devDependencies) - Same as noted in #17. This is a dev/lint tool and shouldn't ship as a runtime dependency. Should be moved to devDependencies.

Fixed.

2. Commented-out code in MediaPortAssignment handler:

// this.interfaceLinkStatuses.set(interfaceId, linkStatus)
// this.checkFeedbacks('interfaceLinkStatus')

These look like copy-paste artifacts. Should be removed rather than left commented.

Still hoping to add these at some point when I get time, but maybe in another PR before this one gets too huge.

3. enableIdentify / disableIdentify use setTimeout for status refresh:

public enableIdentify(): void {
    this.sendMessage('/Identify/Enable', {})
    setTimeout(() => this.fetchIdentifyStatus(), 500)
}

There's also a StatusChanged handler (/Identify/StatusChanged) that calls fetchIdentifyStatus(). So the setTimeout is redundant - the panel will notify via WebSocket when the state changes. The timeout creates a race condition where the polled fetch could arrive before the actual state change. Consider removing the setTimeout and relying solely on the StatusChanged notification, or at minimum documenting why both are needed (e.g., if some firmware versions don't send StatusChanged).

Over to you there @maxajbarlow . I just copied the existing patterns and then extended them when I found out about the Changed notifications. Can we remove them or are there

(e.g., if some firmware versions don't send StatusChanged).

4. Full JSON debug logging of every message:

this.log('debug', `Received: ` + JSON.stringify(data))

Same concern as in #14 - this will dump the full body of every WebS message. On panels that send frequent updates (network status, PTP, etc.), this could flood logs. Consider either:

• Removing it (the topic-level log is usually sufficient)
• Only logging the body for unhandled topics (you already log those at info level)

Still very useful generally while the module is still relatively new as any end-user can send a log with useful data in it, rather than it just failing on some mis-match and not knowing what's changed because the topic matched.

5. artistConnectionStatus feedbacks referenced but not defined:

this.checkFeedbacks('artistConnectionStatus', 'artistConnectionStatusDisplay')

These feedback IDs are checked in main.ts but I don't see them defined in the feedbacks.ts diff. If they're not yet implemented, this will silently do nothing (which is fine), but it suggests incomplete feature work. Either add the feedback definitions or remove the checkFeedbacks call.

These feedbacks have now been added.

6. artist_connection_status variable default missing: The variable definition and getDefaultVariableValues for artist_connection_status is present in variables.ts, but I don't see artist_name being exposed as a variable even though fetchIntercomArtistName() is called. Is the artist name response handler missing from main.ts?

Artist name support now added as a variable since I've had a working connection to read it from.

Happy to approve once those are clarified.

Are you happy to approve and merge now most of this has been covered off @maxajbarlow ?

Thanks.

P.S. also used it in anger to bulk-set a pile of panels which was useful!

[maxajbarlow]

Heads-up: I merged current main into this branch to resolve conflicts that arose after #20 (/Ping keepalive) and #21 (Bonjour discovery) landed.

Resolution approach — your Bonjour design was favored throughout:

• companion/manifest.json and src/config.ts are taken entirely from this PR (the bonjourHost TXT-DeviceType-filtered query array and Regex.IP field — richer than what feat: add Bonjour discovery for panels (#18) #21 added).
• In src/main.ts, your parseIpAndPort() is kept and feat: add Bonjour discovery for panels (#18) #21's now-redundant resolveTarget() was dropped.
• The only thing layered on top is the /Ping keepalive watchdog from feat: add /Ping keepalive and connection health watchdog (#16) #20 (startPingTimer/stopPingTimer, /PingResponse handling, the missed-pong teardown). It slots into parseIpAndPort/target.ip without touching your Bonjour or network-settings work.

Since #21 effectively duplicated the Bonjour feature this PR already had, #18 was closed and the multi-interface nuance you raised is tracked in #22.

Verified locally: tsc build, eslint, and companion-module-check all pass. Note package.json changed here, so a fresh yarn install is needed to regenerate the lockfile.

[peternewman]

Heads-up: I merged current main into this branch to resolve conflicts that arose after #20 (/Ping keepalive) and #21 (Bonjour discovery) landed.

Thanks for the update @maxajbarlow . What (if anything) do I need to do to this PR to get it merged, and hence avoid further conflicts/drift arising?