diff --git a/CODEOWNERS b/CODEOWNERS index 5d22c7a4d4af..d32359a585c3 100644 --- a/CODEOWNERS +++ b/CODEOWNERS @@ -366,6 +366,7 @@ source/_integrations/garage_door.markdown @home-assistant/core source/_integrations/garages_amsterdam.markdown @klaasnicolaas source/_integrations/gardena_bluetooth.markdown @elupus source/_integrations/gate.markdown @home-assistant/core +source/_integrations/gatus.markdown @TN-1 source/_integrations/gaviota.markdown @starkillerOG source/_integrations/gdacs.markdown @exxamalte source/_integrations/generic.markdown @davet2001 @@ -792,7 +793,6 @@ source/_integrations/peco.markdown @IceBotYT source/_integrations/peco_opower.markdown @tronikos source/_integrations/pegel_online.markdown @mib1185 source/_integrations/pepco.markdown @tronikos -source/_integrations/permobil.markdown @IsakNyberg source/_integrations/persistent_notification.markdown @home-assistant/core source/_integrations/pge.markdown @tronikos source/_integrations/pglab.markdown @pglab-electronics diff --git a/source/_actions/jewish_calendar.count_omer.markdown b/source/_actions/jewish_calendar.count_omer.markdown index 1820e2a68aff..88ccac288f9c 100644 --- a/source/_actions/jewish_calendar.count_omer.markdown +++ b/source/_actions/jewish_calendar.count_omer.markdown @@ -5,7 +5,11 @@ domain: jewish_calendar description: "Returns the phrase for counting the Omer on a given date." --- -Use this action to get the phrase for counting the Omer on a given date. +The **Count the Omer** action returns the phrase for counting the Omer on a given date. + +This is useful when you want an automation or script to announce or display the daily Omer count, for example as part of an evening routine during the Omer period. + +This action does not support targets. In the UI, you are not prompted to choose an area, device, entity, or label. Instead, you provide the date and tradition to count for. {% include actions/ui_header.md %} @@ -15,32 +19,30 @@ To count the Omer from an automation or a script: 2. Open an existing automation or script, or select **Create automation** > **Create new automation**. 3. If you're setting up a new automation, add a trigger in the **When** section. Scripts don't need a trigger. They run when something else calls them. 4. In the **Then do** section, select **Add action**. -5. Select **Jewish Calendar: Count the Omer**. -6. Set the nusach and other options. +5. From the search box, search for and select **Jewish Calendar: Count the Omer**. +6. Select the **Nusach**, and optionally set the **Date**, **After sunset**, and **Language**. 7. Select **Save**. ### Options in the UI {% options_ui %} Date: - description: The date for which to get the Omer count. If unset, the action uses today. + description: The date to count the Omer for. Defaults to today. required: false After sunset: - description: If enabled and a date is provided, the action calculates the Omer count based on the Hebrew date, which starts after sunset. Ignored if no date is specified. + description: Uses the next Hebrew day, which starts at sunset, for the given date. This option is ignored if the date is empty. Defaults to on. required: false - default: true Nusach: - description: The nusach, or tradition, of the Omer blessing. - default: sfarad + description: The nusach (tradition) to count the Omer in. One of Sfarad, Ashkenaz, Adot Mizrah, or Italian. + required: true Language: - description: The language to return. Supported languages are English, Hebrew, and French. + description: The language to count the Omer in. Supported languages are English, Hebrew, and French. Defaults to Hebrew. required: false - default: he {% endoptions_ui %} {% include actions/yaml_header.md %} -In YAML, refer to this action as `jewish_calendar.count_omer`. Store the result in a response variable so you can use it in later steps: +In YAML, refer to this action as `jewish_calendar.count_omer`. Because this action returns data, use `response_variable` to capture the result. A basic example looks like this: {% example %} action: | @@ -49,63 +51,89 @@ action: | nusach: sfarad date: "2025-05-20" language: en - response_variable: omer_count + response_variable: omer {% endexample %} -This returns the Omer count for May 20, 2025, in English. +This counts the Omer for the given date and stores the result in the `omer` variable. ### Options in YAML {% options_yaml %} date: - description: The date for which to get the Omer count. If unset, the action uses today. + description: > + The date to count the Omer for. Defaults to today. required: false - type: string + type: date after_sunset: - description: If true and a date is provided, the action calculates the Omer count based on the Hebrew date, which starts after sunset. Ignored if no date is specified. + description: > + Uses the next Hebrew day, which starts at sunset, for the given date. + This option is ignored if the date is empty. required: false type: boolean default: true nusach: - description: The nusach, or tradition, of the Omer blessing. Supported values are `sfarad`, `ashkenaz`, `adot_mizrah`, and `italian`. + description: > + The nusach (tradition) to count the Omer in. One of `sfarad`, + `ashkenaz`, `adot_mizrah`, or `italian`. required: true type: string default: sfarad language: - description: The language to return. Supported values are `en`, `he`, and `fr`. + description: > + The language to count the Omer in. Supported values are `en`, `he`, + and `fr`. Defaults to Hebrew. required: false type: string default: he {% endoptions_yaml %} -This action does not support targets. - ## Response data -The action response includes the following fields: +The action returns the following data: -- `message`: The phrase for counting the Omer. If there is no Omer count on the given day, this value is empty. -- `weeks`: The number of complete weeks. -- `days`: The number of days after the complete weeks. -- `total_days`: The total number of Omer days. +- `message`: The phrase for counting the Omer. Empty when there is no Omer count on the given day. +- `weeks`: The number of complete weeks counted. +- `days`: The number of days counted beyond the complete weeks. +- `total_days`: The total number of days counted. -## Good to know +For the example above, the response looks similar to this: -- If there is no Omer count on the given day, the message is empty. -- The Hebrew date starts after sunset. +{% example %} +output: | + message: >- + Today is the thirty-seventh day, which are five weeks and two days of the + Omer + weeks: 5 + days: 2 + total_days: 37 +{% endexample %} {% include actions/more_examples.md %} -### Minimal count in Hebrew +### Count today's Omer in Hebrew + +For a minimal call, provide only the required nusach. With no date, the action counts the current Hebrew day, taking the current time relative to sunset into account, and returns the text in Hebrew by default. {% example %} action: | action: jewish_calendar.count_omer data: nusach: sfarad - response_variable: omer_count + response_variable: omer +{% endexample %} + +This returns a response similar to: + +{% example %} +output: | + message: היום ארבעה עשר יום שהם שני שבועות לעומר + weeks: 2 + days: 0 + total_days: 14 {% endexample %} +{% include actions/try_it.md %} + {% include actions/stuck.md %} {% include actions/related.md %} diff --git a/source/_actions/mastodon.post.markdown b/source/_actions/mastodon.post.markdown index 95defd04bef4..6ea05fcf8d0e 100644 --- a/source/_actions/mastodon.post.markdown +++ b/source/_actions/mastodon.post.markdown @@ -61,6 +61,12 @@ Media description: Media warning: description: Mark the attached media as sensitive. required: false +In reply to: + description: The ID of the status to reply to. Setting this makes the new post a reply, allowing you to create or continue a thread. + required: false +Quote: + description: The ID of the status to quote in this post. + required: false {% endoptions_ui %} {% include actions/yaml_header.md %} @@ -136,6 +142,16 @@ media_warning: required: false type: boolean default: false +in_reply_to: + description: > + The ID of the status to reply to. Setting this makes the new post a reply, allowing you to create or continue a thread. + required: false + type: string +quoted_status: + description: > + The ID of the status to quote in this post. + required: false + type: string {% endoptions_yaml %} {% note %} diff --git a/source/_actions/music_assistant.play_media.markdown b/source/_actions/music_assistant.play_media.markdown index 1ececb6ec674..2ee88c6e0f54 100644 --- a/source/_actions/music_assistant.play_media.markdown +++ b/source/_actions/music_assistant.play_media.markdown @@ -39,7 +39,7 @@ Enqueue: Enable radio mode: description: Turns on radio mode to auto-generate a playlist based on the selection. Username: - description: Use this Music Assistant user to adjust the playlog entry. If the specified user has provider filtering configured, the media item selection will be made accordingly. For example, this has an effect on the resume point retrieval of an audiobook. + description: Use this Music Assistant user to adjust the playlog entry. If the specified user has provider filtering configured, the media item selection will be made accordingly. For example, this has an effect on the resume point retrieval of an audiobook. When left empty, it defaults to the Home Assistant user that made the request, if their username matches a Music Assistant user. When you call this action from an automation or script, set the username explicitly so the request is attributed to the right user. {% endoptions_ui %} {% include actions/yaml_header.md %} @@ -84,7 +84,7 @@ radio_mode: type: boolean default: false username: - description: Use this Music Assistant user to adjust the playlog entry. If provider filtering is used, the media item will be selected accordingly. + description: Use this Music Assistant user to adjust the playlog entry. If the specified user has provider filtering configured, the media item selection will be made accordingly. For example, this has an effect on the resume point retrieval of an audiobook. When left empty, it defaults to the Home Assistant user that made the request, if their username matches a Music Assistant user. When you call this action from an automation or script, set the username explicitly so the request is attributed to the right user. required: false type: string {% endoptions_yaml %} diff --git a/source/_actions/omie.get_prices_for_date.markdown b/source/_actions/omie.get_prices_for_date.markdown new file mode 100644 index 000000000000..9c6d21efa05a --- /dev/null +++ b/source/_actions/omie.get_prices_for_date.markdown @@ -0,0 +1,106 @@ +--- +title: "Get prices for date" +action: omie.get_prices_for_date +domain: omie +description: "Retrieves OMIE electricity spot prices for a specific date, for Spain, Portugal, or both." +--- + +Use this action to retrieve the day-ahead electricity spot prices for a specific date, for Spain, Portugal, or both countries. + +The OMIE sensors always reflect the current price. This action lets you fetch the prices for any published date instead, which is useful when you want to look ahead. For example, you can compare tomorrow's prices or schedule an appliance to run during the cheapest hours. + +This action returns its result in a response variable, which you can use in later steps of the same automation or script. + +Prices for the next day are published daily at around 13:30 CET/CEST. If you request a date that has not been published yet, the action reports that the prices are not available. Similarly if you request a date that is previous to the date when quarter-hourly prices became available, the action reports that no prices exist for that date and tells you the earliest date you can request. + +{% include actions/ui_header.md %} + +To get prices from an automation or a script: + +1. Go to {% my automations title="**Settings** > **Automations & scenes**" %}. +2. Open an existing automation or script, or select **Create automation** > **Create new automation**. +3. If you're setting up a new automation, add a trigger in the **When** section. Scripts don't need a trigger. They run when something else calls them. +4. In the **Then do** section, select **Add action**. +5. From the search box, search for and select **OMIE - Spain and Portugal electricity prices: Get prices for date**. +6. Select the **Date** you want, and choose the **Countries** to get prices for. +7. In the **Response variable** field, enter a name to store the data in, such as `prices`. +8. Select **Save**. + +### Options in the UI + +{% options_ui %} +Date: + description: The date to get the prices for. + required: true +Countries: + description: The countries to get the prices for. Choose Spain, Portugal, or both. Both are selected by default. + required: true +{% endoptions_ui %} + +{% include actions/yaml_header.md %} + +In YAML, refer to this action as `omie.get_prices_for_date`. Store the result in a response variable so you can use it in later steps: + +{% example %} +action: | + action: omie.get_prices_for_date + data: + date: "2026-07-08" + countries: + - es + - pt + response_variable: prices +{% endexample %} + +This fetches the prices for both Spain and Portugal on the given date. + +### Options in YAML + +{% options_yaml %} +date: + description: > + The date to get the prices for, in YYYY-MM-DD format. + required: true + type: date +countries: + description: > + The countries to get the prices for. A list containing es, pt, or both. + Defaults to both. + required: true + type: list +{% endoptions_yaml %} + +## Response data + +The response contains a key for each requested country: `es` for Spain and `pt` for Portugal. If you request both countries, both keys are present. + +Each key holds a list of quarter-hourly intervals. Each interval includes the following fields: + +- `start`: The start time of the interval, in CET/CEST. +- `end`: The end time of the interval, in CET/CEST. +- `price`: The electricity spot price for the interval, in €/kWh. + +A shortened example of the response looks like this: + +```yaml +es: + - start: "2026-07-08T00:00:00+02:00" + end: "2026-07-08T00:15:00+02:00" + price: 0.03415 + - start: "2026-07-08T00:15:00+02:00" + end: "2026-07-08T00:30:00+02:00" + price: 0.03521 +pt: + - start: "2026-07-08T00:00:00+02:00" + end: "2026-07-08T00:15:00+02:00" + price: 0.0361 + - start: "2026-07-08T00:15:00+02:00" + end: "2026-07-08T00:30:00+02:00" + price: 0.0372 +``` + +{% include actions/try_it.md %} + +{% include actions/stuck.md %} + +{% include actions/related.md %} diff --git a/source/_actions/onedrive.upload.markdown b/source/_actions/onedrive.upload.markdown index 3ef3b97e1dbb..3a95d9698a03 100644 --- a/source/_actions/onedrive.upload.markdown +++ b/source/_actions/onedrive.upload.markdown @@ -66,6 +66,9 @@ filename: description: > One or more paths to the files you want to upload. The path must be in the `allowlist_external_dirs` of your `homeassistant:` configuration. + Wildcards (glob patterns) are supported, so you can upload several files + at once. When you use a wildcard, the folder part before the first + wildcard must be in `allowlist_external_dirs`. required: true type: [string, list] destination_folder: @@ -104,6 +107,32 @@ action: | {% enddetails %} +### Upload files using wildcards + +The `filename` option supports wildcards (glob patterns), so you can upload several files without listing each one: + +- `*` matches any number of characters within a single folder level. For example, `/media/snapshots/*.jpg` uploads every JPG file in the `snapshots` folder. +- `**` matches folders recursively. For example, `/media/snapshots/**/*.jpg` uploads every JPG file in the `snapshots` folder and all of its subfolders. +- `?` matches a single character. +- `[` starts a character range, such as `[0-9]`. + +When a wildcard matches files in subfolders, those subfolders are recreated inside the `destination_folder` on OneDrive, preserving the original structure. + +If a wildcard pattern does not match any files, the action fails with an error listing the patterns that had no matches. The characters `*`, `?`, and `[` are always treated as wildcards. + +{% details "Upload files using a wildcard" %} + +{% example %} +action: | + action: onedrive.upload + data: + config_entry_id: a1bee602deade2b09bc522749bbce48e + filename: /media/snapshots/**/*.jpg + destination_folder: Snapshots/2025 +{% endexample %} + +{% enddetails %} + {% include actions/stuck.md %} {% include actions/related.md %} diff --git a/source/_actions/volvo.get_image_url.markdown b/source/_actions/volvo.get_image_url.markdown index f135d3c7f860..01a396c68cdb 100644 --- a/source/_actions/volvo.get_image_url.markdown +++ b/source/_actions/volvo.get_image_url.markdown @@ -2,65 +2,91 @@ title: "Get image URL" action: volvo.get_image_url domain: volvo -description: "Retrieves URLs for vehicle-specific Volvo images." +description: "Retrieves the URL for one or more vehicle-specific images." --- -Use this action to retrieve URLs for one or more vehicle-specific Volvo images. +The **Get image URL** action retrieves the URLs of images of your vehicle from a specific angle. You can request all available images at once, or pick one or more specific angles. + +This action returns [response data](#response-data) and does not change anything on your vehicle. + +This action does not support targets. In the UI, you are not prompted to choose an area, device, entity, or label. {% include actions/ui_header.md %} -To get Volvo image URLs from an automation or a script: +To get image URLs from an automation or a script: 1. Go to {% my automations title="**Settings** > **Automations & scenes**" %}. -2. Open an existing automation or script, or select **Create automation** > **Create new automation**. -3. If you're setting up a new automation, add a trigger in the **When** section. Scripts don't need a trigger. They run when something else calls them. +2. Open an existing automation or script, or select **Create** to start a new one. +3. If you're setting up a new automation, add a trigger in the **When** section. Scripts don't need a trigger. 4. In the **Then do** section, select **Add action**. -5. Select **Volvo: Get image URL**. -6. Select the vehicle entry. -7. Select one or more image angles, or leave the image list empty to retrieve all available image URLs. +5. From the search box, search for and select **Volvo: Get image URL**. +6. Select the **Entry** for the vehicle you want the images for. +7. Optionally, select one or more image angles in **Images**. Leave this empty to get all images. 8. Select **Save**. ### Options in the UI {% options_ui %} Entry: - description: The Volvo vehicle entry to retrieve image URLs for. + description: The vehicle to retrieve the images for. + required: true Images: - description: The image angles to retrieve. Leave empty to get all available images. + description: The image angles to retrieve. Leave empty to get all images. required: false {% endoptions_ui %} {% include actions/yaml_header.md %} -In YAML, refer to this action as `volvo.get_image_url`. Store the result in a response variable so you can use it in later steps: +In YAML, refer to this action as `volvo.get_image_url`: {% example %} action: | action: volvo.get_image_url data: - entry: VOLVO_CONFIG_ENTRY_ID + entry: 01JVJ0RA387MWA938VE8HGXBMJ images: - exterior_front - - exterior_side_left - response_variable: volvo_images + - interior + response_variable: vehicle_images {% endexample %} -This retrieves URLs for the selected vehicle image angles. +This retrieves the front exterior and interior image URLs and stores the response in the `vehicle_images` variable. ### Options in YAML {% options_yaml %} entry: - description: The Volvo vehicle entry to retrieve image URLs for. + description: The vehicle to retrieve the images for. required: true type: string images: - description: The image angles to retrieve. This option accepts a list of image angle values. Leave empty to get all available images. + description: > + The image angles to retrieve. Leave empty to get all images. One or more of + `exterior_back`, `exterior_back_left`, `exterior_back_right`, + `exterior_front`, `exterior_front_left`, `exterior_front_right`, + `exterior_side_left`, `exterior_side_right`, or `interior`. required: false - type: [string, list] + type: list {% endoptions_yaml %} -This action does not support targets. +## Response data + +The action returns a response containing an `images` list. Each item describes one image that is available for your vehicle: + +- `type`: The angle of the image, for example `exterior_front`. +- `url`: The URL where the image can be retrieved. + +Only images that actually exist for your vehicle are returned, so the list may be shorter than the angles you requested. + +```yaml +images: + - type: "exterior_front" + url: "https://www.example.com/vehicle/exterior_front.png" + - type: "interior" + url: "https://www.example.com/vehicle/interior.png" +``` + +{% include actions/try_it.md %} ## Available image angles @@ -81,6 +107,7 @@ The action response contains the requested image URLs. ## Good to know If you leave `images` empty, the action retrieves all available image URLs for the selected vehicle. +>>>>>>> current {% include actions/stuck.md %} diff --git a/source/_actions/wmspro.set_cover_position_and_tilt.markdown b/source/_actions/wmspro.set_cover_position_and_tilt.markdown new file mode 100644 index 000000000000..a6a48139a6b5 --- /dev/null +++ b/source/_actions/wmspro.set_cover_position_and_tilt.markdown @@ -0,0 +1,105 @@ +--- +title: "Set cover position and tilt" +action: wmspro.set_cover_position_and_tilt +domain: wmspro +description: "Moves the cover and tilt to the target position simultaneously, preventing cancellation of individual movements." +since: "2026.8" +--- + +The **Set cover position and tilt** action moves a cover to a target position and tilt in a single command. Because both values are sent together, the individual actions will not cancel each other out on the WMS radio channel. + +This action is available only for covers that support setting both position and tilt, and that accept the combined command. If your cover does not support it, the action returns an error. + +{% include actions/ui_header.md %} + +To use this action in an automation or script: + +1. Go to {% my automations title="**Settings** > **Automations & scenes**" %}. +2. Open an existing automation or script, or select **Create automation** > **Create new automation**. +3. If you're creating an automation, add a trigger in the **When** section. +4. In the **Then do** section, select **Add action**. +5. Select what you want to control. Under **By target** (see [Targets](#targets)), pick the cover you want to control. You can also select an area, a floor, a device, or a label. +6. From the actions shown for that target, select **Set cover position and tilt**. +7. Under **Position** and **Tilt position**, set the values you want. +8. Select **Save**. + +### Options in the UI + +{% options_ui %} +Position: + description: Target vertical position, from 0 to 100 percent. 0 means closed, 100 means fully open. + required: true +Tilt position: + description: Target tilt position, from 0 to 100 percent. + required: true +{% endoptions_ui %} + +{% include actions/yaml_header.md %} + +In YAML, refer to this action as `wmspro.set_cover_position_and_tilt`. A basic example looks like this: + +{% example %} +action: | + action: wmspro.set_cover_position_and_tilt + target: + entity_id: cover.living_room_blind + data: + position: 50 + tilt_position: 20 +{% endexample %} + +This moves `cover.living_room_blind` to 50% open with the slats tilted to 20% in one continuous movement. + +### Options in YAML + +{% options_yaml %} +position: + description: Target vertical position, from 0 to 100 percent. 0 means closed, 100 means fully open. + required: true + type: integer +tilt_position: + description: Target tilt position, from 0 to 100 percent. + required: true + type: integer +{% endoptions_yaml %} + +{% include actions/targets.md domain="cover" %} + +{% include actions/try_it.md %} + +{% include actions/more_examples.md %} + +### Automation: tilt the blinds against the afternoon sun + +When the afternoon sun starts shining in, you can lower the blinds part way and tilt the slats to block the glare while keeping some light, all in one smooth move. + +- **Trigger**: Sun: above the horizon at a low elevation +- **Action**: Set cover position and tilt + - **Target**: Living room blind + - **Position**: 60 + - **Tilt position**: 30 + +{% details "YAML example for tilting the blinds against the sun" %} + +{% example %} +automation: | + - alias: "Tilt the living room blinds in the afternoon" + triggers: + - trigger: numeric_state + entity_id: sun.sun + attribute: elevation + below: 25 + actions: + - action: wmspro.set_cover_position_and_tilt + target: + entity_id: cover.living_room_blind + data: + position: 60 + tilt_position: 30 +{% endexample %} + +{% enddetails %} + +{% include actions/stuck.md %} + +{% include actions/related.md %} diff --git a/source/_conditions/moon.is_phase.markdown b/source/_conditions/moon.is_phase.markdown new file mode 100644 index 000000000000..11a730696c36 --- /dev/null +++ b/source/_conditions/moon.is_phase.markdown @@ -0,0 +1,103 @@ +--- +title: "Moon phase" +condition: moon.is_phase +domain: moon +description: "Tests if the moon is in a specific phase." +related_conditions: + - moon.is_waxing + - moon.is_waning +--- + +The **Moon phase** condition passes when the moon is currently in the phase you choose, such as full moon or new moon. Home Assistant works the phase out from the date, so it needs no account, no internet connection, and no location. + +Use it to gate an automation on the lunar month, for example to only run a scene on the night of a full moon, or to skip a routine unless it is a new moon. + +{% include conditions/ui_header.md %} + +To use this condition in an automation: + +1. Go to {% my automations title="**Settings** > **Automations & scenes**" %}. +2. Open an existing automation, or select **Create automation** > **Create new automation**. +3. In the **And if** section, select **Add condition**. +4. From the search box, search for and select **Moon phase**. +5. Under **Phase**, select the phase to test for. +6. Select **Save**. + +### Options in the UI + +{% options_ui %} +Phase: + description: | + The moon phase the condition tests for. Select one of the eight phases, from **New moon** through **Full moon** to **Waning crescent**. +{% endoptions_ui %} + +{% include conditions/yaml_header.md %} + +In YAML, refer to this condition as `moon.is_phase`. Set the phase to test for with the `phase` option: + +{% example %} +condition: | + condition: moon.is_phase + options: + phase: full_moon +{% endexample %} + +This passes while the moon is a full moon. + +### Options in YAML + +{% options_yaml %} +phase: + description: > + The moon phase to test for. Accepts one of `new_moon`, `waxing_crescent`, `first_quarter`, `waxing_gibbous`, `full_moon`, `waning_gibbous`, `last_quarter`, or `waning_crescent`. + required: true + type: string +{% endoptions_yaml %} + +## Good to know + +- This condition does not use a target. It checks the moon phase, which is the same everywhere on Earth, so it does not depend on your [home location](/docs/configuration/basic/). +- This is a point-in-time check. It reflects the phase at the moment the automation runs. +- The phase is based on the date, so it changes at most once a day. +- To test the direction the moon is heading rather than a single phase, use [Moon is waxing](/conditions/moon.is_waxing/) or [Moon is waning](/conditions/moon.is_waning/). + +{% include conditions/try_it.md %} + +{% include conditions/more_examples.md %} + +### Automation: full moon garden lights + +When motion is detected in the garden after dark, turn on the garden lights, but only on the night of a full moon. + +- **Trigger**: State + - **Entity**: Garden motion binary sensor + - **To**: On +- **Condition**: Moon phase + - **Phase**: Full moon +- **Action**: Turn on light + - **Target**: Garden lights + +{% details "YAML example for full moon garden lights" %} + +{% example %} +automation: | + alias: "Full moon garden lights" + triggers: + - trigger: state + entity_id: binary_sensor.garden_motion + to: "on" + conditions: + - condition: moon.is_phase + options: + phase: full_moon + actions: + - action: light.turn_on + target: + entity_id: light.garden +{% endexample %} + +{% enddetails %} + +{% include conditions/stuck.md %} + +{% include conditions/related.md %} diff --git a/source/_conditions/moon.is_waning.markdown b/source/_conditions/moon.is_waning.markdown new file mode 100644 index 000000000000..5ae39d40518a --- /dev/null +++ b/source/_conditions/moon.is_waning.markdown @@ -0,0 +1,79 @@ +--- +title: "Moon is waning" +condition: moon.is_waning +domain: moon +description: "Tests if the moon is waning." +related_conditions: + - moon.is_waxing + - moon.is_phase +--- + +The **Moon is waning** condition passes while the moon is waning, the half of the lunar month when the lit part shrinks from the full moon back toward the new moon. Home Assistant works this out from the date, so it needs no account, no internet connection, and no location. + +Use it to gate an automation on the falling half of the moon's cycle, for example to run a routine only while the moon is heading back toward dark. + +{% include conditions/ui_header.md %} + +To use this condition in an automation: + +1. Go to {% my automations title="**Settings** > **Automations & scenes**" %}. +2. Open an existing automation, or select **Create automation** > **Create new automation**. +3. In the **And if** section, select **Add condition**. +4. From the search box, search for and select **Moon is waning**. +5. Select **Save**. + +{% include conditions/yaml_header.md %} + +In YAML, refer to this condition as `moon.is_waning`. It has no options: + +{% example %} +condition: | + condition: moon.is_waning +{% endexample %} + +This passes while the moon is waning. + +## Good to know + +- This condition does not use a target. It checks the moon phase, which is the same everywhere on Earth, so it does not depend on your [home location](/docs/configuration/basic/). +- The moon wanes from the full moon back to the new moon, then waxes from the new moon up to the full moon. For the opposite check, use [Moon is waxing](/conditions/moon.is_waxing/). +- The phase is based on the date, so it changes at most once a day. +- To test for a single phase instead of the direction, use [Moon phase](/conditions/moon.is_phase/). + +{% include conditions/try_it.md %} + +{% include conditions/more_examples.md %} + +### Automation: wind-down reminder while the moon wanes + +Each evening, send a gentle wind-down reminder, but only while the moon is waning. + +- **Trigger**: Time + - **At time**: 9:00:00 PM +- **Condition**: Moon is waning +- **Action**: Send a notification message + - **Target**: My Device (`notify.my_device`) + +{% details "YAML example for a waning moon reminder" %} + +{% example %} +automation: | + alias: "Waning moon wind-down reminder" + triggers: + - trigger: time + at: "21:00:00" + conditions: + - condition: moon.is_waning + actions: + - action: notify.send_message + target: + entity_id: notify.my_device + data: + message: "The moon is waning." +{% endexample %} + +{% enddetails %} + +{% include conditions/stuck.md %} + +{% include conditions/related.md %} diff --git a/source/_conditions/moon.is_waxing.markdown b/source/_conditions/moon.is_waxing.markdown new file mode 100644 index 000000000000..20bb5fcf3155 --- /dev/null +++ b/source/_conditions/moon.is_waxing.markdown @@ -0,0 +1,79 @@ +--- +title: "Moon is waxing" +condition: moon.is_waxing +domain: moon +description: "Tests if the moon is waxing." +related_conditions: + - moon.is_waning + - moon.is_phase +--- + +The **Moon is waxing** condition passes while the moon is waxing, the half of the lunar month when the lit part grows from the new moon toward the full moon. Home Assistant works this out from the date, so it needs no account, no internet connection, and no location. + +Use it to gate an automation on the rising half of the moon's cycle, for example to run a routine only while the moon is on its way to full. + +{% include conditions/ui_header.md %} + +To use this condition in an automation: + +1. Go to {% my automations title="**Settings** > **Automations & scenes**" %}. +2. Open an existing automation, or select **Create automation** > **Create new automation**. +3. In the **And if** section, select **Add condition**. +4. From the search box, search for and select **Moon is waxing**. +5. Select **Save**. + +{% include conditions/yaml_header.md %} + +In YAML, refer to this condition as `moon.is_waxing`. It has no options: + +{% example %} +condition: | + condition: moon.is_waxing +{% endexample %} + +This passes while the moon is waxing. + +## Good to know + +- This condition does not use a target. It checks the moon phase, which is the same everywhere on Earth, so it does not depend on your [home location](/docs/configuration/basic/). +- The moon waxes from the new moon up to the full moon, then wanes from the full moon back to the new moon. For the opposite check, use [Moon is waning](/conditions/moon.is_waning/). +- The phase is based on the date, so it changes at most once a day. +- To test for a single phase instead of the direction, use [Moon phase](/conditions/moon.is_phase/). + +{% include conditions/try_it.md %} + +{% include conditions/more_examples.md %} + +### Automation: planting reminder while the moon is waxing + +Some gardeners sow by the moon. Each morning, send a reminder, but only while the moon is waxing. + +- **Trigger**: Time + - **At time**: 9:00:00 AM +- **Condition**: Moon is waxing +- **Action**: Send a notification message + - **Target**: My Device (`notify.my_device`) + +{% details "YAML example for a waxing moon reminder" %} + +{% example %} +automation: | + alias: "Waxing moon planting reminder" + triggers: + - trigger: time + at: "09:00:00" + conditions: + - condition: moon.is_waxing + actions: + - action: notify.send_message + target: + entity_id: notify.my_device + data: + message: "The moon is waxing, a good time to sow." +{% endexample %} + +{% enddetails %} + +{% include conditions/stuck.md %} + +{% include conditions/related.md %} diff --git a/source/_conditions/vibration.is_detected.markdown b/source/_conditions/vibration.is_detected.markdown new file mode 100644 index 000000000000..c7e8ae890948 --- /dev/null +++ b/source/_conditions/vibration.is_detected.markdown @@ -0,0 +1,116 @@ +--- +title: "Vibration is detected" +condition: vibration.is_detected +domain: vibration +description: "Tests if one or more vibration sensors are detecting vibration." +related_conditions: + - vibration.is_not_detected +--- + +The **Vibration is detected** condition passes when one or more vibration sensors are detecting vibration. Use it in an automation to act only while something is shaking or running, such as holding off a quiet-hours routine while an appliance is still working, or sending an alert if a machine is running when it should not be. + +{% include conditions/ui_header.md %} + +To use this condition in an automation: + +1. Go to {% my automations title="**Settings** > **Automations & scenes**" %}. +2. Open an existing automation, or select **Create automation** > **Create new automation**. +3. In the **And if** section, select **Add condition**. +4. From the search box, search for and select **Vibration is detected**. +5. Under **Targets** (see [Targets](#targets)), select one or more vibration entities, devices, an area, a floor, or a label. +6. If you selected more than one target, under **Condition passes if**, pick **Any** or **All**. +7. Under **For at least**, you can set for how long one or more sensors must be detecting vibration before the condition passes. Leave it at zero for the condition to pass as soon as the sensors start detecting vibration. +8. Select **Save**. + +### Options in the UI + +{% options_ui %} +Condition passes if: + description: When multiple vibration sensors are targeted, controls how results combine. Pick **Any** to pass if at least one targeted sensor is detecting vibration, or **All** to pass only when every sensor is detecting vibration. +For at least: + description: How long one or more sensors must be continuously detecting vibration before the condition passes. The default is `0` hours, `00` minutes and `00` seconds. +{% endoptions_ui %} + +{% include conditions/yaml_header.md %} + +In YAML, refer to this condition as `vibration.is_detected`. A basic example looks like this: + +{% example %} +condition: | + condition: vibration.is_detected + target: + entity_id: binary_sensor.dishwasher_vibration + options: + for: "00:05:00" +{% endexample %} + +This passes when the entity `binary_sensor.dishwasher_vibration` has been continuously detecting vibration for 5 minutes. + +### Options in YAML + +YAML sometimes provides additional options for more complex use cases that are not available through the UI. + +{% options_yaml %} +behavior: + description: > + When multiple vibration sensors are targeted, controls how results combine. Accepts `all` or `any`. + required: false + type: string + default: any +for: + description: > + How long one or more vibration sensors must be continuously detecting vibration before the condition passes. Accepts a duration string in `HH:MM:SS` format. + required: false + type: string + default: "00:00:00" +{% endoptions_yaml %} + +{% include conditions/targets.md %} + +{% include conditions/behavior.md %} + +## Good to know + +- With the **For at least** option, the timer resets if the sensor stops detecting vibration during that period. This helps confirm a machine is really running before acting. +- A vibration sensor reports movement, not what caused it. In a busy spot, brief vibrations from nearby activity can make the condition pass, so choose the sensor placement and **For at least** value to match. + +{% include conditions/try_it.md %} + +{% include conditions/more_examples.md %} + +### Automation: remind you if the dishwasher is still running at bedtime + +At bedtime, if the dishwasher's vibration sensor shows it is still running, this automation sends a reminder so you can decide whether to wait up or leave it. + +- **Trigger**: Time (at 22:30:00) +- **Condition**: Vibration is detected + - **Target**: Dishwasher vibration sensor +- **Action**: Send a notification message + - **Target**: My device (`notify.my_device`) + +{% details "YAML example for a dishwasher-still-running reminder" %} + +{% example %} +automation: | + alias: "Remind if the dishwasher is still running at bedtime" + triggers: + - trigger: time + at: "22:30:00" + conditions: + - condition: vibration.is_detected + target: + entity_id: binary_sensor.dishwasher_vibration + actions: + - action: notify.send_message + target: + entity_id: notify.my_device + data: + message: > + The dishwasher is still running. +{% endexample %} + +{% enddetails %} + +{% include conditions/stuck.md %} + +{% include conditions/related.md %} diff --git a/source/_conditions/vibration.is_not_detected.markdown b/source/_conditions/vibration.is_not_detected.markdown new file mode 100644 index 000000000000..93851147d73c --- /dev/null +++ b/source/_conditions/vibration.is_not_detected.markdown @@ -0,0 +1,116 @@ +--- +title: "Vibration is not detected" +condition: vibration.is_not_detected +domain: vibration +description: "Tests if one or more vibration sensors are not detecting vibration." +related_conditions: + - vibration.is_detected +--- + +The **Vibration is not detected** condition passes when one or more vibration sensors are not detecting vibration. Use it in an automation to act only while something is still, such as running a routine once an appliance has finished, or confirming a machine is idle before turning off its power. + +{% include conditions/ui_header.md %} + +To use this condition in an automation: + +1. Go to {% my automations title="**Settings** > **Automations & scenes**" %}. +2. Open an existing automation, or select **Create automation** > **Create new automation**. +3. In the **And if** section, select **Add condition**. +4. From the search box, search for and select **Vibration is not detected**. +5. Under **Targets** (see [Targets](#targets)), select one or more vibration entities, devices, an area, a floor, or a label. +6. If you selected more than one target, under **Condition passes if**, pick **Any** or **All**. +7. Under **For at least**, you can set for how long one or more sensors must stay without detecting vibration before the condition passes. Leave it at zero for the condition to pass as soon as the sensors stop detecting vibration. +8. Select **Save**. + +### Options in the UI + +{% options_ui %} +Condition passes if: + description: When multiple vibration sensors are targeted, controls how results combine. Pick **Any** to pass if at least one targeted sensor is not detecting vibration, or **All** to pass only when every sensor is not detecting vibration. +For at least: + description: How long one or more sensors must stay without detecting vibration before the condition passes. The default is `0` hours, `00` minutes and `00` seconds. +{% endoptions_ui %} + +{% include conditions/yaml_header.md %} + +In YAML, refer to this condition as `vibration.is_not_detected`. A basic example looks like this: + +{% example %} +condition: | + condition: vibration.is_not_detected + target: + entity_id: binary_sensor.washing_machine_vibration + options: + for: "00:15:00" +{% endexample %} + +This passes when the sensor `binary_sensor.washing_machine_vibration` has not detected vibration for 15 minutes. + +### Options in YAML + +YAML sometimes provides additional options for more complex use cases that are not available through the UI. + +{% options_yaml %} +behavior: + description: > + When multiple vibration sensors are targeted, controls how results combine. Accepts `all` or `any`. + required: false + type: string + default: any +for: + description: > + How long one or more vibration sensors must stay without detecting vibration before the condition passes. Accepts a duration string in `HH:MM:SS` format. + required: false + type: string + default: "00:00:00" +{% endoptions_yaml %} + +{% include conditions/targets.md %} + +{% include conditions/behavior.md %} + +## Good to know + +- With the **For at least** option, the timer resets if any targeted sensor detects vibration during that period. This helps confirm a machine has truly finished rather than briefly paused. +- A vibration sensor only reports movement. If a machine sits completely still during part of its cycle, the condition can pass before the cycle is actually done. Choose the **For at least** value with that in mind. + +{% include conditions/try_it.md %} + +{% include conditions/more_examples.md %} + +### Automation: turn off the washing machine's plug once it is done + +At a set time in the evening, if the washing machine's vibration sensor has been still for 15 minutes, this automation turns off its smart plug to save standby power. + +- **Trigger**: Time (at 23:00:00) +- **Condition**: Vibration is not detected + - **Target**: Washing machine vibration sensor + - **For at least**: 00:15:00 +- **Action**: Turn off switch + - **Target**: Washing machine plug + +{% details "YAML example for turning off the washing machine plug when idle" %} + +{% example %} +automation: | + alias: "Turn off the washing machine plug when idle" + triggers: + - trigger: time + at: "23:00:00" + conditions: + - condition: vibration.is_not_detected + target: + entity_id: binary_sensor.washing_machine_vibration + options: + for: "00:15:00" + actions: + - action: switch.turn_off + target: + entity_id: switch.washing_machine_plug +{% endexample %} + +{% enddetails %} + +{% include conditions/stuck.md %} + +{% include conditions/related.md %} diff --git a/source/_docs/blueprint/selectors.markdown b/source/_docs/blueprint/selectors.markdown index 0653be2694b5..4b6a9d1a9f40 100644 --- a/source/_docs/blueprint/selectors.markdown +++ b/source/_docs/blueprint/selectors.markdown @@ -731,8 +731,8 @@ will contain the entity ID, or list of entity IDs, based on if `multiple` is set to `true`. An entity selector can filter the list of entities, based on things like the -class of the device, the domain of the entity or the domain that provided the -entity. +manufacturer, model, or model ID of the device the entity belongs to, the +device class, the domain of the entity, or the domain that provided the entity. ![Screenshot of an entity selector](/images/blueprints/selector-entity.png) @@ -763,9 +763,45 @@ filter: description: > Can be set to an integration domain. Limits the list of entities to entities provided by the set integration domain, for example, - [`zha`](/integrations/zha). + [`matter`](/integrations/matter). An entity and the device it belongs to can be + provided by different integrations, so this option only filters by the + entity's integration. To filter by the device's integration, use the + `integration` option under `device` instead. type: string required: false + device: + description: > + Filters the entities by properties of the device they belong to. + type: map + required: false + keys: + integration: + description: > + Can be set to an integration domain. Limits the list of entities to + entities that belong to devices provided by the set integration + domain, for example, [`hue`](/integrations/hue). This filters by the + integration that provides the device, which can differ from the + integration that provides the entity itself. + type: string + required: false + manufacturer: + description: > + When set, it limits the list of entities to entities that belong to + devices provided by the set manufacturer name. + type: string + required: false + model: + description: > + When set, it limits the list of entities to entities that belong to + devices that have the set model. + type: string + required: false + model_id: + description: > + When set, the list of entities is limited to entities that belong to + devices that have the set model ID. + type: string + required: false domain: description: > Limits the list of entities to entities of a certain [domain(s)](/docs/configuration/entities_domains/#domains), for example, @@ -817,9 +853,9 @@ light.living_room ### Example entity selector -An example entity selector that, will only show entities that are: +An example entity selector that shows only entities that are: -- Provided by the [ZHA](/integrations/zha) integration. +- Provided by the [Hue](/integrations/hue) integration. - From the [Binary sensor](/integrations/binary_sensor) domain. - Have presented themselves as devices of a motion device class. - Allows selecting one or more entities. @@ -830,11 +866,29 @@ And this is what it looks like in YAML: entity: multiple: true filter: - - integration: zha + - integration: hue domain: binary_sensor device_class: motion ``` +{% tip %} +Integration filters aren't reliable for devices that can connect through +multiple integrations, such as Matter or Zigbee. +To reliably target specific hardware, combine the filter with +`device.manufacturer`, `device.model`, or `device.model_id`. +{% endtip %} + +Filter for a specific device using the device filter: + +```yaml +entity: + multiple: true + filter: + - device: + manufacturer: IKEA of Sweden + model: BILRESA dual button +``` + ## Floor selector The floor selector shows a floor finder that can pick diff --git a/source/_docs/configuration/basic.markdown b/source/_docs/configuration/basic.markdown index b73e0d951038..42a341c1406e 100644 --- a/source/_docs/configuration/basic.markdown +++ b/source/_docs/configuration/basic.markdown @@ -30,7 +30,7 @@ To change the home information (formerly called general settings) that were defi - **Country** - **Language** - To apply your changes, select **Save**. -4. To change network-related configuration, such as the network name, go to {% my network title="**Settings** > **System** > **Network**" %}. +4. To change network-related configuration, such as the network name, Home Assistant URL, or HTTP server settings, go to {% my network title="**Settings** > **System** > **Network**" %}. 5. Troubleshooting: If any of the settings are grayed out and can't be edited, this is because they are defined in the {% term "`configuration.yaml`" %} file. - If you prefer editing the settings in the UI, you have to delete these entries from the {% term "`configuration.yaml`" %} file. - For more information about the general settings in YAML, refer to the [Home Assistant Core integration documentation](/integrations/homeassistant/). diff --git a/source/_docs/configuration/remote.markdown b/source/_docs/configuration/remote.markdown index bcddb9307f3d..423418e6f43b 100644 --- a/source/_docs/configuration/remote.markdown +++ b/source/_docs/configuration/remote.markdown @@ -36,7 +36,7 @@ See [Reverse proxies in the HTTP integration documentation](/integrations/http/# ## Port forwarding -Set up port forwarding (for any port) from your router to port 8123 on the computer that is hosting Home Assistant. General instructions on how to do this can be found by searching ` port forwarding instructions`. You can use any free port on your router and forward that to port 8123. +Set up port forwarding from your router to the port Home Assistant listens on. By default, this is port 8123 on the computer that is hosting Home Assistant. If you changed the Home Assistant HTTP server port, use the port shown under {% my network title="**Settings** > **System** > **Network**" %}. General instructions on how to do this can be found by searching ` port forwarding instructions`. You can use any free port on your router and forward that to the Home Assistant HTTP server port. A problem with making a port accessible is that some Internet Service Providers only offer dynamic IPs. This can cause you to lose access to Home Assistant while away. You can solve this by using a free Dynamic DNS service like [DuckDNS](https://www.duckdns.org/). diff --git a/source/_integrations/alexa.flash_briefings.markdown b/source/_integrations/alexa.flash_briefings.markdown index d9d57fa9b0aa..7b6e3f4f75d2 100644 --- a/source/_integrations/alexa.flash_briefings.markdown +++ b/source/_integrations/alexa.flash_briefings.markdown @@ -15,11 +15,10 @@ As of version [0.31][zero-three-one] Home Assistant supports the new [Alexa Flas Amazon requires the endpoint of a skill to be hosted via SSL. Self-signed certificates are OK because our skills will only run in development mode. Read more on [our blog][blog-lets-encrypt] about how to set up encryption for Home Assistant. Using the [Let's Encrypt](/addons/lets_encrypt/) and [Duck DNS](/addons/duckdns/) apps is the easiest method. If you are unable to get HTTPS up and running, consider using [this AWS Lambda proxy for Alexa skills](https://community.home-assistant.io/t/5230). -Additionally, note that at the time of this writing, your Alexa skill endpoint *must* accept requests over port 443 (Home Assistant default to 8123). There are two ways you can handle this: +Additionally, note that at the time of this writing, your Alexa skill endpoint _must_ accept requests over port 443. The default Home Assistant HTTP server port is 8123. There are two ways you can handle this: - 1. In your router, forward external 443 to your Home Assistant serving port (defaults to 8123) - OR - 2. Change your Home Assistant serving port to 443 this is done in the [`http`](/integrations/http/) section with the `server_port` entry in your {% term "`configuration.yaml`" %} file +1. In your router, forward external port 443 to the Home Assistant HTTP server port. +2. Change the Home Assistant HTTP server port to 443 under {% my network title="**Settings** > **System** > **Network**" %}, in the **HTTP server** section. [blog-lets-encrypt]: /blog/2015/12/13/setup-encryption-using-lets-encrypt/ diff --git a/source/_integrations/alexa_devices.markdown b/source/_integrations/alexa_devices.markdown index b51d5ae117fa..dea97a54ce68 100644 --- a/source/_integrations/alexa_devices.markdown +++ b/source/_integrations/alexa_devices.markdown @@ -117,7 +117,7 @@ All Alexa-enabled devices have timestamp sensors that show the next scheduled al In addition to sensors, you can use the following entities: -- **Button** - Execute Alexa routines +- **Button** - Execute Alexa routines, restart the device - **Media Player** - Play audio/video from several sources - **Notify** - Speak and Announce notifications - **Select** - Select Drop In status @@ -319,6 +319,7 @@ You see something similar to - `Error retrieving devices state: Too many requests for path ['listEndpoints']` - `Error retrieving data: CannotRetrieveData('Request failed: Bad Request')` - `Failed to obtain notification data. Timers and alarms have not been updated` +- `Failed to refresh communications settings for device XXXXXX, used cached values.` In logs. diff --git a/source/_integrations/bluetooth.markdown b/source/_integrations/bluetooth.markdown index cc953535ff2f..271eef29ada1 100644 --- a/source/_integrations/bluetooth.markdown +++ b/source/_integrations/bluetooth.markdown @@ -342,6 +342,11 @@ The following remote adapters are supported: - Bluetooth advertisement bundling: Shelly Gen2+ device - Single active connection: not supported - Multiple active connections: not supported +- [SMLIGHT](/integrations/smlight/) + - Bluetooth advertisement listening: SMLIGHT SLZB-U device + - Bluetooth advertisement bundling: SMLIGHT SLZB-U device + - Single active connection: not supported + - Multiple active connections: not supported Bluetooth advertisement bundling reduces traffic between Home Assistant and the proxy, significantly improving performance and reducing the time that Bluetooth and WiFi compete for air time for devices that share a radio. diff --git a/source/_integrations/centriconnect.markdown b/source/_integrations/centriconnect.markdown index f8b9818c26ca..f2f402826f86 100644 --- a/source/_integrations/centriconnect.markdown +++ b/source/_integrations/centriconnect.markdown @@ -11,6 +11,7 @@ ha_codeowners: - '@gresrun' ha_domain: centriconnect ha_platforms: + - diagnostics - sensor ha_integration_type: device ha_quality_scale: bronze diff --git a/source/_integrations/cielo_home.markdown b/source/_integrations/cielo_home.markdown index 76f52eb3f03f..673453634cb2 100644 --- a/source/_integrations/cielo_home.markdown +++ b/source/_integrations/cielo_home.markdown @@ -3,6 +3,7 @@ title: Cielo Home description: Instructions on how to integrate Cielo smart thermostats in Home Assistant. ha_category: - Climate + - Sensor ha_iot_class: Cloud Polling ha_release: 2026.6 ha_config_flow: true @@ -12,6 +13,7 @@ ha_codeowners: ha_domain: cielo_home ha_platforms: - climate + - sensor ha_integration_type: hub ha_quality_scale: bronze --- @@ -61,7 +63,7 @@ If the message **This key is already used** appears, you must first revoke the o {% include integrations/config_flow.md %} -If authentication succeeds, Home Assistant will automatically create the climate entities for all supported Cielo devices in your account. +If authentication succeeds, Home Assistant will automatically create the climate and sensor entities for all supported Cielo devices in your account. {% note %} @@ -107,6 +109,13 @@ Some fan modes or swing positions depend on the device’s remote configuration. - **Temperature control**: Set the temperature setpoint. - **Presets**: Home, Away, Sleep & pets (where supported and defined) +### Sensors + +Each supported device also exposes sensor entities that appear under the same device as the climate entity: + +- **Temperature**: Reports the current indoor temperature from the device. The unit (°C or °F) follows the device setting. +- **Humidity**: Reports the current humidity from the device, in percent. + ## Data updates This integration relies on cloud {% term polling %}, with data refreshed approximately every 120 seconds (2 minutes). If the Cielo API or your device becomes unavailable, Home Assistant will automatically retry. diff --git a/source/_integrations/data_grand_lyon.markdown b/source/_integrations/data_grand_lyon.markdown index 1902e80d9ffc..87686b66a68e 100644 --- a/source/_integrations/data_grand_lyon.markdown +++ b/source/_integrations/data_grand_lyon.markdown @@ -24,6 +24,7 @@ With this integration, you can: - Track upcoming departure times at transit stops. - Monitor real-time bike and dock availability at [Vélo'v](https://velov.grandlyon.com/) bike-sharing stations. +- Monitor real-time parking space availability at TCL park & ride (P+R) facilities. ## Prerequisites @@ -46,7 +47,7 @@ Password: description: "Your password on data.grandlyon.com." {% endconfiguration_basic %} -After setting up the integration, you can add transit stops and Vélo'v bike-sharing stations as sub-entries from the integration's configuration page. +After setting up the integration, you can add transit stops, Vélo'v bike-sharing stations, and park & ride facilities as sub-entries from the integration's configuration page. ### Adding a transit stop @@ -73,6 +74,17 @@ Station: description: "The Vélo'v station identifier. You can find station IDs on the [Grand Lyon open data platform](https://data.grandlyon.com/portail/fr/jeux-de-donnees/stations-velo-v-metropole-lyon/donnees). Zoom in on the map and select a station. The ID will be displayed at the top of the panel displayed on the right of the screen. The field is called **idstation**." {% endconfiguration_basic %} +### Adding a park & ride + +1. Go to {% my integrations title="**Settings** > **Devices & services**" %} and select the **Data Grand Lyon** integration. +2. Select **Add park & ride**. +3. Select the park & ride you want to monitor. You can search the list by name, or enter a park & ride ID directly. + +{% configuration_basic %} +Park & ride: + description: "The park & ride identifier. You can find park & ride IDs on the [Grand Lyon open data platform](https://data.grandlyon.com/portail/fr/jeux-de-donnees/parcs-relais-reseau-transports-commun-lyonnais-disponibilites-temps-reel/donnees). Zoom in on the map and select a park & ride. The ID will be displayed in the panel on the right of the screen." +{% endconfiguration_basic %} + ## Supported functionality ### Entities @@ -142,6 +154,25 @@ For each Vélo'v station you add, the following sensor entities are created: - **Electrical removable battery bikes** - **Description**: The number of electrical bikes with a removable battery available at the station. Disabled by default. +#### Park & ride sensors + +For each park & ride you add, the following sensor entities are created: + +- **Available parking spaces** + - **Description**: The number of parking spaces currently available at the facility. + +- **Capacity** + - **Description**: The total number of parking spaces at the facility. + +- **Accessible parking spaces** + - **Description**: The number of parking spaces reserved for people with reduced mobility. Disabled by default. + +- **Opening hours** + - **Description**: The opening hours of the facility. Disabled by default. + +- **Name** + - **Description**: The name of the park & ride facility. Disabled by default. + ## Examples ### Refresh data more frequently during a time window @@ -217,6 +248,10 @@ When the source has no live data, it often comes back later. Sometimes the data Make sure the station ID is correct. You can verify it on the [Grand Lyon open data platform](https://data.grandlyon.com/portail/fr/jeux-de-donnees/stations-velo-v-metropole-lyon/donnees). +### Park & ride shows no data + +Make sure the park & ride ID is correct. You can verify it on the [Grand Lyon open data platform](https://data.grandlyon.com/portail/fr/jeux-de-donnees/parcs-relais-reseau-transports-commun-lyonnais-disponibilites-temps-reel/donnees). + ## Removing the integration This integration follows standard integration removal. diff --git a/source/_integrations/denon_rs232.markdown b/source/_integrations/denon_rs232.markdown index 4d687b2987c1..508b4fbb8780 100644 --- a/source/_integrations/denon_rs232.markdown +++ b/source/_integrations/denon_rs232.markdown @@ -36,6 +36,7 @@ For supported receivers, you can use Home Assistant to: - Change the volume - Mute and unmute the main zone - Select the input source +- Select a tuner preset or FM frequency ### Zones @@ -50,3 +51,27 @@ The available zones depend on your receiver model. ### Source selection The available input sources depend on the receiver model you select during setup. + +### Selecting tuner presets and frequencies + +On the main zone, you can tune the receiver to a stored tuner preset or directly to an FM frequency. This works from the media browser, which lists the tuner presets, or by calling the `media_player.play_media` action with a `media_content_type` of `channel`. + +The `media_content_id` can be a preset name from `A1` through `G8`: +```yaml +action: media_player.play_media +target: + entity_id: media_player.denon_avr +data: + media_content_type: channel + media_content_id: "A1" +``` + +It can also be tuned to an FM frequency between `8750` (87.50 MHz) and `10800` (108.00 MHz): +```yaml +action: media_player.play_media +target: + entity_id: media_player.denon_avr +data: + media_content_type: channel + media_content_id: "9870" +``` diff --git a/source/_integrations/dropbox.markdown b/source/_integrations/dropbox.markdown index c5299de524bd..621bdddd6623 100644 --- a/source/_integrations/dropbox.markdown +++ b/source/_integrations/dropbox.markdown @@ -10,7 +10,7 @@ ha_codeowners: - '@bdr99' ha_domain: dropbox ha_integration_type: service -ha_quality_scale: bronze +ha_quality_scale: silver --- This {% term integration %} allows you to connect your [Dropbox](https://dropbox.com) account with Home Assistant Backups. diff --git a/source/_integrations/duco.markdown b/source/_integrations/duco.markdown index a6adf409e24b..9a57f11aa3fe 100644 --- a/source/_integrations/duco.markdown +++ b/source/_integrations/duco.markdown @@ -49,7 +49,7 @@ Other Duco systems that expose public API version 2.1 or newer can also be set u The following node types are supported: -- **BOX**: The main ventilation box; provides fan control, ventilation state select, ventilation state, target flow level, state end time, and Wi-Fi signal strength. Models that expose a filter timer also provide a filter remaining sensor. +- **BOX**: The main ventilation box; provides fan control, ventilation state select, ventilation state, target flow level, state end time, air temperatures, and Wi-Fi signal strength. Models that expose a filter timer also provide a filter remaining sensor. - **BSCO2**: CO₂ sensor module wired directly to the DucoBox PCB; provides CO₂ concentration and CO₂ air quality index. - **UCCO2**: Wall-mounted CO₂ sensor unit; provides CO₂ concentration and CO₂ air quality index. - **BSRH**: Humidity sensor module installed in the duct inlet of the DucoBox, wired directly to the PCB via cable; provides relative humidity and humidity air quality index. @@ -113,6 +113,15 @@ Home Assistant only shows the options advertised by your Duco system for that sp The following sensor entities are created per node, depending on the node type: +#### Air temperatures + +Available for the main ventilation box (BOX) when the Duco system exposes the values. These sensors show the following temperatures in degrees Celsius: + +- **Outdoor air temperature**: Air entering the ventilation box from outdoors. +- **Supply air temperature**: Air supplied from the ventilation box to your home. +- **Extract air temperature**: Air extracted from your home into the ventilation box. +- **Exhaust air temperature**: Air leaving the ventilation box to outdoors. + #### Target flow level Available for the main ventilation box (BOX) and supported valve or extract node families with ventilation data. Shows the actual airflow target as reported by the Duco box, as a percentage (0–100%). This value reflects the real airflow configured in the Duco firmware. On the main ventilation box, it can differ from the abstract speed levels (33%, 66%, or 100%) shown in the fan entity. For example, if your Duco system is configured with manual speed levels of 15%, 30%, and 100%, this sensor shows those values. diff --git a/source/_integrations/edifier_infrared.markdown b/source/_integrations/edifier_infrared.markdown index 242f0452139f..70c98ab00dd2 100644 --- a/source/_integrations/edifier_infrared.markdown +++ b/source/_integrations/edifier_infrared.markdown @@ -50,6 +50,7 @@ The integration supports the following Edifier speaker models and remote profile - RC20G - RC31A - RC80B +- S3000 Pro - S360DB Several of these models share the same IR command set, so other Edifier speakers that ship with the same remote may also work — try the closest model in the list. If your model is not listed and you want it supported, please [open an issue on the infrared-protocols repository](https://github.com/home-assistant-libs/infrared-protocols/issues) with captured IR signals from your remote. @@ -69,11 +70,15 @@ The **Edifier Infrared** integration provides the following entities. Some models also provide button entities for functionality that is not exposed by the media player entity, such as selecting a specific input or toggling sound effects. The available buttons depend on the selected model, because not every Edifier remote exposes the same buttons. Possible buttons include: - **Bluetooth**: Switches the speaker to its Bluetooth input. +- **USB**: Switches the speaker to its USB input. - **Line 1** and **Line 2**: Switch the speaker to the corresponding line input. +- **Line / Balanced**: Toggles between the line and balanced inputs. - **AUX**: Switches the speaker to its auxiliary input. - **PC**: Switches the speaker to its PC input. - **Optical**: Switches the speaker to its optical input. - **Coaxial**: Switches the speaker to its coaxial input. +- **Optical / Coaxial**: Toggles between the optical and coaxial inputs. +- **Classic EQ**, **Dynamic EQ**, **Monitor EQ**, and **Vocal EQ**: Select the corresponding equalizer preset. - **FX on** and **FX off**: Turn the speaker's sound effects on or off. diff --git a/source/_integrations/energieleser.markdown b/source/_integrations/energieleser.markdown index 609f798e9960..c89fe8da337c 100644 --- a/source/_integrations/energieleser.markdown +++ b/source/_integrations/energieleser.markdown @@ -16,12 +16,30 @@ ha_config_flow: true ha_zeroconf: true ha_platforms: - sensor +related: + - docs: /docs/configuration/troubleshooting/#debug-logs-and-diagnostics + title: Debug logs and diagnostics --- -The energieleser {% term integration %} fetches real-time consumption data reported by energieleser devices, such as stromleser.one, gasleser, wasserleser, and wärmeleser, using a local HTTP API. +The energieleser {% term integration %} fetches real-time consumption data reported by energieleser devices, such as stromleser.one, gasleser, wasserleser, and wärmeleser, using local HTTP API. [energieleser](https://energieleser.de/) is a brand by nineti GmbH, a German company offering smart readers for utility meters. +## Supported devices + +The integration supports the following energieleser devices: + +- **stromleser.one** (electricity meter reader) +- **gasleser** (gas meter reader) +- **wasserleser** (water meter reader) +- **wärmeleser** (heat meter reader) + +## Prerequisites + +Ensure your energieleser device is connected to the same local network as your Home Assistant instance and its IP address is accessible. + +For detailed hardware setup instructions, refer to the [energieleser documentation](https://docs.energieleser.de/). + {% include integrations/config_flow.md %} ## Configuration parameters @@ -31,36 +49,90 @@ IP address: description: "The IP address of your energieleser device. For example, `192.168.178.100`." {% endconfiguration_basic %} +## Supported functionality + +The energieleser integration primarily provides the following features based on the connected device type. + +### stromleser.one + +- **Imported energy**: Cumulative energy consumed (kWh) +- **Exported energy**: Cumulative energy exported to the grid (kWh) +- **Active power**: Current active power (W) +- **Phase power**: Current active power for Phase 1, Phase 2, and Phase 3 (W) + +### gasleser + +- **Total gas**: Total gas volume measured by the meter (m³) +- **Gas flow rate**: Current gas flow rate (m³/h) + +### wasserleser + +- **Total water**: Total water volume measured by the meter (m³) +- **Water flow rate**: Current water flow rate in liters per hour (L/h) +- **Volume flow rate**: Current water flow rate in cubic meters per hour (m³/h) + +### wärmeleser + +- **Energy tariffs**: Cumulative heat energy for tariff 1, tariff 2, and tariff 3 (MWh) +- **Power**: Current thermal power (kW) +- **Total volume**: Total volume of heating medium measured by the meter (m³) +- **Volume flow**: Current flow rate of heating medium (L/h) +- **Temperatures**: Flow temperature and return temperature (°C) +- **Temperature difference**: Difference between flow and return temperature (K) + +### Common sensors + +- **Signal strength**: Wi-Fi signal strength of the device (dBm) + ## Data updates -The integration fetches data by polling the device locally over your network. - -## Available sensors - -The following sensors are supported depending on the device type and meter capabilities: - -- **stromleser.one**: - - Imported energy (kWh): Cumulative energy consumed - - Exported energy (kWh): Cumulative energy exported to the grid - - Active power (W): Current active power - - Phase 1, Phase 2, and Phase 3 power (W): Current active power for each of the three phases -- **gasleser**: - - Total gas (m³): Total gas volume measured by the meter - - Gas flow rate (m³/h): Current gas flow rate -- **wasserleser**: - - Total water (m³): Total water volume measured by the meter - - Water flow rate (L/h): Current water flow rate in liters per hour - - Volume flow rate (m³/h): Current water flow rate in cubic meters per hour -- **wärmeleser**: - - Energy tariff 1, tariff 2, and tariff 3 (MWh): Cumulative heat energy for each of the three tariffs - - Power (kW): Current thermal power - - Total volume (m³): Total volume of heating medium measured by the meter - - Volume flow (L/h): Current flow rate of heating medium - - Flow temperature (°C): Temperature of the incoming heating medium - - Return temperature (°C): Temperature of the outgoing heating medium - - Temperature difference (K): Difference between flow and return temperature -- **Common sensors**: - - Signal strength (dBm): Wi-Fi signal strength of the device +The integration {% term polling polls %} data from the device every 10 seconds over your local network. + +## Use cases + +You can use the energieleser integration for a variety of smart home scenarios, such as: + +- Monitoring your energy consumption: Add the sensors to the Home Assistant Energy dashboard to track your daily, monthly, and yearly consumption of electricity, gas, water, or heat. +- Automation based on usage: Trigger automations when electricity consumption goes above or below certain thresholds (for example, turn on appliances when excess solar power is being exported). +- Detection of leaks and anomalies: Create alerts for continuous water flow or unusual gas usage patterns to detect potential leaks. + +## Automation examples + +Below is an example automation to notify you when high power consumption is detected. + +### Automation: Alert on high power consumption + +```yaml +automation: + - alias: "High power consumption alert" + triggers: + - trigger: numeric_state + entity_id: sensor.stromleser_one_active_power + above: 5000 + for: + minutes: 5 + actions: + - action: notify.notify + data: + title: "High Power Usage" + message: "Your active power consumption has been above 5kW for 5 minutes." +``` + +## Known limitations + +Rate limits: The energieleser devices can be overwhelmed by excessive HTTP requests. If you configure multiple apps or integrations to poll the same device simultaneously, the device may reach a rate limit or become temporarily unresponsive. + +## Troubleshooting + +### Cannot connect during setup + +If you see a "Failed to connect" error during setup, verify that: + +- The energieleser device is powered on and connected to your network. +- The IP address you entered is correct. +- Home Assistant can reach the device on the local network. + +Most energieleser devices are discovered automatically via zeroconf, so manual setup is rarely needed. If the device is not discovered, check that zeroconf/mDNS traffic is not blocked on your network. ## Removing the integration diff --git a/source/_integrations/enphase_envoy.markdown b/source/_integrations/enphase_envoy.markdown index 5066ee208cf9..ea813498a916 100644 --- a/source/_integrations/enphase_envoy.markdown +++ b/source/_integrations/enphase_envoy.markdown @@ -47,11 +47,11 @@ This integration does not work with: - The Envoy must be on your local network with IPV4 connectivity from Home Assistant. (Also See troubleshooting, [periodic network connection issues](#periodic-network-connection-issues)) - Envoy firmware version 3.9 or newer. - With Envoy firmware 7 and greater: - - an Enlighten cloud username and password. + - An Enphase cloud username and password. - Home Assistant 2023.9 or newer. {% note %} -Currently, Multi Factor Authentication for the Enlighten account is not supported by this integration. It should be disabled during Envoy configuration and token refresh. +If you have multi-factor authentication enabled on your Enphase account, make sure to read the [required manual input](#required-manual-input) and [credentials and/or token configuration](#credentials-andor-token-configuration) for manual token entry. {% endnote %} {% include integrations/config_flow.md %} @@ -65,10 +65,13 @@ The configuration of an individual Envoy requires you to enter the following inf Host: description: "The name or IP address of the Envoy to configure.
Will be pre-filled if the Envoy was auto-discovered" Username: - description: "For firmware version 7.0 and later, enter your Enlighten cloud username. The Enlighten cloud username (and password) will be used to obtain a 1-year-valid token from the enphase web-site when first configured or upon expiry. -
For firmware before 7.0, enter username *installer* without a password." + description: "For firmware version 7.0 and later, enter your Enphase cloud username. The Enphase cloud username and password are used to obtain a one-year token from the Enphase website when first configured or when the token expires.
If your Enphase account uses multi-factor authentication, you must enter the access token manually instead of entering your username and password.
For firmware before 7.0, enter username *installer* without a password." Password: - description: "For firmware version 7.0 and later, enter your Enlighten cloud password
For firmware before 7.0, with username *installer*, leave blank." + description: "For firmware version 7.0 and later, enter your Enphase cloud password.
For firmware before 7.0, with username *installer*, leave blank." +Enter the Envoy access token manually: + description: "If you want to enable or disable entering a token manually, select or clear this option and select **Submit**. The form will switch between username/password entry and token entry modes. Use manual token entry mode if your Enphase cloud account has multi-factor authentication enabled. See [credentials and/or token configuration](#credentials-andor-token-configuration)." +Envoy access token: + description: "Enter the access token retrieved from the [Enphase token portal](https://entrez.enphaseenergy.com). The description text below the field includes the link to the portal and the current token lifetime. This field is only available when **Enter the Envoy access token manually** is enabled." {% endconfiguration_basic %} {% include integrations/option_flow.md %} @@ -82,11 +85,53 @@ Always use a new connection when requesting data from the Envoy: description: "No/Yes
Some older Envoy firmware may exhibit connection issues when using the default keep-alive connection and report failures. When set, this option disables the use of keep-alive and builds a new connection at each data request. This makes the communication more reliable for these firmware versions. Reported for the Envoy-R, but may apply to other older firmware versions as well." {% endconfiguration_basic %} +## Credentials and/or token configuration + +When configuring an Envoy, a form appears that prompts you for the [required manual input](#required-manual-input). In all cases the Envoy IP address needs to be specified. In most cases the IP address will be pre-filled by the detection mechanism. If this is not the case, enter it as it is a required field. + +{% details "Configuration form in automatic token retrieval mode" %} +
+ Example screenshot of Envoy configuration form in automatic token retrieval mode. +
Envoy configuration form in automatic token retrieval mode.
+
+{% enddetails %} + +For firmware before 7.0, the username *installer* without a password can be used to configure the Envoy. Enter these in the form and select **Submit**. + +For firmware version 7.0 and later, you need to enter your Enphase cloud username and password. Home Assistant stores these credentials in the configuration and uses them to retrieve an access token from the Enphase token portal. Token retrieval happens initially during the configuration process and again 30 days before the one-year token expires. The Enphase token portal must be reachable during configuration. If it is not, the configuration fails, and you need to retry it later. If the Enphase token portal is unreachable during a token refresh attempt 30 days before expiry, Home Assistant retries the refresh on subsequent days until it succeeds. + +If you have multi-factor authentication enabled on your Enphase cloud account, automatic token retrieval will not work. You will have to obtain a token manually and enter it in the form. If this is the case, you have to switch the configuration method to manual token entry. Do this by selecting the option `Enter the Envoy access token manually` and select **Submit**. This will change the form to only prompt for host and token. Enter the access token retrieved from the [Enphase token portal](https://entrez.enphaseenergy.com). The description below the form field includes the link to the portal for easy access and shows the number of days until the token expires. + +{% details "Configuration form in manual token entry mode" %} +
+ Example screenshot of Envoy configuration form in manual token entry mode. +
Envoy configuration form in manual token entry mode.
+
+{% enddetails %} + +If you prefer not to have your Enphase cloud username and password stored by Home Assistant for this integration, you can use the manual token entry mode as well. In this mode, only the token is stored by Home Assistant for the integration. + +To switch back from manual token entry to automatic token retrieval use the reverse process. Deselect the option `Enter the Envoy access token manually` and select **Submit** to switch to the username/password entry mode. + +### Token expiry repair + +When in manual token entry mode, you will have to take care of timely token update. To alert you in time, the integration will display a repair note in **Settings**. The repair will show when the token expiry is within the next 30 days. Use the [reconfigure](#reconfigure) menu option for the Envoy integration to update the token. If you opt to ignore the repair, it will show again the next day. The repair will disappear when the token is updated and valid again. + ## Reconfigure -This integration supports updating the Envoy configuration through a `reconfigure` menu option. The reconfiguration allows for changing the Envoy IP address, username, and/or password. Use this menu option if your Enlighten credentials or the device's IP address has changed and needs to be manually updated. The latter is typically automatically detected and updated. +This integration supports updating the Envoy configuration through a `reconfigure` menu option for the Enphase Envoy integration in {% my integrations title="**Settings** > **Devices & services** > **Integrations** " %}. The reconfiguration allows for changing the Envoy IP address, username, password, manual token entry mode and/or token. The `reconfigure` menu will show the form as described in [Credentials and/or token configuration](#credentials-andor-token-configuration) and [Required manual input](#required-manual-input) with current configured information. + +Use this menu when: + +- You changed your Enphase cloud credentials. +- You need to change the IP address of the Envoy, even though a changed device IP address is typically automatically detected and updated. +- You enable multi-factor authentication on your Enphase account and need to switch the configuration to manual token entry. +- In manual token entry mode you need to update the manual token before expiry. +- In case of an Envoy firmware upgrade requiring to switch from local Envoy username/password to token-based authentication with Enphase username/password. -Use this menu option also when an Envoy firmware upgrade requires a switch from local Envoy username/password to token-based authentication with Enlighten username/password (refer to [required manual input](#required-manual-input)). +## Re-authenticating the Envoy + +The Envoy requires re-authentication if the automatic token refresh fails to update the token, or the manually entered token is not updated before it expires. Home Assistant shows this state, and when you resolve it, the process is the same as described in [Credentials and/or token configuration](#credentials-andor-token-configuration). There is one difference: the IP address is not shown in the re-authentication form. ## Removing the integration @@ -453,7 +498,7 @@ The Enphase C6 combiner controller (C6CC) provides some status information to th ## Data polling interval -All data is collected in one coordinated collection cycle and sourced from a limited set of endpoints on the Envoy. For example, three different values sourced from the same endpoint are not pulled in three different requests but provided from the same single request. This method minimizes the number of requests to the Envoy. The local REST API of the Envoy is used. Only when the 1-year valid token is to expire, 1 month before due data, a new token is requested from the Enphase Enlighten website. +All data is collected in a single coordinated collection cycle and sourced from a limited set of endpoints on Envoy. For example, three different values sourced from the same endpoint are not pulled in three separate requests but are provided in a single request. This method minimizes the number of requests to the Envoy. The local REST API of the Envoy is used. The Enphase cloud is only used when configuring an Envoy and when the one-year-valid token is about to expire. 30 days before the expiry date, a new token is requested from the Enphase website. The integration collects data for all entities by default every 60 seconds. To customize the collection interval, refer to [defining a custom polling interval](/common-tasks/general/#defining-a-custom-polling-interval). Specify one single entity from the envoy device as target of the action using the `+ choose entity` button. Updating one entity will update all entities of the Envoy and the related devices like the inverters; there is no need to specify multiple or all entities or add (all) inverter entities. When using multiple Envoys, add one entity for each envoy as targets or create separate custom polling intervals with a single entity as needed. @@ -461,12 +506,6 @@ Envoy installations without installed CTCT, data granularity increases and shortening the collection interval can provide more details. The Envoy, however, has no unlimited resources and shortening the collection interval may result in dropped connections, Envoy freeze or restarts. It will require some step-wise tuning for each individual situation. -## Credentials or device IP address update - -This integration supports updating the Envoy configuration through a `reconfigure` menu option. The reconfiguration allows for changing the Envoy IP address, username, and/or password. Use this menu option if your Enlighten credentials or the device's IP address has changed and needs to be manually updated. The latter is typically automatically detected and updated. - -Use this menu option also when an Envoy firmware upgrade requires a switch from local Envoy username/password to token-based authentication with Enlighten username/password (refer to [required manual input](#required-manual-input)). - ## Firmware updates The firmware version is read from the envoy when the configuration entry is loaded. The firmware version is then used in the process of determining capabilities and required authorization methods. The firmware version is available as the `sw_version` attribute of the configuration entry and shown on the device view of the envoy. @@ -551,7 +590,7 @@ Although not a replacement for individual energy or power measurement devices, w ## Actions -Available actions are: `switch.turn_on`, `switch.turn_off`, `switch.toggle`, [`number.set_value`](#action-numberset_value), [`select.select`](#action-selectselect) +Available actions are: `switch.turn_on`, `switch.turn_off`, `switch.toggle`, [`number.set_value`](#action-numberset_value) and [`select.select_option`](#action-selectselect_option). ### Action `switch.turn_on`/`switch.turn_off`/`switch.toggle` @@ -788,16 +827,17 @@ The example below shows data gaps starting at 11 PM on multiple, but not all, da ## Troubleshooting -### Enlighten authentication issues +### Enphase authentication issues -If you experience authentication errors during the configuration of the Envoy, ensure if Multi Factor Authentication (MFA) is disabled for your Enlighten account. Currently, this integration does not support MFA for token retrieval. If any of the below errors show, verify if MFA is disabled. +If you experience authentication errors during the (re-)configuration of the Envoy, verify if multi-factor authentication (MFA) is enabled for your Enphase account. When using MFA, automatic token retrieval will fail, and you need to use manual token entry as described in [Credentials and/or token configuration](#credentials-andor-token-configuration). Disabling MFA is not required if manual token entry mode is used. Any of the errors below indicate that MFA is enabled on your Enphase cloud account. - Before HA version 2026.1.2: KeyError: 'is_consumer' - As of Home Assistant version 2026.1.2 - KeyError: 'session_id' - - EnvoyAuthenticationError: No session id in Enlighten login reply, disable Multi Factor Authentication + - EnvoyAuthenticationError: No session id in Enphase login reply, disable multi-factor authentication + - Although the error mentions to disable multi-factor authentication, in the current HA version the resolution is to switch to manual token entry. -These error may also appear in the log upon token refresh, 11 months after initial token collection. +These errors may also appear in the log upon token refresh, 11 months after initial token collection. ### Periodic network connection issues @@ -907,4 +947,8 @@ ___ ### IQ Combiner reference [TEB-00269-2.0-EN, March 2025](https://enphase.com/it-it/media/26097) + +### Enphase token portal + +Obtain a token from the [Enphase token portal](https://entrez.enphaseenergy.com) ___ diff --git a/source/_integrations/fail2ban.markdown b/source/_integrations/fail2ban.markdown index 6cf6db19c9d3..5b1432b044db 100644 --- a/source/_integrations/fail2ban.markdown +++ b/source/_integrations/fail2ban.markdown @@ -166,14 +166,9 @@ server { } ``` -Once that's added to the NGINX configuration, we need to modify the Home Assistant {% term "`configuration.yaml`" %} such that the `X-Forwarded-For` header can be parsed. This is done by adding the following to the `http` integration: +Once that's added to the NGINX configuration, allow Home Assistant to parse the `X-Forwarded-For` header. Go to {% my network title="**Settings** > **System** > **Network**" %}. In the **HTTP server** section, turn on **Trust X-Forwarded-For** and add the IP address or CIDR network of the NGINX reverse proxy to **Trusted proxies**. -```yaml -http: - use_x_forwarded_for: true -``` - -At this point, once the Let's Encrypt and Home Assistant dockers are restarted, Home Assistant should be correctly logging the originating IP of any failed login attempt. Once that's done and verified, we can move onto the final step. +At this point, once the Let's Encrypt and Home Assistant containers are restarted, Home Assistant should be correctly logging the originating IP of any failed login attempt. Once that's done and verified, we can move on to the final step. #### Add the fail2ban sensor diff --git a/source/_integrations/fronius.markdown b/source/_integrations/fronius.markdown index ab83fcff314d..15ea773ebb7d 100644 --- a/source/_integrations/fronius.markdown +++ b/source/_integrations/fronius.markdown @@ -3,6 +3,7 @@ title: Fronius description: Instructions on how to connect your Fronius SolarAPI devices to Home Assistant. ha_release: 0.96 ha_category: + - Binary sensor - Energy - Sensor ha_codeowners: @@ -11,6 +12,7 @@ ha_config_flow: true ha_domain: fronius ha_iot_class: Local Polling ha_platforms: + - binary_sensor - diagnostics - sensor ha_dhcp: true @@ -82,7 +84,9 @@ Each device adds a set of sensors to Home Assistant. - Energy produced on the current day, year and total produced energy - Power fed to the grid (if positive) or consumed from the grid (if negative) - Power load as a generator (if positive) or consumer (if negative) - - Battery charging power (if positive) or discharging power (if negative) and information about backup or standby mode + - Battery charging power (if positive) or discharging power (if negative) + - Whether the battery is in standby, on Gen24 devices with a battery + - Whether the system is currently supplying backup power during a grid outage, on Gen24, Tauro, and Verto devices with backup power configured - Photovoltaic production - Current relative self-consumption of produced energy - Current relative autonomy diff --git a/source/_integrations/fuelprices_dk.markdown b/source/_integrations/fuelprices_dk.markdown new file mode 100644 index 000000000000..8f2994e9100a --- /dev/null +++ b/source/_integrations/fuelprices_dk.markdown @@ -0,0 +1,78 @@ +--- +title: Fuelprices.dk +description: Use current fuel prices from Danish fuel stations in Home Assistant using the Fuelprices.dk API. +ha_category: + - Sensor +ha_release: 2026.8 +ha_iot_class: Cloud Polling +ha_codeowners: + - "@MTrab" +ha_domain: fuelprices_dk +ha_config_flow: true +ha_integration_type: hub +ha_platforms: + - sensor +ha_quality_scale: bronze +related: + - url: https://fuelprices.dk + title: Fuelprices.dk +--- + +The **Fuelprices.dk** {% term integration %} uses the [Fuelprices.dk API](https://fuelprices.dk) as a source for fuel price data from Danish fuel companies. + +All station data and prices are provided by [Fuelprices.dk](https://fuelprices.dk) and the fuel companies. + +## Companies currently supported + +To view a list of currently supported companies, refer to [Fuelprices.dk Companies](https://fuelprices.dk/selskaber). + +## Prerequisites + +To set up the integration, you need a valid [Fuelprices.dk](https://fuelprices.dk) API key + +1. Go to [Fuelprices.dk](https://fuelprices.dk). +2. Select **Registrering**. +3. Enter your `name` and `email address`. +4. Select **Opret bruger**. +5. Check your email and copy your API key. + +After setup, you can reconfigure selected products for each station from the integration settings. + +{% include integrations/config_flow.md %} + +{% configuration_basic %} +api_key: + description: Your API key as specified in the email received after registration on [Fuelprices.dk](https://fuelprices.dk) +{% endconfiguration_basic %} + +## Supported functionality + +## Sensors +The integration creates sensor entities for the selected station: + +- One price sensor per selected product (for example **Blyfri 92**, **Oktan 95**, and **Diesel**) + +## Data updates + +The integration {% term polling polls %} [Fuelprices.dk](https://fuelprices.dk) every hour. + +The integration does not modify values. Home Assistant shows the values exactly as returned by [Fuelprices.dk](https://fuelprices.dk). + +## Known limitations + +- Data availability and freshness depend on [Fuelprices.dk](https://fuelprices.dk) and the fuel companies. +- Some stations may not provide all products. +- API rate limits can temporarily delay updates. + +## Troubleshooting + +- **Invalid API key**: Verify that your API key is correct and still active. +- **Cannot connect**: Check your internet connection and try again later. +- **Rate limit exceeded**: Wait and try again later. +- **Missing prices for a product**: Verify that the selected station provides that product on [Fuelprices.dk](https://fuelprices.dk). + +## Removing the integration + +This integration follows standard integration removal. No extra steps are required. + +{% include integrations/remove_device_service.md %} diff --git a/source/_integrations/gardena_bluetooth.markdown b/source/_integrations/gardena_bluetooth.markdown index 72cd79a49a2a..bee2e339c8bd 100644 --- a/source/_integrations/gardena_bluetooth.markdown +++ b/source/_integrations/gardena_bluetooth.markdown @@ -30,7 +30,7 @@ ha_integration_type: device The **Gardena Bluetooth** {% term integration %} allows users to integrate their Gardena Bluetooth devices into Home Assistant. -See device section for support information: [water control](#water-control), [irrigation valves](#irrigation-valves), [lawn mowers](#lawn-mowers), [garden pumps](#gard-pumps), [aqua contours](#aqua-contours). +See the device sections for support information: [water control](#water-control), [irrigation valves](#irrigation-valves), [lawn mowers](#lawn-mowers), [garden pumps](#gard-pumps), [pressure tank units](#pressure-tank-units), [aqua contours](#aqua-contours). {% include integrations/config_flow.md %} @@ -78,6 +78,13 @@ Gardena Bluetooth lawn mowers are currently not supported due to custom protocol - Garden Pump ([9058-61](https://www.gardena.com/int/products/pumps/watering-pumps/garden-pump-6300-silentcomfort/970645301.html)) - Garden Pump ([9059-61](https://www.gardena.com/int/products/pumps/watering-pumps/garden-pump-6500-silentcomfort/970645501.html)) +## Pressure tank units + +- Pressure Tank Unit 5600 SilentComfort ([9067-20](https://www.gardena.com/int/products/pumps/domestic-water-supply-pumps/pressure-tank-unit-5600-silentcomfort/970646301.html)) +- Pressure Tank Unit 6300 SilentComfort ([9068-20](https://www.gardena.com/int/products/pumps/domestic-water-supply-pumps/pressure-tank-unit-6300-silentcomfort/970646501.html)) + +In addition to the pump controls, pressure tank units provide sensors for the current tank pressure and water temperature. + ## Aqua Contours - Aqua Precise Overground ([16000-20](https://www.gardena.com/int/products/watering/sprinklersystem/aquaprecise-solar-powered-lawn-irrigation-system/970746801.html)) diff --git a/source/_integrations/gatus.markdown b/source/_integrations/gatus.markdown new file mode 100644 index 000000000000..779536f06027 --- /dev/null +++ b/source/_integrations/gatus.markdown @@ -0,0 +1,178 @@ +--- +title: Gatus +description: Instructions on how to integrate Gatus with Home Assistant. +ha_category: + - Binary sensor +ha_release: 2026.8 +ha_iot_class: Local Polling +ha_config_flow: true +ha_codeowners: + - '@TN-1' +ha_domain: gatus +ha_integration_type: service +ha_platforms: + - binary_sensor +ha_quality_scale: silver +--- + +The **Gatus** {% term integration %} connects Home Assistant with your [Gatus](https://gatus.io) monitoring instance. Gatus is a developer-oriented health dashboard that lets you monitor your services using HTTP, ICMP, TCP, and DNS queries, and evaluate results based on conditions like status codes, response times, certificate expiration, and response bodies. + +## Use cases + +- Display the live status of your self-hosted services on a Home Assistant dashboard. +- Trigger automations or send notifications when a monitored service goes down or comes back up. +- Combine endpoint status with other Home Assistant entities to coordinate responses to outages, such as switching to a backup service or alerting specific people. + +## Prerequisites + +You need the base URL of your Gatus instance, for example `http://gatus.local:8080` or `https://status.example.com`. + +{% include integrations/config_flow.md %} + +{% configuration_basic %} +URL: + description: "The full base URL of your Gatus status page instance, including the protocol and port. For example: `http://gatus.local:8080` or `https://status.example.com`." +{% endconfiguration_basic %} + +### Supported versions + +This integration supports **Gatus version 5.x.x or higher** + +## Supported functionality + +The **Gatus** {% term integration %} provides the following entities. + +### Binary sensors + +For each endpoint configured in Gatus, the integration creates one binary sensor. + +- **Connectivity**: Reports `on` (connected) when the most recent check for that endpoint succeeded, and `off` (disconnected) when it failed. + +## Gatus automation examples + +Here are a few ideas to get you started. + +{% include docs/paste_yaml_tip.md %} + +### Send a notification when a service goes down + +Get notified the moment one of your monitored endpoints fails its health check. + +To create this automation in the UI: + +1. Go to {% my automations title="**Settings** > **Automations & scenes**" %} and create a new automation. +2. Add a **State** trigger. +3. In **Entity**, select the Gatus binary sensor for the endpoint you want to monitor. +4. In **To**, enter `off`. +5. Add the **Send a notification message** action. +6. In **Target**, select the notification entity for your device, for example **My Phone** (`notify.my_phone`). +7. In **Message**, enter `Service {{ trigger.to_state.name }} is down!`. + +{% details "Example YAML configuration" %} + +{% example %} +automation: | + alias: "Notify when a Gatus endpoint goes down" + triggers: + - trigger: state + entity_id: binary_sensor.my_gatus_endpoint + to: "off" + actions: + - action: notify.send_message + target: + entity_id: notify.my_phone + data: + message: "Service {{ trigger.to_state.name }} is down!" +{% endexample %} + +{% enddetails %} + +### Send a notification when a service recovers + +Get notified when a previously failing endpoint comes back online. + +To create this automation in the UI: + +1. Go to {% my automations title="**Settings** > **Automations & scenes**" %} and create a new automation. +2. Add a **State** trigger. +3. In **Entity**, select the Gatus binary sensor for the endpoint you want to monitor. +4. In **From**, enter `off`. +5. In **To**, enter `on`. +6. Add the **Send a notification message** action. +7. In **Target**, select the notification entity for your device, for example **My Phone** (`notify.my_phone`). +8. In **Message**, enter `Service {{ trigger.to_state.name }} is back online.`. + + +{% details "Example YAML configuration" %} + +{% example %} +automation: | + alias: "Notify when a Gatus endpoint recovers" + triggers: + - trigger: state + entity_id: binary_sensor.my_gatus_endpoint + from: "off" + to: "on" + actions: + - action: notify.send_message + target: + entity_id: notify.my_phone + data: + message: "Service {{ trigger.to_state.name }} is back online." +{% endexample %} + +{% enddetails %} + +## Data updates + +The integration {% term polling polls %} your Gatus instance every 30 seconds. + +## Reconfiguration + +If you need to update the connection details (URL) of your Gatus instance, you can reconfigure the integration: + +1. Go to {% my integrations title="**Settings** > **Devices & services**" %}. +2. Select the **Gatus** integration card. +3. Select the three dots menu {% icon "mdi:dots-vertical" %}, and then select **Reconfigure**. +4. Update the URL of your Gatus instance. +5. Select **Submit**. + +Reconfiguring or reloading the integration will automatically discover and add any newly configured endpoints as new binary sensor entities. + +## Known limitations + +- The integration shows the result of the most recent health check. Historical results stored by Gatus are not available as entities. +- The integration requires a manual reload or reconfiguration to discover when a new endpoint is added or removed. +- The integration currently does not support authenticated instances. + +## Troubleshooting + +### Can't set up the integration + +#### Symptom: "Unable to connect" + +The setup form shows an error saying it cannot connect to your Gatus instance. + +#### Resolution + +1. Confirm your Gatus instance is running and reachable from your Home Assistant host. +2. Check that the URL you entered is correct and includes the protocol and port, for example `http://gatus.local:8080`. +3. If Gatus is behind a reverse proxy or uses HTTPS, make sure the certificate is valid and the URL matches exactly. +4. Check your firewall rules to confirm Home Assistant is allowed to reach the Gatus host on the configured port. + +### Entities are unavailable + +If entities become unavailable after setup, Home Assistant could not reach your Gatus instance during the last data refresh. Check your network connection and confirm the Gatus instance is still running. Entities will recover automatically once the connection is restored. + +## Diagnostics + +The Gatus integration supports [diagnostic data collection](/docs/configuration/troubleshooting/#download-diagnostics) to help troubleshoot issues. If you're experiencing problems with the integration, you can download diagnostic information to include when reporting issues. + +The diagnostic data contains the status of all Gatus endpoints monitored by the integration. It does not include the URL you entered to connect to Gatus. + +## Removing the integration + +This integration follows standard integration removal. + +{% include integrations/remove_device_service.md %} + diff --git a/source/_integrations/gitter.markdown b/source/_integrations/gitter.markdown deleted file mode 100644 index c1f6a2d49beb..000000000000 --- a/source/_integrations/gitter.markdown +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: Gitter -description: Connect and control your Gitter devices using the Matrix integration -ha_category: - - Hub - - Notifications -ha_release: 0.69 -ha_domain: gitter -ha_integration_type: virtual -related: - - docs: /docs/configuration/ - title: Configuration file -ha_supporting_domain: matrix -ha_supporting_integration: Matrix -ha_codeowners: - - '@PaarthShah' -ha_platforms: - - notify -ha_iot_class: Cloud Push ---- - -This **Gitter** {% term integration %} allows one to monitor a [Gitter.im](https://gitter.im) chatroom for unread messages. - -## Configuration - -Visit [Gitter Developer Apps](https://developer.gitter.im/apps) to retrieve your "Personal Access Token". - -To use a Gitter {% term integration %} in your installation, add the following to your {% term "`configuration.yaml`" %} file. -{% include integrations/restart_ha_after_config_inclusion.md %} - -```yaml -# Example configuration.yaml entry -sensor: - - platform: gitter - api_key: YOUR_API_TOKEN -``` - -{% configuration %} -api_key: - description: Your Gitter.im API token. - required: true - type: string -room: - description: Gitter room to monitor. - required: false - type: string - default: "`home-assistant/home-assistant`" -{% endconfiguration %} diff --git a/source/_integrations/google_health.markdown b/source/_integrations/google_health.markdown new file mode 100644 index 000000000000..f4a38038d1c3 --- /dev/null +++ b/source/_integrations/google_health.markdown @@ -0,0 +1,181 @@ +--- +title: Google Health +description: Instructions on how to integrate Google Health within Home Assistant. +ha_release: 2026.7 +ha_category: + - Health +ha_iot_class: Cloud Polling +ha_domain: google_health +ha_codeowners: + - '@allenporter' +ha_config_flow: true +ha_platforms: + - sensor +ha_integration_type: service +related: + - url: https://developers.google.com/health-api + title: Google Health API + - url: https://console.cloud.google.com/apis/library/health.googleapis.com + title: Google Developers Console +--- + +The **Google Health** {% term integration %} allows you to expose health and fitness data from Google Health (including Fitbit, Pixel Watch, and other devices connected to your Google Account) to Home Assistant. + +## Prerequisites + +You need to configure developer credentials to allow Home Assistant to access your Google Account. These credentials are the same as the ones for [Google Photos](/integrations/google_photos), [Nest](/integrations/nest), [Google Tasks](/integrations/google_tasks), and [Google Mail](/integrations/google_mail). + +If you have already set up the correct credentials, you can enable the API and then skip the consent screen and credential creation steps. + +{% details "Generate client ID and client secret" %} + +This section explains how to enable the API, configure the consent screen, and generate a client ID and client secret on the Google Developers Console. + +1. First, go to the Google Developers Console to enable the [Google Health API](https://console.cloud.google.com/apis/library/health.googleapis.com). +2. Select a project and select **Continue**. Verify that the API is enabled. +3. Go to the [Branding page](https://console.cloud.google.com/auth/branding) in the Google Auth Platform Console. +4. If prompted to configure OAuth, select **Get started** and follow the setup wizard. When the wizard asks for the user type, select **External**, and continue once the OAuth consent configuration is created. +5. Select **Branding** in the left sidebar. Fill in the required fields: + - **App name**: Enter a name (like *Home Assistant*). This is shown during the OAuth login flow. + - **User support email**: Select your Google Account email. + - **Developer contact email**: Enter your email address. + Leave all other fields empty to avoid triggering Google's verification process. Select **Save**. +6. Select **Audience** in the left sidebar. + - Under **User type**, confirm it shows **External**. + - Under **Test users**, select **+ Add users** and add your Google Account email address. Select **Save**. +7. Under **Publishing status**, select **Publish app** to set the status to **In production**. Make sure the status is not **Testing**, or your authentication token will expire every 7 days. +8. Select **Credentials** in the left sidebar. +9. Select **Create Credentials** at the top of the page, then select **OAuth client ID**. +10. Set the Application type to **Web application** and give these credentials a name (like *Home Assistant Credentials*). +11. Under **Authorized redirect URIs**, enter `https://my.home-assistant.io/redirect/oauth` and select **Create**. This is not a placeholder and is the URI that must be used. +12. Copy the **Client ID** and **Client Secret** from the pop-up, or select the pencil icon next to your client ID to view them later. + +{% enddetails %} + +{% include integrations/config_flow.md %} + +The integration setup will next give you instructions to enter the [Application Credentials](/integrations/application_credentials/) (OAuth Client ID and Client Secret) and authorize Home Assistant to access your Google Health data. + +{% details "OAuth and authorization steps" %} + +1. Continue through the steps of selecting the Google Account you want to authorize. +2. You will be asked to grant access to specific data in your Google Health account. The integration will dynamically adjust based on the permissions you grant: + - **Profile** (required): Allows Home Assistant to verify your account identity. + - **Activity and fitness** (optional): Granting this scope creates daily steps and distance sensors. + - **Health metrics and measurements** (optional): Granting this scope creates weight and resting heart rate sensors. +3. You may get a message telling you that the app has not been verified. Acknowledge this to proceed. +4. You can now see the details of what you are authorizing Home Assistant to access with options at the bottom. Select **Continue**. +5. The page will now display **Link account to Home Assistant?**, noting **Your instance URL**. If this is not correct, refer to [My Home Assistant](/integrations/my). If everything looks good, select **Link Account**. +6. You may close the window and return to Home Assistant, where you should see a **Success!** message. + +{% enddetails %} + +## Supported functionality + +The **Google Health** integration provides the following entities: + +### Sensors + +- **Distance** + - **Description**: Daily distance in meters. + - **Available for**: All authorized accounts that grant the activity and fitness scope. +- **Resting heart rate** + - **Description**: Daily resting heart rate in beats per minute (bpm). + - **Available for**: All authorized accounts that grant the health metrics and measurements scope. +- **Steps** + - **Description**: Daily steps count. + - **Available for**: All authorized accounts that grant the activity and fitness scope. +- **Weight** + - **Description**: Body weight in kilograms (kg). + - **Available for**: All authorized accounts that grant the health metrics and measurements scope. + +## Google Health automation examples + +The real power of this integration is automating your home environment or notifications based on your health metrics. Here are a few ideas to get you started. + +{% include docs/paste_yaml_tip.md %} + +### Automation: Step goal reminder + +Send a notification in the evening if you have not met your daily step goal. + +- **Trigger**: Time: 20:00 (8:00 PM) +- **Condition**: Numeric state: steps sensor is below your goal (for example, 10,000 steps) +- **Action**: Send a notification to your mobile phone + +{% details "YAML example for step goal reminder" %} + +{% example %} +automation: | + alias: "Reminder to meet daily step goal" + triggers: + - trigger: time + at: "20:00:00" + conditions: + - condition: numeric_state + entity_id: sensor.google_health_steps + below: 10000 + actions: + - action: notify.mobile_app_your_phone + data: + message: > + You have only completed + {{ states('sensor.google_health_steps') }} steps today. + Time for a short walk! +{% endexample %} + +{% enddetails %} + +### Automation: Resting heart rate alert + +Notify you if your daily resting heart rate goes above a certain threshold (for example, 80 bpm), which could indicate fatigue or stress. + +- **Trigger**: State: resting heart rate sensor state changes +- **Condition**: Numeric state: resting heart rate is above 80 bpm +- **Action**: Send a notification + +{% details "YAML example for resting heart rate alert" %} + +{% example %} +automation: | + alias: "Alert on high resting heart rate" + triggers: + - trigger: state + entity_id: sensor.google_health_resting_heart_rate + conditions: + - condition: numeric_state + entity_id: sensor.google_health_resting_heart_rate + above: 80 + actions: + - action: notify.mobile_app_your_phone + data: + message: > + Your resting heart rate is higher than usual at + {{ states('sensor.google_health_resting_heart_rate') }} + bpm. Make sure to rest! +{% endexample %} + +{% enddetails %} + +## Data updates + +The integration updates sensors on different intervals based on the data type: + +- Activity sensors (Steps and Distance) are updated every 15 minutes. +- Body sensors (Weight and Resting heart rate) are updated every hour. + +## Troubleshooting + +### Resetting a broken or incorrect configuration + +If the Google Health integration was initially configured incorrectly, you can delete the credentials in the [Application Credentials](/integrations/application_credentials/) user interface and start the setup again. + +### Connection failed after authorization + +If authorization appears to succeed but Home Assistant returns a connection error, verify that you granted the required **Profile** permission. Home Assistant requires the profile scope to verify your account identity and setup the integration. + +## Removing the integration + +This integration follows standard integration removal. + +{% include integrations/remove_device_service.md %} diff --git a/source/_integrations/gree.markdown b/source/_integrations/gree.markdown index 9bb0e9be96c2..d0d60261cc92 100644 --- a/source/_integrations/gree.markdown +++ b/source/_integrations/gree.markdown @@ -52,12 +52,46 @@ The `gree` climate platform integrates Gree HVAC systems into Home Assistant, en - [`turn on/off`](/integrations/climate/#action-turn-on) - [`fan mode`](/integrations/climate/#action-set-fan-mode) - [`swing mode`](/integrations/climate/#action-set-swing-mode) +- [`swing horizontal mode`](/integrations/climate/#action-set-swing-horizontal-mode) - [`set_preset_mode`](/integrations/climate/#action-set-preset-mode) {% note %} Preset mode **Away** represents Gree's "8°C heating mode." {% endnote %} +### Swing modes + +Both the vertical and horizontal airflow directions can be controlled independently, with granular position control. + +{% important %} +The vertical swing mode values changed in Home Assistant 2026.x. If you have automations or scripts that use the old values (`off`, `vertical`, `horizontal`, or `both`), you will need to update them to use the new values listed below. +{% endimportant %} + +The vertical swing mode controls the up/down airflow direction and supports the following positions: + +- `default`: device default position +- `full_swing`: full vertical sweep +- `fixed_upper`: fixed at the upper position +- `fixed_upper_middle`: fixed at the upper-middle position +- `fixed_middle`: fixed at the middle position +- `fixed_lower_middle`: fixed at the lower-middle position +- `fixed_lower`: fixed at the lower position +- `swing_upper`: oscillates in the upper range +- `swing_upper_middle`: oscillates in the upper-middle range +- `swing_middle`: oscillates in the middle range +- `swing_lower_middle`: oscillates in the lower-middle range +- `swing_lower`: oscillates in the lower range + +The horizontal swing mode controls the left/right airflow direction and supports the following positions: + +- `default`: device default position +- `full_swing`: full horizontal sweep +- `left`: fixed at the left position +- `left_center`: fixed at the left-center position +- `center`: fixed at the center position +- `right_center`: fixed at the right-center position +- `right`: fixed at the right position + ## Switch Gree devices expose multiple switches to control various features: diff --git a/source/_integrations/harman_luxury.markdown b/source/_integrations/harman_luxury.markdown new file mode 100644 index 000000000000..38b9cc7f1278 --- /dev/null +++ b/source/_integrations/harman_luxury.markdown @@ -0,0 +1,59 @@ +--- +title: Harman Luxury Audio +description: Instructions on how to integrate Harman Luxury Audio streamers into Home Assistant. +ha_category: + - Media player +ha_release: 2026.8 +ha_iot_class: Local Polling +ha_config_flow: true +ha_codeowners: + - '@sbesh91' +ha_domain: harman_luxury +ha_platforms: + - media_player +ha_integration_type: device +ha_quality_scale: bronze +ha_ssdp: true +--- + +The **Harman Luxury Audio** {% term integration %} lets you control network streamers built on the Harman Luxury Audio (StreamUnlimited StreamSDK) platform, such as the Arcam Radia **ST5** and **ST60**, and equivalent JBL and Mark Levinson streamers. + +It talks to the device directly on your local network; no cloud account is required. + +{% include integrations/config_flow.md %} + +Devices are discovered automatically over SSDP. You can also add one manually by entering its hostname or IP address. + +{% configuration_basic %} +Host: + description: The hostname or IP address of the streamer on your network. +{% endconfiguration_basic %} + +## Supported devices + +The following devices are known to work: + +- Arcam Radia ST5 +- Arcam Radia ST60 + +Other streamers on the same Harman Luxury Audio / StreamUnlimited platform (including JBL and Mark Levinson models) are expected to work but have not all been verified. + +## Supported functionality + +A media player entity is created for the device, exposing: + +- Playback state (playing, paused, idle) and standby status +- Now playing information: title, artist, album, artwork, duration, and position +- Volume level and mute +- Transport controls (play, pause, stop, next, previous) + +## Known limitations + +- Power cannot be controlled from Home Assistant. The device only reports its power state; it is switched on and off by its own remote, front panel, or automatic standby. The media player reports `off` when the device is in standby but does not offer power on/off. +- Transport control depends on the active source. Spotify Connect and AirPlay are controlled by the sending app: the device can pause them, but only the source app can resume. Because of this, transport buttons are shown only when the current source reports them as available. For those sources, use the originating app to start or resume playback. + +## Removing the integration + +This integration follows standard integration removal. + +{% include integrations/remove_device_service.md %} diff --git a/source/_integrations/homekit.markdown b/source/_integrations/homekit.markdown index e4edfb3f7c28..547c15f3355a 100644 --- a/source/_integrations/homekit.markdown +++ b/source/_integrations/homekit.markdown @@ -222,10 +222,10 @@ homekit: required: true type: string type: - description: Only for `switch` and `fan` entities. Type of accessory to be created within HomeKit. Valid types for `switch` entities are `faucet`, `outlet`, `shower`, `sprinkler`, `switch` and `valve`. Valid types for `fan` entities are `fan` and `air_purifier`. + description: Only for `switch`, `fan`, and `climate` entities. Type of accessory to be created within HomeKit. Valid types for `switch` entities are `faucet`, `outlet`, `shower`, `sprinkler`, `switch` and `valve`. Valid types for `fan` entities are `fan` and `air_purifier`. Valid types for `climate` entities are `heater_cooler` and `thermostat`. For `climate` entities, the type is chosen automatically when you leave this unset. required: false type: string - default: '`switch`' + default: "`switch` for `switch` entities, `fan` for `fan` entities, and chosen automatically for `climate` entities" stream_count: description: Only for `camera` entities. The number of simultaneous streams the camera can support. required: false @@ -361,6 +361,24 @@ If you create a HomeKit integration via the UI (for example, **Settings** > **De It is recommended to only edit a HomeKit instance in the UI that was created in the UI, and likewise, only edit a HomeKit instance in YAML that was created in YAML. +### Climate accessory type + +Climate entities are exposed to HomeKit as one of two accessory types. Air conditioners and heat pumps that offer two or more fan speeds or a swing mode that can be turned off are listed as Heater Cooler accessory type. This puts the mode, target temperature, heating and cooling thresholds, fan speed, and swing on one tile, matching how the device works. Everything else, such as a central thermostat, is exposed as a Thermostat accessory. A climate entity that controls a target humidity always stays a Thermostat, since the Heater Cooler accessory cannot control humidity. + +This choice is made automatically the first time an entity is added to HomeKit. Entities that were already exposed before this feature was introduced keep their Thermostat accessory, and you can switch them to the Heater Cooler accessory at any time. + +You can also pick the accessory type yourself at any time. For a bridge created in the UI, go to {% my integrations title="**Settings** > **Devices & services**" %}, select **Configure** on the HomeKit bridge, and choose **Thermostat** or **Heater Cooler** for each climate entity in the climate step. For a bridge set up in YAML, set the entity's `type` to `heater_cooler` or `thermostat` in `entity_config`: + +```yaml +# Example configuration.yaml entry +homekit: + entity_config: + climate.living_room: + type: heater_cooler +``` + +The accessory keeps its identifier, which is derived from the entity ID, so its room assignment and name are preserved when the accessory type changes. Any Home app scenes or automations that referenced the old controls may need to be recreated against the new tile. + ### Accessory mode When exposing a Camera, Activity based remote (a `remote` that supports activities), Lock, or Television media player (a `media_player` with device class `tv` or `receiver`) to HomeKit, `mode` must be set to `accessory`, and the relevant `include` filter should be set up to only include a single entity. diff --git a/source/_integrations/html5.markdown b/source/_integrations/html5.markdown index bf749be7f19b..c276f6d58ce4 100644 --- a/source/_integrations/html5.markdown +++ b/source/_integrations/html5.markdown @@ -97,71 +97,6 @@ Each event includes **state attributes** that provide additional context: {% include integrations/actions.md %} -## Automating notification events - -During the lifespan of a single push notification, Home Assistant will emit a few different events to the event bus which you can use to write automations against. - -Common event payload parameters are: - -| Parameter | Description | -| --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| `action` | The `action` key that you set when sending the notification of the action clicked. Only appears in the `clicked` event. | -| `data` | The data dictionary you originally passed in the notify payload, minus any parameters that were added to the HTML5 notification (`actions`, `badge`, `body`, `dir`, `icon`, `image`, `lang`, `renotify`, `requireInteraction`, `tag`, `timestamp`, `vibrate`, `silent`). | -| `tag` | The unique identifier of the notification. Can be overridden when sending a notification to allow for replacing existing notifications. | -| `target` | The target that this notification callback describes. | -| `type` | The type of event callback received. Can be `received`, `clicked` or `closed`. | - -You can use the `target` parameter to write automations against a single `target`. For more granularity, use `action` and `target` together to write automations which will do specific things based on what target clicked an action. - -### Received event - -You will receive an event named `html5_notification.received` when the -notification is received on the device. - -{% example %} -automation: | - alias: "HTML5 push notification received and displayed on device" - triggers: - - trigger: event - event_type: html5_notification.received -{% endexample %} - -### Clicked event - -You will receive an event named `html5_notification.clicked` when the notification or a notification action button is clicked. The action button clicked is available as `action` in the `event_data`. - -{% example %} -automation: | - alias: "HTML5 push notification clicked" - triggers: - - trigger: event - event_type: html5_notification.clicked -{% endexample %} - -or - -{% example %} -automation: | - alias: "HTML5 push notification action button clicked" - triggers: - - trigger: event - event_type: html5_notification.clicked - event_data: - action: open_door -{% endexample %} - -### Closed event - -You will receive an event named `html5_notification.closed` when the notification is closed. - -{% example %} -automation: | - alias: "HTML5 push notification clicked" - triggers: - - trigger: event - event_type: html5_notification.closed -{% endexample %} - ## Enabling HTML5 Push Notifications behind an NGINX reverse proxy with authentication If your Home Assistant instance is behind an NGINX reverse proxy with authentication enabled, device events may fail to reach Home Assistant. This happens because the authentication token used by the HTML5 Push Notifications integration may not pass through the proxy correctly. diff --git a/source/_integrations/http.markdown b/source/_integrations/http.markdown index 4ad7813a6911..4efcfcf053d2 100644 --- a/source/_integrations/http.markdown +++ b/source/_integrations/http.markdown @@ -1,6 +1,6 @@ --- title: HTTP -description: Offers a web framework to serve files. +description: Configure the HTTP server that serves the Home Assistant frontend and APIs. ha_category: - Other ha_release: pre 0.7 @@ -12,112 +12,70 @@ ha_domain: http ha_integration_type: system --- -The **HTTP** {% term integration %} serves all files and data required for the Home Assistant frontend. You only need to add this to your configuration file if you want to change any of the default settings. +The **HTTP** {% term integration %} serves the Home Assistant frontend and APIs. You can manage the HTTP server settings from the UI under {% my network title="**Settings** > **System** > **Network**" %}. -There is currently support for the following device types within Home Assistant: +The integration supports these entity types: - [Binary sensor](#binary-sensor) - [Sensor](#sensor) -{% warning %} -The option `server_host` should only be used on a Home Assistant Container installation! -{% endwarning %} +## HTTP server settings -```yaml -# Example configuration.yaml entry -http: -``` +To change how Home Assistant serves its web interface, go to {% my network title="**Settings** > **System** > **Network**" %}, then find the **HTTP server** section. -{% configuration %} -server_host: - description: "Only listen to incoming requests on specific IP/host. By default the `http` integration auto-detects IPv4/IPv6 and listens on all connections. Use `server_host: 0.0.0.0` if you want to only listen to IPv4 addresses. The default listed assumes support for IPv4 and IPv6." - required: false - type: [list, string] - default: "0.0.0.0, ::" -server_port: - description: Allows you to specify which port Home Assistant should listen on. - required: false - type: integer - default: 8123 -ssl_certificate: - description: Path to your TLS/SSL certificate to serve Home Assistant over a secure connection. If you are using the [Let's Encrypt app for Home Assistant](https://github.com/home-assistant/addons/tree/master/letsencrypt) (formerly known as Let's Encrypt add-on), this will be at `/ssl/fullchain.pem`. We recommend to use the [NGINX app for Home Assistant](https://github.com/home-assistant/addons/tree/master/nginx_proxy) (formerly known as NGINX add-on) instead of using this option. +### Options in the UI + +{% options_ui %} +Server port: + description: | + The port Home Assistant listens on. The default is `8123`. + + _Caution_: If you use the + [Home Assistant Companion app](https://companion.home-assistant.io/), update the Home Assistant URL + in the app after changing this port. + required: true +Listen addresses: + description: The IP addresses Home Assistant binds to. Leave this empty to listen on all interfaces. required: false - type: string -ssl_peer_certificate: - description: Path to the client/peer TLS/SSL certificate to accept secure connections from. +SSL certificate path: + description: The absolute path to the TLS certificate, for example `/ssl/fullchain.pem`. required: false - type: string -ssl_key: - description: Path to your TLS/SSL key to serve Home Assistant over a secure connection. If you are using the [Let's Encrypt app](https://github.com/home-assistant/addons/tree/master/letsencrypt), this will be at `/ssl/privkey.pem`. +SSL key path: + description: The absolute path to the TLS private key, for example `/ssl/privkey.pem`. required: false - type: string -cors_allowed_origins: - description: "A list of origin domain names to allow [CORS](https://en.wikipedia.org/wiki/Cross-origin_resource_sharing) requests from. Enabling this will set the `Access-Control-Allow-Origin` header to the Origin header if it is found in the list, and the `Access-Control-Allow-Headers` header to `Origin, Accept, X-Requested-With, Content-type, Authorization`. You must provide the exact Origin. That is, `https://www.home-assistant.io` will allow requests from `https://www.home-assistant.io` but __not__ `http://www.home-assistant.io`." +SSL peer certificate path: + description: The absolute path to a client certificate Home Assistant should require for secure connections. required: false - type: [string, list] -use_x_forwarded_for: - description: "Enable parsing of the `X-Forwarded-For` header, passing on the client's correct IP address in proxied setups. You **must** also whitelist trusted proxies using the `trusted_proxies` setting for this to work. Non-whitelisted requests with this header will be considered IP spoofing attacks, and the header will, therefore, be ignored." +SSL profile: + description: The Mozilla SSL profile to use. Use **Intermediate** only if integrations have SSL handshake issues. required: false - type: boolean - default: false -use_x_frame_options: - description: "Controls the `X-Frame-Options` header to help prevent [clickjacking](https://en.wikipedia.org/wiki/Clickjacking)." +Trust X-Forwarded-For: + description: Trust the `X-Forwarded-For` header when Home Assistant is behind a reverse proxy. required: false - type: boolean - default: true -trusted_proxies: - description: "List of trusted proxies, consisting of IP addresses or networks, that are allowed to set the `X-Forwarded-For` header. This is required when using `use_x_forwarded_for` because all requests to Home Assistant, regardless of source, will arrive from the reverse proxy IP address. Therefore in a reverse proxy scenario, this option should be set with extreme care. If the immediate upstream proxy is not in the list, the request will be rejected. If any other intermediate proxy is not in the list, the first untrusted proxy will be considered the client." +Trusted proxies: + description: Reverse proxy IP addresses or CIDR networks that are allowed to set `X-Forwarded-For`. required: false - type: [string, list] -ip_ban_enabled: - description: Flag indicating whether additional IP filtering is enabled. +Enable IP banning: + description: Automatically ban IP addresses after repeated failed logins. required: false - type: boolean - default: true -login_attempts_threshold: - description: "Number of failed login attempts from a single IP after which it will be automatically banned if `ip_ban_enabled` is `true`. When set to -1 no new automatic bans will be added." +Login attempts before ban: + description: Failed login attempts before an IP address is banned. Set this to `-1` to disable automatic bans. + required: true +CORS allowed origins: + description: Origins that may make cross-origin requests. Include the scheme, for example `https://example.com`. required: false - type: integer - default: -1 -ssl_profile: - description: The [Mozilla SSL profile](https://wiki.mozilla.org/Security/Server_Side_TLS) to use. Only lower if you are experiencing integrations causing SSL handshake errors. +Send X-Frame-Options: + description: Send the `X-Frame-Options` header to help prevent clickjacking. required: false - type: string - default: modern -{% endconfiguration %} +{% endoptions_ui %} -The sample below shows a configuration entry in the {% term "`configuration.yaml`" %} file with possible values: - -```yaml -# Example configuration.yaml entry -http: - server_port: 12345 - ssl_certificate: /etc/letsencrypt/live/hass.example.com/fullchain.pem - ssl_key: /etc/letsencrypt/live/hass.example.com/privkey.pem - cors_allowed_origins: - - https://google.com - - https://www.home-assistant.io - use_x_forwarded_for: true - trusted_proxies: - - 10.0.0.200 - - 172.30.33.0/24 - ip_ban_enabled: true - login_attempts_threshold: 5 -``` - -The [Set up encryption using Let's Encrypt](/blog/2015/12/13/setup-encryption-using-lets-encrypt/) blog post gives you details about the encryption of your traffic using free certificates from [Let's Encrypt](https://letsencrypt.org/). +Saving HTTP server settings restarts Home Assistant. After Home Assistant restarts, an administrator is asked to confirm the new settings. If the settings are not confirmed within 5 minutes, Home Assistant automatically returns to the previous settings. ## Reverse proxies -When using a reverse proxy, you will need to enable the `use_x_forwarded_for` and `trusted_proxies` options. Requests from reverse proxies will be blocked if these options are not set. - -```yaml -http: - use_x_forwarded_for: true - trusted_proxies: - - 10.0.0.200 # Add the IP address of the proxy server - - 172.30.33.0/24 # You may also provide the subnet mask -``` + + +When using a reverse proxy, turn on **Trust X-Forwarded-For** and add the proxy to **Trusted proxies**. Requests from reverse proxies are blocked if these options are not set. {% important %} When a network mask is provided, you must use the network address (for example, `192.168.1.0/24`), not a host address (for example, `192.168.1.50/24`). @@ -125,7 +83,7 @@ When a network mask is provided, you must use the network address (for example, {% note %} -The `use_x_forwarded_for` and `trusted_proxies` settings only apply when Home Assistant is behind a traditional reverse proxy, such as NGINX, Caddy, Traefik, or HAProxy. If you use [Home Assistant Cloud](/integrations/cloud/) for remote access, requests arrive through a secure tunnel without `X-Forwarded-*` headers containing the original client IP address. For cloud connections, these settings have no effect, and all requests appear as coming from `127.0.0.1`. +The **Trust X-Forwarded-For** and **Trusted proxies** settings only apply when Home Assistant is behind a traditional reverse proxy, such as NGINX, Caddy, Traefik, or HAProxy. If you use [Home Assistant Cloud](/integrations/cloud/) for remote access, requests arrive through a secure tunnel without `X-Forwarded-*` headers containing the original client IP address. For cloud connections, these settings have no effect, and all requests appear as coming from `127.0.0.1`. {% endnote %} @@ -137,15 +95,15 @@ The `http` platforms are not real platforms within the meaning of the terminolog ## HTTP sensors -To use those kind of [sensors](#sensor) or [binary sensors](#binary-sensor) in your installation no configuration in Home Assistant is needed. All configuration is done on the devices themselves. This means that you must be able to edit the target URL or endpoint and the payload. The entity will be created after the first message has arrived. +To use an HTTP [sensor](#sensor) or [binary sensor](#binary-sensor), you do not need to configure anything in Home Assistant. All configuration is done on the devices themselves. This means that you must be able to edit the target URL or endpoint and the payload. The entity is created after the first message arrives. If you want to use an HTTP sensor, create a [Long-Lived Access Token](https://developers.home-assistant.io/docs/auth_api/#long-lived-access-token) in the Home Assistant UI in the **Security** section of your {% my profile title="**User profile**" %} page. -All [requests](https://developers.home-assistant.io/docs/api/rest#post-apistatesentity_id) need to be sent to the endpoint of the device and must be **POST**. +All [requests](https://developers.home-assistant.io/docs/api/rest#post-apistatesentity_id) need to be sent to the endpoint of the device and use **POST**. ## IP filtering and banning -If you want to apply additional IP filtering, and automatically ban brute force attempts, set `ip_ban_enabled` to `true` and `login_attempts_threshold` to the maximum number of attempts before a ban is activated. After the first ban, an `ip_bans.yaml` file will be created in the root configuration folder. It will have the banned IP address and time in UTC when it was added: +If you want to apply additional IP filtering and automatically ban brute force attempts, turn on **Enable IP banning** and set **Login attempts before ban** to the maximum number of attempts before a ban is activated. After the first ban, an `ip_bans.yaml` file is created in the root configuration folder. It contains the banned IP address and the time in UTC when it was added: {% note %} @@ -158,11 +116,11 @@ If you use [Home Assistant Cloud](/integrations/cloud/) for remote access, all c banned_at: "2016-11-16T19:20:03" ``` -After a ban is added a Persistent Notification will appear in the Home Assistant frontend. +After a ban is added, a persistent notification appears in the Home Assistant frontend. To clear an IP ban, you can either: -- Remove the specific IP entry from `ip_bans.yaml`, or +- Remove the specific IP entry from `ip_bans.yaml`. - Delete the entire `ip_bans.yaml` file. It will be recreated automatically the next time a ban occurs. After making changes, restart Home Assistant to apply them. @@ -280,7 +238,7 @@ http://IP_ADDRESS:8123/api/states/sensor.DEVICE_NAME You should choose a unique device name (DEVICE_NAME) to avoid clashes with other devices. {% endimportant %} - The JSON payload must contain the new state and should include the unit of measurement and a friendly name. The friendly name is used in the frontend to name the sensor. +The JSON payload must contain the new state and should include the unit of measurement and a friendly name. The friendly name is used in the frontend to name the sensor. ```json {"state": "20", "attributes": {"unit_of_measurement": "°C", "friendly_name": "Bathroom Temperature"}} diff --git a/source/_integrations/hypontech.markdown b/source/_integrations/hypontech.markdown index 4cc637b35313..1ee1a0d4fe60 100644 --- a/source/_integrations/hypontech.markdown +++ b/source/_integrations/hypontech.markdown @@ -2,6 +2,7 @@ title: Hypontech Cloud description: Instructions on how to integrate Hypontech Cloud solar inverters within Home Assistant. ha_category: + - Binary sensor - Energy - Sensor ha_release: 2026.3 @@ -11,6 +12,7 @@ ha_codeowners: - '@jcisio' ha_domain: hypontech ha_platforms: + - binary_sensor - sensor ha_integration_type: hub ha_quality_scale: bronze @@ -70,6 +72,12 @@ All sensors are updated every minute. If there is no current clamp and no batter - Total power = PV power + Battery power - Load power = Total power + Grid power +### Binary sensors + +Each Plant device has the following diagnostic binary sensor: + +- **Status**: On when Hypontech Cloud reports the plant as online, and off otherwise. + ## Data updates The integration polls data from the Hypontech Cloud every 60 seconds. diff --git a/source/_integrations/imou.markdown b/source/_integrations/imou.markdown index 6d6fc4c636e7..d558e1ae098d 100644 --- a/source/_integrations/imou.markdown +++ b/source/_integrations/imou.markdown @@ -4,8 +4,10 @@ description: Integrate Imou smart devices into Home Assistant. ha_category: - Button - Camera + - Sensor + - Switch ha_iot_class: Cloud Polling -ha_release: 2026.6 +ha_release: 2026.7 ha_config_flow: true ha_domain: imou ha_codeowners: @@ -13,15 +15,17 @@ ha_codeowners: ha_platforms: - button - camera + - sensor + - switch ha_integration_type: hub ha_quality_scale: bronze --- -The **Imou** {% term integration %} connects to the [Imou Open Platform](https://open.imoulife.com/) using your App ID and App secret. Devices linked to your platform account are discovered automatically. Channel devices expose **Live view SD** and **Live view HD** camera entities, and supported actions are exposed as button entities in Home Assistant. +The **Imou** {% term integration %} connects to the [Imou Open Platform](https://open.imoulife.com) using your App ID and App secret. Devices linked to your platform account are discovered automatically. Channel devices expose **Live view SD** and **Live view HD** camera entities, supported actions are exposed as button entities, supported toggles are exposed as switch entities, and supported measurements are exposed as sensor entities in Home Assistant. ## Supported devices -The integration supports Imou devices that are already added to your Imou Open Platform account and reported by the cloud API. Supported button entities depend on each device type (for example, PTZ controls are only created when the device supports PTZ). +The integration supports Imou devices that are already added to your Imou Open Platform account and reported by the cloud API. Supported button, switch, and sensor entities depend on each device type (for example, PTZ controls are only created when the device supports PTZ, and battery sensors only appear on devices that report battery level). Add or remove devices in the Imou Open Platform or Imou app; new devices are picked up on the next data refresh. @@ -29,7 +33,7 @@ Add or remove devices in the Imou Open Platform or Imou app; new devices are pic Before using the Imou integration, create an Imou Open Platform application: -1. Visit [Imou Open Platform](https://open.imoulife.com/). +1. Visit [Imou Open Platform](https://open.imoulife.com). 2. Register or log in to your Imou account, then open the **Control board**. 3. Go to **App Information** to obtain an **App ID** and **App secret**. 4. Add your Imou devices in the Imou Open Platform or Imou mobile app so they appear on your account. @@ -84,6 +88,35 @@ The integration exposes button entities when the cloud API reports that the acti - **Mute**: Silence alarm audio on supported gateway devices. - **Restart**: Remotely restart the device (shown with the restart device class when supported). +### Switches + +When the cloud API reports that the toggle is supported for a device, the integration exposes the following switch entities: + +- **Abnormal sound alarm**: Toggle abnormal sound detection alarms. +- **Audio recording**: Toggle audio recording on supported cameras. +- **Human detection**: Toggle human detection on supported cameras. +- **Indicator light**: Toggle the device status indicator LED on supported models. +- **Motion detection**: Toggle motion detection on supported cameras. +- **Plug switch**: Control the main power relay on supported IoT socket devices. +- **Privacy mode**: Enable privacy mode that closes or disables the camera lens on supported models. +- **White light**: Manually toggle the camera white LED illuminator on supported models. + +### Sensors + +When the cloud API reports that a measurement is supported for a device, the integration exposes sensor entities. Only supported sensor types are created for each device. + +- **Battery**: Battery level as a percentage on supported battery-powered devices. +- **Temperature**: Current ambient temperature in degrees Celsius on supported models. +- **Humidity**: Current relative humidity as a percentage on supported models. +- **Power**, **Voltage**, **Current**: Real-time electrical measurements on supported IoT socket and power-monitoring devices. +- **Energy consumption**: Total energy used in kilowatt-hours on supported socket devices. +- **Usage duration**: Total operating time in minutes on supported socket devices. +- **Cycles today**: Number of switch cycles for the current day on supported socket devices. +- **Storage used**: Storage usage as a percentage. When the storage medium is unavailable or reports an abnormal condition, the entity state is `unknown`. +- **Status**: Device connectivity state (`online`, `offline`, `sleep`, or `upgrading`). This sensor remains available when the device is offline so you can still see its last reported state. + +Battery, storage used, and status sensors are shown under **Diagnostic** on the device page. Other sensors appear under **Sensors**. + ## Data updates The integration {% term polling polls %} Imou cloud APIs every 2 minutes to refresh the device list and online status. New devices on your account are added automatically; devices removed from your account are removed from Home Assistant. @@ -106,6 +139,16 @@ The integration polls the platform regularly to discover devices and refresh onl Buttons are unavailable when a device is offline or no longer on your account. Ensure the device has power and network connectivity and appears online in the Imou app. +### A switch is unavailable + +Switches are unavailable when a device is offline or no longer on your account. Ensure the device has power and network connectivity and appears online in the Imou app. + +### A sensor is unavailable + +Most sensors are unavailable when a device is offline or no longer on your account. Ensure the device has power and network connectivity and appears online in the Imou app. + +The **Status** sensor is an exception: it stays available when the device is offline and reports `offline` instead of becoming unavailable. + ## Removing the integration This integration follows standard integration removal. diff --git a/source/_integrations/indevolt.markdown b/source/_integrations/indevolt.markdown index f745b8a7f700..9c90555d12d2 100644 --- a/source/_integrations/indevolt.markdown +++ b/source/_integrations/indevolt.markdown @@ -121,6 +121,7 @@ The following button entity allows triggering device actions directly from Home - Grid frequency (Hz) - Equivalent full cycles - Transformer temperature (°C) +- Remaining charging / discharging time (min) - Main battery serial number - Main battery cycle count - Main battery SOC (%) diff --git a/source/_integrations/iotorero.markdown b/source/_integrations/iotorero.markdown index 2372285c7ca7..49d9d94b7564 100644 --- a/source/_integrations/iotorero.markdown +++ b/source/_integrations/iotorero.markdown @@ -1,7 +1,7 @@ --- title: IoTorero description: Connect and control your IoTorero devices using the ESPHome integration -ha_release: 0.85 +ha_release: '2026.7' ha_category: - Alarm - DIY diff --git a/source/_integrations/izone.markdown b/source/_integrations/izone.markdown index 6f6f62520379..4fe7d07fbc8e 100644 --- a/source/_integrations/izone.markdown +++ b/source/_integrations/izone.markdown @@ -18,7 +18,7 @@ related: title: Configuration file --- -The **iZone** {% term integration %} allows access of control of a local [iZone](https://izone.com.au/) ducted reverse-cycle climate control devices. These are largely available in Australia. +The **iZone** {% term integration %} lets you monitor and control local [iZone](https://izone.com.au/) ducted reverse-cycle climate control systems. These systems are largely available in Australia. ## Supported hardware @@ -26,15 +26,22 @@ Any current iZone unit with ducted reverse cycle air-conditioning, and the CB wi {% include integrations/config_flow.md %} -## Manual configuration +## Multiple iZone systems + +If you have more than one iZone system on your local network, the iZone integration discovers all available controllers and shows them during setup. You can then choose the controller you want to configure. + +Any other controllers found during the search will become available as discovered controllers. + +## Legacy YAML configuration + +YAML configuration is now deprecated, it will be removed in a future update. + +For legacy setups, or if you need to exclude specific controllers from Home Assistant, you can configure the iZone integration via the {% term "`configuration.yaml`" %} file with the `exclude` option. -Alternatively, the iZone integration can be configured manually via the -{% term "`configuration.yaml`" %} file if there is more than one iZone system on the local -network and one or more must be excluded use manual configuration. {% include integrations/restart_ha_after_config_inclusion.md %} ```yaml -# Full manual example configuration.yaml entry +# Example configuration.yaml entry with excluded controllers izone: exclude: - "000013170" @@ -42,7 +49,7 @@ izone: {% configuration %} exclude: - description: Exclude particular units from integration with Home Assistant. + description: Exclude specific units from Home Assistant. This option applies only to YAML-based configuration. required: false type: list {% endconfiguration %} diff --git a/source/_integrations/karakeep.markdown b/source/_integrations/karakeep.markdown new file mode 100644 index 000000000000..c8aa550b231f --- /dev/null +++ b/source/_integrations/karakeep.markdown @@ -0,0 +1,102 @@ +--- +title: Karakeep +description: Instructions on how to integrate Karakeep into Home Assistant. +ha_release: 2026.8 +ha_category: + - Sensor +ha_iot_class: Local Polling +ha_config_flow: true +ha_domain: karakeep +ha_codeowners: + - '@sli-cka' +ha_integration_type: service +ha_quality_scale: bronze +related: + - url: https://karakeep.app/ + title: Karakeep + - url: https://docs.karakeep.app/ + title: Karakeep documentation +ha_platforms: + - sensor +--- + +The **Karakeep** {% term integration %} allows you to connect your [Karakeep](https://karakeep.app/) instance to Home Assistant and monitor bookmark statistics. + +Karakeep is a self-hostable bookmarking and read-it-later service for saving, organizing, and tagging links, notes, images, and other content. + +## Prerequisites + +To use this integration, you need: + +- A running Karakeep instance that Home Assistant can reach. +- A Karakeep API key. + +{% details "Create an API key" %} + +1. Log in to your Karakeep instance. +2. Go to **Settings** > **API Keys**. +3. Create a new API key. +4. If your Karakeep instance is version `0.32.0` or later and uses granular scopes, grant the API key the **User account** > **read** scope. +5. Copy the API key and use it during setup in Home Assistant. + +{% enddetails %} + +{% include integrations/config_flow.md %} + +{% configuration_basic %} +URL: + description: "The URL of your Karakeep instance, for example `https://karakeep.example.com`." +API key: + description: "The Karakeep API key used to connect to your instance." +Verify SSL certificate: + description: "Whether to verify the SSL certificate of your Karakeep instance. Disable this if your instance uses a self-signed certificate." +{% endconfiguration_basic %} + +## Supported functionality + +The Karakeep integration provides sensors for account statistics. The Karakeep server version is shown on the integration's device page when your instance is running version `0.29.0` or later. + +### Sensors + +For each config entry, the integration creates the following {% term sensors %}: + +- **Bookmarks**: Number of bookmarks in Karakeep. +- **Favorites**: Number of favorite bookmarks. +- **Archived**: Number of archived items. +- **Highlights**: Number of highlights. +- **Lists**: Number of lists. +- **Tags**: Number of tags. + +## Data updates + +The Karakeep integration {% term polling polls %} the statistics from your Karakeep instance every 5 minutes. + +## Troubleshooting + +### Cannot connect to Karakeep + +#### Symptom: "Failed to connect" + +During setup, Home Assistant cannot reach the Karakeep instance. + +#### Resolution + +1. Make sure the URL includes `http://` or `https://`. +2. Make sure Home Assistant can reach the Karakeep instance over the network. +3. Check whether a reverse proxy, firewall, or TLS certificate issue is blocking access from Home Assistant. + +### Authentication fails during setup + +#### Symptom: "Invalid authentication" + +During setup, Home Assistant reports that the provided API key is not valid. + +#### Resolution + +Verify that the API key is copied correctly and is still valid in Karakeep. + +## Removing the integration + +{% include integrations/remove_device_service.md %} + +If you no longer use the API key, you can remove it from your Karakeep instance. diff --git a/source/_integrations/kiosker.markdown b/source/_integrations/kiosker.markdown index 1cd18443a6be..51a8a1d0791c 100644 --- a/source/_integrations/kiosker.markdown +++ b/source/_integrations/kiosker.markdown @@ -176,6 +176,10 @@ This means that Home Assistant can't connect to the Kiosker App. 6. If you have enabled TLS, make sure that you have installed a valid certificate in the Kiosker App, typically a self-signed certificate. 7. If you have enabled `Verify certificate`, make sure that the certificate is valid and that the root certificate is marked as trusted on the host. +### Home Assistant asks you to reauthenticate + +If the API token in the Kiosker App is regenerated or changed, Home Assistant detects the failed authentication and starts a reauthentication flow. Select **Reconfigure** on the integration's notification and enter the new token. The integration reconnects without losing your existing entities or automations. + ## Removing the integration This integration follows standard integration removal. No extra steps are required. diff --git a/source/_integrations/knx.markdown b/source/_integrations/knx.markdown index da89fc57378c..2d8530274c06 100644 --- a/source/_integrations/knx.markdown +++ b/source/_integrations/knx.markdown @@ -1150,11 +1150,7 @@ device_class: The KNX date platform allows you to send date values to the KNX bus and update its state from received telegrams. It can optionally respond to read requests from the KNX bus. -{% note %} -Date entities without a `state_address` will restore their last known state after Home Assistant was restarted. - -Dates that have a `state_address` configured request their current state from the KNX bus. -{% endnote %} +Date entities restore their last known state after Home Assistant is restarted. Dates that have a `state_address` configured request their current state from the KNX bus according to their state updater configuration. {% note %} DPT 11.001 covers the range 1990 to 2089. Year values outside of this range are not allowed. @@ -1215,11 +1211,7 @@ sync_state: The KNX datetime platform allows you to send datetime values to the KNX bus and update its state from received telegrams. It can optionally respond to read requests from the KNX bus. -{% note %} -Date entities without a `state_address` will restore their last known state after Home Assistant was restarted. - -DateTimes that have a `state_address` configured request their current state from the KNX bus. -{% endnote %} +DateTime entities restore their last known state after Home Assistant is restarted. DateTimes that have a `state_address` configured request their current state from the KNX bus according to their state updater configuration. {% note %} System timezone is used as DPT 19.001 doesn't provide timezone information. @@ -1608,11 +1600,7 @@ data: The KNX number platform allows you to send generic numeric values to the KNX bus and update its state from received telegrams. It can optionally respond to read requests from the KNX bus. -{% note %} -Number entities without a `state_address` will restore their last known state after Home Assistant was restarted. - -Numbers that have a `state_address` configured request their current state from the KNX bus. -{% endnote %} +Number entities restore their last known state after Home Assistant is restarted. Numbers that have a `state_address` configured request their current state from the KNX bus. Number entities can be created from the frontend in the KNX panel or via YAML. @@ -1724,11 +1712,7 @@ scene_number: The KNX select platform allows the user to define a list of values that can be selected via the frontend and can be used within conditions of automation. When a user selects a new item, the assigned generic raw payload is sent to the KNX bus. A received telegram updates the state of the select entity. It can optionally respond to read requests from the KNX bus. -{% note %} -Select entities without a `state_address` will restore their last known state after Home Assistant was restarted. - -Selects that have a `state_address` configured request their current state from the KNX bus. -{% endnote %} +Select entities restore their last known state after Home Assistant is restarted. Selects that have a `state_address` configured request their current state from the KNX bus according to their state updater configuration. ```yaml # Example configuration.yaml entry @@ -1922,8 +1906,7 @@ The KNX switch platform is used as an interface to switching actuators. Switch entities can be created from the frontend in the KNX panel or via YAML. -Switch entities without a `state_address` will restore their last known state after Home Assistant was restarted. -Switches that have a `state_address` configured request their current state from the KNX bus. +Switches restore their last known state after Home Assistant is restarted. Switches that have a `state_address` configured request their current state from the KNX bus according to their state updater configuration. Until the bus responds or the state is restored, the state is unknown if no previous state exists. {% details "Configuration of KNX switch entities via YAML" %} @@ -1969,11 +1952,7 @@ The optional `state_address` can be used to inform Home Assistant about state ch The KNX text platform allows you to send text values to the KNX bus and update its state from received telegrams. It can optionally respond to read requests from the KNX bus. -{% note %} -Text entities without a `state_address` will restore their last known state after Home Assistant was restarted. - -Texts that have a `state_address` configured request their current state from the KNX bus. -{% endnote %} +Text entities restore their last known state after Home Assistant is restarted. Texts that have a `state_address` configured request their current state from the KNX bus. Text entities can be created from the frontend in the KNX panel or via YAML. @@ -2028,11 +2007,7 @@ mode: The KNX time platform allows you to send time values to the KNX bus and update its state from received telegrams. It can optionally respond to read requests from the KNX bus. -{% note %} -Time entities without a `state_address` will restore their last known state after Home Assistant was restarted. - -Times that have a `state_address` configured request their current state from the KNX bus. -{% endnote %} +Time entities restore their last known state after Home Assistant is restarted. Times that have a `state_address` configured request their current state from the KNX bus according to their state updater configuration. {% note %} The `day` field of the time telegram will always be set to 0 (`no day`). diff --git a/source/_integrations/led_infrared.markdown b/source/_integrations/led_infrared.markdown new file mode 100644 index 000000000000..ab72f2c4fbc4 --- /dev/null +++ b/source/_integrations/led_infrared.markdown @@ -0,0 +1,102 @@ +--- +title: LED Infrared +description: Integration to control LED infrared lights with Home Assistant. +ha_category: + - Light +ha_release: 2026.8 +ha_iot_class: Assumed State +ha_codeowners: + - '@tr4nt0r' +ha_domain: led_infrared +ha_config_flow: true +ha_platforms: + - light +ha_integration_type: device +--- + +The **LED Infrared** {% term integration %} lets you control lights with any infrared emitter that has been previously configured in Home Assistant. + +Because the integration communicates over infrared, it operates in a one-way, fire-and-forget fashion: commands are sent to the light, but there is no feedback channel to confirm the current state of the light. The integration therefore uses assumed states. + +## Supported devices + +This integration supports many branded and unbranded LED bulbs, lamps, and LED strip controllers that use generic infrared remotes. If your device uses one of the remote controls listed below, it may be compatible with this integration. + +{% details "24-key remote" %} + +![24-key remote](/images/integrations/led_infrared/24-key.png) + +{% enddetails %} + +{% details "13-key remote" %} + +![13-key remote](/images/integrations/led_infrared/13-key.png) + +{% enddetails %} + +## Prerequisites + +Before setting up the LED Infrared integration, you need a working infrared transmitter set up in Home Assistant that exposes an [Infrared](/integrations/infrared/) entity. For example, you can use an ESPHome device with an IR LED pointed at your lights. + +{% include integrations/config_flow.md %} + +Select the device type that matches your remote control, then select an infrared emitter. + +{% configuration_basic %} +Device type: + description: The type of remote control used for the LED light bulb, lamp, or controller. +Infrared emitter: + description: The infrared emitter entity to use for sending commands to your device. This must be an entity provided by a hardware integration (such as ESPHome) that has already been set up with an IR emitter. +{% endconfiguration_basic %} + +## Supported functionality + +The **LED Infrared** integration provides the following entities. + +### Lights + +A light entity is created when an infrared emitter is configured. + +- **Light** + - **Description**: Represents the LED device and allows it to be controlled using infrared (IR) commands. + - **Supported features**: Turn on, turn off, and select effects. + - **Available effects**: Depend on the capabilities of the configured IR remote. + +## LED Infrared automation examples + +The following example demonstrates how to automate an LED Infrared device. For additional automation examples, refer to the light platform [actions reference](/integrations/light/#list-of-actions). + +{% include docs/paste_yaml_tip.md %} + +### Automation: Turning on the LED strip at night + +- **Trigger**: Sun: after sunset + - **Target**: Optional trigger target if needed +- **Condition**: Optional condition if needed +- **Action**: Turn on light + +{% details "YAML example for turning on LED strip at night" %} + +{% example %} +automation: | + alias: "Turn on the LEDs during the night" + triggers: + - trigger: sun + event: sunset + actions: + - action: light.turn_on + target: + entity_id: light.led_strip +{% endexample %} + +{% enddetails %} + +## Known limitations + +The integration uses assumed state, meaning Home Assistant cannot read the actual state of the light (for example, whether it is on or off, or what the current brightness is). + +## Removing the integration + +This integration follows standard integration removal. + +{% include integrations/remove_device_service.md %} diff --git a/source/_integrations/liebherr.markdown b/source/_integrations/liebherr.markdown index f39217b5e199..37e4fa61f085 100644 --- a/source/_integrations/liebherr.markdown +++ b/source/_integrations/liebherr.markdown @@ -20,12 +20,14 @@ related: - docs: /common-tasks/general/#defining-a-custom-polling-interval title: Defining a custom polling interval ha_category: + - Cover - Light - Number - Select - Sensor - Switch ha_platforms: + - cover - diagnostics - light - number @@ -87,7 +89,19 @@ The Liebherr appliances operate based on the temperature unit selected on the de ## Supported functionality -The **Liebherr** integration provides temperature monitoring, climate control, presentation lighting, and special feature management for refrigerator and freezer zones in your SmartDevice appliances. +The **Liebherr** integration provides temperature monitoring, setpoint control, door control (AutoDoor), presentation lighting, and special feature management for refrigerator and freezer zones in your SmartDevice appliances. + +### Covers + +The integration creates cover entities for appliances equipped with an AutoDoor feature. The AutoDoor allows you to open and close the appliance door remotely. + +- **AutoDoor**: Controls the automatic door. Supports opening and closing the door. + +For appliances with multiple cooling zones, a separate cover entity is created for each zone that has an AutoDoor: + +- **Top zone AutoDoor**: Controls the automatic door for the uppermost compartment. +- **Middle zone AutoDoor**: Controls the automatic door for the middle compartment (if present). +- **Bottom zone AutoDoor**: Controls the automatic door for the lowermost compartment (if present). ### Lights diff --git a/source/_integrations/litellm.markdown b/source/_integrations/litellm.markdown new file mode 100644 index 000000000000..fb2ae3ed393f --- /dev/null +++ b/source/_integrations/litellm.markdown @@ -0,0 +1,68 @@ +--- +title: LiteLLM +description: Instructions on how to integrate a LiteLLM proxy as a conversation agent in Home Assistant +ha_category: + - AI +ha_release: 2026.8 +ha_iot_class: Cloud Polling +ha_config_flow: true +ha_codeowners: + - '@luismalves' +ha_domain: litellm +ha_integration_type: service +ha_platforms: + - conversation +ha_quality_scale: bronze +--- + +The [LiteLLM](https://www.litellm.ai/) {% term integration %} allows you to use a LiteLLM proxy as a conversation agent in Home Assistant. + +LiteLLM exposes a single OpenAI-compatible API in front of a wide range of model providers, so you can use almost any model through one endpoint. This is similar to a service like OpenRouter, with the added benefit that you can run LiteLLM yourself if you prefer to keep everything under your own control. This integration lets you point Home Assistant at any LiteLLM proxy, whether it is a hosted instance or one you self-host. + +## Prerequisites + +Before you add this integration, you need the following: + +- **A LiteLLM proxy that Home Assistant can reach.** This is the endpoint the integration connects to. You can use a hosted LiteLLM proxy or [run one yourself](https://docs.litellm.ai/docs/simple_proxy). +- **At least one model configured on the proxy.** The integration discovers the available models from the proxy during setup and creates a conversation agent for each one. +- **An API key, if your proxy requires authentication.** This is used to authorize Home Assistant's requests to the proxy. You can leave it empty if your proxy does not require one. + +{% include integrations/config_flow.md %} + +{% configuration_basic %} +URL: + description: The base URL of your LiteLLM proxy, including the host and port. The integration automatically appends the OpenAI `/v1` path if it is missing. +API key: + description: An optional LiteLLM API key or virtual key. Leave it empty if your proxy does not require authentication. +{% endconfiguration_basic %} + +### Adding a conversation agent + +After the integration is set up, add a conversation agent for the model you want to use: + +1. Go to {% my integrations title="**Settings** > **Devices & services**" %} and select your LiteLLM entry. +2. Select **Add conversation agent**. +3. Fill in the fields: + +{% configuration_basic %} +Model: + description: "The model to use for the conversation agent. The list is discovered from your LiteLLM proxy." +Instructions: + description: "Instruct how the LLM should respond. This field supports [templates](/docs/configuration/templating/)." +Control Home Assistant: + description: "Select which tools the agent can use to interact with your devices and entities. Leave empty if you do not want the agent to control Home Assistant." +{% endconfiguration_basic %} + +To change the model, instructions, or tools later, select the conversation agent and choose **Reconfigure conversation agent**. + +## Supported functionality + +This integration provides a conversation agent for each model you add. You can use it in [Assist](/voice_control/) like any other conversation agent. + +When you grant the agent control of Home Assistant, it can call the configured tools to interact with your devices and entities. To choose which devices and entities the agent can access, see [exposing entities to Assist](/voice_control/voice_remote_expose_devices/). + +## Removing the integration + +This integration follows standard integration removal, no extra steps are required. + +{% include integrations/remove_device_service.md %} diff --git a/source/_integrations/llama_cpp.markdown b/source/_integrations/llama_cpp.markdown new file mode 100644 index 000000000000..98b6cca5662b --- /dev/null +++ b/source/_integrations/llama_cpp.markdown @@ -0,0 +1,117 @@ +--- +title: llama.cpp +description: Instructions on how to integrate llama.cpp (and other OpenAI-compatible servers) as a conversation agent. +ha_category: + - AI + - Voice +ha_release: 2026.7 +ha_iot_class: Local Polling +ha_config_flow: true +ha_domain: llama_cpp +ha_integration_type: service +ha_platforms: + - conversation +related: + - docs: /voice_control/voice_remote_expose_devices/ + title: Exposing entities to Assist + - docs: /voice_control/assist_create_open_ai_personality/ + title: Create an AI personality +ha_quality_scale: bronze +ha_codeowners: + - '@allenporter' +--- + +The **llama.cpp** {% term integration %} allows you to use a local or remote server that implements the OpenAI-compatible chat completions API as a conversation agent in Home Assistant. + +This integration lets you connect with self-hosted models running on servers such as llama.cpp, llama-cpp-python, vLLM, DeepSeek, or other compatible API backends. + +{% note %} +If you are using Ollama, you should prefer the official [Ollama](/integrations/ollama/) integration. +{% endnote %} + +{% note %} +If you are using OpenRouter, you should prefer the official [OpenRouter](/integrations/open_router/) integration. +{% endnote %} + +Controlling Home Assistant is done by providing the AI access to the Assist API of Home Assistant. You can control what devices and entities it can access from the {% my voice_assistants title="exposed entities page" %}. The AI can provide you information about your devices and control them. + +This integration does not integrate with [sentence triggers](/docs/automation/trigger/#sentence-trigger). + +## Prerequisites + +This integration requires an external server running an OpenAI-compatible API. Standard examples of compatible servers and their typical URLs include: + +- **llama.cpp**: Running on `http://localhost:8080/v1` or another port of your choosing. See the [llama.cpp quick start guide](https://github.com/ggml-org/llama.cpp/tree/master#quick-start) for more details. +- **llama-cpp-python**: Running on `http://localhost:8000/v1` or another port of your choosing. See the [llama-cpp-python installation guide](https://llama-cpp-python.readthedocs.io/en/latest/#installation) for more details. +- **vLLM**: Running on `http://localhost:8000/v1` or another port of your choosing. See the [vLLM installation guide](https://docs.vllm.ai/en/latest/getting_started/installation/) for more details. +- **DeepSeek**: Using the cloud API URL `https://api.deepseek.com`. + +{% include integrations/config_flow.md %} + +{% configuration_basic %} +URL: + description: "The base URL of your running OpenAI-compatible server. For example, `http://localhost:8080/v1`." +API key: + description: "The API key to use when connecting to the server. This is optional if your server does not require authentication." +{% endconfiguration_basic %} + +Once the connection is established, you will be prompted to select the chat model to use. + +{% include integrations/option_flow.md %} + +The conversation agent has the following configuration options: + +{% configuration_basic %} +Instructions: + description: "Instructions for the AI on how it should respond to your requests. It is written using [Home Assistant Templating](/docs/templating/)." +Control Home Assistant: + description: "Select the level of control over Home Assistant. The model can only control or provide information about entities that are [exposed](/voice_control/voice_remote_expose_devices/) to it." +Recommended model settings: + description: "Select whether to use recommended model settings. If enabled, default values are used for max tokens, temperature, and top P." +{% endconfiguration_basic %} + +If you choose not to use the recommended settings, you can configure the following options: + +{% configuration_basic %} +Model: + description: "The language model used for text generation." +Maximum tokens to return in response: + description: "The maximum number of tokens that the AI model should generate in its completion of the prompt." +Temperature: + description: "A value that determines the level of creativity and risk-taking the model should use when generating text. A higher temperature means the model is more likely to generate unexpected results, while a lower temperature results in more deterministic results." +Top P: + description: "An alternative to temperature, top P determines the proportion of the most likely word choices the model should consider when generating text." +{% endconfiguration_basic %} + +## Supported functionality + +The **llama.cpp** integration provides the following entities: + +- **Conversation agent**: A conversation agent that can handle text-based queries, respond to requests, and control Home Assistant devices when configured to do so + +## Known limitations + +This integration requires an external server that implements the OpenAI-compatible chat completions API. Features that depend on specific proprietary API properties (such as billing or usage tracking) are not supported. + +## Troubleshooting + +### Cannot connect to the server + +#### Symptom: Connection failed or timed out during setup + +When configuring the integration, you receive a connection error. + +#### Resolution + +To resolve this issue, try the following steps: + +1. Confirm the server is running and reachable from the Home Assistant host. +2. Verify that the URL contains the correct protocol (HTTP or HTTPS), hostname, port, and path (such as `/v1`). +3. Ensure any firewall or network settings do not block connections between Home Assistant and the server. +4. If authentication is required, verify that the API key is correct. + +## Removing the integration + +This integration follows standard integration removal. No extra steps are required. + +{% include integrations/remove_device_service.md %} diff --git a/source/_integrations/llm.markdown b/source/_integrations/llm.markdown new file mode 100644 index 000000000000..42db4926c4cf --- /dev/null +++ b/source/_integrations/llm.markdown @@ -0,0 +1,19 @@ +--- +title: LLM +description: Organizes the LLM APIs that large language models can use in Home Assistant. +ha_category: + - Voice +ha_release: 2026.7 +ha_iot_class: Calculated +ha_quality_scale: internal +ha_codeowners: + - '@home-assistant/core' +ha_domain: llm +ha_integration_type: system +--- + +The **LLM** {% term integration %} organizes the [LLM APIs](https://developers.home-assistant.io/docs/core/llm/) that large language models can use to interact with Home Assistant. An LLM API is a set of tools that a model can call. For example, to control your devices or answer questions about your home. + +This integration provides the framework that lets other integrations contribute tools to an LLM API. It is set up automatically when needed and has no configuration options. + +To let a conversation agent use an LLM API, configure it on the conversation agent integration, such as [Ollama](/integrations/ollama/), [Google Generative AI](/integrations/google_generative_ai_conversation/), or [OpenAI](/integrations/openai_conversation/). diff --git a/source/_integrations/logger.markdown b/source/_integrations/logger.markdown index afe63424a174..f6d88193fc8e 100644 --- a/source/_integrations/logger.markdown +++ b/source/_integrations/logger.markdown @@ -166,3 +166,5 @@ Or read the file directly: ```bash tail -f /config/home-assistant.log ``` + +To rely only on the container runtime logs and prevent Home Assistant from writing `home-assistant.log`, set the `HA_DISABLE_LOG_FILE` environment variable to `1` (or `true`). When the log file is disabled, `/config/home-assistant.log` is not available, and you cannot enable **Show raw logs** or download the log file in the Home Assistant UI. diff --git a/source/_integrations/luci.markdown b/source/_integrations/luci.markdown index 3872d34622a2..082442a779ac 100644 --- a/source/_integrations/luci.markdown +++ b/source/_integrations/luci.markdown @@ -5,66 +5,66 @@ ha_category: - Presence detection ha_iot_class: Local Polling ha_release: pre 0.7 +ha_config_flow: true ha_codeowners: - '@mzdrale' ha_domain: luci ha_platforms: - device_tracker -ha_integration_type: integration +ha_integration_type: hub ha_quality_scale: legacy --- -This is a presence detection scanner for OpenWrt using [luci](https://openwrt.org/docs/techref/luci). - -Before this scanner can be used you have to install the luci RPC package on OpenWrt: - -```bash -apk update -apk add luci-mod-rpc -``` - -To use this device tracker in your installation, add the following to your {% term "`configuration.yaml`" %} file. -{% include integrations/restart_ha_after_config_inclusion.md %} - -```yaml -# Example configuration.yaml entry -device_tracker: - - platform: luci - host: ROUTER_IP_ADDRESS - username: YOUR_ADMIN_USERNAME - password: YOUR_ADMIN_PASSWORD -``` - -{% configuration %} -host: - description: The hostname or IP address of your router, e.g., `192.168.1.1`. - required: true - type: string -username: - description: The username of a user with administrative privileges, usually `admin`. - required: true - type: string -password: - description: The password for your given admin account. - required: true - type: string -ssl: - description: If your router enforces SSL connections, set to `true`. - required: false - default: false - type: boolean -verify_ssl: - description: If SSL/TLS verification for HTTPS resources needs to be turned off (for self-signed certs) - required: false - type: boolean - default: true -{% endconfiguration %} - -See the [device tracker integration page](/integrations/device_tracker/) for instructions how to configure the people to be tracked. - -This device tracker provides several additional attributes for each tracked device (if it is at home): `flags`, `ip`, `device`, and `host`. The first three attributes are taken from the ARP table returned by the luci RPC. The `host` attribute is taken from the platform configuration and can be used to distinguish in which router a device is logged in, if you are using multiple OpenWrt routers. - -{% note %} -Some installations have [a small bug](https://github.com/openwrt/luci/issues/576). The timeout for luci RPC calls is not set and this makes the call fail. -If you want to locally fix your OpenWrt installation, you can apply the change manually to `/usr/lib/lua/luci/controller/rpc.lua`, or simply set a fixed timeout. The default is 3600. -{% endnote %} +The **OpenWrt (luci)** {% term integration %} tracks the devices connected to a router that runs [OpenWrt](https://openwrt.org/) with the [LuCI](https://openwrt.org/docs/techref/luci) web interface. Home Assistant polls the router locally, so you can use the presence of a phone or another device to tell who is home and trigger automations based on that. + +## Supported devices + +This integration works with routers running OpenWrt that have the LuCI web interface and its RPC package installed. It has been used with a wide range of OpenWrt-supported hardware. + +## Prerequisites + +Before you add the integration, prepare your router: + +- Install the LuCI RPC package on your OpenWrt router. Connect to the router over SSH and run: + + ```bash + apk update + apk add luci-mod-rpc + ``` + + On OpenWrt versions that use the older package manager, use `opkg update` and `opkg install luci-mod-rpc` instead. + +- Have the credentials of a user with administrative privileges ready. This is usually the `admin` account. + +{% include integrations/config_flow.md %} + +{% configuration_basic %} +Host: + description: "The hostname or IP address of your router, for example `192.168.1.1`." +Username: + description: "The username of a user with administrative privileges on the router, usually `admin`." +Password: + description: "The password for that account." +SSL: + description: "Connect to the router over HTTPS. Enabled by default. Turn this off if your router only serves the LuCI interface over HTTP." +Verify SSL certificate: + description: "Verify the router's SSL certificate. Disabled by default, because most routers use a self-signed certificate. Only enable this if your router presents a certificate that Home Assistant can validate." +{% endconfiguration_basic %} + +If the credentials for your router change later, Home Assistant asks you to enter the new username and password so it can reconnect. You don't need to remove and add the integration again. + +## Supported functionality + +For each device it finds on the router, the integration creates a {% term "device tracker" %} entity that shows whether the device is home or away. Each entity also exposes the device's IP address, hostname, and MAC address. + +To choose which devices to track and how they are shown, see the [device tracker integration page](/integrations/device_tracker/). + +## Known limitations + +Some OpenWrt installations are affected by [a small bug](https://github.com/openwrt/luci/issues/576) where the timeout for LuCI RPC calls is not set, which makes the calls fail. To fix this on your router, you can apply the change manually to the `/usr/lib/lua/luci/controller/rpc.lua` file, or set a fixed timeout. The default is 3600. + +## Removing the integration + +This integration follows standard integration removal. No extra steps are required. + +{% include integrations/remove_device_service.md %} diff --git a/source/_integrations/lyngdorf.markdown b/source/_integrations/lyngdorf.markdown new file mode 100644 index 000000000000..57eac9bb03ae --- /dev/null +++ b/source/_integrations/lyngdorf.markdown @@ -0,0 +1,99 @@ +--- +title: Lyngdorf +description: Instructions on how to integrate Lyngdorf audio processors into Home Assistant. +ha_category: + - Media player +ha_release: 2026.8 +ha_iot_class: Local Push +ha_config_flow: true +ha_codeowners: + - '@fishloa' +ha_domain: lyngdorf +ha_ssdp: true +ha_platforms: + - media_player +ha_integration_type: device +ha_quality_scale: silver +--- + +The **Lyngdorf** {% term integration %} allows you to control [Lyngdorf] audio processors and amplifiers from Home Assistant. Lyngdorf Audio is known for their RoomPerfect room correction technology. This integration lets you control power, volume, source selection, sound modes, and audio processing parameters. + +[Lyngdorf]: https://lyngdorf.steinwaylyngdorf.com/electronics/ + +## Supported devices + +- [MP-40](https://lyngdorf.steinwaylyngdorf.com/lyngdorf-mp-40/) +- MP-50 +- [MP-60](https://lyngdorf.steinwaylyngdorf.com/lyngdorf-mp-60/) +- [TDAI-1120](https://lyngdorf.steinwaylyngdorf.com/lyngdorf-tdai-1120/) +- TDAI-2170 +- [TDAI-3400](https://lyngdorf.steinwaylyngdorf.com/lyngdorf-tdai-3400/) + +{% note %} +The MP-60 is the only model that has been tested in the wild so far. Other models should work but may not support all features. If you have a different model, please report any issues on [GitHub](https://github.com/home-assistant/core/issues). +{% endnote %} + +## Prerequisites + +- Your Lyngdorf device must be connected to the same network as Home Assistant. + +{% include integrations/config_flow.md %} + +{% configuration_basic %} +Host: + description: "The hostname or IP address of your Lyngdorf device." +{% endconfiguration_basic %} + +## Supported functionality + +### Media players + +The integration creates two media player {% term entities %}: + +- **Main zone**: Controls your Lyngdorf device, including power, volume, mute, source selection, and sound mode. +- **Zone B**: Controls the Zone B output, including power, volume, mute, and source selection. + +## Data updates + +The **Lyngdorf** integration uses local push to receive real-time updates from the device over a TCP connection. State changes on the device are pushed to Home Assistant immediately. + +## Known limitations + +- Only the MP-60 has been tested. Other models may not support all features. +- Only local network control is supported. + +## Troubleshooting + +### Device not discovered + +#### Symptom: Device is not automatically discovered + +The Lyngdorf device does not show up as a discovered device in Home Assistant. + +#### Resolution + +To resolve this issue, try the following steps: + +1. Make sure your Lyngdorf device is powered on and connected to the same network as Home Assistant. +2. Check that UPnP/SSDP is not blocked on your network. +3. Add the device manually using its IP address. + +### Connection issues + +#### Symptom: Device shows as unavailable + +The integration shows as unavailable or disconnects frequently. + +#### Resolution + +To resolve this issue, try the following steps: + +1. Ensure your Lyngdorf device has a static IP address or DHCP reservation. +2. Check your network for stability issues. +3. Verify that no firewall rules are blocking TCP communication between Home Assistant and your device. + +## Removing the integration + +This integration follows standard integration removal. + +{% include integrations/remove_device_service.md %} diff --git a/source/_integrations/lyric.markdown b/source/_integrations/lyric.markdown index 8a516386518d..61eab07e1163 100644 --- a/source/_integrations/lyric.markdown +++ b/source/_integrations/lyric.markdown @@ -2,6 +2,7 @@ title: Honeywell Lyric description: How to integrate the Honeywell Lyric integration into Home Assistant. ha_category: + - Binary sensor - Climate - Select - Sensor @@ -12,6 +13,7 @@ ha_codeowners: - '@timmo001' ha_domain: lyric ha_platforms: + - binary_sensor - climate - select - sensor @@ -54,6 +56,21 @@ The integration setup will ask for the **Client ID** and **Client Secret**. Thes During setup, you will be redirected to Honeywell to sign in. Use your regular Resideo/Honeywell Home account here, not the developer account you created on the developer site. These are two separate accounts, even if they share the same email address. {% endimportant %} +## Binary sensors + +This integration provides the following binary sensors: + +| Name | Description | +| ------------------------ | ----------------------------------------------------------- | +| Vacation Hold | Indicates whether the thermostat is currently in vacation hold. | +| Device Pairing Enabled | Indicates whether pairing mode is enabled on the thermostat. | + +Additional binary sensors will be created for each room sensor accessory assigned to a thermostat device, if applicable: + +| Name | Description | +| ----------- | --------------------------------------------------------------------- | +| Room Motion | Indicates whether motion has been detected by a room sensor accessory. | + ## Selects - **Room priority** @@ -65,18 +82,22 @@ During setup, you will be redirected to Honeywell to sign in. Use your regular R This integration provides the following sensors: -| Name | Description | -| ------------------- | ------------------------------------------- | -| Indoor Temperature | The reported temperature from the device | -| Indoor Humidity | The reported humidity from the device | -| Outdoor Temperature | Lyric's outdoor temperature report | -| Outdoor Humidity | Lyric's outdoor humidity | -| Next Period Time | The next time the thermostat will change | -| Setpoint Status | A description of the setpoint of the device | +| Name | Description | +| ------------------- | ------------------------------------------------------------------------------------------------------------------- | +| Indoor Temperature | The reported temperature from the device | +| Indoor Humidity | The reported humidity from the device | +| Outdoor Temperature | Lyric's outdoor temperature report | +| Outdoor Humidity | Lyric's outdoor humidity | +| Next Period Time | The next time the thermostat will change | +| Setpoint Status | A description of the setpoint of the device | +| Schedule Status | The thermostat's current schedule status (for example, "Resume") | +| Priority Status | The current room priority hold status (for example, "No Hold"). Available for T9 and T10 thermostats with at least one paired room sensor. | Additional sensors will be created for each room sensor accessory assigned to a thermostat device, if applicable: -| Name | Description | -| -------------------- | ----------------------------------------------------------------- | -| Room Temperature | The temperature reported from a room sensor accessory | -| Room Humidity | The humidity reported from a room accessory | +| Name | Description | +| ------------------------- | ------------------------------------------------------------------ | +| Room Temperature | The temperature reported from a room sensor accessory | +| Room Humidity | The humidity reported from a room accessory | +| Room Average Temperature | The average temperature reported for the room | +| Accessory Status | The reported status of the room sensor accessory (for example, "Ok") | diff --git a/source/_integrations/mcp_server.markdown b/source/_integrations/mcp_server.markdown index a958b9a2494c..6a4aae84a7aa 100644 --- a/source/_integrations/mcp_server.markdown +++ b/source/_integrations/mcp_server.markdown @@ -67,6 +67,23 @@ will likely continue to evolve. The Home Assistant MCP server is exposed as `/api/mcp` and requires the client to provide an authentication token. +### Exposing a specific LLM API + +The `/api/mcp` endpoint serves the LLM API you select when you set up the +integration. If you have more than one LLM API available, you can also connect a +client to a specific one by adding its ID to the URL: + +`/api/mcp/` + +For example, the built-in Assist API is always available at `/api/mcp/assist`. +Point your MCP client at this URL in the same way you would use the base +`/api/mcp` endpoint. If you request an API ID that does not exist, Home Assistant +responds with a 404 Not Found error. + +Connecting to any API other than Assist requires the authenticated user to be an +administrator. The Assist API stays available to non-administrator users, just +like the base `/api/mcp` endpoint. + ### Access control #### OAuth diff --git a/source/_integrations/melcloud_home.markdown b/source/_integrations/melcloud_home.markdown index 75f06c024280..76846d19bbaf 100644 --- a/source/_integrations/melcloud_home.markdown +++ b/source/_integrations/melcloud_home.markdown @@ -3,6 +3,7 @@ title: MELCloud Home description: Instructions on how to integrate MELCloud Home with Home Assistant. ha_category: - Climate + - Number - Sensor ha_release: 2026.7 ha_iot_class: Cloud Polling @@ -14,6 +15,7 @@ ha_platforms: - binary_sensor - climate - diagnostics + - number - sensor - switch ha_integration_type: hub @@ -85,6 +87,13 @@ The following extra sensors are only applicable for the Air-to-Water units: - **Room zone temperature 1 & 2**: Either one or the two room temperatures are returned, if applicable for the setup. - **Tank water temperature**: The current measured tank water temperature. +### Number + +Thw following controls are available: + +- **Frost protection**: minimum and maximum temperatures for the frost protection, if the enabled. +- **Overheat protection**: minimum and maximum temperatures for the overheaet protection, if the enabled. + ## Data updates The integration {% term polling polls %} the MELCloud Home API every 60 seconds. diff --git a/source/_integrations/midea_lan.markdown b/source/_integrations/midea_lan.markdown new file mode 100644 index 000000000000..e59fe396b4c5 --- /dev/null +++ b/source/_integrations/midea_lan.markdown @@ -0,0 +1,117 @@ +--- +title: Midea LAN +description: Instructions on how to integrate devices with Midea protocol into Home Assistant. +ha_category: + - Climate +ha_release: 2026.8 +ha_domain: midea_lan +ha_config_flow: true +ha_codeowners: + - '@chemelli74' + - '@rokam' + - '@wuwentao' +ha_iot_class: Local Push +ha_platforms: + - climate +ha_integration_type: device +ha_quality_scale: bronze +--- + +The **Midea LAN** {% term integration %} lets you control devices with Midea protocol connected to various clouds. + +The integration provides information on connected devices and enables control of the main features. + +## Supported devices + +There is support for the following device types within Home Assistant: + +- **Air Box** +- **Air Conditioner** +- **Air Purifier** +- **Bathroom Master** +- **Clothes Dryer** +- **Dehumidifier** +- **Dish Sterilizer** +- **Dishwasher** +- **Electric Heater** +- **Electric Oven** +- **Electric Pressure Cooker** +- **Electric Rice Cooker** +- **Electric Slow Cooker** +- **Electric Water Heater** +- **Fan** +- **Fresh Air Appliance** +- **Front Load Washer** +- **Gas Stove** +- **Gas Water Heater** +- **Heat Pump Water Heater** +- **Heat Pump Wi-Fi Controller** +- **Heat Pump** +- **Humidifier** +- **Integrated Ceiling Fan** +- **Light** +- **MDV Wi-Fi Controller** +- **Microwave Oven** +- **Microwave Steam Oven** +- **Range Hood** +- **Refrigerator** +- **Sink Dishwasher** +- **Toaster** +- **Toilet** +- **Top Load Washer** +- **Water Drinking Appliance** + +{% warning %} + +This integration requires devices with protocol V1, V2, and V3. +It is based on **API v1** while some new devices are based on **API v2**. + +{% endwarning %} + +{% include integrations/config_flow.md %} + +The integration offers automatic discovery and manual configuration. + +{% configuration_basic %} + name: + description: The name of the device. + appliance code: + description: The code of the device. Needs to be retrieved from mobile app. + type: + description: The type of the device. See list above + ip_address: + description: The IP address of the device. + port: + description: The TCP/IP port of the device. + protocol: + description: The protocol version of the device. Can be V1, V2 or V3. + model: + description: The model of the device. Needs to be retrieved from mobile app. + subtype: + description: The subtype of the device. Needs to be retrieved from mobile app. + token: + description: The token of the device. Needs to be retrieved from mobile app. + key: + description: The key of the device. Needs to be retrieved from mobile app. +{% endconfiguration_basic %} + +## Data updates + +The integration pushes updates to Home Assistant upon changes for all main functions of the device. + +## Supported functionality + +The **Midea LAN** {% term integration %} provides the following entities: + +- Climate + +## Known limitations + +This integration requires devices with protocol V1, V2, and V3. +It is based on **API v1** while some new devices are based on **API v2**. + +## Removing the integration + +This integration follows standard integration removal. No extra steps are required. + +{% include integrations/remove_device_service.md %} diff --git a/source/_integrations/mikrotik.markdown b/source/_integrations/mikrotik.markdown index 87e87989f9c1..b170092019e3 100644 --- a/source/_integrations/mikrotik.markdown +++ b/source/_integrations/mikrotik.markdown @@ -2,8 +2,10 @@ title: Mikrotik description: Instructions on how to integrate MikroTik/RouterOS based devices into Home Assistant. ha_category: + - Button - Hub - Presence detection + - Sensor ha_release: 0.44 ha_codeowners: - '@engrbm87' @@ -11,7 +13,9 @@ ha_config_flow: true ha_domain: mikrotik ha_iot_class: Local Polling ha_platforms: + - button - device_tracker + - sensor ha_integration_type: device --- @@ -40,7 +44,6 @@ Go to **IP** > **Services** > **API** and enable it. Make sure that port 8728 or the port you choose is accessible from your network. - {% include integrations/config_flow.md %} {% configuration_basic %} @@ -101,3 +104,25 @@ You will be prompted to set a password for the newly created user. Depending on ```bash /user set [find username=homeassistant] password=PASSWORD ``` + +## Supported functionality + +The **MikroTik** {% term integration %} provides the following entities. + +### Sensors + +The integration creates sensor entities when the connected device exposes that information. Not every device supports every sensor. + +- Uptime +- Memory usage +- Disk usage +- CPU usage +- Device temperature +- Device power voltage + +### Buttons + +The integration creates the following button entities: + +- **Restart**: Reboots the MikroTik device. +- **Shutdown**: Powers off the MikroTik device. After a shutdown, the device is no longer reachable over the network and cannot be powered back on remotely from Home Assistant. diff --git a/source/_integrations/modbus.markdown b/source/_integrations/modbus.markdown index 275e8296e2aa..4b20f8230f15 100644 --- a/source/_integrations/modbus.markdown +++ b/source/_integrations/modbus.markdown @@ -1,6 +1,6 @@ --- title: Modbus -description: Instructions on how to integrate modbus and platforms. +description: Instructions on how to manually register Modbus entities and platforms. ha_category: - Hub ha_release: pre 0.7 @@ -22,9 +22,13 @@ related: [modbus](http://www.modbus.org/) is a communication protocol to control PLCs (Programmable Logic Controller) and RTUs (Remote Terminal Unit). +The Modbus {% term integration %} lets you manually register Modbus entities by describing each register in your `configuration.yaml` file. It is meant for people who are comfortable working with Modbus, as it requires knowledge of the protocol and of the specific registers your device exposes. + +Before setting this up, we recommend looking for a vendor-specific integration that already supports your Modbus device. A dedicated integration handles the register details for you and is easier to set up and maintain. + The integration adheres strictly to the [protocol specification](https://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b3.pdf) using [pymodbus](https://github.com/pymodbus-dev/pymodbus) for the protocol implementation. -The modbus {% term integration %} supports all devices adhering to the modbus standard. The communication to the device/devices can be serial (rs-485), TCP, or UDP connections. The modbus integration allows multiple communication channels e.g. a serial port connection combined with one or more TCP connections. +The Modbus integration supports all devices adhering to the Modbus standard. The communication to the device or devices can be serial (RS-485), TCP, or UDP connections. The integration allows multiple communication channels, for example a serial port connection combined with one or more TCP connections. # Configuring modbus communication diff --git a/source/_integrations/moon.markdown b/source/_integrations/moon.markdown index 1686345d31b1..15e4f88101f1 100644 --- a/source/_integrations/moon.markdown +++ b/source/_integrations/moon.markdown @@ -46,6 +46,10 @@ The sensor shows a matching moon icon for each phase, so you can recognize the c The more info dialog showing the current moon phase.

+{% include integrations/triggers.md %} + +{% include integrations/conditions.md %} + ## Data updates The phase is calculated on your own system from the current date, so no data is fetched from the internet. Home Assistant recalculates it as the date advances, so the sensor changes at most once per day. @@ -53,6 +57,7 @@ The phase is calculated on your own system from the current date, so no data is ## Known limitations - The phase is based on the date only. The sensor does not report the exact percentage of illumination, moonrise and moonset times, or how the moon looks from your specific location or hemisphere. +- The triggers and conditions are also based only on the phase. They do not react to moonrise, moonset, the moon's elevation, or the exact percentage of illumination. ## Removing the integration diff --git a/source/_integrations/mqtt.markdown b/source/_integrations/mqtt.markdown index 52b63cdc3aab..a2bedc974fc4 100644 --- a/source/_integrations/mqtt.markdown +++ b/source/_integrations/mqtt.markdown @@ -198,12 +198,12 @@ Add the MQTT integration, then provide your broker's hostname (or IP address) an MQTT subentries can also be reconfigured. Additional entities can be added, or an entity can be removed from the sub entry. Each MQTT subentry holds one MQTT device. The MQTT device must have at least one entity. {% important %} -If you experience an error message like `Failed to connect due to exception: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed`, then turn on `Advanced options` and set [Broker certificate validation](/integrations/mqtt/#broker-certificate-validation) to `Auto`. +If you experience an error message like `Failed to connect due to exception: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed`, then check the collapse section `Other settings` and set [Broker certificate validation](/integrations/mqtt/#broker-certificate-validation) to `Auto`. {% endimportant %} -### Advanced broker configuration +### Other broker configuration settings -Advanced broker configuration options include setting a custom client ID, configuring a client certificate and key for authentication, and enabling TLS validation of the broker's certificate to ensure a secure connection. To access the advanced options, open the MQTT broker settings, select **Advanced options**, and select **Next**. Advanced broker options are shown by default when the default advanced broker settings are changed. +Additional broker configuration options include setting a custom client ID, configuring a client certificate and key for authentication, and enabling TLS validation of the broker's certificate to ensure a secure connection. To access these settings, open the MQTT broker settings, and expand **Other settings**. #### Alternative client ID diff --git a/source/_integrations/music_assistant.markdown b/source/_integrations/music_assistant.markdown index b667050127c7..42575f6e8b5f 100644 --- a/source/_integrations/music_assistant.markdown +++ b/source/_integrations/music_assistant.markdown @@ -53,6 +53,8 @@ If using `media_player.play_media`, then note the `media_content_id` payload can - A streaming provider URI. For example, `spotify://artist/12345`. - A streaming provider URL. For example, `https://open.spotify.com/track/31cWPvM99ZHxMl3mdgiw4I`. +The `media_player.play_media` action runs as the Home Assistant user who made the request if their username matches a Music Assistant user. This affects the playlog entry and any provider filtering configured for that user. The `media_player.play_media` action doesn't let you choose the user, so if you call it from a script or automation and want the request attributed to a specific user, use the Music Assistant [Play media](/actions/music_assistant.play_media/) action instead and set its **Username** field. + If using `media_player.browse_media`, then the `media_content_id` payload must be a URI of the form `library://artist/1`, `library://album/20`, or `spotify://album/5zj4Ej0FrlJQaSo0d6cttH`. The type of item that the URI refers to must be an album or artist. These URIs can, for example, be obtained from the output of the [Get library items](/actions/music_assistant.get_library/) or [Search Music Assistant](/actions/music_assistant.search/) actions, or the `media_player.browse_media` action from Home Assistant. diff --git a/source/_integrations/neopool.markdown b/source/_integrations/neopool.markdown new file mode 100644 index 000000000000..7cf8506a0e7b --- /dev/null +++ b/source/_integrations/neopool.markdown @@ -0,0 +1,179 @@ +--- +title: NeoPool +description: Instructions on how to integrate NeoPool / Sugar Valley pool controllers with Home Assistant. +ha_release: 2026.8 +ha_iot_class: Local Polling +ha_config_flow: true +ha_codeowners: + - "@svasek" +ha_domain: neopool +ha_platforms: + - sensor +ha_integration_type: hub +ha_quality_scale: silver +ha_category: + - Hub +--- + +The **NeoPool** {% term integration %} integrates pool controllers built around the **NeoPool control system** (originally developed by **Sugar Valley**, acquired by **Hayward** in 2016) with Home Assistant. It communicates entirely locally over Modbus TCP, providing real-time monitoring of water chemistry, filtration, and hydrolysis without any cloud dependency. + +The same control system is sold under many brand names worldwide, including **Hidrolife**, **Aquascenic**, **Oxilife**, **Bionet**, **Hidroniser**, **UVScenic**, **Station**, and **Aquarite**, distributed by **Hayward**, **Brilix** (Albixon), **Bayrol**, **Certikin**, **Poolstar**, **GrupAquadirect**, **Pentair**, **ProducPool**, **Pool Technologie**, **Kripsol**, and others. + +{% note %} +_VistaPool_ is the name of Hayward's mobile/web app for cloud-based pool management. The **NeoPool** integration works entirely locally via Modbus and does not require or use the VistaPool app or any cloud service. If you prefer to use the cloud API instead, see the [Vistapool integration](/integrations/vistapool/). +{% endnote %} + +## Use cases + +The NeoPool integration brings your pool controller into Home Assistant, providing comprehensive data and control capabilities. Which entities appear depends on which modules and options the controller reports; unavailable ones are hidden automatically. + +- **Monitor water chemistry**: track pH, Redox/ORP, free chlorine, conductivity, and water temperature. +- **Monitor hydrolysis/electrolysis**: read current production intensity, cell voltage, polarity state, and cell wear counters. +- **Monitor ionization**: read the current ionization level and polarity. +- **Monitor filtration**: read the current mode, variable-speed percentage, and Intelligent-mode scheduling data. +- **Track backwash cycles**: read the remaining time when a Besgo automatic filter valve is running a cycle. +- **Surface pool-controller problems**: expose alarm states as sensor readings, and raise a repair issue if the controller's GPIO configuration register becomes corrupted. + +## Supported devices + +The integration supports any pool controller built on the NeoPool / Sugar Valley platform that exposes the standard Modbus register set, including: + +- **Hayward**: Aquarite (with NeoPool option), Hidroniser, UVScenic, Station +- **Sugar Valley**: Hidrolife, Aquascenic, Oxilife, Bionet +- **Brilix** (Albixon), **Bayrol**, **Certikin**, **Poolstar**, **GrupAquadirect**, **Pentair**, **ProducPool**, **Pool Technologie**, **Kripsol**, and other regional rebrands of the same control system + +The Modbus protocol implemented here follows the official _NeoPool Control System MODBUS Register description_ documentation by Sugar Valley. + +## Prerequisites + +Before setting up the NeoPool integration, make sure: + +- Your NeoPool controller is connected to a Modbus TCP gateway (any RS-485 to TCP converter, such as the USR-DR164) on your home network. +- The gateway is configured for 19200 baud, 1 stop bit, no parity, Modbus RTU. +- You know the hostname or IP address and TCP port of the gateway. +- The RS-485 wiring is connected to the controller's `WIFI` or `EXTERNAL` port (do **not** use `DISPLAY` unless the internal LCD is disconnected). The pinout (top to bottom) is: + + ```text + . ___ + 1 |* |– +12V (from internal power supply) + 2 |* |– NC (not connected) + 3 |* |– Modbus A+ + 4 |* |– Modbus B- + 5 |*__|– GND + ``` + + The connector is a standard 2.54 mm 5-pin PCB female header. + +{% note %} +The NeoPool device acts as a Modbus _server_. This integration is a Modbus _client_. Only one Modbus client can be connected to a given Modbus connector at a time. +{% endnote %} + +{% include integrations/config_flow.md %} + +### Configuration parameters + +{% configuration_basic %} +Host: + description: The hostname or IP address of your Modbus TCP gateway, for example `192.168.1.50` or `pool-gateway.local`. +Port: + description: The TCP port of your Modbus gateway. Defaults to `502`. +Unit ID: + description: The Modbus unit (server) ID of the NeoPool controller. Defaults to `1`. +Modbus framer: + description: Protocol framer to use. `tcp` works for most gateways. Pick `rtu` only if your gateway forwards raw RTU frames over TCP. +{% endconfiguration_basic %} + +## Supported functionality + +The integration exposes the controller's runtime state as sensor entities. **Only entities backed by a detected hardware module or an enabled controller option are registered**; the rest stay hidden until the module or option becomes available. Each bullet below lists the specific requirement for that sensor. + +### Sensors + +- **Water temperature**: current pool water temperature (when the temperature sensor is present). +- **pH**: measured pH level (when the pH module is present). +- **Redox / ORP**: measured oxidation-reduction potential in mV (when the Redox module is present). +- **Free chlorine**: measured chlorine concentration (when the chlorine module is present). +- **Conductivity**: measured water conductivity (when the conductivity module is present). +- **pH pump status**: current state of the pH dosing pump (off, idle, acid pump, base pump, both pumps) (when the pH module is present). +- **pH alarm**: latched pH-regulation alarm state (when the pH module is present). +- **Hydrolysis intensity**: current production level in % (when the hydrolysis module is present). +- **Hydrolysis voltage**: current cell voltage (when the hydrolysis module is present; diagnostic, disabled by default). +- **Hydrolysis polarity**: current polarity of the electrolytic cell (when the hydrolysis module is present). +- **Ionization intensity**: current ionization level (when the ionization module is present). +- **Ionization polarity**: current polarity of the ionization electrodes (when the ionization module is present). +- **Filtration mode**: current mode reported by the controller (Manual, Auto, Heating, Smart, Intelligent, Backwash). +- **Filtration speed**: current variable-speed filtration percentage (when the controller reports a variable-speed pump). +- **Intelligent-mode intervals** and **time to next interval**: scheduling data for Intelligent mode (when a heating relay and temperature sensor are configured). +- **Backwash remaining**: time remaining in the active backwash cycle (when a Besgo automatic filter valve is configured). +- **Cell runtime counters**: five diagnostic counters tracking wear on the electrolytic cell (when the hydrolysis module is present), total runtime, runtime since last reset, runtime in polarity 1 and 2, and polarity-change count. All five are diagnostic and disabled by default; enable them in the entity registry if you want to track cell wear over time. + +## Data updates + +The integration {% term polling polls %} the controller over Modbus TCP at a fixed interval. To stay responsive, the integration reads data from the controller in as few requests as possible per update cycle. + +If a poll cycle fails (for example, because the Modbus gateway becomes unreachable), all entities transition to `unavailable` until the next successful poll. + +## Known limitations + +- **Discovery is not supported.** Modbus TCP gateways do not expose a standard discovery protocol that uniquely identifies a NeoPool controller behind the gateway, so the integration must be configured manually. +- **One controller per config entry.** Multiple physical controllers are supported, but each one needs its own config entry. +- **Authentication is not used.** Modbus TCP itself has no authentication mechanism; the integration relies on network isolation between Home Assistant and the gateway. The gateway should not be exposed to untrusted networks. +- **The DISPLAY connector is reserved.** The NeoPool controller exposes the same protocol on its `DISPLAY` connector as on `WIFI` / `EXTERNAL`, but the built-in LCD usually occupies it. Connecting to `DISPLAY` while the LCD is attached will result in collisions. +- **Variable-speed pump support depends on the controller firmware.** The Filtration speed entity is registered only when the controller reports a variable-speed pump. + +## Troubleshooting + +### Cannot connect during setup + +#### Symptom: "Cannot connect" during the initial config flow + +When trying to set up the integration, the form shows the message **Cannot connect** or **Cannot read Modbus**. + +#### Description + +The integration could reach the network address but did not receive a valid Modbus reply within the timeout, or the gateway refused the TCP connection altogether. + +#### Resolution + +1. Verify the Modbus TCP gateway is reachable from Home Assistant by pinging the gateway IP. +2. Confirm the gateway is configured for 19200 baud, 1 stop bit, no parity (Modbus RTU). +3. Check the RS-485 wiring (A+ / B− / GND) and that the connector is plugged into `WIFI` or `EXTERNAL`, not `DISPLAY` (when the LCD is connected). +4. Make sure the unit ID matches the controller's configured Modbus address (default `1`). + +### All entities went unavailable suddenly + +#### Symptom: every NeoPool entity is `unavailable` at the same time + +All entities provided by the integration become `unavailable` simultaneously, often after a network change or gateway restart. + +#### Description + +The integration has lost contact with the Modbus gateway. Entities recover automatically on the next successful poll after connectivity is restored. + +#### Resolution + +If entities stay unavailable for more than a few minutes: + +1. Check the Home Assistant logs for `neopool` errors. +2. Power-cycle the Modbus gateway. +3. Verify nothing else on the network has taken over the same TCP connection (only one Modbus client per gateway port at a time). + +### Repair issue: "Corrupted GPIO register" + +#### Symptom: a repair issue is created with the message "Corrupted GPIO register" + +The integration raises a [repair issue](/integrations/repairs/) shortly after setup or after a controller restart. + +#### Description + +The integration detected a known-bad value in the controller's GPIO configuration register. This usually points at a relay configuration that was partially written or lost across firmware updates. + +#### Resolution + +Follow the steps in the repair flow to acknowledge or fix the condition. The issue clears automatically once the register reads a valid value again. + +## Removing the integration + +This integration follows standard integration removal. + +{% include integrations/remove_device_service.md %} diff --git a/source/_integrations/netatmo.markdown b/source/_integrations/netatmo.markdown index 23a2642e5dbe..17ec8c85422e 100644 --- a/source/_integrations/netatmo.markdown +++ b/source/_integrations/netatmo.markdown @@ -268,7 +268,7 @@ To confirm your Home Assistant instance is receiving events via webhooks, you ca ### Light -If the lights show as unavailable the issue usually is that webhook is banned by Netatmo. To solve that [unregister](#un-register-webhooks) the webhook, go to the [Netatmo Developer Page](https://dev.netatmo.com/) to unban your webhook and then [register](#un-register-webhooks) the webhook. +If the lights show as unavailable, the webhook has likely been banned by Netatmo. To resolve this, go to the [Netatmo Developer Page](https://dev.netatmo.com/) to unban your webhook, and then reload the integration. ## Removing the integration diff --git a/source/_integrations/nina.markdown b/source/_integrations/nina.markdown index 89e803152f36..3b6876996106 100644 --- a/source/_integrations/nina.markdown +++ b/source/_integrations/nina.markdown @@ -122,9 +122,66 @@ The following attributes are available for the warnings. - **Attributes**: - `id`: Individual ID for each warning. +## Actions + +The integration provides the following actions. + +### Action: Get warning details + +The `nina.get_details` action is used to fetch all details of a warning. + +- **Target**: NINA binary sensor entity + - **Description**: The NINA warning binary sensor to get the recommended actions for. + - **Optional**: No + #### Response data -The response data is a string with the description as provided by NINA. +The response data is an object containing all the warning data. Returns `null` when no warning is active. + +```json +{ + { + "binary_sensor.bad_ditzenbach_goppingen_baden_wurttemberg_warning_1": { + "headline": "Amtliche WARNUNG vor extremer HITZE", + "description": "Am Freitag wird eine extreme Wärmebelastung bis zu einer Höhe von 400m erwartet.

Am Samstag wird eine extreme Wärmebelastung bis zu einer Höhe von 600m erwartet.

Heute ist der 9. Tag der Warnsituation in Folge.", + "sender": "Zentrum für Medizin-Meteorologische Forschung", + "severity": "Severe", + "recommended_actions": "Hitzebelastung kann für den menschlichen Körper gefährlich werden und zu einer Vielzahl von gesundheitlichen Problemen führen. Vermeiden Sie nach Möglichkeit die Hitze, trinken Sie ausreichend Wasser und halten Sie die Innenräume kühl.", + "affected_areas": "Gemeinde Oberreichenbach, Gemeinde Neuweiler, Gemeinde Simmersfeld, Gemeinde Simmozheim, Gemeinde Rohrdorf, Gemeinde Ostelsheim, Gemeinde Egenhausen, Gemeinde Dobel, Gemeinde Schopfloch, Stadt Haiterbach, Gemeinde Gechingen, Gemeinde Wörnersberg, Gemeinde Enzklösterle, Gemeinde Seewald, Gemeinde Waldachtal, Stadt Bonndorf im Schwarzwald, Stadt Engen, Gemeinde Eigeltingen, Mitgliedsgemeinde in Verwaltungsgemeinschaft Pfofeld, Stadt Pappenheim und 229 weitere.", + "web": "https://dwd.de/warnungen", + "id": "dwd.2.49.0.0.276.0.DWD.PVW.1782460800000.559ba8f2-38a1-484f-b6e7-1424f85d1441.MUL", + "sent": "2026-06-26T09:59:50+02:00", + "start": "2026-06-26T10:00:00+02:00", + "expires": "2026-06-27T19:00:00+02:00" + } +} +``` + +## Examples + +{% details "Example usage" %} +{% raw %} + +```yaml +alias: "Notify on NINA warning with full affected areas" +description: "When a NINA warning becomes active, fetch the full list of affected areas and send a notification." +triggers: + - trigger: state + entity_id: binary_sensor.nina_warning_1 + to: "on" +actions: + - action: nina.get_details + target: + entity_id: binary_sensor.nina_warning_1 + response_variable: warning_data + - action: notify.mobile_app + data: + title: "NINA warning active" + message: "Affected areas: {{ warning_data['binary_sensor.nina_warning_1']['affected_areas'] }}" +``` + +{% endraw %} +{% enddetails %} ## Data updates diff --git a/source/_integrations/nobo_hub.markdown b/source/_integrations/nobo_hub.markdown index 977ea36af5e4..eef51597dda7 100644 --- a/source/_integrations/nobo_hub.markdown +++ b/source/_integrations/nobo_hub.markdown @@ -17,72 +17,227 @@ ha_platforms: ha_integration_type: hub ha_quality_scale: bronze ha_dhcp: true +related: + - docs: /docs/organizing/areas/#creating-an-area + title: Areas in Home Assistant + - docs: /docs/automation/ + title: Automations --- -Integrates [Nobø Ecohub](https://en.nobo.no/product/nobo-hub) -into Home Assistant. This integration is not officially supported or endorsed by Glen Dimplex Nordic AS, -and the authors/maintainers are not official partners of Glen Dimplex Nordic AS. +The **Nobø Ecohub** {% term integration %} connects Home Assistant to your [Nobø Ecohub](https://en.nobo.no/product/nobo-hub), a Norwegian heating controller from Glen Dimplex Nordic AS. The hub manages electric panel heaters, floor heating, and on/off receivers grouped into zones, and lets you follow weekly heating schedules with eco, comfort, and away setpoints. -To configure the integration, you need the 3 last digits of the serial number of your hub. The serial number is located -on the back of the hub. If the hub is on a different network than Home Assistant (such as IoT VLAN or another routable network from Home Assistant), you also need to provide the IP address of the hub. +With this integration, you can control your heating zones, switch between week profiles, and read temperatures from any connected Nobø Switch—all locally over your network, without depending on a cloud service. + +This integration is not officially supported or endorsed by Glen Dimplex Nordic AS, and the authors and maintainers are not official partners of Glen Dimplex Nordic AS. + +## How you can use this integration + +The Nobø Ecohub is mainly used in homes and cabins with electric heating in the Nordic region. Typical things you can do with this integration are: + +- Control heating zones directly from your dashboard, with the same eco, comfort, and away presets you have in the Nobø Energy mobile app. +- Switch the active week profile for a zone from an automation. For example, switch a cabin to its weekend profile when you leave for a trip on Friday. +- Trigger a global override (such as away or eco) when everyone leaves home, and clear it again when someone returns. +- Use the temperature reading from a Nobø Switch as a trigger in your automations, or display it on a dashboard alongside other room sensors. +- Coordinate the Nobø heaters with other heat sources, such as a heat pump, by switching presets or week profiles based on outdoor temperature, electricity price, or solar production. +- Turn heaters fully off in a zone, for example to switch off cabin heating outside of the heating season. See [Turning a zone fully off](#turning-a-zone-fully-off) for the recommended approach. + +## Supported devices + +The integration is built around the Nobø Ecohub and supports the devices that the hub itself manages: + +- **Nobø Ecohub**: The bridge between your Nobø system and Home Assistant. Each zone you have configured in the hub is exposed in Home Assistant. +- **Heaters and on/off receivers**: Floor and wall-mounted heaters, and any on/off receivers in a zone, are controlled through their zone's climate entity. Heaters with a built-in thermostat that supports remote control let you change the zone's eco and comfort temperatures from Home Assistant. +- **Nobø Switch (SW4)**: Exposed as a temperature {% term sensor %}. If the switch is linked to a zone in the Nobø Energy app, its temperature is also shown as the current temperature of that zone. + +Individual heaters, switches, and zones must be added and configured using the Nobø Energy mobile app. Home Assistant reads whatever the hub already knows about. + +Each zone is added as a device in Home Assistant, and its zone name is offered as a suggested [area](/docs/organizing/areas/#creating-an-area). You can accept the suggestion to group the zone's entities with the rest of that room, or pick a different area. + +## Prerequisites + +Before adding the integration, make sure the following is in place: + +- Your Nobø Ecohub is powered up and connected to your network. +- Your zones, heaters, and any Nobø Switches are set up in the Nobø Energy mobile app, and you can control them from the app. +- You know the last 3 digits of your hub's serial number. The full 12-digit serial number is printed on a label on the back of the hub. +- If your hub is on a different network than Home Assistant, for example on an IoT VLAN, make sure that network is routable from Home Assistant and that you know the hub's IP address. {% include integrations/config_flow.md %} -# Heaters +In most cases, the hub is discovered automatically on your network, and you only need to enter the 3-digit serial number suffix. If the hub is not discovered, choose **Manual** in the device list and enter the full 12-digit serial number together with the hub's IP address. + +{% configuration_basic %} +Discovered hubs: + description: "Select the Nobø Ecohub discovered on your local network, or choose **Manual** to enter the details by hand." +Serial number suffix (3 digits): + description: "The last 3 digits of the serial number printed on the back of your Nobø Ecohub. Used to confirm that you own the discovered hub." +Serial number (12 digits): + description: "The full 12-digit serial number printed on the back of your Nobø Ecohub. Only required when adding the hub manually." +IP address: + description: "The IP address of your Nobø Ecohub. Only required when adding the hub manually, for example when the hub is on a different network than Home Assistant." +{% endconfiguration_basic %} + +## Reconfiguration + +You can update the IP address without removing and re-adding the integration. + +This is useful when: + +- The hub has moved to a new network and the stored IP address no longer reaches it. +- You want to switch between internal and external addresses (for example, when the hub is reachable on multiple subnets). + +1. Go to {% my integrations title="**Settings** > **Devices & services**" %}. +2. On the **Nobø Ecohub** integration, select the three dots menu {% icon "mdi:dots-vertical" %} and choose **Reconfigure**. +3. Enter the new IP address. +4. Select **Submit** to save. + +## Configuration options + +The integration provides one configuration option that you can change later under {% my integrations title="**Settings** > **Devices & services**" %} by selecting **Configure** on the Nobø Ecohub entry: + +{% configuration_basic %} +Override type: + description: "Controls how long overrides stay active when you change the preset of a zone or trigger a global override. Select **Constant** to keep the override until you clear it manually, or **Now** to end the override at the next week profile change (the same as duration **Now** in the Nobø Energy app). The default is **Constant**." +{% endconfiguration_basic %} + +## Supported functionality + +The integration creates entities for every zone in the hub, a global override selector for the hub itself, and a temperature sensor for every Nobø Switch and thermostat that reports a temperature. + +### Climate entities + +Each zone in your hub is exposed as a climate entity. You can use it to set the HVAC mode, change the preset, and adjust the eco and comfort target temperatures. + +- **HVAC modes**: + - **Auto**: The zone follows the active week profile. The preset reflects the state the zone is currently in. + - **Heat**: The zone is overridden and stays in the selected preset (away, eco, or comfort) until the override ends. + - **Off**: Shown only when the current week profile sets the zone to off. You cannot select this mode manually. See [Turning a zone fully off](#turning-a-zone-fully-off). +- **Presets**: **None**, **Comfort**, **Eco**, and **Away**. In **Away**, the setpoint is fixed at 7°C for frost protection and cannot be changed, and any on/off receivers in the zone are switched off. +- **Target temperatures**: Eco (low) and comfort (high) setpoints, between 7°C and 30°C, in steps of 1°C. You can change these setpoints on any zone, but a new value only takes effect if the zone contains a thermostat that supports remote control of its eco or comfort temperature. + +The HVAC mode and preset are linked, so a change to one updates the other: + +- Selecting a preset of **Away**, **Eco**, or **Comfort** switches the HVAC mode to **Heat**. +- Selecting preset **None** switches the HVAC mode to **Auto** and updates the preset to match the active week profile. +- Selecting HVAC mode **Auto** clears the override and updates the preset to match the active week profile. +- Selecting HVAC mode **Heat** sets the preset to **Comfort**. + +### Select entities + +- **Week profile**: Per zone. Lets you change which week profile is active. Week profiles must be created and edited in the Nobø Energy mobile app. The selector lists the profiles the hub currently knows about. +- **Global override**: One per hub. Overrides every zone (except zones that are configured in the Nobø Energy app to ignore the global override) to the selected preset. The available options are **None**, **Away**, **Eco**, and **Comfort**. The global override uses the same override type as preset changes. + +### Sensor entities + +- **Temperature**: One per device that reports a temperature, such as a Nobø Switch (SW4) or a thermostat with a temperature sensor. The reading is in degrees Celsius. If the device is linked to a zone, the same temperature is also shown as the current temperature on that zone's climate entity. + +## Examples + +A few practical ways to use the integration: + +- Activate away mode when nobody is home: use a state change on your home and away group or a person {% term entity %} as the trigger, and have the automation select **Away** on the global override selector. When someone returns, change the global override back to **None** to follow the normal week profiles again. +- Preheat before arrival: when you start the drive to a cabin, set the relevant zones to preset **Comfort**. On arrival, switch them back to preset **None** to let the week profile take over again. +- Pause heating when the heat pump can carry the load: when your heat pump is producing enough heat, switch the Nobø zones to preset **Eco** to avoid double-heating. Switch back to **None** when the heat pump stops. +- Show room temperatures on a dashboard: add the temperature sensors from your Nobø Switches to a dashboard alongside your other room sensors to keep an eye on every zone at a glance. + +### Following presence with the global override + +This pair of automations sets the global override to **Away** when everyone leaves home, and clears it again when the first person returns so every zone goes back to its normal week profile. Replace `group.family` with your own presence group or person {% term entity %}, and `select.my_eco_hub_global_override` with the name of your hub's global override selector. + +{% example %} +automation: | + - alias: "Nobø: set away when everyone leaves" + triggers: + - trigger: state + entity_id: group.family + from: "home" + actions: + - action: select.select_option + target: + entity_id: select.my_eco_hub_global_override + data: + option: "away" + - alias: "Nobø: clear away when someone comes home" + triggers: + - trigger: state + entity_id: group.family + to: "home" + actions: + - action: select.select_option + target: + entity_id: select.my_eco_hub_global_override + data: + option: "none" +{% endexample %} + +### Turning a zone fully off + +The Nobø system does not expose an off preset, because the away preset doubles as frost protection and is fixed at 7°C. To turn a zone fully off, for example outside of the heating season or while a cabin is empty for a longer time, use a dedicated week profile: + +1. In the Nobø Energy mobile app, create a new week profile and set every day to state off. +2. To turn a zone off, switch that zone to the new week profile. You can do this from Home Assistant by changing the **Week profile** select entity for the zone. +3. To turn the zone on again, switch back to your normal week profile. + +To automate this, use a `select.select_option` action on the zone's week profile selector. Replace `select.cabin_week_profile` with the week profile selector for your zone, and `Off` with the exact name of the profile you created in the Nobø Energy app. + +{% example %} +action: | + - action: select.select_option + target: + entity_id: select.cabin_week_profile + data: + option: "Off" +{% endexample %} + +The climate entity for the zone shows HVAC mode **Off** while the active week profile keeps the zone off. On/off receivers in the zone are switched off, and heaters with their own thermostat are no longer driven by the hub. + +For more background on week profiles, see the [Nobø Ecohub manual](https://help.nobo.no/en/user-manual/before-you-start/what-is-a-weekly-program/). + +## Data updates + +The integration uses a local push connection to your Nobø Ecohub. When you set up the integration, Home Assistant opens a persistent TCP connection to the hub and registers for live updates. Any change made on the hub—for example, when a week profile changes state, when the temperature reported by a Nobø Switch changes, or when someone presses a Nobø Switch—is pushed to Home Assistant within seconds. + +The current preset of a zone can also change on its own, when the active week profile moves from one scheduled state to the next. The hub does not send an event for this. To keep the zone's preset accurate, the integration re-checks the active week profile against the clock every 60 seconds. This check is local and does not add any traffic to the hub. -Each zone containing floor or wall mounted heaters is represented as an HVAC entity. Adding and removing zones -and heaters must be done using the Nobø Energy mobile app. +If the connection to the hub is lost, for example because the hub's IP address has changed, the integration tries to rediscover the hub on your local network using a UDP broadcast and reconnects automatically when it finds the hub again. This rediscovery only works if Home Assistant and the hub are on the same network segment. -## Operation modes +## Known limitations -Currently, you can see and change operation and preset for zones and set eco/comfort temperatures if you have -a thermostat that supports remote control of the temperature settings. +The integration cannot manage the configuration of your Nobø system. The following must be done in the Nobø Energy mobile app: -The possible operation modes are as follows: +- Registering or deregistering Nobø devices: Heaters, on/off receivers, and Nobø Switches have to be paired with and removed from the hub in the Nobø Energy app. +- Creating or deleting zones: Zones, including their name and which devices belong to them, are defined in the Nobø Energy app. +- Creating, updating, or deleting week profiles: Week profile schedules can only be edited in the Nobø Energy app. In Home Assistant, you can only select which existing profile is active for a zone. -- "Auto" - In this mode, the zone is in the default setting and preset shows which state the zone is in right now - (according to calendar setup). -- "Heat" - In this mode the zone is overridden and in the state selected by the preset ("Away", "Eco" - or "Comfort"). +## Troubleshooting -This can be utilized the following ways: +### Setup fails with "Failed to connect - check serial number" -- Changing preset to "Away", "Eco", or "Comfort" will automatically change operation mode to "Heat". -- Changing preset to none will automatically change operation to "Auto" and update preset. -- Changing operation to "Auto" will automatically update preset. -- Changing operation to "Heat" will set preset to "Comfort". +The hub was reachable on the network, but it rejected the serial number you entered. Re-check the last 3 digits of the serial number on the label on the back of the hub and try again. If you set up the hub manually, also check that the full 12-digit serial number matches. -### Preset override duration +### Setup fails with "Failed to connect - check IP address" -By default, all overrides (when operation is not in "Auto" mode) are constant. It is possible to change this -to let overrides end when the week profile changes next (same as duration "Now" in the Nobø Energy mobile app) -in the integration configuration. +Home Assistant could not open a connection to the IP address you entered. Make sure that: -### Week profiles +- The hub is powered up and connected to your network. +- The IP address is correct. To confirm the hub is reachable, check {% my logs title="**Settings** > **System** > **Logs**" %} for connection errors, or ping the hub's IP address from another device on your network. +- No firewall rule blocks the traffic between Home Assistant and the hub, especially if the hub is on a different VLAN. -The week profiles are retrieved from the hub. It is possible to change the current week profile for a zone -using a selector. Week profiles must be created and edited using the Nobø Energy mobile app. +### The hub becomes unavailable after its IP address changes -### No preset "Off" +The integration tries to rediscover the hub automatically when it cannot reach the stored IP address. This uses a UDP broadcast that only works on the same network segment. -Nobø heaters do not support preset "Off". This is not a limitation of the integration, but a safety mechanism in the -Nobø system (perhaps related to frozen pipes due to frost in Nordic regions). -"Away" temperature is fixed to 7°C and cannot be altered. On/off receivers will be off when the zone is in "Away" status. +- If Home Assistant and the hub are on the same network, the integration usually picks up the new IP address on its own. +- If the hub is on a different network, the rediscovery does not reach it. In that case, update the stored address using [Reconfiguration](#reconfiguration). -To turn heaters completely off, follow these steps (this is a workaround solution): -1. In the Nobø Energy mobile app, create a week profile. - - In this profile, set all days to state off. -2. To turn a zone off, select this week profile for the zone. -3. To turn a zone on again, switch to the normal week profile for the zone. +To avoid this issue, give the hub a static IP address or a DHCP reservation on your router. -For more information, see the [Nobø Ecohub manual](https://help.nobo.no/en/user-manual/before-you-start/what-is-a-weekly-program/). +### Setting a target temperature does not seem to do anything -## Global override +The eco and comfort setpoints always update, but they only take effect on zones that include a thermostat that supports remote control of the temperature setpoints. Zones that contain only on/off receivers or heaters without this support keep following their own temperature settings and ignore the new setpoint. -To override all zones to a given preset (except the zones configured to not respect global override), use the global -override selector. Global override duration respects the same configuration as preset override duration. +## Removing the integration -# Nobø Switch +This integration follows standard integration removal. -Each Nobø Switch (SW4) is represented as a temperature sensor. If a switch is linked to a zone, the temperature is -also available as the current temperature of the HVAC entity. +{% include integrations/remove_device_service.md %} diff --git a/source/_integrations/number.markdown b/source/_integrations/number.markdown index bc9aef1c95bf..60ab647a39b8 100644 --- a/source/_integrations/number.markdown +++ b/source/_integrations/number.markdown @@ -77,6 +77,7 @@ The following device classes are supported for numbers: - **precipitation**: Accumulated precipitation in cm, in or mm - **precipitation_intensity**: Precipitation intensity in in/d, in/h, mm/d or mm/h - **pressure**: Pressure in mPa, Pa, hPa, kPa, bar, cbar, mbar, mmHg, inHg, inH₂O or psi +- **radon**: Concentration of radon in Bq/m³ or pCi/L - **reactive_energy**: Reactive energy in varh or kvarh - **reactive_power**: Reactive power in mvar, var, or kvar - **signal_strength**: Signal strength in dB or dBm diff --git a/source/_integrations/ohme.markdown b/source/_integrations/ohme.markdown index 9138b92d3966..a03e897122a8 100644 --- a/source/_integrations/ohme.markdown +++ b/source/_integrations/ohme.markdown @@ -93,9 +93,6 @@ The Ohme integration provides the following entities. - **Current** - **Description**: Current draw from the charger in amperes. - **Available for devices**: all -- **Energy** - - **Description**: Energy consumption of the charger in kWh. - - **Available for devices**: all - **Voltage** - **Description**: Voltage supplied to the charger. This is only available when a vehicle is connected. - **Available for devices**: all diff --git a/source/_integrations/omie.markdown b/source/_integrations/omie.markdown index e5ffbb710afe..beeca502c3b1 100644 --- a/source/_integrations/omie.markdown +++ b/source/_integrations/omie.markdown @@ -32,6 +32,8 @@ The **OMIE** integration retrieves the results of the [day-ahead market](https:/ - **Portugal spot price**: Current quarter-hour electricity spot price in Portugal, in €/kWh. - **Spain spot price**: Current quarter-hour electricity spot price in Spain, in €/kWh. +{% include integrations/actions.md %} + ## Data updates The OMIE integration {% term polling polls %} OMIE for new data at the start of each quarter-hour (in Central European Time). diff --git a/source/_integrations/openai_conversation.markdown b/source/_integrations/openai_conversation.markdown index e3a8c3924ac9..d84b4e130fde 100644 --- a/source/_integrations/openai_conversation.markdown +++ b/source/_integrations/openai_conversation.markdown @@ -90,6 +90,8 @@ Store requests and responses in OpenAI: description: If enabled, OpenAI stores requests and responses and you can view them in your OpenAI dashboard logs. Disabled by default. Service tier: description: The available service tiers are Auto, Standard, Flex, and Priority. Flex tier offers lower costs in exchange for slower response times, which can be useful for background automations. [Priority processing](https://openai.com/api-priority-processing/) delivers significantly lower and more consistent latency than the Standard tier at a higher price. Auto is the default value, which uses the [project settings](https://platform.openai.com/settings/organization/projects). See the [Pricing](https://developers.openai.com/api/docs/pricing) for details on the supported models. When the selected tier is unavailable due to capacity or ramp rate limits, the request is processed at the Standard tier, and you are charged the Standard tier price. +Pro mode: + description: Perform more model work to improve reliability on difficult tasks and return a single final answer. Enable it when quality matters more than latency and token usage. Pro mode aggregates the model work performed to produce the final answer and bills those tokens at the selected model’s standard token rates. Pro mode performs more model work than standard mode, increasing token usage and cost. This parameter is only applicable to GPT-5.6 and above; existing Pro model IDs keep their current behavior and pricing. Enable web search: description: Enable OpenAI-provided [Web search tool](https://openai.com/index/new-tools-for-building-agents/#web-search). Note that it is only available for gpt-4o and newer models. Search context size: diff --git a/source/_integrations/permobil.markdown b/source/_integrations/permobil.markdown deleted file mode 100644 index 31c65465ed1b..000000000000 --- a/source/_integrations/permobil.markdown +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: MyPermobil -description: Instructions on how to integrate Permobil wheelchair into Home Assistant. -ha_category: - - Sensor -ha_iot_class: Cloud Polling -ha_release: 2023.12 -ha_domain: permobil -ha_codeowners: - - '@IsakNyberg' -ha_config_flow: true -ha_platforms: - - binary_sensor - - sensor -ha_integration_type: device ---- - -The **MyPermobil** {% term integration %} allows you to view various sensors with information about your Permobil wheelchair. For example: battery status, distance traveled, and number of seating adjustments. The values of the sensors may be delayed by several minutes and should not be relied on for any crucial applications. For the integration to work, you must ensure that _voice assistant linking_ is activated in the MyPermobil app. To do this, open the app and navigate to **Settings** > **My Account** > **Connection Settings**. - -{% include integrations/config_flow.md %} - -## Sensors - -A total of 13 sensors are available: - -- **Battery charge** - The current battery state of the wheelchair as a percentage. -- **Battery health** - The maximum amount of charge the battery can hold. Measured as a percentage of the battery's original capacity. -- **Charge time left** - A number indicating how many hours the battery needs until it is fully charged. The battery needs to be charging for this sensor to work. -- **Distance left** - The distance the wheelchair can travel on its current charge. This figure is an estimate and should not be relied upon. -- **Indoor drive time** - The estimated number of hours of indoor drive time that is left on the current battery charge. -- **Battery max watt hours** - The number of watt hours of energy stored in the battery when it is at maximum capacity. -- **Watt hours left** - The number of watt hours of energy stored in the battery on its current charge. -- **Full charge distance** - The distance the wheelchair can travel on a full charge. This figure is an estimate and should not be relied upon. -- **Distance traveled** - The distance the wheelchair has traveled today. -- **Number of adjustments** - The number of adjustments sessions today. Multiple different adjustment within a short time period are counted as a single sessions. -- **Highest number of adjustments** - The highest number of adjustments ever recorded in a single day. -- **Longest distance traveled** - The largest distance traveled ever recorded in a single day. -- **Is charging** - Binary sensor that is true when the Permobil wheelchair is charging. diff --git a/source/_integrations/picnic.markdown b/source/_integrations/picnic.markdown index b76837bbaa33..a6d7af1af452 100644 --- a/source/_integrations/picnic.markdown +++ b/source/_integrations/picnic.markdown @@ -40,6 +40,7 @@ This integration provides the following sensors. Some sensors are disabled by de | Last order total price | The total price of the last order. | | Next delivery ETA start | Start of the ETA window of the next delivery, will get more precise if the driver is underway. | | Next delivery ETA end | End of the ETA window of the next delivery. | +| Estimated arrival of next delivery | Precise estimated arrival time of the next delivery, based on the live position of the delivery vehicle. Only available shortly before the delivery, `unknown` otherwise. | | Next delivery slot start | Start of the next delivery's delivery slot. | | Next delivery slot end | End of the next delivery's delivery slot. | diff --git a/source/_integrations/portainer.markdown b/source/_integrations/portainer.markdown index 247fd3cff023..1e3bdf2cc1e2 100644 --- a/source/_integrations/portainer.markdown +++ b/source/_integrations/portainer.markdown @@ -6,6 +6,7 @@ ha_category: - Button - Sensor - Switch + - Update ha_release: '2025.10' ha_iot_class: Local Polling ha_codeowners: diff --git a/source/_integrations/proxmoxve.markdown b/source/_integrations/proxmoxve.markdown index a5ad65dd84e5..15a112a92d5b 100644 --- a/source/_integrations/proxmoxve.markdown +++ b/source/_integrations/proxmoxve.markdown @@ -166,6 +166,8 @@ To create a token: ## Entities +Some entities are not enabled by default, you can enable them via the device page. + ### Sensor - **CPU**: Percentage of CPU usage. diff --git a/source/_integrations/ptdevices.markdown b/source/_integrations/ptdevices.markdown index 109b601ed403..16a5978fbdf5 100644 --- a/source/_integrations/ptdevices.markdown +++ b/source/_integrations/ptdevices.markdown @@ -2,9 +2,11 @@ title: PTDevices description: Instructions on how to integrate your PTLevel into Home Assistant. ha_release: 2026.6 -ha_category: +ha_category: + - Binary sensor - Sensor ha_platforms: + - binary_sensor - sensor ha_iot_class: Cloud Polling ha_quality_scale: bronze @@ -77,6 +79,16 @@ Some sensors are disabled by default because they provide information that is on {% endnote %} +### Binary sensors + +- **Battery status**: + - **Description**: Indicates whether the onboard battery is low. + - **Available for models**: All battery-powered models + +- **External power**: + - **Description**: Indicates whether external power is present. + - **Available for models**: All externally-powered models + ### Sensors - **Level depth**: diff --git a/source/_integrations/reolink.markdown b/source/_integrations/reolink.markdown index cb627362b93a..a68926e40693 100644 --- a/source/_integrations/reolink.markdown +++ b/source/_integrations/reolink.markdown @@ -227,6 +227,7 @@ Depending on the supported features of the camera ([see specifications of the ca - PTZ continuous rotation* - Guard go to - Guard set current position +- Pre-siren - Restart* **PTZ left**, **right**, **up**, **down**, **left up**, **left down**, **right up**, **right down**, **zoom in** and **zoom out** will continually move the camera in the respective position until the **PTZ stop** is called or the hardware limit is reached. @@ -291,6 +292,7 @@ Depending on the supported features of the camera ([see specifications of the ca - Infrared lights in night mode - Record audio - Siren on event +- Pre-siren on event - Auto tracking - Auto focus - Guard return @@ -332,6 +334,8 @@ The **Manual record** switch will turn off automatically after 10 minutes. There Polling the status of the **Hardwired chime enabled** switch can make the hardwired chime rattle a bit depending on the model of the chime. Therefore the status of this switch is only polled one time (about 1 minute after the integration starts). The rattle at startup can only happen if you chose to enable this switch. +The **Pre-siren on event** switch only takes effect when the **Siren on event** switch is ON. + ### Light entities Depending on the supported features of the camera ([see specifications of the camera model on Reolink.com](#tested-models)), light entities are added for: diff --git a/source/_integrations/scorpiontrack.markdown b/source/_integrations/scorpiontrack.markdown new file mode 100644 index 000000000000..ca63121ee199 --- /dev/null +++ b/source/_integrations/scorpiontrack.markdown @@ -0,0 +1,78 @@ +--- +title: ScorpionTrack +description: Instructions on how to integrate ScorpionTrack shared vehicle locations into Home Assistant. +ha_category: + - Device tracker +ha_release: 2026.8 +ha_iot_class: Cloud Polling +ha_domain: scorpiontrack +ha_platforms: + - device_tracker +ha_config_flow: true +ha_integration_type: hub +ha_codeowners: + - '@Herbertmt978' +ha_quality_scale: bronze +--- + +The **ScorpionTrack** {% term integration %} lets Home Assistant follow vehicles that have been shared through a public ScorpionTrack location-share link. + +This integration is intentionally focused on the share-link workflow. It does not use your private ScorpionTrack account credentials. Instead, it reads the shared vehicle feed exposed by ScorpionTrack and creates `device_tracker` entities from that data, which appear on the Home Assistant map. + +## Prerequisites + +Before setting up the integration, you need: + +- A valid ScorpionTrack shared-location link +- At least one vehicle included in that share + +## Create a share link + +Create the share in the ScorpionTrack customer portal: + +1. Open the ScorpionTrack location share page at [app.scorpiontrack.com/customer/locationshare](https://app.scorpiontrack.com/customer/locationshare). +2. Create a new shared-location entry. +3. Add every vehicle you want Home Assistant to track. +4. Choose a suitable expiry time for the share. +5. Copy the generated share URL. + +You can paste either the full shared-location URL or just the token from that URL. + +{% include integrations/config_flow.md %} + +{% configuration_basic %} +Share URL or token: + description: "Paste the full ScorpionTrack shared-location URL or only the token from that URL." +{% endconfiguration_basic %} + +## Supported functionality + +The **ScorpionTrack** integration creates one {% term "device tracker" %} for each vehicle included in the share. + +Each tracker represents the vehicle directly on the Home Assistant map and in zone logic, using the latest GPS location reported through the ScorpionTrack share. The tracker name uses the vehicle registration when available, and otherwise falls back to the vehicle name from the ScorpionTrack share. + +## Data updates + +The **ScorpionTrack** integration {% term polling polls %} ScorpionTrack every 2 minutes for the latest shared vehicle position. + +## Known limitations + +- This integration only supports ScorpionTrack shared-location links. +- If the share expires or is revoked, the entities will become unavailable until a valid share is configured again. +- The update speed is limited by the polling interval and by how often ScorpionTrack updates the shared feed itself. + +## Troubleshooting + +### The integration says the share is invalid + +Make sure the shared-location link is still active in ScorpionTrack and that the token was copied correctly. If you pasted the full URL, verify that it is the actual share URL and not the customer portal page address. + +### No vehicles appear after setup + +Confirm that the ScorpionTrack share still includes vehicles and that the share has not expired. Home Assistant creates tracker entities for vehicles present in the share when the integration is set up or reloaded. If you add vehicles to the share later, reload or reconfigure the integration. + +## Removing the integration + +This integration follows standard integration removal. + +{% include integrations/remove_device_service.md %} diff --git a/source/_integrations/screenlogic.markdown b/source/_integrations/screenlogic.markdown index bc05134c94e9..e46bc965377f 100644 --- a/source/_integrations/screenlogic.markdown +++ b/source/_integrations/screenlogic.markdown @@ -30,10 +30,4 @@ The **Pentair ScreenLogic** {% term integration %} allows you to integrate your {% include integrations/config_flow.md %} -## Options - -ScreenLogic options are set via **Settings** > **Devices & services** > **Pentair ScreenLogic** > **Options**. - --= Seconds between scans - How many seconds between each polling of the ScreenLogic gateway. - {% include integrations/actions.md %} diff --git a/source/_integrations/sensor.markdown b/source/_integrations/sensor.markdown index 2cbeff902fb3..5b78237d5fd1 100644 --- a/source/_integrations/sensor.markdown +++ b/source/_integrations/sensor.markdown @@ -89,6 +89,7 @@ The following device classes are supported for sensors: - **precipitation**: Accumulated precipitation in cm, in or mm - **precipitation_intensity**: Precipitation intensity in in/d, in/h, mm/d or mm/h - **pressure**: Pressure in mPa, Pa, hPa, kPa, bar, cbar, mbar, mmHg, inHg, inH₂O or psi +- **radon**: Concentration of radon in Bq/m³ or pCi/L - **reactive_energy**: Reactive energy in varh or kvarh - **reactive_power**: Reactive power in mvar, var, or kvar - **signal_strength**: Signal strength in dB or dBm diff --git a/source/_integrations/shelly.markdown b/source/_integrations/shelly.markdown index 5b9e2ffcb790..8e572a278254 100644 --- a/source/_integrations/shelly.markdown +++ b/source/_integrations/shelly.markdown @@ -56,6 +56,8 @@ Host: description: "The Hostname or IP address of your Shelly device. You can find it in your router." Port: description: "Custom TCP port of the device. Change this only if the device is connected via Shelly Range Extender." +Verify SSL: + description: "Verify SSL/TLS certificate when connecting on HTTPS (port 443, Gen2+). Enable this only if the device uses a certificate signed by a certificate authority your Home Assistant instance trusts." {% endconfiguration_basic %} {% include integrations/option_flow.md %} @@ -71,6 +73,12 @@ There are four generations of devices and all generations are supported by this Shelly BLU series devices (e.g. Shelly BLU H&T) are not supported; please use BTHome integration to configure such devices with Home Assistant. The exception to this is Shelly BLU TRV, which is supported by this integration via Shelly BLU Gateway Gen3. +## Shelly Enhanced Security + +Enhanced Security is a firmware 2.0.0 feature for Gen2+ devices that enables additional security measures required for compliance with the Radio Equipment Directive (RED). When enabled, the device uses HTTPS and enforces secure communication. Devices shipped from factory with firmware 2.0.0+ come with HTTPS already enabled using certificates issued by Shelly's internal PKI. Devices that were updated to firmware 2.0.0+ (but not originally shipped with it) do not have factory-provisioned certificates and serve only plain HTTP by default, so you must upload your own certificate before using this feature. See [the official guide](https://shelly-api-docs.shelly.cloud/gen2/General/CustomHTTPSCertificates/) for instructions on creating and installing a certificate. + +The Shelly integration automatically detects whether Enhanced Security is enabled on the device and always communicates with that device over HTTPS using port 443. If you uploaded a certificate signed by a certificate authority your Home Assistant instance trusts, enable **Verify SSL**; otherwise, leave it disabled. + ## Data updates Shelly devices push updates to Home Assistant upon changes for all main functions of the device. For push updates to work correctly, some devices need additional configuration: diff --git a/source/_integrations/smlight.markdown b/source/_integrations/smlight.markdown index 54936a2736b5..2bea79d9b49c 100644 --- a/source/_integrations/smlight.markdown +++ b/source/_integrations/smlight.markdown @@ -141,7 +141,29 @@ SLZB-Ultima devices support additional peripherals not found on other SLZB adapt #### Infrared -- **IR Emitter**: This entity can be used by other integrations as an [Infrared](/integrations/infrared/) proxy to send IR commands through the SLZB-Ultima device. For example, you can use the [LG Infrared](/integrations/lg_infrared/) integration with this entity type to control your TV. +- **Infrared emitter** - Allows other integrations to send infrared commands. +- **Infrared receiver** - Allows other integrations to receive infrared signals. + +For more details, see the [Infrared integration](/integrations/infrared/). + +## Bluetooth remote adapter (proxy) + +SMLIGHT SLZB U-series devices running SLZB-OS can act as a Bluetooth remote adapter (proxy). They scan for and forward Bluetooth advertisement data to Home Assistant. + +To use the Bluetooth remote adapter, select a [scanning mode](/integrations/bluetooth/#scanning-modes) in the integration options: + +1. Go to {% my integrations title="**Settings** > **Devices & services**" %}. +2. Select **Configure** on the **SMLIGHT SLZB** card. +3. Select a **Bluetooth scanning mode**. + +Setting a mode other than **Disabled** automatically enables the Bluetooth remote adapter on the SMLIGHT device. + +{% tip %} +SMLIGHT devices do _not_ support proxying active (GATT) connections. +{% endtip %} + +For more details, see [Remote adapters (Bluetooth proxies)](/integrations/bluetooth/#remote-adapters-bluetooth-proxies) in the [Bluetooth integration](/integrations/bluetooth). + ## Actions {% include integrations/actions.md %} diff --git a/source/_integrations/sonarr.markdown b/source/_integrations/sonarr.markdown index e06dafea9e54..0fa781dae0b3 100644 --- a/source/_integrations/sonarr.markdown +++ b/source/_integrations/sonarr.markdown @@ -10,6 +10,7 @@ ha_config_flow: true ha_codeowners: - '@ctalkington' ha_platforms: + - calendar - sensor ha_integration_type: service --- @@ -25,6 +26,10 @@ API Key: description: Your Sonarr API key. To find it, open your Sonarr web interface and navigate to **Settings** > **General**. The API key is listed under the **Security** section. {% endconfiguration_basic %} +## Calendar + +A {% term calendar %} entity is created that shows your upcoming episodes. Each event is titled with the series name, the season and episode number, and the episode title, such as `Bob's Burgers - S04E11 - Easy Com-mercial, Easy Go-mercial`. Events are timed using the episode's air time and the series runtime. + ## Sensors The Sonarr integration will add the following sensors: diff --git a/source/_integrations/steam_online.markdown b/source/_integrations/steam_online.markdown index f5717cb49613..434b44f8e510 100644 --- a/source/_integrations/steam_online.markdown +++ b/source/_integrations/steam_online.markdown @@ -40,6 +40,46 @@ To find an account's 64-bit SteamID: 3. Select **Account details**. - Your **Steam ID** is displayed just below the label **Your-Account-Name Account**. + +## Supported functionality + +The **Steam** integration provides the following entities. + +### Sensors + +- **Primary sensor** + - **Name**: The Steam profile name of the account. + - **Description**: Represents the account's current presence status. + - **Available states**: + - Online + - Offline + - Away + - Busy + - Snooze + - Looking to play + - Looking to trade + - **Attributes**: + - **Account created**: The date and time when the Steam account was created. + - **Real name**: The user's real name, if provided on their Steam profile. + - **Level**: The current Steam level of the user. + - **Last online**: The date and time the Steam user was last seen online. + - **Game**: The title of the game the user is currently playing. + - **Game ID**: The Steam App ID of the currently played game. + - **Game image**: The URL of the logo image for the game the user is currently playing. + - **Game header image**: The URL of the header image for the game the user is currently playing. + - **Game icon**: The URL of the icon for the game the user is currently playing. + +- **Last online** + - **Description**: The date and time the Steam user was last seen online. + +- **Level** + - **Description**: The current Steam level of the user. + +- **Now playing** + - **Description**: The title of the game the user is currently playing. + - **Attributes**: + - **Steam App ID**: The Steam App ID of the currently played game. + ## Examples If you want to add the accounts to a group for example you will have to use: diff --git a/source/_integrations/stiebel_eltron.markdown b/source/_integrations/stiebel_eltron.markdown index e08070fb2f33..e1609c763493 100644 --- a/source/_integrations/stiebel_eltron.markdown +++ b/source/_integrations/stiebel_eltron.markdown @@ -47,37 +47,32 @@ The following HVAC modes are supported. The STIEBEL ELTRON modes are mapped and The following preset modes are supported. The STIEBEL ELTRON modes are mapped and configurable as follows: -- Eco mode (PRESET_ECO) -- Day mode (PRESET_DAY) -- Setback mode (PRESET_SETBACK) +- Standby mode (PRESET_READY) +- Setback mode (PRESET_ECO) +- Day mode (PRESET_COMFORT) +- Water heating mode (PRESET_WATER_HEATING) +- Automatic mode (PRESET_AUTO) +- Manual mode (PRESET_MANUAL) - Emergency mode (PRESET_EMERGENCY) -## Configuration +## Installation -To enable this integration, add the following lines to your {% term "`configuration.yaml`" %} file. -{% include integrations/restart_ha_after_config_inclusion.md %} +{% include integrations/config_flow.md %} -```yaml -# Example configuration.yaml entry -stiebel_eltron: - name: LWZ504e - host: IP_ADDRESS - port: 502 -``` - -{% configuration %} -name: - description: Displayed name of the unit. - required: false - default: Unnamed Device - type: string -host: - description: The hostname or IP of the stiebel eltron ISG. +{% configuration_basic %} +Host: + description: "The IP address of the ISG. You can find it in your router." required: true type: string -port: - description: The port of the stiebel eltron ISG. +Port: + description: The TCP port for Modbus. required: false default: 502 type: integer -{% endconfiguration %} +{% endconfiguration_basic %} + +## Removing the integration + +This integration follows standard integration removal. No extra steps are required. + +{% include integrations/remove_device_service.md %} diff --git a/source/_integrations/subaru.markdown b/source/_integrations/subaru.markdown index 9318716c1e1a..e48844c9c70f 100644 --- a/source/_integrations/subaru.markdown +++ b/source/_integrations/subaru.markdown @@ -54,17 +54,22 @@ If your account includes multiple vehicles, the same PIN will be used for all ve Available sensors will vary by model, year, and subscription type. The integration will add all supported sensors for your vehicle. Sensor data is usually only updated when the vehicle is turned off unless the [polling option](#options) is enabled. -| Sensor | Gen 1 | Gen 2 | Gen 3 | -|--------------------------|---------|---------|---------| -| Average fuel consumption | | ✓ | ✓ | -| Distance to empty | | ✓ | ✓ | -| EV battery level | | ✓ | ✓ | -| EV range | | ✓ | ✓ | -| EV time to full charge | | ✓ | ✓ | -| Odometer | ✓*| ✓ | ✓ | -| Tire pressures | | ✓ | ✓ | - -\* Gen 1 odometer only updates every 500 miles
+| Sensor | Gen 1 | Gen 2 | Gen 3 | +|-----------------------------------|----------|---------|---------| +| Average fuel consumption | | ✓ | ✓ | +| Distance to empty | | ✓ | ✓ | +| EV battery level | | ✓ | ✓ | +| EV range | | ✓ | ✓ | +| EV time to full charge | | ✓ | ✓ | +| Odometer | ✓* | ✓ | ✓ | +| Recommended tire pressure front | | ✓ | ✓ | +| Recommended tire pressure rear | | ✓ | ✓ | +| Tire pressures | | ✓ | ✓ | +| Vehicle state | | ✓ | ✓ | + +\* Gen 1 odometer only updates every 500 miles.
+ +EV sensors (EV battery level, EV range, EV time to full charge) are only present on PHEV vehicles. The recommended tire pressure sensors are disabled by default and may report `unknown` on older Gen 2 vehicles that do not advertise the underlying tire-pressure recommendation in `vehicle_health`. The vehicle state sensor reports one of `ignition_off`, `ignition_acc` (accessory power), `ignition_on`, or `engine_on_remote_start`; if your vehicle reports a value not in that list, please file a bug and attach the integration's diagnostics download. ## Lock diff --git a/source/_integrations/switchbot.markdown b/source/_integrations/switchbot.markdown index 051c32686e86..f3dcf599316b 100644 --- a/source/_integrations/switchbot.markdown +++ b/source/_integrations/switchbot.markdown @@ -155,6 +155,7 @@ For instructions on how to obtain the encryption key, see README in [PySwitchbot - [RGBICWW Strip Light](https://www.switch-bot.com/products/switchbot-rgbicww-strip-light) - [RGBICWW Floor Lamp](https://www.switch-bot.com/products/switchbot-rgbicww-floor-lamp) - [Permanent Outdoor Light](https://www.switch-bot.com/products/switchbot-permanent-outdoor-light) +- [Candle Warmer Lamp](https://www.switch-bot.com/products/switchbot-candle-warmer-lamp) ### Locks @@ -661,6 +662,15 @@ Features: - change color - set effect +#### Candle Warmer Lamp + +This is an encrypted device. + +Features: + +- turn on or off +- change brightness + ### Locks Note: The integration currently only uses the primary lock state; in dual lock mode, not all things might work properly. diff --git a/source/_integrations/telegram_bot.markdown b/source/_integrations/telegram_bot.markdown index 6e7aa1ee2d54..34d34eb97728 100644 --- a/source/_integrations/telegram_bot.markdown +++ b/source/_integrations/telegram_bot.markdown @@ -89,30 +89,17 @@ If you have a Home Assistant Cloud subscription, you can [enable remote access]( If your Home Assistant is behind a publicly accessible reverse proxy (for example NGINX, Caddy, Traefik) with HTTPS enabled, do the following: -1. Go to {% my network title="**Settings** > **System** > **Network**" %} and configure *Home Assistant URL*. -2. Configure the [HTTP integration](/integrations/http) to allow Home Assistant to accept connections from your reverse proxy: - - Set `use_x_forwarded_for` to `true`. - - Add the IP address of the reverse proxy to `trusted_proxies`. - -Example `configuration.yaml`: - -```yaml -http: - use_x_forwarded_for: true - trusted_proxies: - - 192.168.0.0/16 -``` +1. Go to {% my network title="**Settings** > **System** > **Network**" %} and configure **Home Assistant URL**. +2. In the **HTTP server** section, allow Home Assistant to accept connections from your reverse proxy: + - Turn on **Trust X-Forwarded-For**. + - Add the IP address or CIDR network of the reverse proxy to **Trusted proxies**. #### Direct If your Home Assistant is publicly accessible, do the following: -1. Go to {% my network title="**Settings** > **System** > **Network**" %} and configure *Home Assistant URL*. -2. Configure the [HTTP integration](/integrations/http) to enable HTTPS on your Home Assistant by configuring the following variables: - - `server_host` - - `server_port` - - `ssl_certificate` - - `ssl_key` +1. Go to {% my network title="**Settings** > **System** > **Network**" %} and configure **Home Assistant URL**. +2. In the **HTTP server** section, configure the settings needed for HTTPS, such as **Server port**, **Listen addresses**, **SSL certificate path**, and **SSL key path**. {% include integrations/config_flow.md %} diff --git a/source/_integrations/template.markdown b/source/_integrations/template.markdown index 22e21c1b1117..02c7019cc9e5 100644 --- a/source/_integrations/template.markdown +++ b/source/_integrations/template.markdown @@ -1135,7 +1135,7 @@ template: set_temperature: action: input_number.set_value data: - value: "{{ color_temp }}" + value: "{{ color_temp_kelvin }}" entity_id: input_number.temperature_input set_hs: - action: input_number.set_value @@ -1192,7 +1192,7 @@ template: set_temperature: action: input_number.set_value data: - value: "{{ color_temp }}" + value: "{{ color_temp_kelvin }}" entity_id: input_number.temperature_input set_hs: - action: input_number.set_value @@ -1365,7 +1365,7 @@ light: type: template default: false temperature: - description: Defines a template to get the color temperature of the light. The template must return the color temperature in mireds. If you are using a `color_temp_kelvin` attribute from another source, convert the value to mireds by dividing 1000000 by the `color_temp_kelvin` result. + description: Defines a template to get the color temperature of the light in Kelvin. The template must return a value between 2000 and 6535. required: false type: template default: optimistic diff --git a/source/_integrations/tesla_wall_connector.markdown b/source/_integrations/tesla_wall_connector.markdown index bd3e0f5f0e1d..a262340a3ee9 100644 --- a/source/_integrations/tesla_wall_connector.markdown +++ b/source/_integrations/tesla_wall_connector.markdown @@ -10,6 +10,7 @@ ha_iot_class: Local Polling ha_config_flow: true ha_codeowners: - '@einarhauks' + - '@sarabveer' ha_domain: tesla_wall_connector ha_dhcp: true ha_platforms: @@ -18,39 +19,67 @@ ha_platforms: ha_integration_type: device --- -The **Tesla Wall Connector** {% term integration %} allows you to integrate your Gen 3 [Tesla Wall Connector](https://www.tesla.com/support/home-charging-installation/wall-connector) with Wi-Fi into Home Assistant. +The **Tesla Wall Connector** {% term integration %} allows you to integrate your Gen 3 [Tesla Wall Connector](https://www.tesla.com/support/charging/wall-connector) with Wi-Fi into Home Assistant. {% include integrations/config_flow.md %} +{% configuration_basic %} +Host: + description: The hostname or IP address of your Tesla Wall Connector. +Single-phase / Split-phase electrical service: + description: Enable this option if your Wall Connector is powered by single-phase or split-phase electrical service. This affects the calculation of the **Total power** sensor. Leave it disabled for three-phase supply. Defaults to disabled. +{% endconfiguration_basic %} + +## Configuration options + +After setup, you can change the electrical service type. Go to {% my integrations title="**Settings** > **Devices & services**" %}, select the **Tesla Wall Connector** integration, and then select **Configure**. + +{% configuration_basic %} +Single-phase / Split-phase electrical service: + description: Enable this option if your Wall Connector is powered by single-phase or split-phase electrical service. This affects the calculation of the **Total power** sensor. Leave it disabled for three-phase supply. Defaults to disabled. +{% endconfiguration_basic %} + ## Supported functionality -### Entities - -The Tesla Wall Connector integration provides the following entities. - -#### Sensors -- **Energy** - Running total of energy used by the Wall Connector. -- **Session energy** - Energy used during the current charging session. -- **Status** - Present status of the Wall Connector. - - **Possible states** - booting, not_connected, connected, ready, negotiating, error, charging_finished, waiting_car, charging_reduced, charging -- **Contactor closed** - Binary sensor indicating if the Wall Connector is currently charging. -- **Grid frequency** - Sensor for grid frequency of the incoming AC power. -- **Grid voltage** - Sensor for grid voltage of the incoming AC power. -- **Handle temperature** - Sensor for temperature of the Wall Connector handle. -- **MCU temperature** - Sensor for temperature of the Wall Connector Main Computing Unit (MCU). -- **PCB temperature** - Sensor for temperature of the Wall Connector Power Control Board (PCB). -- **Phase current** - Sensor for the power current of each incoming AC electricity phase. -- **Phase voltage** - Sensor for the voltage of each incoming AC electricity phase. -- **Vehicle connected** - Binary sensor indicating if a vehicle is connected. -- **Status code** - Sensor for error codes generated by the Wall Connector. +The Tesla Wall Connector integration provides sensors and binary sensors that you can show on dashboards, use in automations, and add to the [Energy dashboard](/docs/energy/). + +### Sensors + +- **Lifetime energy**: Running total of energy used by the Wall Connector. +- **Session energy**: Energy used during the current charging session. +- **Status**: Present status of the Wall Connector. Possible states are **Booting**, **Vehicle not connected**, **Vehicle connected**, **Ready to charge**, **Negotiating connection**, **Error**, **Charging finished**, **Waiting for car**, **Charging (reduced)**, and **Charging**. +- **Grid frequency**: Grid frequency of the incoming AC power. +- **Grid voltage**: Grid voltage of the incoming AC power. +- **Handle temperature**: Temperature of the Wall Connector handle. +- **MCU temperature**: Temperature of the Wall Connector main computing unit. +- **PCB temperature**: Temperature of the Wall Connector power control board. +- **Phase A current**, **Phase B current**, and **Phase C current**: Current for each incoming AC electricity phase. +- **Phase A voltage**, **Phase B voltage**, and **Phase C voltage**: Voltage for each incoming AC electricity phase. +- **Total power**: Total power reported by the Wall Connector. If the Wall Connector uses single-phase or split-phase electrical service, enable **Single-phase / Split-phase electrical service** so Home Assistant calculates this sensor correctly. +- **Vehicle current**: Current being delivered to the connected vehicle. +- **Wi-Fi RSSI**: Wi-Fi signal strength reported by the Wall Connector. +- **Status code**: Error code generated by the Wall Connector. This diagnostic sensor is disabled by default. + +### Binary sensors + +- **Contactor closed**: Whether the Wall Connector is currently charging. +- **Vehicle connected**: Whether a vehicle is connected. + +### Device information + +The device page shows the Wall Connector model, model ID, serial number, and firmware version. + +## Data updates + +The Tesla Wall Connector integration {% term polling polls %} the device every 30 seconds. ## Energy dashboard -Energy usage can be easily added to the built-in [Energy dashboard](/docs/energy/) using the energy sensor. +Energy usage can be added to the built-in [Energy dashboard](/docs/energy/) using the **Lifetime energy** sensor. To add the Tesla Wall Connector to your Energy dashboard: -1. Navigate to **Settings** > **Dashboards** > **Energy**. +1. Go to {% my energy title="**Settings** > **Dashboards** > **Energy**" %}. 2. In the **Electricity grid** section, select **Add consumption**. -3. Select the Tesla Wall Connector's "Energy" sensor. +3. Select the Tesla Wall Connector **Lifetime energy** sensor. 4. Select **Save**. diff --git a/source/_integrations/teslemetry.markdown b/source/_integrations/teslemetry.markdown index fdf45fe5d9f6..1a011e9b04fc 100644 --- a/source/_integrations/teslemetry.markdown +++ b/source/_integrations/teslemetry.markdown @@ -143,6 +143,8 @@ Entities in the device tracker platform specifically require the `Vehicle locati |Media player|Media player|Yes| |Number|Charge current|Yes| |Number|Charge limit|Yes| +|Select|Seat cooler front left|Yes| +|Select|Seat cooler front right|Yes| |Select|Seat heater front left|Yes| |Select|Seat heater front right|Yes| |Select|Seat heater rear center|No| diff --git a/source/_integrations/tessie.markdown b/source/_integrations/tessie.markdown index f35961afc8e4..7dc131714417 100644 --- a/source/_integrations/tessie.markdown +++ b/source/_integrations/tessie.markdown @@ -11,7 +11,10 @@ ha_category: - Lock - Media Player - Number + - Select - Sensor + - Switch + - Text - Update ha_release: 2024.1 ha_iot_class: Cloud Polling @@ -32,6 +35,7 @@ ha_platforms: - select - sensor - switch + - text - update ha_integration_type: hub ha_quality_scale: silver @@ -52,6 +56,7 @@ This integration provides comprehensive control and monitoring of your Tesla veh - Enable Sentry mode, valet mode, and defrost mode - Flash lights, honk horn, and trigger HomeLink - Track vehicle location and navigation destination +- Send a navigation destination to the vehicle - Install software updates ### Energy product monitoring and control @@ -275,6 +280,12 @@ The integration will create switch entities to control various aspects of your v - Steering wheel heater - Valet mode +### Text + +The integration will create a text entity to send a navigation destination to the vehicle: + +- Navigation destination + ### Update The integration will show vehicle software updates and their installation progress. Updates can only be installed from Home Assistant after they have finished downloading. diff --git a/source/_integrations/unifiprotect.markdown b/source/_integrations/unifiprotect.markdown index eb44ace932c3..e04a054d017a 100644 --- a/source/_integrations/unifiprotect.markdown +++ b/source/_integrations/unifiprotect.markdown @@ -163,6 +163,8 @@ Each UniFi Protect floodlight will get a device in Home Assistant with the follo UniFi Protect smart sensors are a bit different than normal sensors. They are a multi-sensor that can act as a contact sensor (door/window), a motion detector, a light level detector, a humidity sensor, a temperature level sensor, an alarm sound sensor, and/or a leak detector. Each sensor function can be enabled or disabled dynamically. Disabled sensors will be marked as "unavailable". +On UniFi Protect versions newer than 7.1, UniFi Protect reports each sensor's capabilities, and entities are only created for the functions the device actually supports. This enables proper support for newer sensor models: for example, an entry sensor (USL Entry) gets contact and tamper entities, an environmental sensor (USL Environmental) gets temperature, humidity, light level, and leak entities, and a glass break sensor (USL GlassBreak) gets motion and tamper entities. On older versions, an entity is created for every function, matching the behavior of the original UniFi Protect Smart Sensor (UP Sense). + - **Sensors** - A sensor is provided for each major function of the smart sensor device: - **Contact** - A contact sensor will be available if the mount type is set as "Door", "Window" or "Garage". - **Motion Detection** - A motion detection sensor will be available if the mount type is not set to "Leak" and motion detection is enabled. @@ -170,6 +172,7 @@ UniFi Protect smart sensors are a bit different than normal sensors. They are a - **Humidity** - A humidity sensor will be available if the mount type is not set to "Leak" and the humidity sensor is enabled. - **Temperature** - A temperature sensor will be available if the mount type is not set to "Leak" and the temperature sensor is enabled. - **Alarm Sound** - An alarm sensor will be available if the mount type is not set to "Leak" and the alarm sound sensor is enabled. The Alarm Sound sensor can have the values "none", "smoke" and "co". More values may be added over time automatically as UniFi Protect adds support for detecting more alarms. + - **Leak** - A moisture sensor will be available if the mount type is set to "Leak", or (on UniFi Protect versions newer than 7.1) if the sensor supports water leak detection and leak detection is enabled. - **Tamper** - A binary sensor to detect tampering. - **Device Configuration** - Smart sensors will get configuration controls for the Status Light, enabling/disabling all of the main sensors, selecting the Paired Camera, and changing the Mount Type of the sensor. - **Button** - A button to clear the tampered state as well as a disabled by default button to restart the device. diff --git a/source/_integrations/upnp.markdown b/source/_integrations/upnp.markdown index d91749f9b35d..683f3e58eb15 100644 --- a/source/_integrations/upnp.markdown +++ b/source/_integrations/upnp.markdown @@ -33,7 +33,22 @@ UPnP or NAT-PMP needs to be enabled on your router for this {% term integration Some UPnP/IGD devices have a broken UPnP implementation and will provide invalid data or no data at all. A configuration option is provided to fall back to polling of all data for the sensors. Please try this when you feel not all sensors which should be working are working. -## Debugging integration +## Troubleshooting + +### Traffic counters not handling rollover properly + +Routers keep a running total of the data passing through them. This total is stored in a counter that has a maximum value. Once the total reaches that maximum, the counter resets to zero and starts counting again. This reset is called a _rollover_. The **Download speed**, **Upload speed**, **Packet download speed**, and **Packet upload speed** sensors correct for it so the speed stays accurate when a counter wraps. + +Some routers don't report these counters correctly, and the correction can misfire, causing a sudden, large spike. If you see these spikes, switch to the matching sensors that skip the correction and instead report `unavailable` when a rollover is detected: + +- **Download speed (no rollover handling)** +- **Upload speed (no rollover handling)** +- **Packet download speed (no rollover handling)** +- **Packet upload speed (no rollover handling)** + +These sensors are disabled by default. Enable them from the integration's device page, and optionally disable the original speed sensors. + +### Debugging the integration If you have problems with this {% term integration %} you can add debug prints to the log. diff --git a/source/_integrations/v2c.markdown b/source/_integrations/v2c.markdown index d01cea35311f..b05d24520f2d 100644 --- a/source/_integrations/v2c.markdown +++ b/source/_integrations/v2c.markdown @@ -14,6 +14,7 @@ ha_platforms: - diagnostics - light - number + - select - sensor - switch ha_integration_type: device @@ -26,6 +27,7 @@ There is currently support for the following platforms within Home Assistant: - [Binary sensor](#binary-sensor) - [Sensor](#sensor) - [Number](#number) +- [Select](#select) - [Light](#light) - [Switch](#switch) @@ -61,6 +63,11 @@ The V2C integration currently exposes the following number entity: - intensity: current used to charge your vehicle +## Select + +The V2C integration currently exposes the following select entity: + +- charge_mode: Sets the charger mode to either single-phase or three-phase. ## Light The V2C integration currently exposes the following lights: diff --git a/source/_integrations/velux.markdown b/source/_integrations/velux.markdown index 672f93fddea6..d20509eeb3b4 100644 --- a/source/_integrations/velux.markdown +++ b/source/_integrations/velux.markdown @@ -36,7 +36,7 @@ There is currently support for the following device types within Home Assistant: - Button (Reboot button on the gateway device to reboot the KLF 200 gateway) - Cover - Light -- Number (controls the power level of exterior heating devices connected to the gateway, from 0% to 100%) +- Number - Scene - Switch @@ -65,6 +65,10 @@ Password: Remember: You must complete the configuration within 5 minutes of rebooting the KLF 200 gateway. If you can't complete in time and setup fails, power cycle the device and try again. +## Known limitations + +The number entities for the window opening limitation and the rain sensor binary sensor use the same data from the gateway. If you set the opening limitation to 11% or less, the rain sensor can show as wet even when no rain is detected. + ## Removing the integration This integration follows standard integration removal. No extra steps are required. diff --git a/source/_integrations/vibration.markdown b/source/_integrations/vibration.markdown new file mode 100644 index 000000000000..e1758d443b59 --- /dev/null +++ b/source/_integrations/vibration.markdown @@ -0,0 +1,18 @@ +--- +title: Vibration +description: This integration provides vibration automation triggers and conditions. +ha_category: + - Automation +ha_release: 2026.8 +ha_quality_scale: internal +ha_codeowners: + - '@home-assistant/core' +ha_domain: vibration +ha_integration_type: system +--- + +This {% term integration %} provides automation triggers and conditions for binary sensors with device class vibration. There are no configuration options for this integration. + +{% include integrations/triggers.md %} + +{% include integrations/conditions.md %} diff --git a/source/_integrations/vizio.markdown b/source/_integrations/vizio.markdown index 56898c199d8f..147f755cfdf7 100644 --- a/source/_integrations/vizio.markdown +++ b/source/_integrations/vizio.markdown @@ -217,45 +217,45 @@ pyvizio --ip=0 get-apps-list ## Remote -The VIZIO SmartCast integration automatically creates a remote entity for each configured device (TVs and speakers). You can use it to send remote control commands via the `remote.send_command` action. Commands are case-insensitive. +The VIZIO SmartCast integration automatically creates a remote entity for each configured device (TVs and speakers). You can use it to send remote control commands via the `remote.send_command` action. Commands are case-insensitive. You can use either the native key name (for example, `vol_up`) or a human-friendly alias (for example, `volume_up`). ### Available commands #### TV commands -| Command | -| :------ | -| `back` | -| `cc_toggle` | -| `ch_down` | -| `ch_prev` | -| `ch_up` | -| `down` | -| `exit` | -| `home` | -| `info` | -| `input_next` | -| `left` | -| `left2` | -| `menu` | -| `mute_off` | -| `mute_on` | -| `mute_toggle` | -| `ok` | -| `pause` | -| `pic_mode` | -| `pic_size` | -| `play` | -| `pow_off` | -| `pow_on` | -| `pow_toggle` | -| `right` | -| `seek_back` | -| `seek_fwd` | -| `smartcast` | -| `up` | -| `vol_down` | -| `vol_up` | +| Command | Additional aliases | +| :------ | :------ | +| `back` | | +| `cc_toggle` | `closed_captions`, `cc` | +| `ch_down` | `channel_down` | +| `ch_prev` | `previous_channel` | +| `ch_up` | `channel_up` | +| `down` | | +| `exit` | | +| `home` | | +| `info` | | +| `input_next` | `next_input` | +| `left` | | +| `left2` | | +| `menu` | | +| `mute_off` | | +| `mute_on` | | +| `mute_toggle` | `mute`, `toggle_mute` | +| `ok` | `enter`, `select` | +| `pause` | | +| `pic_mode` | `picture_mode` | +| `pic_size` | `picture_size` | +| `play` | | +| `pow_off` | `off`, `power_off` | +| `pow_on` | `on`, `power_on` | +| `pow_toggle` | `power_toggle`, `toggle_power`, `power` | +| `right` | | +| `seek_back` | `reverse`, `rewind` | +| `seek_fwd` | `forward`, `fast_forward`, `ff` | +| `smartcast` | | +| `up` | | +| `vol_down` | `volume_down` | +| `vol_up` | `volume_up` | #### Speaker commands @@ -263,6 +263,8 @@ Speakers support a subset of the commands above: `mute_off`, `mute_on`, `mute_toggle`, `pause`, `play`, `pow_off`, `pow_on`, `pow_toggle`, `vol_down`, `vol_up` +Aliases that map to these commands (for example, `mute`, `volume_up`, `on`, `off`) also work on speakers. + ### Examples Send a single command: @@ -297,7 +299,7 @@ target: entity_id: remote.vizio_smartcast data: command: - - vol_up + - volume_up num_repeats: 5 delay_secs: 0.4 ``` diff --git a/source/_integrations/weatherflow.markdown b/source/_integrations/weatherflow.markdown index 56ad6a8299ad..e080279dfde6 100644 --- a/source/_integrations/weatherflow.markdown +++ b/source/_integrations/weatherflow.markdown @@ -37,44 +37,114 @@ There are two integrations for WeatherFlow devices, and you are not limited to s This {% term integration %} will expose the following sensors: -- Air density -- Air pressure -- Dew point -- Feels like -- Humidity -- Illuminance -- Irradiance -- Lightning average distance -- Lightning count -- Precipitation (accumulated over the previous minute) -- Precipitation intensity ([extrapolated](https://weatherflow.github.io/Tempest/api/derived-metric-formulas.html#rain-rate) from the accumulation over the previous minute) -- Precipitation type -- Temperature -- UV index -- Vapor pressure -- Wet bulb temperature -- Wind direction -- Wind direction average -- Wind gust -- Wind lull -- Wind speed - -## Event entity - -The WeatherFlow Tempest station also sends out event triggers when it starts raining and when there is a lightning strike near by. -This {% term integration %} will expose these {% term event %} {% term entities %} and can be used for automations. The following entities will be exposed: - -- Lightning strike -- Precipitation start - -## Diagnostic sensors +### Atmospheric sensors + +- **Air density** + - **Description**: The mass per unit volume of Earth’s atmosphere. + +- **Air pressure** + - **Description**: The atmospheric pressure at the station level. + +- **Dew point** + - **Description**: The temperature to which air must be cooled to become saturated with water vapor. + +- **Feels like** + - **Description**: An index that combines temperature and humidity to determine the apparent temperature. + +- **Humidity** + - **Description**: Percentage of moisture in the air relative to the maximum it can hold at the current temperature. + +- **Temperature** + - **Description**: The degree or intensity of heat present in the area. + +- **Vapor pressure** + - **Description**: Pressure exerted by water vapor in the air (absolute moisture content). + +- **Wet bulb temperature** + - **Description**: The lowest temperature that can be reached under current ambient conditions by the evaporation of water only. + +### Wind sensors + +- **Wind direction** + - **Description**: Wind direction relative to the station direction. + +- **Wind direction average** + - **Description**: Wind direction average. + +- **Wind gust** + - **Description**: Wind gusts over a maximum 3 second sample. + +- **Wind lull** + - **Description**: Wind lull over a minimum 3 second sample. + +- **Wind speed** + - **Description**: Wind speed at the station. + +### Precipitation sensors + +- **Precipitation** + - **Description**: Precipitation (accumulated over the previous minute). + +- **Precipitation intensity** + - **Description**: Precipitation intensity ([extrapolated](https://weatherflow.github.io/Tempest/api/derived-metric-formulas.html#rain-rate) from the accumulation over the previous minute). + +- **Precipitation type** + - **Description**: Precipitation type (`none`, `rain`, `hail`, `rain_hail`). + +### Lightning sensors + +- **Lightning average distance** + - **Description**: Average distance of recently detected lightning strikes. + +- **Lightning count** + - **Description**: Count of lightning strikes in the past minute. + +- **Lightning last distance** + - **Description**: Distance to the most recent detected lightning strike. + +- **Lightning last energy** + - **Description**: Energy estimate for the most recent detected lightning strike, as reported by the station. + +- **Lightning last strike** + - **Description**: Timestamp of the most recent detected lightning strike; unlike the `Lightning strike` event entity below, this sensor stores the last recorded strike time. + +### Solar and light sensors + +- **Illuminance** + - **Description**: Amount of visible light received, measured in lux. + +- **Irradiance** + - **Description**: Total solar radiation received, measured in W/m². + +- **UV index** + - **Description**: Intensity of ultraviolet radiation received. + +### Diagnostic sensors Additionally the following diagnostic sensors are available: -- Battery (percentage) -- Battery voltage -- Signal strength -- Uptime +- **Battery (percentage)** + - **Description**: Station battery (percentage). + +- **Battery voltage** + - **Description**: Battery voltage of station. + +- **Signal strength** + - **Description**: Signal strength between station and hub. + +- **Uptime** + - **Description**: Uptime of station. + +## Event entities + +The WeatherFlow Tempest station also sends event triggers when it starts raining and when there is a lightning strike nearby. +This {% term integration %} will expose these {% term event %} {% term entities %} and can be used for automations. The following entities will be exposed: + +- **Lightning strike** + - **Description**: Fires when lightning strikes within range of station. + +- **Precipitation start** + - **Description**: Fires when precipitation starts at the station. ## Networking notes diff --git a/source/_integrations/whirlpool.markdown b/source/_integrations/whirlpool.markdown index ca390397be44..f00ff6610ac0 100644 --- a/source/_integrations/whirlpool.markdown +++ b/source/_integrations/whirlpool.markdown @@ -5,6 +5,8 @@ ha_category: - Button - Climate - Hub + - Light + - Number - Select ha_release: '2022.10' ha_iot_class: Cloud Push @@ -18,6 +20,8 @@ ha_platforms: - button - climate - diagnostics + - light + - number - select - sensor ha_integration_type: hub @@ -71,10 +75,12 @@ This {% term integration %} maps appliances to entities in Home Assistant. A sin - [Binary Sensor](#binary-sensor) - [Button](#button) - [Climate](#climate) +- [Light](#light) +- [Number](#number) - [Select](#select) - [Sensor](#sensor) -### Binary Sensor +### Binary sensor The binary sensor platform provides the following functionality: @@ -98,12 +104,34 @@ The following actions are also available: - [**fan mode**](/integrations/climate/#action-set-fan-mode) (`low`, `medium`, `high`) - [**swing mode**](/integrations/climate/#action-set-swing-mode) (`off`, `horizontal`) +### Light + +The light platform provides the following functionality: + +- turn an oven cavity light on or off + +Ovens with two cavities have separate light entities for the upper and lower cavity. + +### Number + +The number platform provides the following entity for ovens: + +- **Target temperature**: Sets the target temperature for an oven cavity, keeping the current cooking mode. + +{% important %} +If the oven is idle, setting the target temperature starts a bake cycle at the set temperature. +{% endimportant %} + ### Select The select platform provides the following entity for refrigerators: - **Temperature level**: Sets the temperature level of the refrigerator. The available options are `-4 °C`, `-2 °C`, `0 °C`, `3 °C`, and `5 °C`. +The select platform provides the following entity for ovens: + +- **Cook mode**: Sets the cook mode of an oven cavity, keeping the current target temperature. Selecting `Standby` turns the oven off by stopping the current cook. + ### Sensor The `whirlpool` sensor platform integrates Whirlpool Washer and Dryer systems into Home Assistant, allowing views of the machine state, time remaining, and the "wash & go" tank fill status as sensors for each device. diff --git a/source/_integrations/wmspro.markdown b/source/_integrations/wmspro.markdown index c8c34f3cc480..12e0a63ca584 100644 --- a/source/_integrations/wmspro.markdown +++ b/source/_integrations/wmspro.markdown @@ -43,24 +43,30 @@ See device section for support information: [buttons](#buttons), [covers](#cover The WMS WebControl pro *may* also be discovered on your local network via DHCP. -## Buttons +{% include integrations/actions.md %} + +## Supported functionality + +The **WMS WebControl pro** integration provides the following entities. + +### Buttons - All devices that support an identification activity (for example, winking an awning or blinking a light) can be triggered to perform such activity. -## Covers +### Covers - *Awnings*, *volant awnings* (vertical drop sun shades), and *roller shutters/blinds* can be opened, closed, set to a certain position, and stopped. - *Slat-based blinds* can additionally have their slats rotated open, closed, or to a specific rotation angle. -### Rotation support +#### Rotation support Home Assistant treats the slat rotation as a linear scale from fully open to fully closed. The integration uses the maximum rotation angle as the fully closed position, but the minimum (opposite) angle is not treated as fully open. Instead when you set the slats to the open position in Home Assistant, they move to the position where the slats are parallel to the ground as expected. You can change the minimum and maximum rotation angles via configuration [number](#numbers) entities or [automatic learning](#automatic-learning). -## Lights +### Lights - Dimmers (with brightness control) and switches are fully supported. -## Numbers +### Numbers - *Slat-based blinds* have configuration entities to overwrite the minimum and maximum rotation angle. This is required as the WMS WebControl pro currently reports invalid minimum and maximum rotation values. @@ -69,15 +75,21 @@ Home Assistant treats the slat rotation as a linear scale from fully open to ful - *Slat-based covers* like roofs that only have rotation, but not position control, only have this entity. For covers with rotation only, this entity appears as the main control. -### Automatic learning +#### Automatic learning The number entities persist across Home Assistant restarts. They are updated automatically on slat rotation to allow automatic learning of the valid rotation range based on the current rotation angle. For learning, it is sufficient to rotate *slat-based blinds* to both end positions while Home Assistant is connected and wait until the position has updated. -## Scenes +### Scenes - Scenes can be activated, but not changed or monitored. - Scenes are accessible via a virtual device per room. -## Switches +### Switches - Load switches (for example, a connected heater) can be turned on and off. + +## Removing the integration + +This integration follows standard integration removal. No extra steps are required. + +{% include integrations/remove_device_service.md %} diff --git a/source/_integrations/yardian.markdown b/source/_integrations/yardian.markdown index 5cc4adc8a51e..391065d09236 100644 --- a/source/_integrations/yardian.markdown +++ b/source/_integrations/yardian.markdown @@ -13,6 +13,7 @@ ha_codeowners: ha_domain: yardian ha_platforms: - binary_sensor + - button - sensor - switch ha_integration_type: device @@ -42,5 +43,10 @@ The **Yardian** integration provides the following entities. - **Freeze prevent**: Turns on when the controller enables freeze prevention. - **Zone enabled**: `On` if a zone is enabled. These entities are disabled by default and created per zone. +### Button + +- **Stop all irrigation**: Enabled by default. Pressing this button entity will immediately stop any currently active zone. + +## Actions {% include integrations/actions.md %} diff --git a/source/_redirects b/source/_redirects index dde189d3a25e..0afb62c44c19 100644 --- a/source/_redirects +++ b/source/_redirects @@ -37,6 +37,7 @@ layout: null # Design & User research /join-chat-design https://discord.com/channels/330944238910963714/1475553148847526123 +/surveys/onboarding https://usabi.li/do/i39njudc3tl7/ksqzg8 # Older development pages /developers https://developers.home-assistant.io @@ -660,6 +661,7 @@ layout: null /integrations/plum_lightpad /more-info/removed-integration 301 /integrations/postnl /more-info/removed-integration 301 /integrations/prezzibenzina /more-info/removed-integration 301 +/integrations/permobil /more-info/removed-integration 301 /integrations/ptvsd /more-info/removed-integration 301 /integrations/pushetta /more-info/removed-integration 301 /integrations/raspihats /more-info/removed-integration 301 diff --git a/source/_triggers/moon.phase_changed.markdown b/source/_triggers/moon.phase_changed.markdown new file mode 100644 index 000000000000..c07c9cd31a3f --- /dev/null +++ b/source/_triggers/moon.phase_changed.markdown @@ -0,0 +1,103 @@ +--- +title: "Moon phase changed" +trigger: moon.phase_changed +domain: moon +description: "Triggers when the moon enters a new phase." +--- + +The **Moon phase changed** trigger fires when the moon moves into a new phase, such as from waxing gibbous to full moon. Home Assistant works the phase out from the date, so the trigger needs no account, no internet connection, and no location. + +Use it to follow the rhythm of the lunar month in your home, for example to send a notification on the night of a full moon, play a scene at every new moon, or start a garden routine when the moon reaches its first quarter. + +{% include triggers/ui_header.md %} + +To use this trigger in an automation: + +1. Go to {% my automations title="**Settings** > **Automations & scenes**" %}. +2. Open an existing automation, or select **Create automation** > **Create new automation**. +3. In the **When** section, select **Add trigger**. +4. From the search box, search for and select **Moon phase changed**. +5. Under **Phase**, keep **Any** to trigger on every phase change, or select a single phase to trigger only when the moon enters that phase. +6. Select **Save**. + +### Options in the UI + +{% options_ui %} +Phase: + description: | + Which phase change fires the trigger: + + - **Any**: every time the moon enters a new phase. This is the default. + - A specific phase, such as **Full moon** or **New moon**: only when the moon enters that phase. +{% endoptions_ui %} + +{% include triggers/yaml_header.md %} + +In YAML, refer to this trigger as `moon.phase_changed`. A basic example looks like this: + +{% example %} +trigger: | + trigger: moon.phase_changed +{% endexample %} + +This fires whenever the phase changes. To trigger on a single phase, add the `phase` option: + +{% example %} +trigger: | + trigger: moon.phase_changed + options: + phase: full_moon +{% endexample %} + +### Options in YAML + +{% options_yaml %} +phase: + description: > + Limits the trigger to a single moon phase. Accepts `any` (every phase change) or one of `new_moon`, `waxing_crescent`, `first_quarter`, `waxing_gibbous`, `full_moon`, `waning_gibbous`, `last_quarter`, or `waning_crescent`. + required: false + type: string + default: any +{% endoptions_yaml %} + +## Good to know + +- This trigger does not use a target. It follows the moon phase, which is the same everywhere on Earth, so it does not depend on your [home location](/docs/configuration/basic/). +- The phase is based on the date, so the trigger fires at most once a day, when the phase changes. +- With a specific phase selected, the trigger fires the moment the moon enters that phase, not for the whole time the moon stays in it. To check whether the moon is currently in a phase, use a [state condition](/docs/scripts/conditions/#state-condition) for `sensor.moon` instead. + +{% include triggers/try_it.md %} + +For this trigger, there is no target entity to change. To test it, wait for the next phase change, or temporarily switch to a trigger you can control while you build the rest of the automation. + +{% include triggers/more_examples.md %} + +### Automation: run a scene on the full moon + +When the moon turns full, activate a moonlit scene in the living room. + +- **Trigger**: Moon phase changed + - **Phase**: Full moon +- **Action**: Activate scene + - **Target**: Full moon scene + +{% details "YAML example for a full moon scene" %} + +{% example %} +automation: | + alias: "Full moon scene" + triggers: + - trigger: moon.phase_changed + options: + phase: full_moon + actions: + - action: scene.turn_on + target: + entity_id: scene.full_moon +{% endexample %} + +{% enddetails %} + +{% include triggers/stuck.md %} + +{% include triggers/related.md %} diff --git a/source/_triggers/vibration.cleared.markdown b/source/_triggers/vibration.cleared.markdown new file mode 100644 index 000000000000..c01da4e35d9b --- /dev/null +++ b/source/_triggers/vibration.cleared.markdown @@ -0,0 +1,130 @@ +--- +title: "Vibration cleared" +trigger: vibration.cleared +domain: vibration +description: "Triggers when one or more vibration sensors stop detecting vibration." +related_triggers: + - vibration.detected +--- + +The **Vibration cleared** trigger fires when one or more vibration sensors stop detecting vibration. + +Use it to automate actions when something stops shaking or moving, such as sending a notification when a washing machine finishes its cycle, or when a running appliance goes quiet. Use a single sensor for one object and a group of sensors to cover several at once. + +{% include triggers/ui_header.md %} + +To use this trigger in an automation: + +1. Go to {% my automations title="**Settings** > **Automations & scenes**" %}. +2. Open an existing automation, or select **Create automation** > **Create new automation**. +3. In the **When** section, select **Add trigger**. +4. From the search box, search for and select **Vibration cleared**. +5. Select **Add target** (see [Targets](#targets)) and pick the vibration sensor that you want to watch. You can also select an area, a floor, a device, or a label. +6. Under **Trigger when** (see [Behavior](#behavior-with-multiple-targets)), pick **Each**, **First**, or **All** to control how the trigger behaves when multiple sensors are targeted. +7. Under **For at least**, you can set how long the sensor must stay without detecting vibration before the trigger fires. Leave it at zero to fire immediately. +8. Select **Save**. + +### Options in the UI + +{% options_ui %} +Trigger when: + description: | + When multiple vibration sensors are targeted, controls when the trigger fires: + + - **Each** (default): fires every time any targeted sensor stops detecting vibration. + - **First**: fires only when the first sensor stops detecting vibration. + - **All**: fires only after every targeted sensor stops detecting vibration. + required: false +For at least: + description: How long the sensor or sensors must stay without detecting vibration before the trigger fires. The default is `0` hours, `00` minutes and `00` seconds (fires immediately). + required: false +{% endoptions_ui %} + +{% include triggers/yaml_header.md %} + +In YAML, refer to this trigger as `vibration.cleared`. A basic example looks like this: + +{% example %} +trigger: | + trigger: vibration.cleared + target: + entity_id: binary_sensor.washing_machine_vibration + options: + for: + minutes: 5 +{% endexample %} + +This fires 5 minutes after the sensor entity `binary_sensor.washing_machine_vibration` stops detecting vibration. + +### Options in YAML + +YAML sometimes provides additional options for more complex use cases that are not available through the UI. + +{% options_yaml %} +behavior: + description: | + When multiple vibration sensors are targeted, controls when the trigger fires: + + - `each`: fires every time any targeted sensor stops detecting vibration. + - `first`: fires only when the first sensor stops detecting vibration. + - `all`: fires only after every targeted sensor stops detecting vibration. + required: false + type: string + default: each +for: + description: | + How long the sensor or sensors must stay without detecting vibration before the trigger fires. Accepts a duration string in `HH:MM:SS` format or a time period mapping in hours, minutes and seconds. + required: false + type: string + default: "00:00:00" +{% endoptions_yaml %} + +{% include triggers/targets.md %} + +{% include triggers/behavior.md %} + +## Good to know + +- A washing machine or dryer often pauses between stages of its cycle. Set **For at least** to a few minutes to avoid a false "finished" notification during those pauses. +- Pair this trigger with [Vibration detected](/triggers/vibration.detected/) to track both when a machine starts and when it stops. + +{% include triggers/try_it.md %} + +{% include triggers/more_examples.md %} + +### Automation: notify when the washing machine finishes + +When the washing machine's vibration sensor stops detecting vibration for 5 minutes, this automation sends a notification that the laundry is done. + +- **Trigger**: Vibration cleared + - **Target**: Washing machine vibration sensor + - **For at least**: 00:05:00 +- **Action**: Send a notification message + - **Target**: My device (`notify.my_device`) + +{% details "YAML example for a laundry-done notification" %} + +{% example %} +automation: | + alias: "Notify when the washing machine finishes" + triggers: + - trigger: vibration.cleared + target: + entity_id: binary_sensor.washing_machine_vibration + options: + for: + minutes: 5 + actions: + - action: notify.send_message + target: + entity_id: notify.my_device + data: + message: > + The washing machine has finished. Time to hang the laundry. +{% endexample %} + +{% enddetails %} + +{% include triggers/stuck.md %} + +{% include triggers/related.md %} diff --git a/source/_triggers/vibration.detected.markdown b/source/_triggers/vibration.detected.markdown new file mode 100644 index 000000000000..137b48a92069 --- /dev/null +++ b/source/_triggers/vibration.detected.markdown @@ -0,0 +1,129 @@ +--- +title: "Vibration detected" +trigger: vibration.detected +domain: vibration +description: "Triggers when one or more vibration sensors start detecting vibration." +related_triggers: + - vibration.cleared +--- + +The **Vibration detected** trigger fires when one or more vibration sensors start detecting vibration. + +Use it to automate actions, such as turning devices on or off, or sending notifications, when something starts to shake or move. For example, react to a knock on a door, an appliance that starts running, or a package being moved. Use a single sensor for one object and a group of sensors to cover several at once. + +{% include triggers/ui_header.md %} + +To use this trigger in an automation: + +1. Go to {% my automations title="**Settings** > **Automations & scenes**" %}. +2. Open an existing automation, or select **Create automation** > **Create new automation**. +3. In the **When** section, select **Add trigger**. +4. From the search box, search for and select **Vibration detected**. +5. Select **Add target** (see [Targets](#targets)) and pick the vibration sensor that you want to watch. You can also select an area, a floor, a device, or a label. +6. Under **Trigger when** (see [Behavior](#behavior-with-multiple-targets)), pick **Each**, **First**, or **All** to control how the trigger behaves when multiple sensors are targeted. +7. Under **For at least**, you can set how long the sensor must keep detecting vibration before the trigger fires. Leave it at zero to fire immediately. +8. Select **Save**. + +### Options in the UI + +{% options_ui %} +Trigger when: + description: | + When multiple vibration sensors are targeted, controls when the trigger fires: + + - **Each** (default): fires every time any targeted sensor starts detecting vibration. + - **First**: fires only when the first sensor starts detecting vibration. + - **All**: fires only after every targeted sensor starts detecting vibration. + required: false +For at least: + description: How long the sensor or sensors must keep detecting vibration before the trigger fires. The default is `0` hours, `00` minutes and `00` seconds (fires immediately). + required: false +{% endoptions_ui %} + +{% include triggers/yaml_header.md %} + +In YAML, refer to this trigger as `vibration.detected`. A basic example looks like this: + +{% example %} +trigger: | + trigger: vibration.detected + target: + entity_id: binary_sensor.washing_machine_vibration + options: + for: + minutes: 1 +{% endexample %} + +This fires 1 minute after the sensor entity `binary_sensor.washing_machine_vibration` starts detecting vibration. + +### Options in YAML + +YAML sometimes provides additional options for more complex use cases that are not available through the UI. + +{% options_yaml %} +behavior: + description: | + When multiple vibration sensors are targeted, controls when the trigger fires: + + - `each`: fires every time any targeted sensor starts detecting vibration. + - `first`: fires only when the first sensor starts detecting vibration. + - `all`: fires only after every targeted sensor starts detecting vibration. + required: false + type: string + default: each +for: + description: | + How long the sensor or sensors must keep detecting vibration before the trigger fires. Accepts a duration string in `HH:MM:SS` format or a time period mapping in hours, minutes and seconds. + required: false + type: string + default: "00:00:00" +{% endoptions_yaml %} + +{% include triggers/targets.md %} + +{% include triggers/behavior.md %} + +## Good to know + +- Vibration sensors are well suited to detecting when an appliance starts running, a knock on a door, or an object being moved or tampered with. +- Add the **For at least** option to avoid firing on brief, one-off vibrations, such as a passing truck or a nearby door closing. +- To cover several machines or a large object at once, target multiple vibration sensors and use the **Trigger when** option to decide whether the trigger fires for each sensor or only once they all detect vibration. + +{% include triggers/try_it.md %} + +{% include triggers/more_examples.md %} + +### Automation: turn on the porch light when someone knocks at night + +When the vibration sensor on the front door detects a knock late in the evening, this automation turns on the porch light. + +- **Trigger**: Vibration detected + - **Target**: Front door vibration sensor +- **Condition**: Time (after 22:00:00 and before 06:00:00) +- **Action**: Turn on light + - **Target**: Porch light + +{% details "YAML example for turning on the porch light on a knock at night" %} + +{% example %} +automation: | + alias: "Porch light on a knock at night" + triggers: + - trigger: vibration.detected + target: + entity_id: binary_sensor.front_door_vibration + conditions: + - condition: time + after: "22:00:00" + before: "06:00:00" + actions: + - action: light.turn_on + target: + entity_id: light.porch +{% endexample %} + +{% enddetails %} + +{% include triggers/stuck.md %} + +{% include triggers/related.md %} diff --git a/source/images/integrations/enphase_envoy/enphase_envoy_automatic_token.png b/source/images/integrations/enphase_envoy/enphase_envoy_automatic_token.png new file mode 100644 index 000000000000..47f542c3e03d Binary files /dev/null and b/source/images/integrations/enphase_envoy/enphase_envoy_automatic_token.png differ diff --git a/source/images/integrations/enphase_envoy/enphase_envoy_manual_token_entry.png b/source/images/integrations/enphase_envoy/enphase_envoy_manual_token_entry.png new file mode 100644 index 000000000000..e3c47f37cbe6 Binary files /dev/null and b/source/images/integrations/enphase_envoy/enphase_envoy_manual_token_entry.png differ diff --git a/source/images/integrations/enphase_envoy/enphase_envoy_token_lifetime_action_ui.png b/source/images/integrations/enphase_envoy/enphase_envoy_token_lifetime_action_ui.png new file mode 100644 index 000000000000..523223b5cd5a Binary files /dev/null and b/source/images/integrations/enphase_envoy/enphase_envoy_token_lifetime_action_ui.png differ diff --git a/source/images/integrations/led_infrared/13-key.png b/source/images/integrations/led_infrared/13-key.png new file mode 100644 index 000000000000..6c167c7e49a0 Binary files /dev/null and b/source/images/integrations/led_infrared/13-key.png differ diff --git a/source/images/integrations/led_infrared/24-key.png b/source/images/integrations/led_infrared/24-key.png new file mode 100644 index 000000000000..f2cf14b272c4 Binary files /dev/null and b/source/images/integrations/led_infrared/24-key.png differ