Home Assistant events, devices, time, and scheduled triggers

Why this chapter matters

Judging by node names alone, it is easy to assume that Events: all, Device, and Time all simply “send a message when something happens.” In practice, Events: all subscribes to Home Assistant events or WebSocket client lifecycle events; Device can operate in Trigger or Action mode; Time schedules messages from the state or an attribute of a specified entity; and Calendar polls a calendar and schedules timers. Choosing the wrong entry point can create a flood of events, repeat operations after reconnection, or turn a read-only flow into one that affects devices.

If you only need to detect an entity changing from off to on, start with Chapter 9, Events: state. If you need to query the current state after a trigger, use Chapter 10, Current State. The nodes in this chapter do not replace state nodes; they handle events and scheduling sources outside the entity-state model.

Do not mix the four trigger models

An event name is not an entity ID. An event type selects event-bus messages, an entity ID identifies a state, a device ID identifies an entry in the device registry, and tag IDs and webhook IDs occupy different identifier namespaces again. Do not interchange identifiers because their strings look similar, and do not treat a UI display name as a stable ID.

Receiving and sending also carry different risks. Events: all, Tag, and Zone are input nodes. Fire Event sends an event to Home Assistant. Device in Action mode sends a device action. Sentence in response mode—and a trigger-mode Sentence configured with a fixed response or timeout fallback—responds to the voice assistant. Time entity in set mode updates an entity value. In a test flow, every sending or response configuration must remain disabled and have no incoming connection.

Validate in six steps by observing, not executing

1. Write one trigger contract.

   Record the source, narrowest filter, permitted fields, disconnection behavior, and duplicate-handling policy. Use whole-value placeholders such as PLACEHOLDER_EVENT_TYPE, PLACEHOLDER_ENTITY_ID, and PLACEHOLDER_DEVICE_ID; never include real environment data.

2. Choose the narrowest node.

   Use Events: state for a state transition, Device Trigger only for an existing device-automation capability, Time for a time stored in an entity, and Calendar for a calendar item. Do not use Events: all with a blank event type as a universal entry point.

3. Create an isolated copy and disable the HA nodes.

   In a test workspace, draw only “disabled trigger node → field allowlist → Debug.” Leave every sending node unwired, especially Device Action, Fire Event, Sentence response, a Sentence trigger with a fixed/fallback response, Time entity set, and any downstream Action.

4. Test branches with synthetic messages.

   Use only core Inject/Change nodes to create data containing no real IDs. Check normal, duplicate, missing-field, unknown, unavailable, and expired-time branches. This tests data routing; it does not reproduce Home Assistant’s complete semantics for each event.

5. Review reconnection and time behavior individually.

   Document the expected behavior for deployment, Node-RED restart, Home Assistant restart, WebSocket disconnection, midnight rollover, and DST transitions. Every uncertain case must take the “no action” branch; do not validate it by resending a real operation.

6. Observe first; seek separate approval later.

   If your organization permits a connection to a test Home Assistant instance, enable only one read-only trigger node at a time and keep downstream Actions disabled. Verify only masked event counts and timestamps. Production actions require a separate change review; this chapter does not authorize enabling them.

Events: all, Sentence, and Fire Event

Events: all: use it only with an explicit event type

In 0.80.3, Events: all accepts an Event Type or, when left blank, receives all events. Both the editor and official documentation explicitly warn that a blank value can overwhelm the WebSocket message queue. Event data must be a JSON object; at runtime, it is matched as a subset of the event content. This matching can further narrow a known event, but it is not a substitute for input validation.

The special event type home_assistant_client receives client lifecycle events, but those messages indicate only a data-loading or client phase. They do not mean that a device state satisfies a business condition. Do not build a gate that waits for connected. Instead, use the lifecycle events actually emitted by the pinned version to update flow health, then query any required state again. Never send a catch-up action directly from a lifecycle event.

Sentence: triggers and responses travel in opposite directions

The Sentence node supports trigger and response modes and requires the separately installed hass-node-red custom integration. In trigger mode, the Home Assistant integration sends the sentence, match result, device ID, and response ID; the output message includes the internal _sentence_response_id. Response mode reads that ID and sends a dynamic response back to the integration. Sentences can reveal household activities and device locations, so Debug must retain only a classification result—not the original sentence or device ID.

A trigger does not need a response node to produce an external response: a fixed response is sent directly, and dynamic mode can send a fallback response after a timeout. For observation only, leave the fixed response and fallback blank or configured not to respond, and do not connect a response-mode node. A node is not purely input merely because mode=trigger. If a response ID expires or is lost, end that invocation; never retry with an old ID.

Fire Event: an output, not a test button

When Fire Event receives a message, it sends fire_event over WebSocket. The event type can come from configuration or the message, and data can be evaluated with a template or JSONata. Other Home Assistant automations may listen for that event, so even “just a custom event” can trigger an alarm, notification, or device control. The example contains only PLACEHOLDER_EVENT_TYPE and blank data. Keep the node disabled, do not connect an Inject node, and do not deploy it to try the button.

Identifier boundaries for Device, Tag, Webhook, and Zone

Device: verify the custom integration and device capability first

The Device node offers Trigger and Action modes. This device-automation path requires the hass-node-red custom integration to be loaded in Home Assistant. Trigger mode registers through the integration and emits a message when the device trigger fires. After receiving a Node-RED message, Action mode sends the configured action and capabilities to Home Assistant. Available triggers, actions, and capabilities come from the integration to which the device belongs; they are not a common list that 0.80.3 provides for every device. You therefore cannot claim that every sensor supports “single press,” every light has the same brightness field, or different brands produce identical data.

If the UI does not show an expected device capability, first confirm the device registry entry and integration support in Home Assistant. Do not hand-write a guessed object. A test should contain only a disabled Device Trigger; leave Device Action unwired. For actual service control, follow Chapter 11, Action node to review the action, target, and data.

Tag: both tags and scanners have sensitive IDs

Tag can listen for one tag or all tags and can restrict which scanning devices are accepted. When no devices are specified, 0.80.3 accepts any scanning device. Output can include the tag name, tag ID, device ID, and user ID. Those fields can reveal people and locations. Apply the narrowest filter and emit only an anonymous purpose code; never use “all tags” in a production flow.

Webhook: knowing the ID may be enough to invoke it

The Webhook node requires the separately installed hass-node-red custom integration in Home Assistant. It registers a webhook ID and the permitted POST, PUT, GET, and HEAD methods with that integration, then receives payload, headers, and params. It is not a Node-RED HTTP In node and does not imply authenticated user access. Actual reachability depends on Home Assistant’s network exposure and webhook mechanism. Do not expose Home Assistant for convenience, and never put a webhook ID in a tutorial, screenshot, repository, or Debug output.

Zone: crossing a boundary does not guarantee real-time presence

Zone compares the old and new coordinates of a person or tracked entity with zone coordinates to detect enter, leave, or both. It emits no output without old_state/new_state, location data, or zone data. Location latency, GPS drift, and radius boundaries can cause flapping, and location data is highly sensitive. A safe flow emits only “anonymous zone state changed,” adds a duration threshold or cooldown, and never stores coordinates.

Time and Time entity: scheduling and writable time entities

The Time node reads a property from a specified entity; the default is state. This chapter guarantees only a previously validated date string—preferably ISO 8601 with an offset—or HH:MM[:SS]. If an upstream value is a numeric epoch, explicitly convert it to an ISO string before passing it to Time; do not pass the number directly. The node applies a positive or negative offset, can optionally randomize within the offset range, and can repeat daily on selected weekdays. It rebuilds the timer when the entity state or attribute changes. Treat unavailable values, type mismatches, invalid dates, nonnumeric offsets, and a repeating schedule with no selected weekday as configuration or data errors that produce no output.

DST is not simply a one-hour addition or subtraction. Some local times do not exist on a particular day; others occur twice. Test in isolation using the actual time zones of Home Assistant, the Node-RED host, and the source calendar. Record the expected behavior for both the spring-forward and fall-back transitions, and make downstream actions idempotent. When you need an absolute time, retain an ISO timestamp with an offset and convert it only for display; do not mix it with time-zone-free strings.

Time entity is a separate node. It requires the hass-node-red custom integration in Home Assistant and works with an Entity config to expose a time value to Home Assistant. Its modes are listen, get, and set. set is a write operation; in 0.80.3, it validates 24-hour HH:MM[:SS] and adds seconds when omitted. listen and get process the existing value. It is not a replacement for the ordinary WebSocket Time trigger. Keep all three modes disabled in testing, and in particular do not connect set to any untrusted message.

Calendar scheduling, restarts, and deduplication

Events: calendar selects one calendar entity and triggers at its start or end, adjusted by a positive or negative offset. Filter performs a substring match against the summary. The 0.80.3 source polls about every 15 minutes and uses a 1-minute overlap between query windows. After retrieving events, it schedules precise timers in an in-memory queue and reduces duplicates with a cache of emitted events. It aligns all-day events to midnight before applying the offset.

These mechanisms improve ordinary scheduling, but they do not mean “never miss and never duplicate.” A last-minute addition or modification between polls may not be discovered in time. Restarting Node-RED clears in-memory timers and the emitted-event cache, and the rescan result depends on the query window at that time. Network errors are retried, but no usable events remain if that polling round ultimately fails. Your business rules must define the recovery policy; do not claim that the node guarantees catch-up delivery.

A safe “meeting reminder” specification

• Keep the Calendar node disabled and set calendar to PLACEHOLDER_CALENDAR_ENTITY. Use a classification term containing no name or location as the Filter.
• Retain only an anonymized UID hash, event start time, and classification in output; do not record description, location, or the original summary.
• Build a deduplication key from “anonymous UID + occurrence date + reminder type.” Give the key a reasonable expiry; do not retain schedule details indefinitely.
• Send events that exceed the lateness tolerance, fail time parsing, arrive just after reconnection, or lack required data to a bounded diagnostic Debug—not to a notification Action.
• Keep the real notification node disabled until the rate-limit and error-branch checks in Chapter 14, notifications and error branches receive separate approval.

If a schedule only needs to wait for an entity condition rather than a calendar time, use the Wait Until design in Chapter 13. These approaches respectively answer “when is the scheduled time?” and “when does the condition become true?” Do not use a long Delay to guess an external state.

Troubleshooting: disable first, then inspect the source

• Events: all produces a message flood: disable the node immediately. Check whether Event Type is blank and whether the event data JSON actually narrows the match. Clear Debug, then review only the known PLACEHOLDER_EVENT_TYPE; do not use all-events mode to search for an answer.
• The Device list lacks an expected trigger/action: the current integration or device usually does not expose that capability. Confirm the Home Assistant device registry entry, integration status, and 0.80.3 compatibility. Do not copy another device’s configuration or guess a capability by hand.
• Time reports invalid, unavailable, or in the past: check the property path, original type, time zone, offset, and weekday selection. Route invalid data to an error branch; do not reuse an old time or mistake ignore past date for catch-up execution.
• Calendar misses a last-minute change: compare the event update time with the approximately 15-minute polling boundary and check whether the API query exhausted its retries. If the requirement cannot tolerate polling latency, stop the automation and select a different architecture instead of shortening an undocumented internal constant.
• An event appears duplicated after reconnection: compare the source event ID, business deduplication key, running timestamp, and deployment time. Block every Action first, then determine whether the source resent the event, states reloaded, or the flow restarted. Do not delete deduplication data merely to try again.
• Webhook, Tag, Zone, or Sentence Debug output exposes data: disable the flow and delete that Debug message. Rotate an exposed webhook ID; mask tag, device, and user IDs, coordinates, and original sentences. Follow the incident-reporting procedure, and never paste raw output into a public issue.

Pinned sources and related nodes

This chapter uses the exact pinned commit of HA WebSocket 0.80.3 as its version boundary. Official node documentation supplements the operational semantics; if rolling documentation has changed, use the pinned source to determine this chapter’s baseline.

• HA WebSocket 0.80.3 pinned commit 2cbbb69
• Official Events: all documentation, 0.80.3 Device automation documentation, and Calendar documentation
• Official Time documentation, 0.80.3 Time entity documentation, and 0.80.3 Webhook documentation
• 0.80.3 Sentence documentation and the hass-node-red custom integration (with no assumed version)

This chapter covers 10 related nodes: Device, Events: all, Events: calendar, Fire Event, Sentence, Tag, Time, Webhook, Zone, and Time entity. Fire Event, Device Action, Sentence response, a Sentence trigger with a fixed/fallback response, and Time entity set all have external side effects and must remain disabled in every example. Device automation, Sentence, Webhook, and Time entity also require the custom integration.

FAQ