Disable Enable Switch (JPS)

This is the twin of Enable Disable Switch (JPS), and if you've found this page you've probably already found that one - same logic, same use case, opposite ordering. Both exist because ComfyUI's widget-type matching for combo/enum inputs cares about the exact list of options and their order, and different node authors declare their enable/disable widgets in different orders. Some nodes (the README's own example is KSampler-adjacent options) expose a dropdown that lists disable first, enable second; others list them the other way. JPS ships one switch for each so you've always got a matching output type to wire in, instead of getting a "type mismatch" the one time you happen to pick the wrong twin.

How it works

Two integers, select and compare (both 1–9), plus match - "Set to Disable" or "Set to Enable." When select equals compare, the output takes whatever match says; when they don't match, it flips to the opposite. The single output, disable_enable, only ever carries the literal values disable or enable, typed as that specific pair in that specific order - which is the whole reason this node exists as a separate class from its sibling rather than the two being interchangeable.

Where this is actually useful

The scenario is identical to Enable Disable Switch: you're driving several branch-selecting switches off one shared select value elsewhere in the graph - flip a number, and Model Switch, Latent Switch, Conditioning Switch all jump to the matching branch together. If part of that same branch logic needs to toggle a node whose input widget happens to be typed disable/enable (rather than enable/disable), plug this node in instead of its sibling - set compare to the branch number that widget should read as active, point select at the same shared driver, done. The only decision to make is which of the two switches actually matches the target widget's declared option order, and that's something you generally have to check by trying the connection - ComfyUI will refuse it outright if the types don't line up.

Installing it

Through ComfyUI Manager (search "JPS Custom Nodes for ComfyUI"), or manually:

cd ComfyUI/custom_nodes
git clone https://github.com/JPS-GER/ComfyUI_JPS-Nodes.git

Restart ComfyUI and find it under JPS Nodes/Switches, right next to Enable Disable Switch. If you're reinstalling over an older copy of the pack, delete that first - the author's README is explicit that two overlapping installs collide on class names. No models, no extra dependencies.

Where people get tripped up

The most common mix-up is grabbing this node when the widget you're actually targeting wanted the other ordering, or vice versa - since both nodes look and behave identically apart from the option order baked into their output type, it's an easy one to get backwards, especially if you're copying a pattern from an example workflow without checking which twin it actually used. If ComfyUI refuses the connection, that's your answer: try the other switch. Past that, the comparison logic itself trips people up the same way it does on the sibling node - the output depends on whether select matches compare, not on the raw value of either number alone, so trace through manually if the enable/disable state isn't what you expect. And remember disable_enable is a dedicated type, not a boolean or string - it only wires into inputs specifically built to accept it.