Skip to content
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 7 additions & 2 deletions Integrations/ESPHome/Core.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -268,6 +268,9 @@ binary_sensor:
input: true
pullup: true
inverted: true
filters:
- delayed_on: 5s
- delayed_off: 5s
Comment on lines +271 to +273

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🌐 Web query:

In ESPHome, do binary_sensor filters (delayed_on/delayed_off) affect both binary_sensor.is_on/is_offconditions used in scripts and trigger callbacks likeon_release? Please cite the official docs.

💡 Result:

Yes, in ESPHome, binary_sensor filters like delayed_on and delayed_off affect both the binary_sensor.is_on/is_off conditions used in scripts and automations, as well as trigger callbacks like on_release. Filters are applied in a pipeline to the raw input values before they update the binary sensor's state. The filtered state is what is exposed via .state (used by is_on/is_off conditions), published to Home Assistant, and used by on_state/on_press/on_release triggers. Official docs confirm: "With binary sensor filters you can customize how ESPHome handles your binary sensor values even more... All filters are processed in a pipeline." (esphome.io/components/binary_sensor). The API shows publish_state processes through filters before triggering state change callbacks used by automations. Examples use delayed_off with on_press/on_release for debouncing, confirming triggers fire on filtered state changes.

Citations:


Potential safety delay from filtering a shared control sensor.

Applying delayed_on/off to fluid_input_sensor delays safety/state checks that use binary_sensor.is_on/off for pump stop/start logic. ESPHome filters apply in a pipeline to all state conditions and triggers, so the ~5s delay will extend pump runtime after real dry/full transitions. Validate this worst-case behavior on hardware before merge, or split into a raw safety sensor plus a debounced automation sensor.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@Integrations/ESPHome/Core.yaml` around lines 271 - 273, The current use of
delayed_on/delayed_off on fluid_input_sensor will postpone
binary_sensor.is_on/off transitions used by pump stop/start logic, potentially
causing unsafe extended pump runtimes; remove the filters from the safety sensor
and instead create two sensors: keep fluid_input_sensor_raw (no filters) for
safety checks and automations (pump control, binary_sensor.is_on/off usages) and
add a separate fluid_input_sensor_debounced that applies delayed_on/delayed_off
for UI/automation smoothing; update all pump-related automations and
binary_sensor references to use fluid_input_sensor_raw (or its corresponding raw
binary_sensor) while leaving any user-facing displays to reference the debounced
sensor, then test the behavior on hardware.

on_release:
then:
- if:
Expand All @@ -285,7 +288,7 @@ binary_sensor:

- platform: gpio
name: Fluid Output
id: fulid_output_sensor
id: fluid_output_sensor
icon: mdi:water
device_class: moisture
pin:
Expand All @@ -294,6 +297,8 @@ binary_sensor:
input: true
pullup: true
inverted: true
filters:
- delayed_off: 5s

number:
- platform: template
Expand Down Expand Up @@ -442,7 +447,7 @@ script:
condition:
- and:
- switch.is_on: stop_pump_when_full
- binary_sensor.is_on: fulid_output_sensor
- binary_sensor.is_on: fluid_output_sensor
then:
- logger.log: "Pump stopping - tank full"
- switch.turn_off: pump_control
Expand Down
Loading