@vintecc/node-red-capture 1.0.7

Capture UNS/Raw MQTT nodes for Node-RED

npm install @vintecc/node-red-capture

capture-mqtt-node

Node-RED nodes for the Capture platform's MQTT broker: subscribe to raw/uns data (capture-in) and publish to data/read (capture-out).

Running it

docker compose up

Node-RED will be available at http://localhost:1880. This repo is mounted straight into Node-RED's node_modules, so the Capture category (broker config, capture-in, capture-out) shows up in the palette on startup.

Changes to nodes/*.js/nodes/*.html need a container restart to be picked up:

docker compose restart

Nodes

• capture-broker — config node holding the broker URL and credentials.
• capture-in — subscribes to v1/raw/... or v1/uns/... topics.
• capture-out — publishes to v1/sources/<SourceID>/data/read/.... Topic segments (sourceId, connectionTag, measurement, key) and payload come from the incoming msg, not node config — see the node's help panel for the expected shape.

Note on credentials

Per Capture's MQTT docs, data/read can only be published to by a source/device account (credentials from that source's auth config in the Capture portal), not a regular user login — capture-out will get disconnected by the broker if used with the wrong credential type.

• capture-in (subscribe): use a regular Capture user account (username/password), or a user API token as username with an empty password.
• capture-out (publish): use the target device's own credentials — username is that device's ActivationUID, password is the one Capture generated for it. A user account, or a different device's credentials, will connect fine but get rejected the moment it tries to publish.

One broker config node only holds one identity — if you need a subscriber and a publisher running at the same time, use two separate capture-broker nodes.

Troubleshooting

Hard-won lessons from getting this working end-to-end against a real Capture environment — read this before re-debugging from scratch.

"Connection refused: Not authorized" right at connect time. This is an auth/authorization rejection, not a network issue (per Capture's own docs: "if you get disconnected immediately after connecting, it is most likely an authorization issue"). Check, in order:

1. Is the capture-broker URL pointing at the right environment? A device created via one environment's config API (e.g. a dev broker) does not exist in a different environment's (e.g. production) user/device database — same credentials, different broker host, will get rejected outright.
2. Are the credentials actually the right type for this node (see above)?

Connects fine, publishes report success, but nothing ever shows up anywhere (not the device's "Last data package", not the raw topic tree, nothing). This is more subtle: at QoS 0, client.publish()'s callback fires the instant the packet hits the socket — the broker never has to acknowledge anything, so a broker-side rejection (wrong topic scope, bad routing, whatever) is completely invisible to the client. Don't trust a clean "Published" status alone. To actually confirm data landed:

• Subscribe directly to the equivalent v1/raw/<Company>/<SourceID>/<ConnectionTag>/<Measurement>/# topic with a user account and watch for the message to arrive there — this doesn't depend on any UNS mapping.
• Check the device's own info panel in the Capture portal for "Last data package"/"Last heartbeat" actually updating.
• If neither ever updates despite clean, error-free publishes, the issue is on the device/environment side, not in this code — try the same publish with an already-proven tool/device before assuming a bug here.

Two connections sharing the same credentials fight each other. Capture's broker appears to allow only one live session per identity. Two capture-in/capture-out nodes pointed at the same capture-broker config, or a second external client (MQTT Explorer, another tool) connecting with the same device's credentials at the same time, causes either visible reconnect-cycling or — more confusingly — one connection silently not having its publishes routed while it still reports "connected". If something that used to work suddenly stops, check for a second connection using the same identity first.

Data lands in the raw tree but not the UNS builder. These are independent. Raw is populated automatically from data/read publishes; UNS requires a separate, explicit one-time mapping of the measurement/fields to UNS variables in the portal's UNS builder. No data in raw either means something's wrong upstream of UNS entirely — check that before assuming a mapping problem.