mirror of
https://github.com/home-assistant/developers.home-assistant.git
synced 2025-07-18 23:06:31 +00:00
Rename Services to Service actions in more places (#2250)
This commit is contained in:
parent
8eeaf3af91
commit
20c58b1128
@ -7,5 +7,5 @@ This guide describes how to build a native Home Assistant app that communicates
|
||||
|
||||
- Allow the user to establish a connection and authenticate with their own Home Assistant instance.
|
||||
- Send location and device info back to Home Assistant.
|
||||
- Call services, fire events and render templates.
|
||||
- Call service actions, fire events and render templates.
|
||||
- A view to control the house via an authenticated webview.
|
||||
|
@ -334,9 +334,9 @@ The server will respond with a result message to indicate that the event was fir
|
||||
}
|
||||
```
|
||||
|
||||
## Calling a service
|
||||
## Calling a service action
|
||||
|
||||
This will call a service in Home Assistant. Right now there is no return value. The client can listen to `state_changed` events if it is interested in changed entities as a result of a service call.
|
||||
This will call a service action in Home Assistant. Right now there is no return value. The client can listen to `state_changed` events if it is interested in changed entities as a result of a call.
|
||||
|
||||
```json
|
||||
{
|
||||
@ -353,12 +353,12 @@ This will call a service in Home Assistant. Right now there is no return value.
|
||||
"target": {
|
||||
"entity_id": "light.kitchen"
|
||||
}
|
||||
// Must be included for services that return response data
|
||||
// Must be included for service actions that return response data
|
||||
"return_response": true
|
||||
}
|
||||
```
|
||||
|
||||
The server will indicate with a message indicating that the service is done executing.
|
||||
The server will indicate with a message indicating that the action is done executing.
|
||||
|
||||
```json
|
||||
{
|
||||
@ -376,7 +376,7 @@ The server will indicate with a message indicating that the service is done exec
|
||||
}
|
||||
```
|
||||
|
||||
The `result` of the call will always include a `response` to account for services that support responses. When a service that doesn't support responses is called, the value of `response` will be `null`.
|
||||
The `result` of the call will always include a `response` to account for service actions that support responses. When a action that doesn't support responses is called, the value of `response` will be `null`.
|
||||
|
||||
## Fetching states
|
||||
|
||||
@ -422,9 +422,9 @@ The server will respond with a result message containing the config.
|
||||
}
|
||||
```
|
||||
|
||||
## Fetching services
|
||||
## Fetching service actions
|
||||
|
||||
This will get a dump of the current services in Home Assistant.
|
||||
This will get a dump of the current service actions in Home Assistant.
|
||||
|
||||
```json
|
||||
{
|
||||
@ -433,7 +433,7 @@ This will get a dump of the current services in Home Assistant.
|
||||
}
|
||||
```
|
||||
|
||||
The server will respond with a result message containing the services.
|
||||
The server will respond with a result message containing the service actions.
|
||||
|
||||
```json
|
||||
{
|
||||
@ -531,7 +531,7 @@ If an error occurs, the `success` key in the `result` message will be set to `fa
|
||||
}
|
||||
```
|
||||
|
||||
### Error handling during service calls and translations
|
||||
### Error handling during service action calls and translations
|
||||
|
||||
The JSON below shows an example of an error response. If `HomeAssistantError` error (or a subclass of `HomeAssistantError`) is handled, translation information, if set, will be added to the response.
|
||||
|
||||
|
@ -62,11 +62,11 @@ When firing an event from a thread other than the event loop thread, instead use
|
||||
|
||||
#### hass.services.async_register
|
||||
|
||||
When registering a service from a thread other than the event loop thread, instead use `hass.services.register`
|
||||
When registering a service action from a thread other than the event loop thread, instead use `hass.services.register`
|
||||
|
||||
#### hass.services.async_remove
|
||||
|
||||
When removing a service from a thread other than the event loop thread, instead use `hass.services.remove`
|
||||
When removing a service action from a thread other than the event loop thread, instead use `hass.services.remove`
|
||||
|
||||
#### async_write_ha_state
|
||||
|
||||
|
@ -128,7 +128,7 @@ if not user.permissions.check_entity(entity_id, POLICY_CONTROL):
|
||||
|
||||
### The context object
|
||||
|
||||
All service action calls, fired events and states in Home Assistant have a context object. This object allows us to attribute changes to events and actions. These context objects also contain a user id, which is used for checking the permissions.
|
||||
All service actions, fired events and states in Home Assistant have a context object. This object allows us to attribute changes to events and actions. These context objects also contain a user id, which is used for checking the permissions.
|
||||
|
||||
It's crucial for permission checking that actions taken on behalf of the user are done with a context containing the user ID. If you are in a service action handler, you should re-use the incoming context `call.context`. If you are inside a WebSocket API or Rest API endpoint, you should create a context with the correct user:
|
||||
|
||||
@ -174,7 +174,7 @@ from homeassistant.auth.permissions.const import POLICY_CONTROL
|
||||
|
||||
|
||||
async def handle_entity_service(call):
|
||||
"""Handle a service call."""
|
||||
"""Handle a service action call."""
|
||||
entity_ids = call.data["entity_id"]
|
||||
|
||||
for entity_id in entity_ids:
|
||||
@ -206,12 +206,12 @@ async def async_setup(hass, config):
|
||||
#### Checking admin permission
|
||||
|
||||
Starting Home Assistant 0.90, there is a special decorator to help protect
|
||||
services that require admin access.
|
||||
service actions that require admin access.
|
||||
|
||||
```python
|
||||
# New in Home Assistant 0.90
|
||||
async def handle_admin_service(call):
|
||||
"""Handle a service call."""
|
||||
"""Handle a service action call."""
|
||||
# Do admin action
|
||||
|
||||
|
||||
|
@ -61,7 +61,7 @@ Not all existing code follows the requirements in this checklist. This cannot be
|
||||
Keep a new integration to the minimum functionality needed for someone to get value out of the integration. This allows reviewers to sign off on smaller chunks of code one at a time, and lets us get your new integration/features in sooner. **Pull requests containing large code dumps will not be a priority for review and may be closed.**
|
||||
|
||||
- Limit to a single platform
|
||||
- Do not add features not needed to directly support the single platform (such as custom services)
|
||||
- Do not add features not needed to directly support the single platform (such as custom service actions)
|
||||
- Do not mix clean-ups and new features in a single pull request.
|
||||
- Do not solve several issues in a single pull request.
|
||||
- Do not submit pull requests that depend on other work which is still unmerged.
|
||||
|
@ -17,9 +17,9 @@ If your integration is going to integrate one or more devices, you will need to
|
||||
- More info on [available entity integrations](core/entity.md).
|
||||
- More info on [creating platforms](creating_platform_index.md).
|
||||
|
||||
## Integrating services - `services.yaml`
|
||||
## Integrating service actions - `services.yaml`
|
||||
|
||||
If your integration is going to register services, it will need to provide a description of the available services. The description is stored in `services.yaml`. [More information about `services.yaml`.](dev_101_services.md)
|
||||
If your integration is going to register service actions, it will need to provide a description of the available actions. The description is stored in `services.yaml`. [More information about `services.yaml`.](dev_101_services.md)
|
||||
|
||||
## Data update coordinator - `coordinator.py`
|
||||
|
||||
|
@ -278,17 +278,18 @@ action:
|
||||
message: Hi there!
|
||||
```
|
||||
|
||||
### Service targets
|
||||
### Service action targets
|
||||
|
||||
If you want to fire a service call for an entity ID (for example, to turn
|
||||
If you want to fire a service action call for an entity ID (for example, to turn
|
||||
on a light), you can do so in three different ways.
|
||||
|
||||
The entity ID can be specified as a property of the service level, part of the
|
||||
data that is sent in the service call or as an entity in a service target.
|
||||
The entity ID can be specified as a property of the action level, part of the
|
||||
data that is sent in the service action call or as an entity in a service
|
||||
action target.
|
||||
|
||||
Service targets is the most modern way and allows one to target a service call
|
||||
for an entity, device or area. Therefore, the target is the most flexible of the options
|
||||
available and is the one that should be used.
|
||||
Service action targets is the most modern way and allows one to target a
|
||||
service action call for an entity, device or area. Therefore, the target is the
|
||||
most flexible of the options available and is the one that should be used.
|
||||
|
||||
```yaml
|
||||
# Good
|
||||
|
@ -176,9 +176,9 @@ When new data arrives, use `coordinator.async_set_updated_data(data)` to pass th
|
||||
This is an advanced topic.
|
||||
:::
|
||||
|
||||
Home Assistant has built-in logic to make sure that integrations do not hammer APIs and consume all available resources in Home Assistant. This logic is built around limiting the number of parallel requests. This logic is automatically used during service calls and entity updates.
|
||||
Home Assistant has built-in logic to make sure that integrations do not hammer APIs and consume all available resources in Home Assistant. This logic is built around limiting the number of parallel requests. This logic is automatically used during service action calls and entity updates.
|
||||
|
||||
Home Assistant controls the number of parallel updates (calls to `update()`) by maintaining a [semaphore](https://docs.python.org/3/library/asyncio-sync.html#asyncio.Semaphore) per integration. For example, if the semaphore allows 1 parallel connection, updates and service calls will wait if one is in progress. If the value is 0, the integration is itself responsible for limiting the number of parallel requests if necessary.
|
||||
Home Assistant controls the number of parallel updates (calls to `update()`) by maintaining a [semaphore](https://docs.python.org/3/library/asyncio-sync.html#asyncio.Semaphore) per integration. For example, if the semaphore allows 1 parallel connection, updates and service action calls will wait if one is in progress. If the value is 0, the integration is itself responsible for limiting the number of parallel requests if necessary.
|
||||
|
||||
The default value for parallel requests for a platform is decided based on the first entity that is added to Home Assistant. It's 0 if the entity defines the `async_update` method, else it's 1. (this is a legacy decision)
|
||||
|
||||
|
@ -26,7 +26,7 @@ This integration is able to cope when things go wrong. It will not print any exc
|
||||
- Handles expiration of auth credentials. Refresh if possible or print correct error and fail setup. If based on a config entry, should trigger a new config entry flow to re-authorize. ([docs](config_entries_config_flow_handler.md#reauthentication))
|
||||
- Handles internet unavailable. Log a warning once when unavailable, log once when reconnected.
|
||||
- Handles device/service unavailable. Log a warning once when unavailable, log once when reconnected.
|
||||
- Operations like service calls and entity methods (e.g. *Set HVAC Mode*) have proper exception handling. Raise `ServiceValidationError` on invalid user input and raise `HomeAssistantError` for other failures such as a problem communicating with a device. [Read more](/docs/core/platform/raising_exceptions) about raising exceptions.
|
||||
- Operations like service action calls and entity methods (e.g. *Set HVAC Mode*) have proper exception handling. Raise `ServiceValidationError` on invalid user input and raise `HomeAssistantError` for other failures such as a problem communicating with a device. [Read more](/docs/core/platform/raising_exceptions) about raising exceptions.
|
||||
- Set `available` property to `False` if appropriate ([docs](core/entity.md#generic-properties))
|
||||
- Entities have unique ID (if available) ([docs](entity_registry_index.md#unique-id-requirements))
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user