Merge branch 'current' into rc

This commit is contained in:
Franck Nijhof 2025-05-07 14:27:13 +00:00
commit 24b58884ee
No known key found for this signature in database
GPG Key ID: AB33ADACE7101952
4 changed files with 21 additions and 14 deletions

View File

@ -12,7 +12,7 @@ group :development do
gem 'sassc', '2.1.0'
gem 'sass-embedded', '1.87.0'
gem 'rubocop', '1.75.5'
gem 'ruby-lsp', '0.23.16'
gem 'ruby-lsp', '0.23.17'
gem 'rackup', '2.2.1'
end

View File

@ -99,12 +99,12 @@ GEM
prism (1.4.0)
public_suffix (6.0.2)
racc (1.8.1)
rack (3.1.13)
rack (3.1.14)
rack-protection (4.1.1)
base64 (>= 0.1.0)
logger (>= 1.6.0)
rack (>= 3.0.0, < 4)
rack-session (2.1.0)
rack-session (2.1.1)
base64 (>= 0.1.0)
rack (>= 3.0.0)
rackup (2.2.1)
@ -133,7 +133,7 @@ GEM
rubocop-ast (1.44.1)
parser (>= 3.3.7.2)
prism (~> 1.4)
ruby-lsp (0.23.16)
ruby-lsp (0.23.17)
language_server-protocol (~> 3.17.0)
prism (>= 1.2, < 2.0)
rbs (>= 3, < 4)
@ -159,7 +159,7 @@ GEM
rack-protection (= 4.1.1)
rack-session (>= 2.0.0, < 3)
tilt (~> 2.0)
sorbet-runtime (0.5.12067)
sorbet-runtime (0.5.12070)
stringex (2.8.6)
terminal-table (3.0.2)
unicode-display_width (>= 1.1.1, < 3)
@ -186,7 +186,7 @@ DEPENDENCIES
rackup (= 2.2.1)
rake (= 13.2.1)
rubocop (= 1.75.5)
ruby-lsp (= 0.23.16)
ruby-lsp (= 0.23.17)
sass-embedded (= 1.87.0)
sass-globbing (= 1.1.5)
sassc (= 2.1.0)

View File

@ -3,7 +3,7 @@ title: "Automation actions"
description: "Automations result in action."
---
The action of an automation rule is what is being executed when a rule fires. The action part follows the [script syntax](/docs/scripts/) which can be used to interact with anything via other actions or events.
The action of an automation is what is being executed when an automation fires. The action part follows the [script syntax](/docs/scripts/) which can be used to interact with anything via other actions or events.
For actions, you can specify the `entity_id` that it should apply to and optional parameters (to specify for example the brightness).

View File

@ -15,24 +15,31 @@ We can break up this automation into the following three parts:
(action) Turn the lights on in the living room
```
The first part is the [trigger](/docs/automation/trigger/) of the automation rule. Triggers describe {% term events %} that should trigger the automation rule. In this case, it is a person arriving home, which can be observed in Home Assistant using {% term devices %}/{% term sensors %} by observing the state of Paulus changing from `not_home` to `home`.
The first part is the [trigger](/docs/automation/trigger/) of the automation. Triggers describe {% term events %} that should trigger the automation. In this case, it is a person arriving home, which can be observed in Home Assistant using {% term devices %}/{% term sensors %} by observing the state of Paulus changing from `not_home` to `home`.
The second part is the [condition](/docs/automation/condition/). Conditions are optional tests that can limit an automation rule to only work in your specific use cases. A condition will test against the current state of the system. This includes the current time, devices, people and other things like the sun. In this case, we only want to act when the sun has set.
The second part is the [condition](/docs/automation/condition/). Conditions are optional tests that can limit an automation to only work in your specific use cases. A condition will test against the current state of the system. This includes the current time, devices, people and other things like the sun. In this case, we only want to act when the sun has set.
The third part is the [action](/docs/automation/action/), which will be performed when a rule is triggered and all conditions are met. For example, it can turn a light on, set the temperature on your thermostat or activate a scene.
The third part is the [action](/docs/automation/action/), which will be performed when an automation is triggered and all conditions are met. For example, it can turn a light on, set the temperature on your thermostat or activate a scene.
{% note %}
The difference between a condition and a trigger can be confusing as they are very similar. Triggers look at the actions, while conditions look at the current state: turning a light on versus a light being on.
The difference between a trigger and a condition can be confusing as they are very similar.
Triggers require an event to happen for the conditions to be evaluated using current state information.
Event: Arrive home \
Condition: After Sunset? \
Action: Turn lights on
{% endnote %}
## Exploring the internal state
Automation rules interact directly with the internal state of Home Assistant, so you'll need to familiarize yourself with it. Home Assistant exposes its current state via the developer tools. These are available at the bottom of the sidebar in the frontend. **{% my developer_states title="Developer Tools > States" %}** will show all currently available states. An entity can be anything. A light, a switch, a person and even the sun. A state consists of the following parts:
Automations interact directly with the internal state of Home Assistant, so you'll need to familiarize yourself with it. Home Assistant exposes its current state via the developer tools. These are available at the bottom of the sidebar in the frontend. **{% my developer_states title="Developer Tools > States" %}** will show all currently available states. An entity can be anything. A light, a switch, a person and even the sun. A state consists of the following parts:
| Name | Description | Example |
| ---- | ----- | ---- |
| Entity ID | Unique identifier for the entity. | `light.kitchen`
| State | The current state of the device. | `home`
| Entity ID | Unique identifier for the entity. | `light.living_room`
| State | The current state of the device. | `off`
| Attributes | Extra data related to the device and/or current state. | `brightness`
State changes can be used as the source of triggers and the current state can be used in conditions.