DHT Temperature Humidity Sensor: Adds instructions for sensor halting #5274
Conversation
✅ Deploy Preview for esphome ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
WalkthroughAdded a “Sensor halting” section to the DHT documentation showing a YAML example that power-cycles a stalled DHT via a GPIO-powered switch when a NaN reading is detected; notes updated about humidity decimals, model selection, pull-up resistor usage, and placement after update_interval details. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
actor ESPNode as ESPHome Node
participant DHT as DHT Sensor
participant PwrSwitch as GPIO Power Switch
ESPNode->>DHT: Periodic read (update_interval: 30s)
DHT-->>ESPNode: Temperature/Humidity value
alt Reading is NaN
ESPNode->>PwrSwitch: Turn OFF (pwrsensor -> false)
Note right of PwrSwitch #DDEBF7: Power-cycle start
ESPNode->>ESPNode: Wait 5s
ESPNode->>PwrSwitch: Turn ON (pwrsensor -> true)
Note right of DHT #F7F3DE: Sensor re-initializes
else Reading valid
ESPNode->>ESPNode: No action
end
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Tip 🔌 Remote MCP (Model Context Protocol) integration is now available!Pro plan users can now connect to remote MCP servers from the Integrations page. Connect with popular remote MCPs such as Notion and Linear to add more context to your reviews and chats. ✨ Finishing Touches🧪 Generate unit tests
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type 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
🧹 Nitpick comments (4)
content/components/sensor/dht.md (4)
63-69: Prefer a safer power switching pattern; avoid sourcing sensor VCC directly from a GPIO.Driving VCC from a GPIO can be marginal on some boards (current limits, boot strapping, brownout risk). Recommend switching the sensor’s supply via a transistor/P-MOSFET or a dedicated high-side switch, while controlling that switch from the GPIO.
If you keep the example minimal, at least add a cautionary line to set expectations.
Apply this diff to add a brief safety note and slightly clearer naming:
- - platform: gpio - pin: GPIO12 - id: pwrsensor - name: "Power for sensor" + - platform: gpio + pin: GPIO12 + id: dht_power + name: "DHT power (via transistor/MOSFET preferred)" restore_mode: ALWAYS_ON @@ - - switch.turn_off: pwrsensor + - switch.turn_off: dht_power - delay: 5s - - switch.turn_on: pwrsensor + - switch.turn_on: dht_powerOptional doc sentence (immediately above the YAML block):
+A note on power switching: powering a DHT directly from a GPIO is only safe if your MCU pin can supply the required current. Prefer a transistor/MOSFET to switch 3.3V.Also applies to: 82-85
70-90: Ensure NaN actually propagates toon_value; otherwise, the automation won’t fire on stalls.In some components, failed reads are logged but NaN is not published, so
on_valuedoesn’t trigger. If DHT does publish NaN, this is fine; if not, consider an interval watchdog that checksisnan(id(current_temperature).state)and power-cycles.If needed, add this alternative watchdog (outside the DHT block):
interval: - interval: 2min then: - if: condition: lambda: |- return isnan(id(current_temperature).state); then: - switch.turn_off: dht_power - delay: 5s - switch.turn_on: dht_powerAlso consider mirroring the
on_valueNaN check on the humidity sensor to increase the chance of catching a bad sample.
86-88: Align the example with the guidance onaccuracy_decimals.The note below suggests 1 decimal for non‑DHT11 models; reflect that in the example. Also,
id: current_humidityis unused.Apply this diff:
humidity: name: "Humidity" - id: current_humidity + accuracy_decimals: 1
94-96: Polish grammar for clarity.Minor phrasing adjustments for readability.
Apply this diff:
-The default `accuracy_decimals` value of the *humidity* levels is `0`, as the DHT11 for which this was -originally written does not have a higher resolution. All other DHT sensors have a higher resolution, it's worth -to configure them with `accuracy_decimals: 1`. +The default `accuracy_decimals` for humidity is `0`, as the DHT11 (for which this was +originally written) does not have a higher resolution. All other DHT sensors have a higher resolution; +configure them with `accuracy_decimals: 1`.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (1)
content/components/sensor/dht.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/dht.md
🪛 GitHub Check: build
content/components/sensor/dht.md
[failure] 92-92:
Multiple consecutive blank lines [Expected: 1; Actual: 2]
[failure] 62-62:
Fenced code blocks should be surrounded by blank lines [Context: "```yaml"]
🪛 GitHub Actions: Lint
content/components/sensor/dht.md
[error] 62-62: MD031: Fenced code blocks should be surrounded by blank lines.
🔇 Additional comments (1)
content/components/sensor/dht.md (1)
59-61: Title and intro of the new section look good.Clear, actionable placement right after
update_interval. Thanks for adding a concrete recovery pattern.
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (1)
content/components/sensor/dht.md (1)
63-64: MD031 fenced‑block spacing now looks correct.Blank lines before/after the fenced YAML are present and only a single blank line follows the block. Previous lint failures appear resolved.
Also applies to: 91-92
🧹 Nitpick comments (6)
content/components/sensor/dht.md (6)
59-62: Tighten phrasing and fix minor grammar in lead-in sentence."A GPIO port as power supply" reads awkwardly. Suggest a clearer, more idiomatic sentence.
- A possible solution is to use a GPIO port as power supply and restart the sensor on error. + A possible solution is to use a GPIO pin as the power source and power‑cycle the sensor when a read fails.
63-70: Make the power switch internal to avoid exposing it to Home Assistant.This switch is purely infrastructural. Hiding it prevents accidental toggling from the UI while preserving restore behavior.
switch: - platform: gpio pin: GPIO12 id: pwrsensor - name: "Power for sensor" + internal: true restore_mode: ALWAYS_ON
59-62: Add a hardware safety warning about sourcing VCC directly from a GPIO.Some boards can’t safely source sensor VCC from a GPIO; recommending a high‑side P‑MOSFET or low‑side NPN/MOSFET controlled by the GPIO reduces risk. A short doc callout helps readers avoid damage.
## Sensor halting A possible solution is to use a GPIO pin as the power source and power‑cycle the sensor when a read fails. + +{{< warning >}} +Powering a sensor directly from a GPIO pin may exceed the pin’s current limits on some boards. For robust setups, use the GPIO to drive a transistor/MOSFET (or a dedicated load switch/relay) that switches the sensor’s VCC. +{{< /warning >}}
71-86: Force an immediate read after power‑cycle to reduce recovery time.Without this, the component waits until the next update_interval. Adding a component update after a short stabilization delay improves UX. Requires giving the DHT component an id.
sensor: - platform: dht + id: dht_sensor pin: GPIO14 temperature: name: "Temperature" id: current_temperature on_value: then: - if: condition: - lambda: "return isnan(x);" then: - switch.turn_off: pwrsensor - delay: 5s - switch.turn_on: pwrsensor + # Allow sensor to stabilize, then force an immediate update. + - delay: 2s + - component.update: dht_sensorNote: Please verify that component.update with the DHT platform id is supported in your ESPHome version. If not, we can switch to updating via a script or adjust to the appropriate component id.
86-90: Also monitor humidity NaNs to catch partial stalls.In practice, one channel can go NaN while the other still reports. Mirroring the automation for humidity closes that gap.
humidity: name: "Humidity" id: current_humidity + on_value: + then: + - if: + condition: + - lambda: "return isnan(x);" + then: + - switch.turn_off: pwrsensor + - delay: 5s + - switch.turn_on: pwrsensor + - delay: 2s + - component.update: dht_sensor
90-91: Nudge readers to pick the right model in the example.A small inline comment prevents copy‑paste misconfiguration.
- model: AM2302 + # Adjust to match your sensor (AUTO_DETECT works for most except SI7021) + model: AM2302
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (1)
content/components/sensor/dht.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/dht.md
🪛 LanguageTool
content/components/sensor/dht.md
[grammar] ~61-~61: There might be a mistake here.
Context: ...possible solution is to use a GPIO port as power supply and restart the sensor on ...
(QB_NEW_EN)
Description:
Related issue (if applicable): fixes
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
[ x] 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.
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: