Skip to content

Conversation

swoboda1337
Copy link
Member

Description:

Add note about hardware version

Related issue (if applicable): fixes esphome/esphome#10738

Pull request in esphome with YAML changes (if applicable):

  • esphome/esphome#

Checklist:

  • I am merging into next because this is new documentation that has a matching pull-request in esphome as linked above.
    or

  • I am merging into current because 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.rst when 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.

To generate a component image:

  1. Comment on this pull request with the following command, replacing COMPONENT_NAME with your component name in UPPER_CASE format with underscores (e.g., BME280, SHT3X, DALLAS_TEMP):

    @esphomebot generate image COMPONENT_NAME
    
  2. The ESPHome bot will respond with a downloadable ZIP file containing the SVG image.

  3. Extract the SVG file and place it in the images/ folder of this repository.

  4. Use the image in your component's index table entry in /components/index.rst.

Example: For a component called "DHT22 Temperature Sensor", use:

@esphomebot generate image DHT22

@esphome esphome bot added the current label Sep 22, 2025
Copy link

netlify bot commented Sep 22, 2025

Deploy Preview for esphome ready!

Name Link
🔨 Latest commit 45047bd
🔍 Latest deploy log https://app.netlify.com/projects/esphome/deploys/68d16d0c039bae00080a771f
😎 Deploy Preview https://deploy-preview-5390--esphome.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

Copy link
Contributor

coderabbitai bot commented Sep 22, 2025

Walkthrough

Documentation for HTU21D sensor’s model option was updated to add a note about potential mislabeling on some boards and to try HTU21D if I2C errors occur. Default remains HTU21D. No code or configuration logic changes.

Changes

Cohort / File(s) Summary
Docs: HTU21D model guidance
content/components/sensor/htu21d.md
Expanded model option description with advisory about mislabeling and troubleshooting I2C errors; default unchanged (HTU21D).

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

Suggested labels

current

Pre-merge checks and finishing touches

❌ Failed checks (2 warnings)
Check name Status Explanation Resolution
Linked Issues Check ⚠️ Warning The linked issue #10738 calls for a code-based fix or mitigation to prevent I2C hardware NACKs and continuous reboot behavior on affected ESP32 hardware, but this PR only introduces documentation changes and does not implement any of the required code modifications. To satisfy the objectives of issue #10738, the PR should include the necessary code changes or configuration logic to address and suppress I2C hardware NACK errors and prevent boot loops, or else decouple this documentation update into its own PR and pursue the code fix separately.
Out of Scope Changes Check ⚠️ Warning All changes in this PR are limited to documentation in the HTU21D component guide and do not touch any code or configuration that would resolve the bug described in issue #10738, making the current diff out of scope relative to the bug-fix objectives. Either restrict this PR purely to documenting hardware labeling quirks by removing the “fixes” reference to issue #10738, or expand it to include the actual code modifications required to resolve the I2C hardware NACK and reboot loop problem.
✅ Passed checks (3 passed)
Check name Status Explanation
Title Check ✅ Passed The pull request title “[htu21d] Add note about hardware version” accurately and concisely describes the primary change, which is adding a hardware version note to the HTU21D sensor documentation without extraneous details.
Description Check ✅ Passed The pull request description clearly states that a note about hardware version is being added and references the related issue, directly matching the documentation change made in this PR.
Docstring Coverage ✅ Passed No functions found in the changes. Docstring coverage check skipped.
✨ Finishing touches
🧪 Generate unit tests
  • Create PR with unit tests
  • Post copyable unit tests in a comment

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between bafffc3 and 45047bd.

📒 Files selected for processing (1)
  • content/components/sensor/htu21d.md (1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
**

⚙️ CodeRabbit configuration file

  • Do not generate or add any sequence diagrams

Files:

  • content/components/sensor/htu21d.md
🔇 Additional comments (1)
content/components/sensor/htu21d.md (1)

47-48: Clarify wording, use I²C, and show exact YAML knob (model: htu21d).

Verified: official docs/examples use model: htu21d (lowercase) and the component API exposes model enums — showing the YAML knob model: htu21d and replacing "I2C" with "I²C" is consistent. (esphome.io)

-**model** (*Optional*): Possible values are HTU21D, SI7021, SHT21. Note some boards are labeled with the
-incorrect model. If I2C errors are encountered try using the HTU21D. Defaults to HTU21D.
+**model** (*Optional*): Possible values are HTU21D, SI7021, SHT21. Note: some boards may be mislabeled.
+If I²C errors are encountered, try setting `model: htu21d`. Defaults to HTU21D.

Tip

👮 Agentic pre-merge checks are now available in preview!

Pro plan users can now enable pre-merge checks in their settings to enforce checklists before merging PRs.

  • Built-in checks – Quickly apply ready-made checks to enforce title conventions, require pull request descriptions that follow templates, validate linked issues for compliance, and more.
  • Custom agentic checks – Define your own rules using CodeRabbit’s advanced agentic capabilities to enforce organization-specific policies and workflows. For example, you can instruct CodeRabbit’s agent to verify that API documentation is updated whenever API schema files are modified in a PR. Note: Upto 5 custom checks are currently allowed during the preview period. Pricing for this feature will be announced in a few weeks.

Please see the documentation for more information.

Example:

reviews:
  pre_merge_checks:
    custom_checks:
      - name: "Undocumented Breaking Changes"
        mode: "warning"
        instructions: |
          Pass/fail criteria: All breaking changes to public APIs, CLI flags, environment variables, configuration keys, database schemas, or HTTP/GraphQL endpoints must be documented in the "Breaking Change" section of the PR description and in CHANGELOG.md. Exclude purely internal or private changes (e.g., code not exported from package entry points or explicitly marked as internal).

Please share your feedback with us on this Discord post.


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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

I2C Hardware NACK and continuous boot loop on wt32-eth01 and ESPHome 2025.8.3
1 participant