source/_integrations/generic_thermostat.markdown (2)

85-89: Prefer “before” over “prior to” for brevity
The phrase “must change prior to being switched on” is a bit wordy. Consider replacing “prior to” with “before” for clearer, more concise documentation.

-description: Set a minimum amount of difference between the temperature read by the sensor specified in the *target_sensor* option and the target temperature that must change prior to being switched on. For example, if the target temperature is 25 and the tolerance is 0.5, the heater will start when the sensor goes below 24.5.
+description: Set a minimum amount of difference between the temperature read by the sensor specified in the *target_sensor* option and the target temperature that must change before being switched on. For example, if the target temperature is 25 and the tolerance is 0.5, the heater will start when the sensor goes below 24.5.

🧰 Tools

🪛 LanguageTool

[style] ~86-~86: ‘prior to’ might be wordy. Consider a shorter alternative.
Context: ...the target temperature that must change prior to being switched on. For example, if the ...

(EN_WORDINESS_PREMIUM_PRIOR_TO)

---

90-93: Add comma in hot_tolerance example for consistency
The cold_tolerance example includes a comma after the tolerance value, improving readability. For consistency, add a comma in the hot_tolerance example as well.

-hot_tolerance:
-  description: Set a minimum amount of difference between the temperature read by the sensor specified in the *target_sensor* option and the target temperature that must change prior to being switched off. For example, if the target temperature is 25 and the tolerance is 0.5 the heater will stop when the sensor equals or goes above 25.5.
+hot_tolerance:
+  description: Set a minimum amount of difference between the temperature read by the sensor specified in the *target_sensor* option and the target temperature that must change prior to being switched off. For example, if the target temperature is 25 and the tolerance is 0.5, the heater will stop when the sensor equals or goes above 25.5.

🧰 Tools

🪛 LanguageTool

[style] ~91-~91: ‘prior to’ might be wordy. Consider a shorter alternative.
Context: ...the target temperature that must change prior to being switched off. For example, if the...

(EN_WORDINESS_PREMIUM_PRIOR_TO)

source/_integrations/overkiz.markdown (1)

90-91: Align configuration key styling and add token guidance
The "Token": key is quoted while Verify SSL: is not—this is inconsistent with the cloud API snippet above. Either quote all keys or none. Also consider clarifying that this developer token is case‐sensitive and must be entered exactly as generated by the app.

source/_integrations/google_travel_time.markdown (2)

23-23: Confirm update frequency and call estimate: The sensor update interval has been changed to 10 minutes (≈144 calls/day), which is correct. Consider noting how daylight savings or timezone shifts might affect daily call counts.

---

25-25: Enhance quota guidance: Recommending an 'Elements per day' limit of 161 aligns with the free usage tier. You may want to add a brief note on how to monitor current usage and quotas via the Google Cloud Console.

source/_integrations/mcp.markdown (2)

32-35: Clarify numbering and indentation in prerequisites

The newly added third prerequisite item (3. If your MCP server requires authentication…) is helpful, but the multi-line formatting of item 2 versus the single-line item 3 looks inconsistent. Consider reformatting for clarity and uniform indentation:

-2. If your MCP server only supports the <abbr title="Standard input/output">*stdio*</abbr> protocol, you will also need an additional
-   MCP proxy (such as [mcp-proxy](https://github.com/sparfenyuk/mcp-proxy)) to expose
-   the server over <abbr title="Server-sent events">*SSE*</abbr>.
-3. If your MCP server requires authentication, then you will need an OAuth Client ID and Secret.
+2. If your MCP server only supports the <abbr title="Standard input/output">*stdio*</abbr> protocol, you will also need an
+   MCP proxy (such as [mcp-proxy](https://github.com/sparfenyuk/mcp-proxy)) to expose the server over
+   <abbr title="Server-sent events">*SSE*</abbr>.
+3. If your MCP server requires authentication, you will need:
+   - An OAuth Client ID
+   - An OAuth Client Secret

This ensures both items use consistent wrapping and indenting.

---

82-87: Enhance the Authorization subsection with step-by-step guidance

The new ### Authorization block conveys the right information, but users will benefit from explicit steps and a direct link to creating application credentials. For example:

### Authorization

The Model Context Protocol supports OAuth and allows Home Assistant to access restricted MCP servers. To configure:

1. Create Application Credentials in your Home Assistant user profile  
   ([Learn more](/integrations/application_credentials/)).
2. Provide the **client_id** and **client_secret** under the MCP integration’s configuration.

This format guides users through setup with less cognitive overhead.

source/_integrations/google_gemini.markdown (1)

9-11: Unify codeowners quoting style.
Other integration metadata files typically list codeowners without quotes. To maintain consistency and avoid unnecessary quoting in YAML, consider removing the quotes around the GitHub handles.

- ha_codeowners:
-   - '@tronikos'
-   - '@ivanlh'
+ ha_codeowners:
+   - @tronikos
+   - @ivanlh

source/_integrations/weheat.markdown (2)

49-49: Format and clarify the new sensor entry.
The sensor name is missing a colon and a unit of measurement, which deviates from the style of other entries and may confuse users.

- - **Central heating flow** The flow volume of the central heating pump
+ - **Central heating flow**: The flow volume of the central heating pump in liters per minute

---

58-58: Include unit for the DHW pump flow sensor.
All other sensors list their measurement units; please add the appropriate unit here for consistency.

- - **DHW pump flow**: The flow volume of the DHW pump (optional)
+ - **DHW pump flow**: The flow volume of the DHW pump in liters per minute (optional)

source/_integrations/opower.markdown (3)

45-51: New utilities added: ensure consistent ordering and linking

The entries for "Glendale Water and Power (GWP)" and the "National Grid US subsidiaries" group are alphabetically placed correctly. Consider adding direct links to their respective integration pages (e.g., /integrations/glendale_water_power/ and /integrations/national_grid_us/) and verifying that the domain names match those pages.

---

129-133: Clarify placeholder usage in steps

Steps 1–4 introduce {utility name} and {account number} placeholders. To maintain consistency across the documentation, define these placeholders at the top of the section or link to a reference that explains them.

---

134-141: Verify details block formatting and context

The {% details %} block for "Track return to grid energy and compensation" is correctly implemented. Ensure the introductory context is sufficient and that list indentation renders as expected in the final build.

source/_integrations/national_grid_us.markdown (1)

20-21: Enhance integration guidance

This file currently embeds only integrations/supported_brand.md. Consider adding a brief introduction or a link to the Opower integration setup steps to guide users on prerequisites and configuration.

source/_dashboards/gauge.markdown (2)

42-45: Refine wording in attribute description.
Add the article “the” for clarity:

- description: Attribute from the selected entity to display
+ description: The attribute of the selected entity to display

---

205-215: Example of attribute usage is clear.
The new example correctly demonstrates displaying battery_level instead of the main state. Consider adding a screenshot to match other examples.

🧰 Tools

🪛 LanguageTool

[uncategorized] ~206-~206: The grammatical number of this noun doesn’t look right. Consider replacing it.
Context: ... color: var(--error-color) Display attribute of an entity instead of its state: ...

(AI_EN_LECTOR_REPLACEMENT_NOUN_NUMBER)

source/_dashboards/picture-glance.markdown (1)

75-79: Introduce fit_mode option correctly
The new fit_mode parameter is well-documented with valid modes (cover, contain, fill), a default, and clear behavior.

• Consider aligning with other card docs by explicitly listing allowed values under an enum key instead of only in the description.
• You may also add a short YAML usage example for fit_mode in the Examples section to illustrate its effect.

source/_dashboards/energy.markdown (1)

247-274: Validate Sankey card YAML schema section
The added configuration block follows the established pattern (type, required, description, type, default) nicely. A few enhancements to consider:

1. Explicitly declare allowed values for layout using an enum key rather than embedding them in the description.
2. Indicate if layout has a default (if not, state “no default”).
3. Ensure blank lines before/after match surrounding sections for consistency.

Example diff for layout enum:

  layout:
    required: false
-   description: "`vertical` or `horizontal`. Determines the orientation (flow direction) of the card"
+   description: "Determines the orientation (flow direction) of the card"
    type: string
+   enum:
+     - vertical
+     - horizontal

source/_integrations/rehlko.markdown (1)

23-34: Consistent configuration block and spacing

• Verify that the {% configuration_basic %} macro name matches the standard template—some integrations use configuration-basic.
• Remove extra blank lines inside the block for cleaner presentation.

 {% configuration_basic %}
-email:
-  description: "The email used to log in to the Rehlko (Kohler Energy Management) application."
-
-password:
-  description: "The password used to log in to the Rehlko (Kohler Energy Management) application."
+email:
+  description: "The email used to log in to the Rehlko (Kohler Energy Management) application."
+password:
+  description: "The password used to log in to the Rehlko (Kohler Energy Management) application."
 {% endconfiguration_basic %}

source/_includes/common-tasks/backups.md (2)

46-50: Refine step description to imperative voice
Consider rephrasing to maintain consistency in instructional tone. For example:

-5. Define if you want to back up automatically before updating.
+5. Choose whether to back up automatically before updating.

---

53-57: Avoid weak intensifier in description
To improve clarity, remove "quite" from the sentence:

-  - Some add-ons may also be quite large.
+  - Some add-ons may also be large.

🧰 Tools

🪛 LanguageTool

[style] ~56-~56: As an alternative to the over-used intensifier ‘quite’, consider replacing this phrase.
Context: ... restore. - Some add-ons may also be quite large. 8. [Define the location for backups](#...

(EN_WEAK_ADJECTIVE)

source/_integrations/s3.markdown (2)

1-4: Correct verb usage and article in front matter
In the description, use the verb "set up" and include the article "an":

-description: Instructions on how to setup S3 bucket to be used as a backup location.
+description: Instructions on how to set up an S3 bucket to be used as a backup location.

---

15-18: Use singular term and include article in introduction
Adjust phrasing to match other integrations and add the missing article:

-The **S3** {% term integrations %} allows you to use S3 bucket with Home Assistant Backups.
+The **S3** {% term integration %} allows you to use an S3 bucket as a backup location for Home Assistant.

source/_integrations/fritz.markdown (2)

73-74: Document default for network device tracking
To make the out-of-the-box behavior explicit, consider adding a default: value (e.g., default: true) for this option. This helps users understand whether tracking is enabled by default.

---

84-85: Consistency check for duplicated option
The Enable network device tracking setting is repeated in the options flow. Please verify that its description—and any default you add—match the config flow entry exactly to avoid drift during future updates.

source/_integrations/heos.markdown (2)

132-152: Fix Markdown table formatting in heos.move_queue_item.
The delimiter row has leading spaces and misaligned columns, which will break rendering. It should match the style of other tables (no spaces before the dashes and aligned to the header width).

@@ -148,7 +148,7 @@
 | Data attribute | Optional | Description                                                     |
-| ---------------------- | -------- | ------------------------------------------------------- |
+|------------------|----------|---------------------------------------------------------------|
 | `queue_ids`            | no       | The IDs (indexes) of the items in the queue to move.    |
 | `destination_position` | no       | The destination position in the queue (starting at 1).  |

---

153-170: Fix Markdown table formatting in heos.remove_from_queue.
The delimiter row here also has leading spaces and misaligned columns. Align it under the header to ensure proper rendering.

@@ -167,7 +167,7 @@
 | Data attribute | Optional | Description                                                     |
-| ---------------------- | -------- | ------------------------------------------------------- |
+|------------------|----------|---------------------------------------------------------------|
 | `queue_ids`            | no       | The IDs (indexes) of the items in the queue to remove.   |

source/_integrations/teslemetry.markdown (2)

54-54: Enhance visibility of scope requirement
The new note about needing the Vehicle location scope is valuable. To improve readability, consider converting this into a standard callout using the Home Assistant admonition format, for example:

> **Note:** Device tracker entities require the `Vehicle location` scope and will appear unavailable otherwise.

---

67-119: Ensure consistent ordering and accuracy of Binary Sensors
A large batch of binary_sensor entities was added across Vehicles and Energy sites. Please verify:

• The Enabled column accurately reflects default availability in the integration code.
• Entity names precisely match the Tesla API naming and Home Assistant conventions.
• Entries are alphabetized within each domain section for easier maintenance.

Also applies to: 253-253

🧰 Tools

🪛 LanguageTool

[duplication] ~73-~73: Possible typo: you repeated a word.
Context: ...inary sensor|Dashcam|No| |Binary sensor|DC DC|No| |Binary sensor|Defrost for precondi...

(ENGLISH_WORD_REPEAT_RULE)

---

[uncategorized] ~106-~106: Did you mean the adjective “Right-hand”?
Context: ... sensor|Remote start|No| |Binary sensor|Right hand drive|No| |Binary sensor|Scheduled char...

(MISSING_HYPHEN)

source/_integrations/ntfy.markdown (3)

1-15: Frontmatter: use correct ha_iot_class value and string literal for release
The field ha_iot_class should match the expected schema (snake_case), e.g. cloud_push instead of Cloud Push. Additionally, quoting ha_release (e.g. "2025.5") will ensure it’s treated as a string rather than a float by the YAML parser.

---

59-70: Consistent indentation in configuration_basic
Descriptions in the {% configuration_basic %} block are indented 4 spaces here; standard practice is 2 spaces for key/value pairs.

---

72-80: Align topic parameters indentation
Similar to the service parameters, use 2-space indentation in the {% configuration_basic %} block for consistency across docs.

source/_integrations/zimi.markdown (3)

88-90: Capitalize headings consistently

For consistency with other integration docs, title case section headings. Change ### Zimi cover controller to ### Zimi Cover Controller.

---

92-94: Capitalize headings consistently

Change ### Zimi light controller to ### Zimi Light Controller to maintain title case for section headings.

---

119-121: Use en dash for numeric ranges

In (typically more than 3-5 requests within a few minutes), replace the hyphen with an en dash for typographic correctness:

-(typically more than 3-5 requests within a few minutes)
+(typically more than 3–5 requests within a few minutes)

🧰 Tools

🪛 LanguageTool

[typographical] ~120-~120: If specifying a range, consider using an en dash instead of a hyphen.
Context: ...xceed these limits (typically more than 3-5 requests within a few minutes), the dev...

(HYPHEN_TO_EN)

source/_integrations/govee_ble.markdown (1)

44-44: Approve new device support addition.

The H5110 Hygrometer Thermometer has been correctly added to the supported devices list.

Consider adding a hyperlink to the H5110 product page (if available) for consistency with other entries that link to the manufacturer’s site.

source/_integrations/vesync.markdown (1)

165-166: Remove extra blank line to comply with markdownlint MD012.

There are two consecutive blank lines before the “## Binary Sensors” section. Please reduce this to a single blank line to satisfy the no-multiple-blanks rule.

🧰 Tools

🪛 markdownlint-cli2 (0.17.2)

165-165: Multiple consecutive blank lines
Expected: 1; Actual: 2

(MD012, no-multiple-blanks)

source/_integrations/ohme.markdown (2)

148-156: Fix blank lines around “Use cases” heading
There are two consecutive blank lines before the ## Use cases header. Reduce to a single blank line to satisfy markdown lint rules (MD012).

Apply this diff:

-161  
-
-## Use cases
+161  
+## Use cases

(Note: ensure exactly one blank line above the heading.)

🧰 Tools

🪛 markdownlint-cli2 (0.17.2)

152-152: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below

(MD022, blanks-around-headings)

---

154-154: Lists should be surrounded by blank lines
null

(MD032, blanks-around-lists)

---

168-181: Surround fenced code block with blank lines
Per MD031, add a blank line before and after the yaml fence inside the raw block for proper rendering.

-167   {% raw %}
-168   ```yaml
+167  
+168   {% raw %}
+169   
+170   ```yaml
...  
-178   message: "Vehicle plugged in"
-179   ```
-180   {% endraw %}
+184   ```
+185  
+186   {% endraw %}

🧰 Tools

🪛 markdownlint-cli2 (0.17.2)

169-169: Fenced code blocks should be surrounded by blank lines
null

(MD031, blanks-around-fences)

---

180-180: Fenced code blocks should be surrounded by blank lines
null

(MD031, blanks-around-fences)

source/_integrations/miele.markdown (2)

102-102: Fix grammar in binary sensor description
Revise to include the definite article and correct verb agreement.

-**Full remote control**: Shows the state of Full remote control feature on appliances that supports it.
+**Full remote control**: Shows the state of the Full remote control feature on appliances that support it.

🧰 Tools

🪛 LanguageTool

[uncategorized] ~102-~102: You might be missing the article “the” here.
Context: ...ll remote control**: Shows the state of Full remote control feature on appliances th...

(AI_EN_LECTOR_MISSING_DETERMINER_THE)

---

156-156: Remove unnecessary comma
Eliminate the comma before “if configured” for smoother phrasing.

-**Start in**: Shows the number of minutes until a delayed program start, if configured.
+**Start in**: Shows the number of minutes until a delayed program start if configured.

source/_integrations/esphome.markdown (1)

156-157: Clarify terminology and emphasize key terms.
The bullet reads "friendly name (or name if unset)"—it may be clearer to specify that name refers to the ESPHome device's name configuration. Consider bolding Entity name and Entity ID for consistency with other sections.

source/_integrations/lamarzocco.markdown (1)

96-99: Binary sensors table revised.
Introducing WebSocket connected and consolidating all sensors to cloud retrieval fits the cloud-push model. Additionally, hyphenate "real-time updates" in the WebSocket connected description for consistency:

- Track your connection to the cloud WebSocket for real time updates.
+ Track your connection to the cloud WebSocket for real-time updates.

🧰 Tools

🪛 LanguageTool

[uncategorized] ~99-~99: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...r connection to the cloud WebSocket for real time updates. | all | {% icon "material-sy...

(EN_COMPOUND_ADJECTIVE_INTERNAL)

source/_integrations/imeon_inverter.markdown (7)

25-25: Correct typo in prerequisites.

The word “pannel” is misspelled. It should read “panel”.

-*ModuleAPI* application must be activated on the OS One pannel of your Imeon inverter.
+*ModuleAPI* application must be activated on the OS One panel of your Imeon inverter.

---

26-26: Fix nested list indentation.

The nested bullet under prerequisites is over-indented by one space.

-   - To do so, connect to **OS One** > **Applications** and by hovering over *ModuleAPI*, select **Activate**.
+  - To do so, connect to **OS One** > **Applications** and by hovering over *ModuleAPI*, select **Activate**.

🧰 Tools

🪛 markdownlint-cli2 (0.17.2)

26-26: Unordered list indentation
Expected: 2; Actual: 3

(MD007, ul-indent)

---

39-39: Avoid split infinitive in sensor description.

Rephrase to eliminate the split infinitive for clarity.

-| `battery_charge_time`| Time required to fully charge the battery.             | None   |
+| `battery_charge_time`| Time to fully charge the battery.                       | None   |

🧰 Tools

🪛 LanguageTool

[style] ~39-~39: Style-wise, it’s not ideal to insert an adverb in the middle of an infinitive construction.
Context: ... None | | battery_charge_time| Time required to fully charge the battery. | None | | `battery_powe...

(SPLIT_INFINITIVE)

---

58-59: Unify table header capitalization.

Two tables use “Sensor Key” while others use “Sensor key”. For consistency, lowercase “key” in these headers:

-| Sensor Key           | Description            | Unit   |
+| Sensor key           | Description            | Unit   |
...
-| Sensor Key           | Description                        | Unit   |
+| Sensor key           | Description                        | Unit   |

Also applies to: 97-98

---

140-142: Remove extra blank line before heading.

There are two blank lines before “### What is my domain name?”—reduce to one, and trim trailing space on the heading:

- 
-### What is my domain name? 
+### What is my domain name?

🧰 Tools

🪛 markdownlint-cli2 (0.17.2)

141-141: Multiple consecutive blank lines
Expected: 1; Actual: 2

(MD012, no-multiple-blanks)

---

142-142: Trailing spaces
Expected: 0 or 2; Actual: 1

(MD009, no-trailing-spaces)

---

142-142: Trim trailing spaces.

Lines 142 and 144 have unnecessary trailing spaces. Remove them:

-### What is my domain name? 
+### What is my domain name?

-The domain name is the internal name given to your inverter by Home Assistant. It's based on the initial name you gave to your device, albeit formatted to avoid internal issues.  
+The domain name is the internal name given to your inverter by Home Assistant. It's based on the initial name you gave to your device, albeit formatted to avoid internal issues.

Also applies to: 144-144

🧰 Tools

🪛 markdownlint-cli2 (0.17.2)

142-142: Trailing spaces
Expected: 0 or 2; Actual: 1

(MD009, no-trailing-spaces)

---

145-146: Outdent and surround list items with blank lines.

List items under the “What is my domain name?” heading should be top-level bullets and separated by blank lines for readability:

-
-   - A name such as `Imeon Inverter number 57` would give you a domain name of `imeon_inverter_number_57`.
-   - If you're still struggling to find the domain name, check the internal name of the entities under the device. The name of each variable is `DOMAIN_variable-name`, for example `neo_110_inverter_software_version` tells us the domain name is `neo_110`.
+
+- A name such as `Imeon Inverter number 57` would give you a domain name of `imeon_inverter_number_57`.
+
+- If you're still struggling to find the domain name, check the internal name of the entities under the device. The name of each variable is `DOMAIN_variable-name`, for example `neo_110_inverter_software_version` tells us the domain name is `neo_110`.

🧰 Tools

🪛 markdownlint-cli2 (0.17.2)

145-145: Unordered list indentation
Expected: 0; Actual: 3

(MD007, ul-indent)

---

145-145: Lists should be surrounded by blank lines
null

(MD032, blanks-around-lists)

---

146-146: Unordered list indentation
Expected: 0; Actual: 3

(MD007, ul-indent)

source/_integrations/squeezebox.markdown (1)

172-178: Consolidate Binary sensors headings
You have both ### Binary sensors and a nested #### Binary sensors heading. This duplication can be confusing. Consider removing the extra #### Binary sensors and keeping a single level.

Example diff:

-### Binary sensors
-
-The integration provides the following entities.
-#### Binary sensors
+### Binary sensors
+The integration provides the following entities.

source/_integrations/home_connect.markdown (1)

22-22: Remove trailing whitespace
Line 22 has a trailing space that triggers MD009. Please remove the extra space at the end of the line.

source/_integrations/nuki.markdown (1)

2-4: Refine description pronoun usage
The frontmatter and opening paragraph use “their Smart Lock devices.” Consider using “your Smart Lock devices” for a more direct user-centric tone.

Suggested diff:

- title: Nuki Bridge
- description: Instructions on how to integrate a Nuki Bridge to control their Smart Lock devices.
+ title: Nuki Bridge
+ description: Instructions on how to integrate a Nuki Bridge to control your Smart Lock devices.

-The Nuki integration allows you to control their Smart Lock devices via a Nuki Bridge.
+The Nuki integration allows you to control your Smart Lock devices via a Nuki Bridge.

Also applies to: 22-23

source/_integrations/nuki_matter.markdown (2)

3-3: Remove trailing period in description.
Other integration docs omit a trailing period in description. For consistency, consider removing the period at the end of this line.

---

15-16: Prefix metadata keys consistently.
The works_with key lacks the ha_ prefix used by other metadata keys (e.g., ha_iot_standard). Please verify if it should be ha_works_with to maintain naming consistency.

source/_integrations/balay.markdown (2)

1-33: Ensure consistent file extension
Other Home Assistant integration docs use the .md extension (balay.md). Please verify that .markdown files are picked up by the site's build pipeline, or consider renaming this file to balay.md for consistency.

---

33-36: Add a brief configuration or usage example
Since this integration uses a config flow, consider adding a “## Configuration” section or a short note about how to link your Home Connect account via the UI. A minimal snippet or description will help users get started without needing to search elsewhere.

source/_integrations/reolink.markdown (1)

235-235: ⚠️ Potential issue

Ensure options and notation are consistent for the new select entity.

The entry for Recording packing time currently omits the list of selectable values and the * (disabled by default) or + (push updates) markers used elsewhere. Please update to include:

• The supported options in parentheses (e.g., (Off, On, …)).
• A + if it supports push updates or * if it’s disabled by default.

Without this, readers won’t know what values to choose or the entity’s default state.

source/_integrations/google_gemini.markdown (1)

21-21: ⚠️ Potential issue

Fix include path to supported brands snippet.
The include reference currently points to integrations/supported_brand.md, but the actual include file in _includes is named supported-brands.markdown. This mismatch will cause a build error.

Apply this diff:

- {% include integrations/supported_brand.md %}
+ {% include integrations/supported-brands.markdown %}

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

{% include integrations/supported-brands.markdown %}

source/_integrations/weheat.markdown (1)

57-57: ⚠️ Potential issue

Fix mismatched quotation in sensor name.
There's an extra double-quote disrupting the bold formatting for “DHW bottom temperature.”

- - **DHW bottom temperature"**: The domestic hot water temperature in the bottom of the vessel in °C (optional)
+ - **DHW bottom temperature**: The domestic hot water temperature in the bottom of the vessel in °C (optional)

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

- **DHW bottom temperature**: The domestic hot water temperature in the bottom of the vessel in °C (optional)

source/_integrations/template.markdown (1)

49-49: ⚠️ Potential issue

Missing mention of “covers” (and “lights”) in the introductory sentence.
The sentence “Sensors, binary (on/off) sensors, buttons, images, numbers, selects, and switches are covered on this page.” should include covers (and potentially lights) to reflect the new support.

Please update to something like:

- Sensors, binary (on/off) sensors, buttons, images, numbers, selects, and switches are covered on this page.
+ Sensors, binary (on/off) sensors, covers, buttons, images, numbers, selects, lights, and switches are covered on this page.

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Sensors, binary (on/off) sensors, covers, buttons, images, numbers, selects, lights, and switches are covered on this page.
They can be configured using [UI](#configuration) or [YAML](#yaml-configuration) file.

source/_dashboards/energy.markdown (1)

15-15: 🛠️ Refactor suggestion

Verify Jinja directive for config link
Line 15 uses {% my config_energy title="energy configuration page" %}, which differs from other docs’ {% config_energy %} helper syntax. Please confirm the correct macro name – likely it should be:

You can configure them on the {% config_energy title="energy configuration page" %}.

source/_integrations/rehlko.markdown (1)

1-17: ⚠️ Potential issue

Front Matter: Remove incorrect ha_dhcp field
The ha_dhcp: true attribute is reserved for integrations that support DHCP-based discovery, which this cloud-polling integration does not. Keeping it may cause the documentation build to fail or mislead readers about discovery capabilities.

Apply this diff to remove the line:

@@ -11,1 +11,0 @@
-ha_dhcp: true

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

---
title: Rehlko
description: Support for Rehlko devices (formerly Oncue and Kohler Energy)
ha_category:
  - Sensor
ha_iot_class: Cloud Polling
ha_release: 2025.5
ha_config_flow: true
ha_codeowners:
  - '@bdraco'
  - '@peterager'
ha_domain: rehlko
ha_platforms:
  - sensor
ha_integration_type: integration
---

source/_integrations/teslemetry.markdown (1)

153-169: 🛠️ Refactor suggestion

Add units and descriptions for Sensor entities
The new sensor entities cover detailed drive inverter metrics and battery parameters. To aid users, consider:

• Documenting units (e.g., V, A, °C, kW) next to each sensor name or in a footnote.
• Including a brief description of what each sensor measures if the name isn’t self-explanatory.
• Verifying each sensor’s YAML key matches the underlying API field (e.g., secondary_drive_unit_torque_command).

Also applies to: 174-182, 189-196, 202-212, 217-217, 236-236

source/_integrations/zimi.markdown (3)

5-5: 🛠️ Refactor suggestion

Use snake_case for ha_iot_class values

Per Home Assistant documentation standards, the ha_iot_class key should use snake_case. Change Local Push to local_push.

---

10-11: 🛠️ Refactor suggestion

Include 'Cover' in ha_category

This integration supports cover entities (e.g., Blind Controller, Garage Door Controller). Please add Cover to the ha_category list.

---

13-14: 🛠️ Refactor suggestion

List all supported ha_platforms

Currently only light is specified, but this integration creates cover, switch, fan, and outlet entities. Consider adding cover, switch, fan, and outlet to the ha_platforms list.

source/_integrations/imeon_inverter.markdown (1)

10-12: ⚠️ Potential issue

Fix YAML frontmatter list indentation.

The ha_codeowners list item is not indented under the key, causing invalid frontmatter YAML.
Apply this diff:

-ha_codeowners:
-@Imeon-Energy
+ha_codeowners:
+  - '@Imeon-Energy'

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

ha_codeowners:
  - '@Imeon-Energy'
ha_domain: imeon_inverter

source/_integrations/whirlpool.markdown (2)

55-55: ⚠️ Potential issue

Fix anchor link for Binary Sensor
The link uses #binary_sensor, but the generated anchor is #binary-sensor. Update it to avoid broken navigation.

Apply this diff:

-  - [Binary Sensor](#binary_sensor)
+  - [Binary Sensor](#binary-sensor)

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

  - [Binary Sensor](#binary-sensor)

---

59-64: 🛠️ Refactor suggestion

Document Diagnostics platform or remove from metadata
The ha_platforms list includes diagnostics, but there’s no Diagnostics section here. Either remove diagnostics if it’s not user-facing or add documentation for it.

Example diff to add Diagnostics:

@@ -55,3 +55,4
-  - [Sensor](#sensor)
+  - [Sensor](#sensor)
+  - [Diagnostics](#diagnostics)

@@ -64 +65,68 @@
 ### Sensor

+### Diagnostics
+
+The diagnostics platform adds a Diagnostics entry under Developer Tools → Diagnostics, showing integration state and configuration for deeper troubleshooting.

Committable suggestion skipped: line range outside the PR's diff.

source/_integrations/homee.markdown (1)

15-15: 🛠️ Refactor suggestion

Missing documentation for new Climate platform support
The frontmatter now includes climate, but there’s no section describing the climate entities or available actions. Please add a "## Climate" section under Supported functionality (or an appropriate spot) to document its features.

Would you like help drafting the climate platform documentation?

source/_integrations/bosch_alarm.markdown (1)

6-6: ⚠️ Potential issue

Remove 'Sensor' from ha_category
The ha_category frontmatter is for integration grouping; entity types belong in ha_platforms. Please remove - Sensor from ha_category.

source/_integrations/gaggenau.markdown (1)

4-12: ⚠️ Potential issue

Mismatch between ha_category and ha_platforms
diagnostics is included under ha_platforms but missing in ha_category. To maintain consistency, add - Diagnostics to the ha_category section.
Proposed diff:

@@ -4,12 +4,13
 ha_category:
   - Binary sensor
   - Button
   - Hub
   - Light
   - Number
   - Select
   - Sensor
   - Switch
+  - Diagnostics

Also applies to: 22-29

source/_integrations/profilo.markdown (1)

4-12: ⚠️ Potential issue

Inconsistent category listing
The ha_platforms list contains diagnostics, yet ha_category does not. Please include - Diagnostics under ha_category to mirror the platforms.
Proposed diff:

@@ -4,12 +4,13
 ha_category:
   - Binary sensor
   - Button
   - Hub
   - Light
   - Number
   - Select
   - Sensor
   - Switch
+  - Diagnostics

Also applies to: 21-29

source/_integrations/constructa.markdown (1)

4-12: ⚠️ Potential issue

Ensure categories match platforms
diagnostics is listed under ha_platforms but omitted from ha_category. Add - Diagnostics to the ha_category section to align with the platforms.
Proposed diff:

@@ -4,12 +4,13
 ha_category:
   - Binary sensor
   - Button
   - Hub
   - Light
   - Number
   - Select
   - Sensor
   - Switch
+  - Diagnostics

Also applies to: 21-29

source/_integrations/motionblinds_matter.markdown (1)

74-74: ⚠️ Potential issue

Fix spelling and hyphenation

• Motionblins store locator → Motionblinds store locator
• custom made blinds → custom-made blinds

-To find where to buy these motors with custom made blinds, visit the [Motionblins store locator](https://motionblinds.com/stores).
+To find where to buy these motors with custom-made blinds, visit the [Motionblinds store locator](https://motionblinds.com/stores).

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

To find where to buy these motors with custom-made blinds, visit the [Motionblinds store locator](https://motionblinds.com/stores).

🧰 Tools

🪛 LanguageTool

[misspelling] ~74-~74: This word is normally spelled with a hyphen.
Context: ... To find where to buy these motors with custom made blinds, visit the [Motionblins store lo...

(EN_COMPOUNDS_CUSTOM_MADE)