[dsmr] Document thermal_mbus_id option#6067
[dsmr] Document thermal_mbus_id option#6067thomwiggers wants to merge 2 commits intoesphome:nextfrom
Conversation
There was a problem hiding this comment.
As this is a feature matched with a PR in https://github.com/esphome/esphome, please target your PR to the next branch and rebase.
|
Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍 |
✅ Deploy Preview for esphome ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
WalkthroughDocumentation update for ESPHome version 2026.3.0-dev, adding new component documentation (CH423 I/O Expander, SY6970 Battery Charger, DLMS Meter, Zigbee Time, Key Collector text sensor) and expanding configuration options across existing components with minor corrections and structural improvements. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested labels
Suggested reviewers
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
Tip Issue Planner is now in beta. Read the docs and try it out! Share your feedback on Discord. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 15
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
content/components/climate/climate_ir.md (2)
359-359:⚠️ Potential issue | 🟡 MinorFix typo in "protocols".
The word "protcols" should be spelled "protocols".
✏️ Proposed fix
-- **protocol** (**Required**, string): Choose one of Arduino-HeatpumpIR's supported protcols: +- **protocol** (**Required**, string): Choose one of Arduino-HeatpumpIR's supported protocols:
361-367:⚠️ Potential issue | 🟠 MajorRemove duplicate
carrier_qlima_1entry and modernize deprecated Hugo shortcodes.The protocol
carrier_qlima_1is duplicated on line 361 and should appear only once. Additionally, this file uses legacy Hugo shortcodes that violate the coding guidelines:
- Line 13:
{{< img >}}should be replaced with standard Markdown image syntax- Lines 42, 48, 264, 322, 382, 387:
{{< docref >}}should be replaced with standard Markdown links
🤖 Fix all issues with AI agents
In `@content/components/ch423.md`:
- Around line 64-65: Replace the legacy Hugo shortcodes {{< docref "switch/gpio"
>}} and {{< docref "binary_sensor/gpio" >}} with standard Markdown links that
point to the same documentation paths (e.g., convert each docref to a
Markdown-style link like [switch/gpio](/switch/gpio) or the appropriate
site-relative URL); update the two occurrences in ch423.md so the display text
and target path reflect the original docref argument (switch/gpio and
binary_sensor/gpio).
In `@content/components/display/hub75.md`:
- Line 98: The configuration docs for the "board" variable are missing the
recently added preset name; update the enumerated valid preset names under the
"board" configuration variable to include `huidu-hd-wf1` so it matches the
"Available Board Presets" section. Locate the list of valid preset names for the
board setting (the paragraph that enumerates presets) and add `huidu-hd-wf1` to
that enumeration, ensuring formatting matches the surrounding entries.
In `@content/components/display/mipi_dsi.md`:
- Around line 59-60: The sentence containing the date "October 14, 2025" needs a
comma after the year for correct punctuation and readability: update the text in
content/components/display/mipi_dsi.md so the clause reads "Units manufactured
before October 14, 2025, use the ILI9881C display driver with separate GT911
touch driver (use `M5STACK-TAB5`)." Keep the second clause referencing
`M5STACK-TAB5-V2` unchanged.
In `@content/components/display/mipi_spi.md`:
- Around line 134-137: The guidance text for the transform option contains a
sentence fragment ("Otherwise the options below:"); update the sentence to be a
complete instruction by replacing that fragment with a full sentence such as
"Otherwise, use one of the following options:" (or similar) so the paragraph for
the transform option (referencing transform, rotation, dimensions and the CUSTOM
model) reads clearly and grammatically correct.
In `@content/components/esp32.md`:
- Around line 252-257: The documentation for the use_full_certificate_bundle
option still uses the legacy Hugo shortcode {{< docref
"/components/http_request" >}}; replace that shortcode with a standard Markdown
link (e.g., [HTTP Request](/components/http_request) or the appropriate
relative/absolute URL) so the line referencing the HTTP request component uses
plain Markdown instead of {{< docref ... >}}—update the text around
use_full_certificate_bundle to use the new Markdown link.
- Around line 379-380: Replace the legacy Hugo docref shortcode '{{< docref
"/components/esphome#libraries" "libraries" >}}' with a standard Markdown link
using the link text "libraries" that points to /components/esphome#libraries;
update the sentence in the esp32.md content so it reads naturally with the
Markdown link in place of the shortcode.
In `@content/components/key_collector.md`:
- Line 132: Replace the Hugo shortcode occurrence {{< docref
"/components/text_sensor/key_collector" >}} with a standard Markdown link
pointing to the same target path — use a descriptive link text (e.g., "Key
collector" or "Text sensor key collector") and the URL
"/components/text_sensor/key_collector" so the line becomes a normal Markdown
link rather than the legacy {{< docref ... >}} shortcode.
In `@content/components/sensor/dlms_meter.md`:
- Around line 117-124: Replace the phrase "Provider specific sensors are listed
separately." with the hyphenated form "Provider-specific sensors are listed
separately." to maintain grammatical consistency for the "provider" field
description and the "Sensor" section; update the sentence where the keyword
"provider" appears in the doc (the line that currently reads "Not all sensors
are available on all meters. Provider specific sensors are listed separately.")
to use "Provider-specific".
In `@content/components/sensor/dsmr.md`:
- Around line 49-50: Update the thermal sensor OBIS code examples to use the
configurable variable instead of the hardcoded ID: locate every occurrence of
the hardcoded prefix "0-3:" used for thermal sensor OBIS codes (the OBIS
examples around the thermal sensor sections) and replace it with
"0-thermal_mbus_id:" so the documentation matches the documented configuration
option `thermal_mbus_id` (default 3) and follows the same pattern used for
`0-gas_mbus_id:` and `0-water_mbus_id:`.
In `@content/components/sensor/xiaomi_ble.md`:
- Around line 190-191: Fix the two typos in the NOTE block that currently reads
"PVVX firmare deprecated any other advertisment format other than "BTHome v2"
starting with version 6.0." — change "firmare" to "firmware" and "advertisment"
to "advertisement" (so the NOTE reads e.g. "PVVX firmware deprecated any other
advertisement format other than 'BTHome v2' starting with version 6.0.").
- Around line 596-599: The text currently references the wrong option name
`bind_key`; update the documentation to use the correct option name `bindkey`
everywhere in this paragraph (replace `bind_key` with `bindkey`) so it matches
the config schema and other docs, and keep the inline code formatting
(backticks) around `bindkey`.
- Line 627: Replace the Hugo shortcode instance {{< img src="telink_flasher.jpg"
alt="Image" caption="Telink flasher application." width="100.0%"
class="align-center" >}} with a standard Markdown image: use the file name as
the src, set the caption text "Telink flasher application." as the alt and/or
title text (e.g., alt text = "Telink flasher application." and title = "Telink
flasher application."), and preserve presentation (width/centering) by adding a
simple HTML wrapper or inline style around the Markdown image if needed to
maintain width:100% and center alignment.
- Around line 521-523: The YAML snippet sets bindkey without quotes which may
cause parsing/formatting inconsistencies; update the bindkey value to be a
quoted string (e.g., change bindkey: 0011223344... to bindkey: "0011223344...")
so it matches other examples and avoids YAML edge cases—modify the bindkey line
adjacent to mac_address in the Xiaomi BLE sensor example to include surrounding
quotes.
In `@content/components/text_sensor/key_collector.md`:
- Around line 10-11: Replace the Hugo docref shortcode usage in the text
mentioning the Key Collector with a standard Markdown link: find the phrase
containing {{< docref "/components/key_collector" "Key Collector" >}} and change
it to a Markdown link like [Key Collector](/components/key_collector) (or the
correct relative URL for the Key Collector docs) in both occurrences (around
lines referencing the Key Collector in this file and the other occurrence at
lines 42-43); ensure the display text remains "Key Collector" and that link
syntax conforms to standard Markdown.
In `@content/components/time/zigbee.md`:
- Around line 11-28: Replace the Hugo docref shortcodes with standard Markdown
links: change `{{< docref "/components/zigbee" "Zigbee" >}}` to a Markdown link
like [Zigbee](/components/zigbee), change `{{< docref
"/guides/configuration-types" "Time" >}}` to [Time](/guides/configuration-types)
and change `{{< docref "/components/time/" "Time Component" >}}` to [Time
Component](/components/time/); update the three occurrences in the text (the
first docref in the intro, the update_interval parenthetical, and the last See
Also list) so all docref shortcodes are replaced with their equivalent Markdown
links.
🧹 Nitpick comments (5)
content/components/water_heater/template.md (1)
143-143: Replace legacydocrefshortcode with a standard Markdown link.This file uses the legacy
{{< docref >}}shortcode. Please replace it with a regular Markdown link. As per coding guidelines, “Hugo shortcode{{< docref >}}is legacy and should be replaced with standard Markdown links.”content/components/sensor/pmsx003.md (1)
128-129: Replace legacydocrefshortcodes with Markdown links.The Markdown guideline forbids
{{< docref >}}. Please switch to standard Markdown links.🔧 Proposed fix
-- {{< docref "/components/sensor/aqi" >}} -- {{< docref "/components/sensor/sds011" >}} +- [AQI Sensor](/components/sensor/aqi) +- [SDS011 Particulate Matter Sensor](/components/sensor/sds011)As per coding guidelines: “Hugo shortcode
{{< docref >}}is legacy and should be replaced with standard Markdown links.”content/components/display/mipi_dsi.md (1)
69-69: Replace legacy{{< img >}}shortcode with Markdown image syntax.The docs guideline deprecates
{{< img >}}. Use standard Markdown image syntax instead.
As per coding guidelines, "Hugo shortcode{{< img >}}is legacy and should be replaced with standard Markdown image syntax".♻️ Suggested change
-{{< img src="tab5-version-label.jpg" alt="Tab5 version label showing model identification" width="50%" class="align-center" >}} +content/components/binary_sensor/status.md (1)
24-25: Replace legacy docref shortcode with a Markdown link.The changed line uses the legacy
{{< docref >}}shortcode, which the guidelines disallow in.mdfiles.🔧 Proposed fix
-- **update_interval** (*Optional*, {{< docref "/guides/configuration-types#time" "Time" >}}): The interval +- **update_interval** (*Optional*, [Time](/guides/configuration-types#time)): The intervalAs per coding guidelines: “
**/*.md: Hugo shortcode{{< docref >}}is legacy and should be replaced with standard Markdown links.”content/components/climate/climate_ir.md (1)
353-353: Consider hyphenating "third-party" for grammatical correctness.When "third party" modifies "library" as a compound adjective, it should be hyphenated as "third-party library" per standard English grammar rules.
📝 Proposed fix
-This platform works with the `arduino` framework and ESP-IDF (on ESP32), and should only be used if your AC unit is not supported by any of the other (native) platforms from above. No support can be provided for Arduino-HeatpumpIR, because it is a third party library. +This platform works with the `arduino` framework and ESP-IDF (on ESP32), and should only be used if your AC unit is not supported by any of the other (native) platforms from above. No support can be provided for Arduino-HeatpumpIR, because it is a third-party library.
|
You have specified the wrong target branch. You should use |
Base branch has been corrected - dismissing previous review.
|
oops, I even rebased on |
Document the
thermal_mbus_idoption exposed by related PR.Pull request in esphome with YAML changes (if applicable):
Checklist:
I am merging into
nextbecause this is new documentation that has a matching pull-request in esphome as linked above.or
N/A I am merging into
currentbecause this is a fix, change and/or adjustment in the current documentation and is not for a new component or feature.N/A Link added in
/components/_index.mdwhen creating new documents for new components or cookbook.