ComfyUI Node

Wireless Send

Hide a wire without hiding your data

By jeremieLouvaert·Created 7 months ago·Updated 17 days ago· 1
Wireless Send
  • value
  • passthrough
channelchannel_1

The name sounds like networking. It isn't. Wireless Send just stuffs whatever you hand it into a named slot in ComfyUI's memory, and its sibling Wireless Get pulls it back out somewhere else on the canvas - no API, no key, no WiFi, not even a wire. It's the Blackmagic Fusion Wireless Link idea ported to ComfyUI, and for a two-node pack that's basically the whole pitch.

Why reach for it? Because a workflow that's loading a model once and feeding three pipelines gets unreadable fast. The usual fixes are reroutes and context bundles from packs like rgthree - nodes that tidy the lines. This is a different trick: it cuts the line entirely. Load your checkpoint, send its MODEL/CLIP/VAE out to named channels, and every branch downstream just does a Get. One Send, many Gets, and nothing crosses the canvas but the channel name.

Here's the honest tradeoff, because nobody says it: a wireless channel is a global store, not a connection. It can't show you what's upstream, it can't stop you reading a channel nobody wrote, and the ordering is on you. For a small workflow that's a needless abstraction. Where it earns its keep is a big graph where the alternative is three crossing wires you'll spend ten minutes untangling later.

How it works

Inside, it's almost embarrassingly simple. The node writes your value into a module-level WIRELESS_STORAGE dict keyed by channel name, marks the channel as freshly written for this execution, and returns the same value out its passthrough port. There's no serialization, no copying semantics beyond Python's usual references - images, models, latents, strings, conditionings, all just move as-is.

Two implementation details are worth knowing because they shape how you use it. First, the value input is forceInput, so it's a socket, not a widget - you can't type a value in, and you wouldn't want to. Second, the node forces re-execution every queue, precisely so it can re-mark the channel fresh and keep Get's stale-data detection honest. The write itself is a dict assignment, so the extra run costs nothing.

The inputs that matter

  • value (ANY) - the actual payload. Wire anything: IMAGE, MODEL, LATENT, CLIP, VAE, STRING, conditioning. It does not discriminate.
  • channel (STRING, default channel_1) - the one field you'll actually set. Case-sensitive, so photo and Photo are different channels and Get won't find the one you meant. The default channel_1 matches Get's default, so a fresh Send + Get pair just works before you've typed a thing.

Output is a single passthrough (ANY) - identical to the input. It exists so you can chain Send into the normal flow and lock down execution order (more below).

Install

ComfyUI Manager - search "wireless link" - or the old reliable way:

cd ComfyUI/custom_nodes
git clone https://github.com/jeremieLouvaert/comfyui-wireless-link-simple.git

Then restart ComfyUI. The nodes land under the wireless category. No extra dependencies, no model downloads, nothing - this is one Python file.

Where people get burned

Forgetting the passthrough. Send is marked as an output node, so it does run even with nothing downstream - but without a wire to follow, ComfyUI's executor doesn't guarantee when. If Get fires first, you get "Channel not found." The fix is in the README and it's worth following: run Send's passthrough into a real downstream node (Preview, Save, anything). That chains execution order so Send always fires before Get.

Case drift. Typing base_image on Send and Base_Image on Get. It fails loudly, at least.

Stale data. The console prints a warning when a channel holds data from a previous execution - usually because you removed a Send node but left the Get, and it's happily reading last run's value. Treat that warning as "this graph is broken, not just old."

One more oddity: the string <auto> is reserved on Send. It's Get's auto-resolution token, so Send raises an error rather than letting you name a channel that would fight Get's special case. Channel names are cheap; just pick a real one.

A note on reach: this isn't a celebrated pack, and that's fine. It's MIT, it's one file, it does one thing cleanly. If you need wireless routing you've almost certainly got a specific mess in mind - and for that, this is about as small a hammer as exists.

Categorywireless

Inputs (2)

NameTypeDefaultDescription
value*Any data to send wirelessly (IMAGE, MODEL, LATENT, CLIP, VAE, STRING, etc.)
channelSTRINGchannel_1Channel name — must match exactly on the Get node (case-sensitive)

Outputs (1)

NameTypeDescription
passthrough*