feat: Device Name Display Implementation

[tonybentley]

Device Name Display Implementation Summary

Overview

Implemented a device name display feature for WebSocket connections in the SignalK Dashboard using a device registry cache approach. This addresses PR 2017 feedback about reducing UI complexity by integrating device names into the existing Dashboard rather than adding new menu items.

What Was Implemented

New Files Created

1. src/deviceNameResolver.ts - Resolves client IDs to user-friendly names with 4-level priority
2. src/deviceRegistryCache.ts - Event-driven in-memory cache for device registry data
3. src/deviceRegistryCacheInit.ts - Initializes cache and sets up event listeners
4. test/deviceNameResolver.js - Unit tests for name resolution logic (10 tests)

Modified Files

1. src/interfaces/ws.js - Enhanced getActiveClients() to accept optional security context (backward compatible)
2. src/deltastats.ts - Uses device registry cache to resolve display names with principal ID matching
3. src/index.ts - Initializes device registry cache after security setup
4. src/serverroutes.ts - Added event emissions for device updates/deletes
5. packages/server-admin-ui/src/views/Dashboard/Dashboard.js - Shows display names in Connection & Plugin Activity

Architecture Implementation

Device Registry Cache

• In-memory cache maintains copy of all registered devices
• Event-driven updates via deviceUpdated and deviceRemoved events
• Initializes at server startup from security.json
• Thread-safe access to device information

Name Resolution Priority

1. Device description from registry (e.g., "SensESP device: esp32-wireless")
2. Principal name from authentication
3. Parsed user agent (OpenCPN, SensESP, ESP32, Web Browser, etc.)
4. Client ID as fallback

Event-Driven Updates

• Device updates in Security → Devices emit events
• Cache updates immediately upon receiving events
• Dashboard reflects changes within 5 seconds (stats update interval)
• Multiple browser sessions see updates simultaneously

Key Technical Details

ID Matching Solution

• WebSocket providers use principal ID format: ws.{principal-id}
• Device registry uses the same principal ID as clientId
• Matching logic checks both WebSocket connection ID and principal identifier
• Successfully resolves device descriptions when principal matches

Current Behavior

• Device descriptions visible to all users (not just admins)
• This is acceptable as device names are not sensitive information
• Simplifies architecture by avoiding security context in background processes

Testing & Validation

• ✅ Unit tests: 10/10 passing for device name resolution
• ✅ TypeScript compilation successful
• ✅ Visual validation confirmed device names display correctly
• ✅ Event-driven updates validated with screen recording
• ✅ Multi-browser real-time updates working

Uploading Screen Recording 2025-06-22 at 2.17.58 PM.mov…

[KEGustafsson]

Related to ws id visibility on Dashboard, I made this kind of proposal to view devices.
#2013

[tkurki]

No biggie, but for PRs with UI changes including screenshots makes it easier to get the overall impression.

[tkurki]

Build failing with

 157 |                             {client.userAgent && client.description !== client.clientId && (
  158 |                               <br />
> 159 |                               <small className="text-muted" title={client.userAgent}>
      |                               ^
  160 |                                 {client.userAgent.length > 50 ? client.userAgent.substring(0, 50) + '...' : client.userAgent}
  161 |                               </small>
  162 |                             )}

[tkurki]

I think the idea and alternative client naming scheme is sound, but I am just thinking that does it make sense to create one more view under Security or could this information be incorporated in the Devices list? More menu items and more views is more UI complexity for the user - like in what cases would you use the existing list view and when this?

There's also the overlap with the list in the Dashboard. Would it make sense to leverage that view? Additions there are potentially useful for all SK users, not just for those that have security active.

Another point is client-server comms: statistics on the dashboard and Data Browser update via WebScket without any user interaction. This view is showing real time status - what devices are online now, so as a user I would expect this view to update automatically, without reloading the view.

[tonybentley]

I'm going to take a stab at a different approach. The issue I am seeing is regarding the security context and how the dashboard, websocket interface, and delta stats are lacking security context. Instead of adding the new endpoint, I am going to inject security context. Here is a comprehensive plan. Let me know if you would like to keep the new endpoint. It might be useful for something, but not for what is needed to properly display device/client information based on security context.

[tonybentley]

Done

[tonybentley]

@tkurki do you need anything to merge this PR? It's been open for over a month

[tkurki]

Apologies for letting this and the one by @KEGustafsson sit here.

The reason is twofold:

1. this one seems overly complex - why do we need this much more code? why do we need a cache, when the devices are listed in the settings file?
2. the current Dashboard logic does not really reflect the cardinality of websockets - as the key is the device it does not really show if there are devices with active ws connections. this is something i’d like to fix properly, so that the list reflects the number of ws connections producing data. it is a bit problematic, as devices with ws connections are semantically a bit different from the server’s configured connections

So please wait a bit more while I have a go at redoing things a bit differently and circle back to this and #2013