[esp32_rmt] Updates for IDF 5+ changes #4480
Conversation
WalkthroughThe documentation for the ESP32 RMT LED Strip, remote receiver, and remote transmitter components has been updated to reflect changes in configuration options. The Changes
Possibly related PRs
Suggested labels
Suggested reviewers
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (4)
components/light/esp32_rmt_led_strip.rst (1)
41-42: Enhance the obsolescence noticeConsider providing more context about the IDF framework v5 changes. This would help users understand why the parameter is now optional and what they should expect in future versions.
- - **rmt_channel** (**Optional**, int): The RMT channel to use. If using multiple strips, you need to use different channels. Obsolete with IDF framework v5. + - **rmt_channel** (**Optional**, int): The RMT channel to use. If using multiple strips, you need to use different channels. + .. note:: + This parameter is obsolete with IDF framework v5 as channels are now automatically managed. + It is retained for backward compatibility with older framework versions.components/remote_receiver.rst (2)
75-75: Consider adding migration guidance for obsolete parameter.The documentation clearly marks
rmt_channelas obsolete with IDF framework v5 and provides comprehensive channel availability information. Consider adding migration guidance to help users transition away from this parameter when using IDF framework v5.Add a note section like this:
- **rmt_channel** (*Optional*, int): The RMT channel to use. Only on **esp32**. Obsolete with IDF framework v5. + **rmt_channel** (*Optional*, int): The RMT channel to use. Only on **esp32**. Obsolete with IDF framework v5. + + .. note:: + + When using IDF framework v5, this parameter is no longer needed as channels are automatically managed. + If you're upgrading from an older version, you can safely remove this parameter from your configuration.
97-100: Add example usage for new IDF v5 parameters.The documentation clearly describes the new parameters
max_length,min_length, andwith_dma. However, it would be helpful to provide an example configuration showing how to use these parameters.Add an example configuration like this:
- **with_dma** (*Optional*, boolean): Enable DMA on variants that support it. Only with IDF framework v5. + + Example configuration with IDF framework v5 parameters: + + .. code-block:: yaml + + remote_receiver: + pin: GPIO4 + dump: all + max_length: 200 # Maximum length of 200 values + min_length: 24 # Filter out signals shorter than 24 values + with_dma: true # Enable DMA for better performancecomponents/remote_transmitter.rst (1)
50-51: Consider adding cross-references for advanced featuresTo help users better understand the new v5 features, consider adding:
- A link to the IDF framework v5 migration guide
- Technical details or examples for DMA usage
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (3)
components/light/esp32_rmt_led_strip.rst(1 hunks)components/remote_receiver.rst(2 hunks)components/remote_transmitter.rst(2 hunks)
🧰 Additional context used
📓 Path-based instructions (3)
components/light/esp32_rmt_led_strip.rst (1)
Pattern **: - Do not generate or add any sequence diagrams
components/remote_receiver.rst (1)
Pattern **: - Do not generate or add any sequence diagrams
components/remote_transmitter.rst (1)
Pattern **: - Do not generate or add any sequence diagrams
🔇 Additional comments (3)
components/light/esp32_rmt_led_strip.rst (1)
43-50: LGTM: Channel information table
The CSV table providing channel information for different ESP32 variants is well-structured and provides valuable reference information for users still using older framework versions.
components/remote_transmitter.rst (2)
37-37: LGTM: Clear documentation of rmt_channel obsolescence
The documentation clearly indicates that the rmt_channel parameter is now optional and obsolete with IDF framework v5, which aligns with the PR objectives and AI summary.
50-51: LGTM: Well-documented new configuration options
The new configuration variables one_wire and with_dma are clearly documented with:
- Their types (boolean)
- Their purpose (bi-directional GPIO and DMA support)
- Framework version requirement (IDF framework v5)
✅ Deploy Preview for esphome ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
kbx81
changed the title
|
Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍 |
Description:
Update docs for new RMT drivers
Related issue (if applicable): fixes
Pull request in esphome with YAML changes (if applicable): esphome/esphome#7770
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
/index.rstwhen creating new documents for new components or cookbook.