Skip to main content

Inspecting the running server

Goal​

Pull a structured snapshot of a running server — endpoints, traffic counters, sessions, channels, certificate folders, and capability limits — out into Node-RED so you can wire it to a Dashboard panel, a Debug node, or a status-monitoring flow.

The Server-Info Function​

The bootstrap helper exposes getServerInfo(server), which returns a plain JSON-serialisable object. Hand it handle.server and forward the result as the message payload:

const sterfive = global.get("sterfive");
if (!sterfive) {
    node.error("global.get('sterfive') is not set — is the Sterfive OPC UA palette loaded?");
} else {
    const { getServerInfo } = sterfive.bootstrap;
    const handle = flow.get("$opcuaHandle");

    if (!handle || !handle.isRunning()) {
        node.warn("OPC UA server is not running");
    } else {
        const info = getServerInfo(handle.server);
        node.send({ payload: info });
    }
}

Wire an Inject (or a periodic Inject set to "every N seconds") into this Function and a Debug node onto its output to see the snapshot live.

Shape of the snapshot​

{
  discoveryServerEndpointUrl: "opc.tcp://localhost:4840",
  port: 4840,
  endpointUrl: "opc.tcp://host:4840/...",
  serverInfo:   { applicationUri, productUri, applicationName, ... },
  buildInfo:    { productName, manufacturerName, softwareVersion, buildDate, ... },
  traffic: {
    bytesRead, bytesWritten, transactionsCount,
    currentChannelCount, currentSessionCount, cumulatedSessionCount,
    rejectedSessionCount, sessionAbortCount, sessionTimeoutCount,
    currentSubscriptionCount, cumulatedSubscriptionCount,
    rejectedRequestsCount, publishingIntervalCount
  },
  sessions: [ { sessionId, sessionName, clientApplicationName, channelId,
                creationDate, lastContactMs, sessionTimeoutMs,
                currentSubscriptionCount, currentMonitoredItemCount,
                currentPublishRequestInQueue }, ... ],
  channels: [ { channelId, remoteAddress, securityMode, securityPolicy,
                bytesRead, bytesWritten, transactionsCount }, ... ],
  certificates: {
    rejectedFolder, trustedFolder,
    privateKey, publicKey,
    userRejectedFolder, userTrustedFolder
  },
  capabilities: {
    maxStringLength, maxSupportedSubscriptions, maxSubscriptionsPerSession,
    recommendedMaxSupportedSubscriptions,
    maxMonitoredItemsPerSubscription, maxMonitoredItems,
    fastestPublishIntervalSupported, fastestSamplingIntervalSupported,
    maxPublishRequestsPerSession, securityNoneEnable,
    maxSupportedSessions, goodCompletesAsynchronouslyDelay, maxBrowseNode
  }
}

Common things you can do with it:

  • Trust-store debugging: when a client can't connect over a secure endpoint, certificates.rejectedFolder is where its certificate just landed. Move it to trustedFolder to allow it. (Trust decisions are shared across every server in this Node-RED runtime — see Security policies and certificates.)
  • Capacity check before redeploy: if traffic.currentSessionCount is close to capabilities.maxSupportedSessions, you'll want to schedule the redeploy at a quieter moment.
  • Loop detection: traffic.cumulatedSessionCount minus currentSessionCount is the count of sessions that came and went. A fast-growing delta usually means a client is reconnecting in a tight loop.
  • Session-level diagnostics: sessions[].lastContactMs and currentPublishRequestInQueue flag clients whose subscriptions are stalled.

Pretty-printing to the Node-RED log​

If you want a human-readable dump in the Node-RED log instead of (or alongside) the structured payload, the helper also offers displayServerInfoOn(info, logger):

const sterfive = global.get("sterfive");
const { getServerInfo, displayServerInfoOn } = sterfive.bootstrap;
const handle = flow.get("$opcuaHandle");

const info = getServerInfo(handle.server);
displayServerInfoOn(info, { log: (m) => node.log(m), warn: (m) => node.warn(m) });

The output is already coloured for the terminal; in the Node-RED debug panel it appears as plain text.