MQTT Publish Image Metadata (JSON)

This is the leaner half of the comfyui-mqtt-node pack, and it does exactly what its name says. Instead of pushing the full image onto an MQTT topic, it publishes a small JSON object describing that image - dimensions, batch size, channel count, dtype - plus any custom fields you add. If your subscriber only needs to know that a render happened, how big it was, and maybe which workflow produced it, this is the node you want. It's the "metadata is the payload" idea ComfyUI already lives by in its PNG files, applied to the wire instead of the file header.

Why a separate node for this? Size, mostly. A JPEG render is hundreds of kilobytes to a couple of megabytes once base64-encoded; the metadata JSON is a few hundred bytes. Publish that to your broker and you can run a monitoring dashboard, trigger a Home Assistant automation ("a 1024×1024 portrait just finished"), or log generation events for analytics without swamping the bus. It's also the node in this pack that works out of the box - more on that below.

How it works

The mechanism is almost embarrassingly simple. The node reads the shape of your input image tensor, builds a dict with batch_size, width, height, channels, and dtype, merges in whatever's in custom_data, serializes it with json.dumps, and publishes that single string to your topic via paho-mqtt. No image encoding, no base64, no binary anywhere. The image tensor is only there to report on - which is exactly why the sibling image node's bug (a missing import base64 in the current release) doesn't touch this one. This node just works.

The inputs that matter

Same broker plumbing as its sibling - you set four things and leave the rest alone:

• broker_url / broker_port - defaults localhost:1883; TLS brokers usually on 8883.
• topic - default comfyui/metadata.
• use_tls - flip on with username/password on any real broker.
• custom_data - a multiline JSON string merged into the payload. This is where your own fields go, e.g. {"workflow": "portrait_generation", "tags": ["AI", "portrait"]}.

Two warnings on custom_data. First, it must be valid JSON: a parse error is silently swallowed and the node publishes {} instead of telling you anything's wrong. Second, it merges over the auto-generated keys, so a conflicting key in your JSON can overwrite width/height/etc. Keep your own keys distinct. qos (default 1) and client_id are the only other options you'd touch.

Outputs: image is a straight pass-through - the node counts as an output node but hands your tensor on, so you can publish early and keep rendering. status returns the ✓ Published metadata to … or ✗ MQTT Error: … string.

Installing

Identical to the image node - one pack, one install, both nodes. There are no model files to download; the only real dependency beyond what ComfyUI already ships is paho-mqtt:

cd ComfyUI/custom_nodes
git clone https://github.com/eljefe80/comfyui-mqtt-node
cd comfyui-mqtt-node
pip install -r requirements.txt

Restart ComfyUI, or search "comfyui-mqtt-node" in ComfyUI Manager. The repo also documents a Kubernetes initContainer install if your ComfyUI lives in a cluster.

Troubleshooting

The broker-side suspects are the same as always: connection refused when mosquitto isn't running, and TLS failures, because the pack uses CERT_REQUIRED with TLSv1.2 and no CA-file option - self-signed certs won't connect, and the hostname must match the certificate. Check the status string first, though; every error lands there and in the console. Test against a local broker before wiring up a cloud one:

mosquitto_sub -h localhost -t "comfyui/metadata" -v

One honest caveat before you trust it with production: this is a small pack from an author with essentially no community footprint, and the README itself warns it's AI-generated and hand-edited. Nothing here is hostile - it's just paho-mqtt talking to a broker, no keys, no phone-home beyond your own bus - but a node that sends data and credentials over the network by design is exactly the shape to keep an eye on with any fresh install. Verify against a local broker first and keep broker passwords out of shared workflow files, and you're fine.