Skip to main content

Monitoring a NodeId from the message

This tutorial shows how to let the incoming message decide which variable a Monitor node watches, instead of configuring it in the node.

Useful when:

  • the variable to monitor comes from user input or application logic
  • you want to switch variables without editing the flow
  • you are building a flexible monitoring system

The one setting that matters​

Open the Monitor node and click the first stop of the NodeId prefix — the source — then choose the message.

The field then holds a message path, not an address. For a Monitor node the default is payload.nodeId, and the field suggests the paths this node honours.

Why this is a setting and not a convention

Before 3.40 you made a node message-driven by leaving its NodeId empty and hoping nothing else filled it in. Now you say so explicitly, and the node cannot be surprised by an upstream inject node. See Where does the NodeId come from?.

Configuration​

  1. NodeId source: the message, path payload.nodeId
  2. Start Immediately: unchecked — the node waits for the first message before subscribing
  3. Sampling Interval: 1000 ms, Queue Size: 10, Discard Oldest: true (the defaults; adjust as needed)

Sending the NodeId​

Send the address at the path you named:

{
    "payload": {
        "nodeId": "ns=1;s=Temperature"
    }
}
msg.topic does not work here

The Monitor node has never read msg.topic or msg.nodeId — only the payload. If you are coming from a Read node, this is the one place the two differ. Under the message mode it reads exactly the path you named and nothing else.

Example flow​

[
    {
        "id": "inject1",
        "type": "inject",
        "name": "Monitor Temperature",
        "payload": "{\"nodeId\":\"ns=1;s=Temperature\"}",
        "payloadType": "json",
        "wires": [["monitor1"]]
    },
    {
        "id": "monitor1",
        "type": "OpcUa-Client2-Monitor",
        "name": "Dynamic Monitor",
        "endpoint": "opcua_endpoint1",
        "subscription": "subscription1",
        "startImmediately": false,
        "nodeId": "payload.nodeId",
        "nodeIdSource": "msg",
        "samplingInterval": 1000,
        "wires": [["debug1"]]
    },
    {
        "id": "debug1",
        "type": "debug",
        "name": "Show Value",
        "wires": [[]]
    }
]

Note nodeId holds the path and nodeIdSource is "msg" — that pair is what the editor writes when you pick the message.

How it works​

  1. Click the Inject node button.
  2. The Monitor node reads msg.payload.nodeId.
  3. The subscription starts on ns=1;s=Temperature.
  4. Value changes are sent to the output.

More than one variable​

The message mode passes whatever it finds at the path through untouched, so the same setting covers every shape the Monitor node supports:

The path points atThe node monitors
a stringone variable
an array of NodeIdsall of them — see Monitor Multiple Variables
an object tree of NodeIdsthe same tree, with values written back in place — see Monitor JSON Structure

So a path of payload.tags pointing at a list of NodeIds drives an array subscription with no further configuration.

Tips​

Subscription lifecycle​

  • The subscription starts when the first message arrives.
  • Injecting a new NodeId switches the monitored variable.
  • The subscription stays active until the flow is stopped.
  • An OPC UA server only sends notifications when a value changes — no change, no message.

Performance​

  • Changing the monitored NodeId frequently has a cost: each change unsubscribes the old item and subscribes the new one.
  • To watch several variables at once, send an array rather than switching repeatedly.

Error handling​

If the path is missing on the incoming message, the node reports a targeted error naming the path — it does not silently fall back to a configured value. Wire a Catch node to handle it:

// in a function node wired to a Catch node
node.warn("Monitor could not resolve its NodeId: " + msg.error.message);
return null;

Troubleshooting​

Nothing happens after injecting​

  1. Check the NodeId source is the message (the first stop shows an envelope).
  2. Check the path matches what you actually send — payload.nodeId, not payload.
  3. Check Start Immediately is unchecked.
  4. Validate the NodeId itself with the verify button on a Read node.

The configured NodeId is used instead of mine​

The source is set to this node. That is the point of it: under this node the message cannot retarget the node. Switch the first stop to the message.

My array payload is ignored​

Same cause. Under this node the node monitors its own configured NodeId and reports once that the payload was ignored. Switch to the message.

Next steps​

See also​