A doorbell rings on its own. A cache only answers when you knock

Every node in this chapter reads Home Assistant state one way or another, but they split cleanly into two families, and mixing them up is where most confusion starts. Events: state has no input at all — it is a zero-input event node that subscribes to matching entities the moment the flow deploys, and it emits a new message every time a real state_changed event arrives on the WebSocket. Current State and Get Entities are the reverse: they do nothing until an upstream message reaches them, and when one does, they read whatever the integration's cache currently holds — never a live round trip to Home Assistant's API.

Which entities wake the node, and the state shapes it actually receives

Events: state's entities configuration holds three selector groups: entity for exact matching, substring for a matching fragment, and regex for a pattern. An event only needs to satisfy any one of the three — they are not combined with AND. When only exact entity selectors are configured, the runtime opens a specific listener for each one. The moment substring or regex is used at all, it instead subscribes to the general state_changed topic and runs every event through shouldIncludeEvent to decide whether it counts.

Now the part that trips people up. In a raw Home Assistant state_changed event, event.old_state and event.new_state are each either a state object or null. An entity being created typically has no old_state; an entity being deleted has no new_state. Both of those are completely different from an existing state object whose state string happens to be unknown or unavailable — those are real strings sitting inside a real object, not an absence.

Here is where the pinned build adds its own twist. Home Assistant's own state object model allows a genuine deletion event with new_state: null. But in HA WebSocket 0.80.3, the integration's own WebSocket handler checks the new_state object and the entity ID before it ever emits its internal event topic — and if either one is falsy, it discards that state_changed event right there. Events: state v6 never sees it. There is no configuration on the node itself that restores a deletion branch; the event is gone before the node's selectors, ignore options, or anything else get a turn.

sequenceDiagram
  participant HA as Home Assistant core
  participant WS as WebSocket handler (0.80.3)
  participant N as Events: state node
  HA->>WS: state_changed, entity removed, new_state is null
  WS->>WS: new_state or entity_id falsy: event is discarded
  Note over WS,N: Events: state never receives this event
  HA->>WS: state_changed, state becomes "unknown"
  WS->>N: forwarded as a normal event
  N->>N: unknown is a string state, handled by the ignore options

Do not assume that every state_changed event even changes the state string, either. Attribute-only updates and timestamp refreshes can fire the same event type. That fact matters as soon as the next section's only-change filter enters the picture.

The full path from a raw event to a message on the wire

Once an event clears the selectors, v6 runs it through a fixed sequence: five ignore options, then only-change, then If State, then For, and only after all of that does it write your configured Output Properties onto a new msg. Each stage can end the story silently. None of the five ignore options do anything clever — each one just decides whether to skip the whole event.

Next is only-change (outputOnlyOnStateChange), which compares the converted old and new state strings for a normal event and returns with no output when they match. Then If State, which compares the converted new state using is, is not, greater-than, less-than, includes/not in, or a JSONata expression. With no condition configured there is simply one output. Once a condition exists, a true result uses the first output and a false result uses the second — and that second output is not an error channel, it is just “the condition was false.” Catch it with a genuine Catch or Status node if what you actually need is configuration or runtime errors, not a false condition.

flowchart TD
  A["A state_changed event
arrives on the WebSocket"] --> B{"Node enabled, and
HA already running?"}
  B -->|"no"| Z1["Not processed"]
  B -->|"yes"| C{"Does entity, substring,
or regex match?"}
  C -->|"no"| Z2["Skipped, no output"]
  C -->|"yes"| D{"Ignore option hits: null
old_state, or unknown /
unavailable on either side?"}
  D -->|"yes, ignored"| Z3["No output, event ignored"]
  D -->|"no"| E{"only-change on, and
the state string is
unchanged?"}
  E -->|"yes"| Z4["No output"]
  E -->|"no"| F{"Is If State configured?"}
  F -->|"no"| G["Standard output,
Output Properties applied"]
  F -->|"yes, true"| G
  F -->|"yes, false"| H["Second output,
not an error"]

Last comes For, which can be a plain number, a JSONata expression, or a value from flow or global context, and it must be nonnegative — an empty string or 0 means no delay at all. A separate timer is tracked per entity ID. When a normal event starts one, a later event for the same entity that fails If State marks that timer inactive and sends it down the false path; a new event that does pass clears any running timeout and starts a fresh one. This timer lives only in the node's memory. A restart does not preserve it as a countdown, and it is not an HA history query of any kind.

One more trap worth naming here: the default v6 stateType is str. A numeric conversion runs the value through parseFloat, and the general boolean conversion is plain JavaScript !!value — which means every nonempty string is true, including "off". If you need a real on/off test, keep the string and compare it explicitly, or use one of Home Assistant's own boolean rules rather than a bare truthiness check.

What happens the moment the listener starts, and after it drops

With Output on Connect turned on, the moment the node's listener starts — immediately if HA is already running, or once InitialConnectionReady fires if it isn't — v6 converts every currently cached entity that matches its selectors into a synthetic state_changed event, with both old_state and new_state pointing at the same current object. Each one is processed with runAll=true. That flag bypasses the only-change comparison entirely, which is the main source of a burst of messages right after deploy or restart: only-change was never asked whether anything changed, because for a synthetic event it wasn't given the chance.

runAll=true also skips the For timer path outright — the controller returns directly along the valid-timer branch rather than starting a new one. So if you combine Output on Connect with a For duration, do not assume every currently matching entity will patiently wait out the full For window after reconnecting before it produces output; that is not how the two interact, and the only honest way to know for a specific combination is to test it, not to guess from the field names.

The controller also checks homeAssistant.isHomeAssistantRunning directly: it will not process a normal event while the WebSocket itself is connected but Home Assistant has not finished starting. And after any reconnection, remember what the cache actually is — a snapshot of right now, not a replay. The event stream gives you no guarantee that it will hand you everything that happened while you were disconnected.

Current State v3: one entity, read on demand, with a lock on the door

Current State does the opposite job from everything above: it waits for a msg, then reads exactly one entity out of the WebSocket integration's cache with getState(entityId). The entity ID itself can come from three places. The node checks msg.payload.entity_id first, then falls back to the camel-case msg.payload.entityId, and otherwise uses the configured entity_id — which is itself rendered through Mustache. Block Input Overrides is the switch that decides whether either payload property is even allowed to matter: turn it on, and the configured entity always wins regardless of what arrives in the message.

flowchart TD
  A["msg arrives at
Current State v3"] --> B{"Block Input
Overrides enabled?"}
  B -->|"yes"| C["Configured entity_id is
used. Payload overrides
are ignored"]
  B -->|"no"| D{"Does payload carry
entity_id or entityId?"}
  D -->|"neither"| C
  D -->|"either one"| E["That value replaces the
configured entity_id"]
  C --> F{"Entity found in the
WebSocket cache?"}
  E --> F
  F -->|"no"| G["InputError: not found.
No normal message is sent"]
  F -->|"yes"| H["timeSinceChangedMs added,
Output Properties applied"]

When the entity is missing from the cache, the node throws an InputError reading “not found.” It does not quietly send a normal message with some default or false-ish payload — catch the error with a Catch node if you want to observe it, but do not fabricate a value in its place. When the entity is found, the controller adds timeSinceChangedMs to it, and if you selected a non-string State Type, it preserves original_state before converting — the same truthiness trap from the previous section applies here too: a bare boolean conversion turns any nonempty string, "off" included, into true.

The For comparator here only combines with is, is not, includes, and does not include, and it only applies once the condition itself has already matched. To actually wait for a condition rather than test a snapshot's age, that is Wait Until's job, with a real timeout. (The official Current State documentation covers every field directly; this section only adds the version-specific behavior worth knowing before you rely on it.)

Get Entities v1: rules across the whole cache, with no lock on the door

Where Current State reads one entity, Get Entities scans every cached state and keeps the ones that pass a set of rules. A rule can inspect a state property directly, or reach into the entity registry for device, area, floor, or label metadata — an area comes from the entity itself or from its device, a floor comes from that area, and a label rule checks labels on the entity, its device, and its area. Multiple rules are combined with AND: any single failed rule excludes the entity. At runtime the node happens to sort rules into label, state, device, area, floor order before evaluating them, but no downstream logic should ever depend on that particular order. Except for a JSONata rule, a state property that is simply missing does not match — it is treated as a fail, not as a wildcard pass.

flowchart TD
  A["Get Entities v1 evaluates
its rules against the cache"] --> B{"outputType"}
  B -->|"array"| C{"outputEmptyResults
true?"}
  C -->|"yes"| C1["Empty array is sent"]
  C -->|"no"| C2["No message is sent"]
  B -->|"count"| D1["Number is sent,
0 counts as a normal result"]
  B -->|"random"| E{"Any matches?"}
  E -->|"none"| E1["No message is sent"]
  E -->|"one or more"| E2["One entity, or an array
sized by outputResultsCount"]
  B -->|"split"| F{"Any matches?"}
  F -->|"none"| F1["No message is sent"]
  F -->|"one or more"| F2["One message per entity,
msg.parts added"]

Random shuffles the matching set and then takes the requested count — it is sampling, not secure allocation or fair rotation. Split deletes the original message's _msgid, creates msg.parts with a new sequence id, a count, and a per-message index, then clones one message per entity; a downstream Join node should key off msg.parts to reassemble the batch, and its own wait should carry a timeout.

Those six properties are always live, with no checkbox anywhere to disable them:

Validating the incoming payload and forwarding it is still not enough on its own, because the dangerous keys are still sitting there afterward — safe handling means building a fresh message, or explicitly deleting every one of the six before a trusted node writes the real, fixed rules. (See the official Get Entities documentation for the rule syntax itself.)

Two nodes with no built-in fence, and where you have to put one yourself

Get History reaches past the cache into Home Assistant's own history store, and it too reads several overrides straight from msg.payload, with no Block Input Overrides switch to stop it: startDate, endDate, entityId, entityIdType, relativeTime, and flatten. Before an untrusted input reaches this node, delete all six of those properties, or rebuild a clean payload against an allowlist and a proper date schema. Just as importantly, the node itself sets no ceiling on the number of results it can return, and its underlying HTTP client applies no request timeout of its own. A short time window, a restriction to one entity, a response-size budget, and any proxy or caller timeout are all fences you have to build outside the node — none of them come from Get History itself.

Wait Until plays a different role entirely: it holds one incoming message, plus its configuration, in a single active slot, until a condition is met or a timeout expires. A later input does not queue behind the first — it cancels whatever timer is currently running and replaces the stored message outright. A timeout of 0 creates no timer at all, which means the node simply waits until the condition becomes true, until it is reset, until a new input replaces it, or until the node itself stops; there is no deadline in play. A safer configuration uses a finite, positive timeout with separate outputs for success and for timeout, and treats a timeout strictly as “the condition was not observed by the deadline” — not as a green light to act on its own.

The symptoms that actually show up, in the order you are likely to meet them

The ones that come up again and again

Where to go from here