new HDMI-cec bus component #5441
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![esphome[bot]](https://avatars.githubusercontent.com/in/247347?s=60&v=4){kind=small}
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 👍 |
WalkthroughAdds new documentation pages (HDMI-CEC bus, WTS01 sensor, Z-Wave Proxy), updates multiple component docs with new options (API, UART, SX126x, Ethernet, Wi-Fi), restructures ESP32 framework docs and related guidance, adjusts BLE-related texts, updates substitutions doc, revises logger interface table, minor text fixes, updates version metadata. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
actor HA as Home Assistant
participant API as ESPHome API
participant ZW as Z-Wave Proxy
participant UART as UART (Z-Wave Modem SoC)
HA->>API: Connect (single client)
HA->>API: Z-Wave frame (to modem)
API->>ZW: Forward frame
ZW->>UART: Write UART bytes
UART-->>ZW: Modem response bytes
ZW-->>API: Forward response
API-->>HA: Deliver response
note over API,ZW: Prefer Ethernet for lower latency
sequenceDiagram
autonumber
participant User as Automation/User
participant HDMI as hdmi_cec Component
participant CEC as HDMI CEC Bus (GPIO/UART)
participant TV as TV/Receiver
User->>HDMI: send_command (e.g., power on)
alt GPIO-based sending
HDMI->>CEC: Drive GPIO with CEC timings
else Optional UART-assisted sending
HDMI->>CEC: Send via UART timing engine
end
CEC-->>TV: CEC frame
TV-->>HDMI: Acknowledge/response (optional)
note over HDMI,CEC: Uses configured logical/physical addresses
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 12
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (6)
content/components/hdmi_cec/images/cec_uart_schematics.pngis excluded by!**/*.pngcontent/components/hdmi_cec/images/hpd_uart_schematics.pngis excluded by!**/*.pngcontent/components/images/hdmi-cec.pngis excluded by!**/*.pngcontent/components/images/z-wave.svgis excluded by!**/*.svgcontent/components/sensor/images/wts01-full.pngis excluded by!**/*.pngstatic/images/wts01.pngis excluded by!**/*.png
📒 Files selected for processing (19)
content/components/_index.md(3 hunks)content/components/api.md(2 hunks)content/components/bluetooth_proxy.md(1 hunks)content/components/esp32.md(4 hunks)content/components/esp32_ble.md(2 hunks)content/components/esp32_ble_tracker.md(1 hunks)content/components/ethernet.md(1 hunks)content/components/hdmi_cec/_index.md(1 hunks)content/components/logger.md(1 hunks)content/components/media_player/speaker.md(1 hunks)content/components/sensor/wts01.md(1 hunks)content/components/substitutions.md(1 hunks)content/components/sx126x.md(1 hunks)content/components/touchscreen/ektf2232.md(1 hunks)content/components/uart.md(4 hunks)content/components/wifi.md(1 hunks)content/components/zwave_proxy.md(1 hunks)content/guides/esp32_arduino_to_idf.md(1 hunks)data/version.yaml(1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
**
⚙️ CodeRabbit configuration file
- Do not generate or add any sequence diagrams
Files:
content/components/substitutions.mdcontent/components/api.mdcontent/components/esp32_ble_tracker.mdcontent/components/hdmi_cec/_index.mdcontent/components/logger.mdcontent/components/ethernet.mdcontent/guides/esp32_arduino_to_idf.mdcontent/components/media_player/speaker.mdcontent/components/sx126x.mdcontent/components/uart.mdcontent/components/touchscreen/ektf2232.mdcontent/components/bluetooth_proxy.mdcontent/components/esp32.mddata/version.yamlcontent/components/zwave_proxy.mdcontent/components/esp32_ble.mdcontent/components/wifi.mdcontent/components/_index.mdcontent/components/sensor/wts01.md
🪛 GitHub Actions: Lint
content/components/hdmi_cec/_index.md
[error] 20-20: MarkdownLint: MD009/no-trailing-spaces Trailing spaces detected at line 20 (column 73).
🪛 GitHub Check: build
content/components/hdmi_cec/_index.md
[failure] 345-345:
Multiple consecutive blank lines [Expected: 1; Actual: 2]
[failure] 235-235:
Fenced code blocks should have a language specified [Context: "```"]
[failure] 235-235:
Fenced code blocks should be surrounded by blank lines [Context: "```"]
[failure] 143-143:
Fenced code blocks should have a language specified [Context: "```"]
[failure] 41-41:
Multiple consecutive blank lines [Expected: 1; Actual: 2]
🔇 Additional comments (1)
content/components/substitutions.md (1)
155-168: Nice addition of !literal guidance.Clear explanation and example make it obvious how to bypass substitutions when needed. Nicely done.
|
|
||
| - **active** (*Optional*, boolean): Enables proxying active connections. Defaults to `true`. | ||
| - **cache_services** (*Optional*, boolean): Enables caching GATT services in NVS flash storage which significantly speeds up active connections. Defaults to `true` when using the ESP-IDF framework. | ||
| - **cache_services** (*Optional*, boolean): Enables caching GATT services in NVS flash storage which significantly speeds up active connections. Defaults to `true`. |
There was a problem hiding this comment.
Restore the framework-specific default description
Core still keeps cache_services defaulting to true only under ESP-IDF (Arduino stays false to protect scarce flash writes). Dropping that qualifier tells Arduino users they’ll get caching automatically, which they won’t. Please reinstate the framework-specific wording so the docs match the component behavior.
🤖 Prompt for AI Agents
In content/components/bluetooth_proxy.md around line 52, restore the
framework-specific default wording for the cache_services option: state that
cache_services defaults to true under ESP-IDF but defaults to false under
Arduino (to avoid extra flash writes). Update the sentence to mention both
framework defaults and keep the Optional boolean type and explanation about NVS
flash caching and performance benefits.
Comment on lines
54
to
55
| Each configured slot consumes ~1KB of RAM, with a maximum of `9`. It is recommended not to exceed `5` | ||
| connection slots to avoid memory issues. Defaults to `3`. |
There was a problem hiding this comment.
Keep the ESP-IDF limitation note
connection_slots remains hard-capped at 3 on Arduino—the setter is only honored under ESP-IDF. Removing the “esp-idf only” note suggests Arduino users can raise the limit, which still isn’t supported. Please keep that restriction in the docs to avoid misconfigurations.
🤖 Prompt for AI Agents
In content/components/bluetooth_proxy.md around lines 54-55, the documentation
removed the ESP-IDF-only limitation for connection_slots; restore a clear note
that the setter is only honored on ESP-IDF and that on Arduino connection_slots
is hard-capped at 3. Update the sentence to state defaults and limits per
platform (e.g., "Each configured slot consumes ~1KB of RAM; on ESP-IDF you can
configure up to 9 with a recommended limit of 5, default 3; on Arduino the value
is hard-capped at 3 and cannot be raised"), and ensure the platform-specific
restriction is prominently mentioned to prevent Arduino users from assuming they
can increase the limit.
Comment on lines
19
to
20
| allows to receive messages from and send messages to any device in the hdmi-connected cluster. Typical messages relate to | ||
| power-on and standby status, input selections, and audio volume control. |
There was a problem hiding this comment.
...
Second comment - double blank lines line 41.
Third comment - code block lines 143-156.
Fourth - code block lines 235-237.
Fifth - missing colon lines 176-192.
Sixth - typos lines 27,16? Maybe two occurrences; we can mention both.
Seventh - `Extended installation`_ lines 54-55.
Maybe numerous but acceptable.
Let's craft.
Comment 1.
Need subject line style: e.g. "**Remove trailing whitespace that breaks lint.**" Provide short explanation, include (since pipeline failing). Suggest diff.
Diff to remove trailing spaces? can't show? we can show `diff` removing trailing spaces? For single line, diff to remove and no addition? we can show restful:
- power-on ... control.
+ power-on ... control.
Ok.
Comment 2: multi blank lines w ? because lint fail. Provide removal diff.
Comment 3: missing language for logs (line 143). Provide suggestion to add `text`. Provide diff.
Comment4: second code.
Comment5: missing colon (major). Provide diff.
Comment6: Typos (HMDI). Maybe , diff.
Comment7: extended installation link? ? but restful.
Need ensure comment tags.
Let's craft comment 5 (missing colon). Provide diff.
For comment 4 (code block 235) ensures also blank lines around? Lint complaining also "Fenced code blocks should be surrounded by blank lines" (line 235). We'll mention in same comment to add blank line before block? need to check if block is preceded by text? In doc there is "these warnings ... like::" they have block. We'll instruct to add newline before/after.
Ok.
Let's craft actual comment text.
Also mention abiding instructions (no referencing other instructions). Use "Line [number]" referencing.
Let's craft comment 1.
Comment 1 text:
"**Remove trailing whitespace causing lint failure.** Trailing space at end of line 20 triggers MarkdownLint MD009; remove." Provide diff.
Comment 2: multi blank lines near 41. Need to show diff: remove extra blank line.
Comment 3: (Log block). Provide diff setting ` ```text`.
Comment 4: second code block.
Comment 5: `api` snippet.
Comment 6: Typos HMDI.
Comment7: `Extended installation`? arguable.
Also abide note: comment referencing knowledge? not necessary.
Let's craft.
Need to ensure line_range referencing actual lines.
For comment 2 line_range 41-45.
For comment3 line_range 143-156.
For comment4 line_range 232-238.
For comment5 line_range 176-192.
For comment6 line_range 16-34.
For comment7 line_range 54-55.
Also maybe mention blank lines near end lines 343-346? Provide comment referencing 342-346. Maybe same as comment 2? we can instruct to fix both occurrences? Maybe in comment 2 mention there is second double blank line near line 345 - to maintain single comment? Should be fine.
Let's craft each.
Comment 2 diff: show remove extra blank line? need careful.
If there are two blank lines there; desire to reduce to single blank line. Example snippet:
Basic installation
Add diff to remove.
Similarly near bottom? maybe same comment include mention? maybe degrade.
Maybe best to instruct to run Markdown lint to catch additional double blanks; referencing reporter. but we don't have doping.
Ok craft comment.
Also mention in comment to check entire doc for other double blank lines to satisfy lint? but unstoppable.
Now craft actual comments.
Comment 3 diff: change ` ``` ` to ` ```text`.
Also mention blank lines around block.
Similarly comment 4.
Comment 5 diff: `api:`.
Comment 6 diff for spelled.
Comment7 diff for link.
Also ensure tags.
Let's produce comments.
First comment (line 19-20). Use .
Second comment (line 40-45). due to lint.
Third comment (line 143-156). . Provide diff.
Fourth comment (line 235). .
Fifth comment (line 176-192). because invalid example.
Sixth comment (line 16-34). .
Seventh comment (line 54-55). Maybe minor? I'd call because readability; not a failure but helpful. However there might not be pipeline failing. Could use . It's textual but referencing not drastically wrong but mania? I'd mark due to odd leftover.
Also there was pipeline failure for multiple blank lines at line 345 (closing). Should we create comment referencing bottom? maybe comment 2 mention also there is double blank lines near bottom; we can mention.
Let's craft actual comment texts.
Comment 1:
🧰 Tools
🪛 GitHub Actions: Lint
[error] 20-20: MarkdownLint: MD009/no-trailing-spaces Trailing spaces detected at line 20 (column 73).
🤖 Prompt for AI Agents
content/components/hdmi_cec/_index.md lines 16-34, 19-20, 27, 41, 54-55,
143-156, 176-192, 235-237 — Remove the trailing whitespace on line 20; collapse
double blank lines at line 41 (and any other consecutive blank-line occurrences)
to single blank lines; fix typos (e.g., HMDI -> HDMI at the occurrences around
lines 16 and 27); add a missing colon for the "api" label/heading in the block
around lines 176-192; mark fenced code blocks with an explicit language (e.g.,
change ``` to ```text) for the blocks at lines 143-156 and 235-237 and ensure
there is a blank line before and after each fenced block so Markdown lint
passes.
Remove trailing whitespace causing lint failure.
Line 20 currently ends with a trailing space, tripping MarkdownLint (MD009) and breaking the pipeline. Trim the space so the line ends flush.
- power-on and standby status, input selections, and audio volume control.
+ power-on and standby status, input selections, and audio volume control.Committable suggestion skipped: line range outside the PR's diff.
🧰 Tools
🪛 GitHub Actions: Lint
[error] 20-20: MarkdownLint: MD009/no-trailing-spaces Trailing spaces detected at line 20 (column 73).
🤖 Prompt for AI Agents
In content/components/hdmi_cec/_index.md around lines 19 to 20, line 20 ends
with a trailing space which triggers MarkdownLint MD009; remove the trailing
whitespace at the end of line 20 so the line ends flush (save the file and
re-run lint to verify).
There was a problem hiding this comment.
@JosVanEijndhoven, thank you for fixing the trailing whitespace! 🎉
🐰✨
(^_^)/
Happy to help!
If you found this review helpful, would you consider giving us a shout-out on X?
Thank you for using CodeRabbit!
Comment on lines
64
to
66
| - **flow_control_pin** (*Optional*, [Pin](#config-pin)): ESP32 only. The pin used to for hardware RS485 flow control. | ||
| Use of this setting enables half-duplex mode. Use the full pin schema and set `inverted: true` to invert logic levels. | ||
|
|
There was a problem hiding this comment.
Fix typo in flow_control_pin description.
Sentence currently reads “The pin used to for hardware RS485 flow control.” Drop “to” so it becomes “The pin used for hardware RS485 flow control.”
🤖 Prompt for AI Agents
In content/components/uart.md around lines 64 to 66, fix the typo in the
flow_control_pin description: remove the extra word "to" so the sentence reads
"The pin used for hardware RS485 flow control." Update the line accordingly and
ensure surrounding punctuation and formatting remain unchanged.
Comment on lines
16
to
21
| As the Z-Wave modem SoC communicates via a serial connection, you need to have a [UART](#uart) defined in your ESPHome | ||
| device's configuration. | ||
|
|
||
| In addition, the `zwave_proxy` expects to proxy messages via ESPHome's {{< docref "/components/api" >}}; this is also | ||
| required in your configuration. | ||
|
|
There was a problem hiding this comment.
Replace broken self-link with docref.
The text links to [UART](#uart), but this page doesn’t define a #uart anchor. Readers will hit a dead link. Please swap it for a docref, e.g. {{< docref "/components/uart" >}}, so the link resolves.
🤖 Prompt for AI Agents
In content/components/zwave_proxy.md around lines 16 to 21 the text links to a
non-existent local anchor `[UART](#uart)` which causes a broken self-link;
replace that link with the proper docref `{{< docref "/components/uart" >}}` so
the link resolves to the UART component documentation, and ensure spacing and
surrounding punctuation remain consistent with the surrounding sentence.
esphome
bot
dismissed
their stale review
Base branch has been corrected - dismissing previous review.
5 tasks
10 tasks
JosVanEijndhoven
force-pushed
the
hdmi_cec
branch
from
f20f596 to
0bbc2fe
Compare
✅ Deploy Preview for esphome ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description:
This component allows to connect an esphome device to the 'HDMI CEC' control bus.
On that bus, it can issue and receive commands to/from the HDMI-connected cluster of devices.
This includes commands to power devices on or off, adjust volume, select A/V inputs, etc.
Related issue (if applicable): fixes
Earlier versions of this component, not yet integrated
in the esphome repo, suffered from long run-times per loop invocation.
This is solved by the optional use of a UART and buffering of messages to send.
To better show how to use this, two pictures with schematics are added.
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
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.Link added in
/components/index.rstwhen creating new documents for new components or cookbook.New Component Images
If you are adding a new component to ESPHome, you can automatically generate a standardized black and white component name image for the documentation.
I have added my own component image
To generate a component image:
Comment on this pull request with the following command, replacing
COMPONENT_NAMEwith your component name in UPPER_CASE format with underscores (e.g.,BME280,SHT3X,DALLAS_TEMP):The ESPHome bot will respond with a downloadable ZIP file containing the SVG image.
Extract the SVG file and place it in the
images/folder of this repository.Use the image in your component's index table entry in
/components/index.rst.Example: For a component called "DHT22 Temperature Sensor", use: