h4 - State Monitor
A tiny node that tells you which run you're on
- Any_In
- loop_count_number
- Any_Pass
ComfyUI doesn't "loop" in the normal sense - the graph is a one-directional pipeline, and when the h4 traffic nodes talk about run 0, run 1, run 2, they're reading a counter that lives in memory. H4_StateMonitor is the little scoreboard that shows you that counter. Drop one anywhere, run the workflow, and it tells you which run you're on.
The node's own description puts it best: "I look at system memory and ask: 'What run is this?'" It's a debug convenience - a way to see the state that the TrafficRouter, TrafficMerge, and TrafficCop are quietly incrementing. If you're building a loop workflow and results aren't changing the way you expect, the first question is usually "am I actually on run 0 or run 1+?" This answers it.
How it works
Every h4_Live traffic node shares one global in-memory counter. Each time a workflow executes, a traffic node bumps it - unless something told it to reset. H4_StateMonitor just reads that counter and hands you the number.
It has two outputs:
- loop_count_number (
INT) - the current run count. Wire this into a Primitive-converted widget, a text display, or anything that wants a number, and you can watch the loop advance. - Any_Pass (
*) - a pass-through of whatever you connect to its optional Any_In input.
That Any_In passthrough is where the one real trick lives: connect your logic node's output to Any_In and the monitor can only run after that node has run. In a loop graph, execution order isn't always what it looks like, and this "daisy chaining" forces the counter read to happen at the moment you actually want it - after the reset, say, not before. The description explicitly suggests this: wire your logic node's output in so the monitor waits for the reset to happen first.
When you'd actually reach for it
- Building your first h4 loop and you want to confirm the counter is incrementing instead of stuck.
- Diagnosing why a
restarttoggle isn't taking effect - check whether the monitor still shows a stale count. - Understanding the order of operations in a feedback graph. It's a debugging aid, not a runtime requirement, so don't leave it in a production workflow.
Installing h4_Live
It's part of the h4_Live pack - one install gets every node. ComfyUI Manager: search h4_Live, install, restart. Or:
cd ComfyUI/custom_nodes
git clone https://github.com/m3rr/h4_Live
Restart and you're done. No model files, no pip requirements; the pack runs on what ComfyUI already ships.
Common issues
- One counter, shared by everything. Every h4 traffic node in the whole graph reads and increments the same counter. Run two separate loops in one workflow and they'll fight over it - one loop's increment feeds the other's run count. There's no per-loop isolation, so keep stateful h4 nodes to a single loop per workflow, or use the Wireless Reset Button to manage it deliberately.
- It reports state, it doesn't change it. New users sometimes wire this hoping to set the count. It's read-only. Resets come from
restart_on_true/restarttoggles on the traffic nodes, or the wireless reset path. - The counter resets when ComfyUI restarts. It's process memory, not persisted. That's usually what you want - fresh start, count at zero - but worth knowing if you reopen a workflow mid-experiment and wonder why run 4 is suddenly run 0.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| Any_Inopt | * | Optional: Connect an output here to force this monitor to wait for that node (Daisy Chaining). |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| loop_count_number | INT | — |
| Any_Pass | * | — |