The Event Bus
Inside WoowTech, the moving parts rarely talk to each other directly. Instead they broadcast small signals onto a shared message channel called the event bus, and any interested listener picks them up. Whenever a sensor flips, a service runs, or the system boots, a corresponding signal is published. Automations can subscribe to these signals and act on them.
How state changes relate to events
Each entity that WoowTech manages publishes a signal every time its value moves. That signal is just one flavor of message travelling across the bus — plenty of other flavors exist, including internal housekeeping messages that integrations use to stay in sync with one another.
Don't confuse a state-change signal with an event entity
A state-change signal and an event entity are two different things. An event entity is simply a category of entity; like every other entity, it emits its own state-change signals when something happens to it. The signal itself — published under the name state_changed — always carries both the value the entity held a moment ago and the value it holds now.
Fields present on every event
No matter which kind of event you are looking at, the following attributes are always attached:
| Field | What it holds |
|---|---|
event_type |
A label naming the kind of event, such as call_service |
origin |
Where it came from — REMOTE for anything arriving through the API or a webhook, LOCAL for the rest |
time_fired |
The moment of firing, for example 2022-01-28T12:19:53.736380+00:00 |
context |
A small record carrying id, parent_id, and user_id |
On top of those, every event ships a data map holding whatever is specific to that event type.
Core events fired by WoowTech itself
call_service
Published the moment a service action is invoked.
| Field | What it holds |
|---|---|
domain |
The domain the action belongs to, e.g. light |
service |
The action that ran, e.g. turn_on |
service_data |
The parameters that were passed, e.g. { 'brightness': 120 } |
service_call_id |
A unique tag for the call, e.g. 23123-4 |
component_loaded
Published once a freshly loaded integration has finished initializing.
| Field | What it holds |
|---|---|
component |
The domain of the integration that came up, e.g. light |
Keep in mind that automations cannot react to this during boot, because the automation engine is the very last thing to start.
core_config_updated
Published when the core settings change — for instance, when you move your home's location. It carries no extra data.
data_entry_flow_progressed
Published when a data-entry flow advances, prompting the frontend to refresh that flow's current state.
| Field | What it holds |
|---|---|
handler |
The handler driving the flow |
flow_id |
The identifier of the flow |
homeassistant_start, homeassistant_started
These fire as WoowTech comes online, in the following sequence:
homeassistant_starthomeassistant_started
Neither carries extra data. For automations, don't subscribe to these directly — use the dedicated WoowTech trigger instead.
homeassistant_stop, homeassistant_final_write, homeassistant_close
These fire as WoowTech winds down, in this sequence:
homeassistant_stophomeassistant_final_writehomeassistant_close
None of them carries extra data. The last two are off-limits for automations, since the automation engine has already shut down by the time they arrive. Reach for the WoowTech trigger instead.
logbook_entry
| Field | What it holds |
|---|---|
name |
The entity's name, e.g. Kitchen light |
message |
The text of the entry, e.g. was turned on |
domain |
Optional — the domain the entry belongs to, e.g. light |
entity_id |
Optional — the entity that was logged |
service_registered
Published when a brand-new service action becomes available within WoowTech.
| Field | What it holds |
|---|---|
domain |
The integration domain providing the action, e.g. light |
service |
The name of the action, e.g. turn_on |
service_removed
Published when a service action is withdrawn from WoowTech.
| Field | What it holds |
|---|---|
domain |
The integration domain that had offered the action, e.g. light |
service |
The name of the action, e.g. turn_on |
state_changed
Published whenever an entity's value moves. It names the entity and carries both new_state and old_state as full state objects.
| Field | What it holds |
|---|---|
entity_id |
The entity that changed, e.g. light.kitchen |
old_state |
The value before the change — left out when the entity is being set for the first time |
new_state |
The value after the change — left out when the entity is being removed |
themes_updated
Published after a theme has been applied or refreshed. It carries no extra data.
user_added
Published when a new user account is created.
| Field | What it holds |
|---|---|
user_id |
The identifier of the newly created user |
user_removed
Published when a user account is deleted.
| Field | What it holds |
|---|---|
user_id |
The identifier of the removed user |
Events fired by the default integrations
automation_reloaded
Integration: automation
Published after automations have been reloaded — they may now differ from before. It carries no extra data.
automation_triggered
Integration: automation
Published when an automation fires.
| Field | What it holds |
|---|---|
name |
The automation's name |
entity_id |
The automation's identifier |
scene_reloaded
Integration: homeassistant
Published after scenes have been reloaded — they may now differ from before. It carries no extra data.
script_started
Integration: script
Published when a script begins running, whether a person or an automation kicked it off. Everything spawned by that run shares one common context.
| Field | What it holds |
|---|---|
name |
The name of the script that ran |
entity_id |
The identifier of the script that ran |
See also
- Event triggers
- The Event integration
The Event Bus
Inside WoowTech, the moving parts rarely talk to each other directly. Instead they broadcast small signals onto a shared message channel called the event bus, and any interested listener picks them up. Whenever a sensor flips, a service runs, or the system boots, a corresponding signal is published. Automations can subscribe to these signals and act on them.
How state changes relate to events
Each entity that WoowTech manages publishes a signal every time its value moves. That signal is just one flavor of message travelling across the bus — plenty of other flavors exist, including internal housekeeping messages that integrations use to stay in sync with one another.
Don't confuse a state-change signal with an event entity
A state-change signal and an event entity are two different things. An event entity is simply a category of entity; like every other entity, it emits its own state-change signals when something happens to it. The signal itself — published under the name state_changed — always carries both the value the entity held a moment ago and the value it holds now.
Fields present on every event
No matter which kind of event you are looking at, the following attributes are always attached:
| Field | What it holds |
|---|---|
event_type |
A label naming the kind of event, such as call_service |
origin |
Where it came from — REMOTE for anything arriving through the API or a webhook, LOCAL for the rest |
time_fired |
The moment of firing, for example 2022-01-28T12:19:53.736380+00:00 |
context |
A small record carrying id, parent_id, and user_id |
On top of those, every event ships a data map holding whatever is specific to that event type.
Core events fired by WoowTech itself
call_service
Published the moment a service action is invoked.
| Field | What it holds |
|---|---|
domain |
The domain the action belongs to, e.g. light |
service |
The action that ran, e.g. turn_on |
service_data |
The parameters that were passed, e.g. { 'brightness': 120 } |
service_call_id |
A unique tag for the call, e.g. 23123-4 |
component_loaded
Published once a freshly loaded integration has finished initializing.
| Field | What it holds |
|---|---|
component |
The domain of the integration that came up, e.g. light |
Keep in mind that automations cannot react to this during boot, because the automation engine is the very last thing to start.
core_config_updated
Published when the core settings change — for instance, when you move your home's location. It carries no extra data.
data_entry_flow_progressed
Published when a data-entry flow advances, prompting the frontend to refresh that flow's current state.
| Field | What it holds |
|---|---|
handler |
The handler driving the flow |
flow_id |
The identifier of the flow |
homeassistant_start, homeassistant_started
These fire as WoowTech comes online, in the following sequence:
homeassistant_starthomeassistant_started
Neither carries extra data. For automations, don't subscribe to these directly — use the dedicated WoowTech trigger instead.
homeassistant_stop, homeassistant_final_write, homeassistant_close
These fire as WoowTech winds down, in this sequence:
homeassistant_stophomeassistant_final_writehomeassistant_close
None of them carries extra data. The last two are off-limits for automations, since the automation engine has already shut down by the time they arrive. Reach for the WoowTech trigger instead.
logbook_entry
| Field | What it holds |
|---|---|
name |
The entity's name, e.g. Kitchen light |
message |
The text of the entry, e.g. was turned on |
domain |
Optional — the domain the entry belongs to, e.g. light |
entity_id |
Optional — the entity that was logged |
service_registered
Published when a brand-new service action becomes available within WoowTech.
| Field | What it holds |
|---|---|
domain |
The integration domain providing the action, e.g. light |
service |
The name of the action, e.g. turn_on |
service_removed
Published when a service action is withdrawn from WoowTech.
| Field | What it holds |
|---|---|
domain |
The integration domain that had offered the action, e.g. light |
service |
The name of the action, e.g. turn_on |
state_changed
Published whenever an entity's value moves. It names the entity and carries both new_state and old_state as full state objects.
| Field | What it holds |
|---|---|
entity_id |
The entity that changed, e.g. light.kitchen |
old_state |
The value before the change — left out when the entity is being set for the first time |
new_state |
The value after the change — left out when the entity is being removed |
themes_updated
Published after a theme has been applied or refreshed. It carries no extra data.
user_added
Published when a new user account is created.
| Field | What it holds |
|---|---|
user_id |
The identifier of the newly created user |
user_removed
Published when a user account is deleted.
| Field | What it holds |
|---|---|
user_id |
The identifier of the removed user |
Events fired by the default integrations
automation_reloaded
Integration: automation
Published after automations have been reloaded — they may now differ from before. It carries no extra data.
automation_triggered
Integration: automation
Published when an automation fires.
| Field | What it holds |
|---|---|
name |
The automation's name |
entity_id |
The automation's identifier |
scene_reloaded
Integration: homeassistant
Published after scenes have been reloaded — they may now differ from before. It carries no extra data.
script_started
Integration: script
Published when a script begins running, whether a person or an automation kicked it off. Everything spawned by that run shares one common context.
| Field | What it holds |
|---|---|
name |
The name of the script that ran |
entity_id |
The identifier of the script that ran |
See also
- Event triggers
- The Event integration
Start writing here...