Knowing the Sump Pump Is Failing Before the Floor Does: Cycle Counts, Runtime Trends, and a Float-Switch Alarm
A sump pump fails in two directions. It can stop running when water is present, or it can run when water is not present. The first failure floods the floor. The second failure burns the motor and often precedes the first. Both are visible in cycle counts and runtime trends before either becomes obvious to a person standing in the basement.
This is a procedure for adding that visibility to an installed residential or small-office system using local-first components: an ESPHome binary sensor on a float switch, a Home Assistant counter for cycles, and a history_stats sensor for runtime. It assumes the pump already works and that the goal is to know when it stops working, not to replace the pump controller.
What the pump actually tells you
A float-activated sump pump is a switch with a motor attached. The float rises, the switch closes, the motor runs, the water level falls, the float drops, the switch opens. Every part of that sequence produces a measurable event: a state change on the float, a duration of motor run, and a count of how many times the sequence happened.
InterNACHI’s sump pump inspection guide describes the mechanism plainly: the pump senses water level through a float that rises and falls, and the pump activates and deactivates based on the height of that float. The same guide notes that a jammed float makes the pump useless because it will not sense when it should turn on and shut off, and that one of the most common reasons sump pumps fail is that the float gets jammed between the pump and the pit because the pit is too cramped. It also recommends annual maintenance and testing by pouring water into the pit to confirm activation and expulsion.
That is the mechanical baseline. The monitoring layer does not change it. It observes it.
Three signals worth logging
Cycle count, runtime per cycle, and time between cycles. Each maps to a different failure mode.
Cycle count answers how often the pump runs. A rising count during dry weather, or a count that keeps climbing after the rain stops, points to water entering the pit when it should not: a check valve that is not holding, a discharge line that drains back, or a pit that is receiving groundwater it did not receive before.
Runtime per cycle answers how long the pump runs to clear the pit. A pump that used to clear the pit in 20 seconds and now takes 40 is moving less water per unit time. That can be a worn impeller, a partially clogged inlet screen, or a discharge line with more restriction than before. InterNACHI notes that the inlet screen prevents dirt and solid material from entering the pump but can become overwhelmed, and that cleanings should occur often for pumps that run constantly.
Time between cycles answers whether the pit is refilling faster than it used to. Shortening intervals during stable weather is the earliest sign of a check valve leak or a rising water table. InterNACHI describes the check valve as the device that prevents pumped water in the discharge line from re-entering the sump pit when the pump turns off, and notes that without it the pump works twice as hard to remove the same column of water.
None of these three signals is a diagnosis on its own. Together they narrow the question from “is the pump broken” to “which part of the sequence changed.”
Wiring the float switch to an ESPHome binary sensor
The least invasive monitoring point is the float switch itself. Many residential sump pumps use a tethered or vertical float that closes a dry contact when the water reaches the trip point. That contact is already switching the pump circuit. Tapping it for a low-voltage signal requires care, and the safe approach depends on the pump’s control voltage and whether the float is in the line-voltage path.
If the float is a dry-contact switch carrying line voltage, do not connect it directly to an ESP board. Use a current transformer or an opto-isolated interface, or monitor the pump circuit with a current sensor instead. If the pump controller exposes a low-voltage dry contact for alarm or status, that is the correct tap point. The electrical details are site-specific and belong to a licensed electrician when line voltage is involved.
Once a dry contact is available, the ESPHome GPIO binary sensor is the right component. The ESPHome documentation states that the GPIO binary sensor uses hardware interrupts by default for efficient state change detection with minimal CPU usage, and that interrupt mode is recommended for most use cases. It also documents debouncing with filters such as delayed_on and delayed_off, which matters here because a float bobbing in turbulent water can produce rapid transitions that are not real cycles.
A minimal configuration for a float contact that closes when the pump runs:
binary_sensor:
- platform: gpio
pin:
number: GPIO4
mode:
input: true
pullup: true
name: "Sump pump running"
device_class: running
filters:
- delayed_on: 2s
- delayed_off: 2s
The two-second delays are a starting point, not a specification. They exist to reject the brief transitions that occur when the float passes through the trip point or when the pit surface is agitated. If the pump genuinely cycles faster than two seconds, the filter is wrong for that site. The ESPHome documentation notes that transitions shorter than the loop interval are ignored for backwards compatibility with polling mode, so very short legitimate pulses can also be lost. That is a tradeoff to measure, not assume.
If the float contact is not accessible, a current transformer on the pump’s hot conductor is the alternative. It reports motor current, which distinguishes “the float closed but the motor did not start” from “the float closed and the motor ran.” That distinction is worth the extra wiring when the pump is on a circuit that also feeds other loads.
Counting cycles and runtime in Home Assistant
Home Assistant has two helpers that do most of the work without custom code.
The Counter helper tracks how many times something has happened. The Home Assistant documentation describes it as a helper for counting events over time, with actions to increment, decrement, reset, and set the value, and triggers for when the counter increments, decrements, reaches a maximum, or reaches a minimum. It restores its previous value when Home Assistant restarts by default.
An automation that increments the counter on each rising edge of the float sensor:
alias: "Count sump pump cycles"
triggers:
- trigger: state
entity_id: binary_sensor.sump_pump_running
from: "off"
to: "on"
actions:
- action: counter.increment
target:
entity_id: counter.sump_pump_cycles
The history_stats integration provides runtime. The Home Assistant documentation states that it can track how long an entity has been in a specific state over a custom time period, and that the type option can be time, ratio, or count. For runtime, type: time with the pump-running state is the direct measurement.
sensor:
- platform: history_stats
name: "Sump pump runtime today"
entity_id: binary_sensor.sump_pump_running
state: "on"
type: time
start: "{{ today_at('00:00') }}"
end: "{{ now() }}"
state_class: total_increasing
The documentation warns that if the duration exceeds the recorder’s purge_keep_days, the sensor will only have the history that is still stored. For a 30-day trend, the recorder must retain 30 days. It also notes that the sensor updates when the source entity changes or once per minute if there is no source change, which is fine for a pump that runs for tens of seconds at a time.
For the trend itself, the Trend integration creates a binary sensor that reports whether a numeric state is rising or falling. The documentation states that it requires at least two updates of the tracked entity to establish a trend, and that sample_duration, max_samples, min_samples, and min_gradient control how the gradient is calculated. A trend sensor on the daily runtime, with a sample duration of several days, can flag a slow upward drift that no single day’s number would reveal.
The gradient is measured in sensor units per second. The documentation gives the example that a temperature falling by 2 degrees per hour corresponds to a gradient of (-2) / (60 x 60) = -0.00055. For runtime in hours per day, the conversion is different, and the threshold should be set from the site’s own baseline rather than from a generic number.
What the numbers look like when something changes
These are patterns, not thresholds. The thresholds come from the pump’s own history.
Runtime per cycle rising while cycle count is stable. The pump is running longer to move the same water. The inlet screen, the impeller, or the discharge line is the likely area. InterNACHI’s maintenance guidance supports cleaning the inlet screen and checking the float for tangles or jams. A pump that runs constantly needs cleaning more often, not less.
Cycle count rising while runtime per cycle is stable. The pit is refilling faster. The check valve is the first suspect because a leaking check valve returns water to the pit and forces the pump to move the same column twice. InterNACHI notes that without a check valve the pump works twice as hard, and that a check valve should be installed to prevent pumped water from re-entering the pit.
Cycle count rising and runtime per cycle falling. The pump is short-cycling. The float may be set too close to the pump inlet, or the pit may be too small for the inflow. InterNACHI identifies a cramped pit as a common cause of float jamming and recommends a pit not less than 24 inches deep and 18 inches wide for most homes.
Cycle count flat and runtime flat during a known rain event. The pump did not run when it should have. This is the failure the alarm exists to catch. The float may be stuck, the pump may have lost power, or the circuit may have tripped. InterNACHI notes that a GFCI can trip during safe conditions and deactivate the pump when it is needed, and that this is a known tradeoff in the inspection community.
Runtime flat but current present. If a current transformer is installed, motor current with no water movement points to a running pump that is not moving water: a broken impeller, a disconnected discharge, or a pump that has lost prime. This is the case where the float sensor alone would report normal operation.
The float-switch alarm as a separate layer
The monitoring above tells you what the pump did. It does not tell you that the pump failed to do it. That requires a second sensor at a higher water level.
A high-level float switch is a normally-open contact mounted above the normal trip point. When water reaches it, the contact closes. Wired to a second ESPHome binary sensor, it produces a state change that is independent of the pump’s own float. If the pump’s float fails closed or the pump loses power, the high-level float still reports.
InterNACHI’s guide describes the value of a warning device that signals water build-up, and notes that alarms are especially important in residences that are not occupied for long periods. It also notes that an alarm is not a requirement, which is accurate: it is a second sensor, not a code mandate.
The high-level float should be on a different power path than the pump if possible. If the pump circuit is dead, the alarm circuit should still be live. A battery-backed ESP board or a separate circuit is the practical way to do this. The tradeoff is cost and complexity. A plain mechanical high-water alarm with a 9V battery is cheaper, simpler, and does not depend on the network. For a single pump in a single pit, that is often the smarter choice. The monitoring layer earns its place when there are multiple pumps, when the pit is remote, or when the owner wants a trend rather than a single alarm.
Diagnostic path: from alert to cause
When the high-level float triggers, the sequence is:
- Check whether the pump is running. If the float sensor is on and the pump is silent, the motor or the power is the problem. If the float sensor is off and the water is high, the float is stuck or the switch has failed.
- Check the circuit. A tripped GFCI or breaker explains a silent pump with a closed float. InterNACHI notes the GFCI nuisance-trip concern; the fix is not to remove the GFCI but to understand why it tripped.
- Check the float. With the pump de-energized, lift the float by hand or with a non-conductive tool. InterNACHI specifically warns that no one should ever reach into the pit, and suggests using a household item such as a golf club with a rubber handle to manipulate the float.
- Check the inlet. If the pump runs but moves little water, the inlet screen is the first thing to inspect. InterNACHI notes that the screen can become overwhelmed and that cleanings should occur often for pumps that run constantly.
- Check the check valve. If the pump runs, clears the pit, and the pit refills within minutes with no rain, the check valve is not holding. InterNACHI describes the check valve as the component that prevents backflow into the pit.
- Check the discharge. InterNACHI recommends discharging water at least 20 feet from the building and notes that water should not drain back into the house. A discharge line that is frozen, kinked, or draining too close to the foundation will produce the same symptoms as a failing pump.
The monitoring layer shortens this list. If the cycle count rose before the alarm, the check valve or the inflow is the likely cause. If the runtime rose before the alarm, the inlet or the impeller is the likely cause. If neither moved and the alarm triggered, the failure was sudden: power, float, or motor.
Graceful degradation when the network or power fails
A local-first stack is not immune to failure. It is designed so that each layer fails in a known way.
Network down, power up. ESPHome devices continue to run their local logic and hold their last state. Home Assistant stops receiving updates. The counter and history_stats sensors stop advancing. The high-level float still works if it is wired to a local alarm, but the notification path is gone. The mitigation is a local audible or visual alarm on the ESP board itself, not only a notification. ESPHome supports local GPIO outputs for exactly this reason.
Power down. The pump is down unless it has a backup. InterNACHI notes that power outages are most likely during heavy rains and floods, which are the situations when the sump pump is most needed, and that a backup power source or backup pump is a recommendation rather than a requirement. The monitoring layer should not be the only thing on the circuit. A battery-backed ESP board or a UPS on the network gear keeps the alarm path alive for a while, but the pump itself needs its own backup.
Home Assistant down. The ESPHome device keeps running. The counter and history_stats sensors stop. The data is lost for the duration unless the ESPHome device is publishing to MQTT and the broker is retained. If the broker is on the same host as Home Assistant, that does not help. A separate broker or a local log on the ESP device is the mitigation.
Vendor cloud down. This is the case the local-first stack is built to avoid. If the float sensor, the counter, and the alarm are all local, a vendor cloud outage is irrelevant. If any part of the chain depends on a cloud service, that part is a single point of failure. The tradeoff is convenience versus control, and the sump pump is a poor place to accept the convenience.
When a mechanical timer or plain switch is the better answer
Not every sump pump needs a monitoring stack. A single pump in a single pit, in a house that is occupied, with a high-water alarm that has a battery and a loud buzzer, is already well protected. The monitoring layer adds trend data and remote notification. If the owner is home during the events that matter, the trend data is interesting but not necessary.
The monitoring layer earns its cost when the pump is in a second home, when the pit is in a crawlspace that is not visited, when there are two pumps and the failure of one is not obvious, or when the owner wants to replace the pump before it fails rather than after. In those cases, the cycle count and runtime trend are the difference between a planned replacement and a flooded floor.
A mechanical timer on the pump is a different tool. It does not detect failure. It only limits how long the pump can run. That is useful for a pump that is short-cycling due to a stuck float, but it is not a substitute for a high-level alarm. The two are complementary, not interchangeable.
FAQ
How often should a sump pump be tested? InterNACHI recommends maintenance annually and when the home is sold, and testing by pouring water into the pit to confirm the pump activates and expels the water. A pump that runs constantly needs cleaning more often.
Can I connect the float switch directly to an ESP32? Only if the float is a low-voltage dry contact. If the float is switching line voltage, use a current transformer or an opto-isolated interface, or have a licensed electrician provide a safe tap point. Do not connect line voltage to a microcontroller board.
Why does my cycle count rise when it has not rained? The most common causes are a check valve that is not holding, a discharge line that drains back toward the pit, or groundwater entering the pit from a new path. InterNACHI notes that water should be discharged at least 20 feet from the building and should not drain back into the house.
What is the difference between a high-level float and the pump’s own float? The pump’s float controls the pump. The high-level float is a separate contact mounted above the normal trip point. It closes when water reaches it, which means it reports a failure that the pump’s own float cannot report.
Does the monitoring layer work if the internet is down? Yes, if the components are local. ESPHome devices run local logic, and Home Assistant runs on the local network. The parts that stop working are remote notifications and any cloud-dependent integrations. A local alarm on the ESP board or a separate mechanical alarm covers that gap.
Is a GFCI required on a sump pump circuit? InterNACHI notes that codes recommend GFCI protection for appliances in basements and crawlspaces, but that there is considerable debate among inspectors because a GFCI can trip during safe conditions and deactivate the pump when it is needed. The decision is jurisdictional and site-specific. The monitoring layer does not resolve it; it only makes the consequence visible.
How long should the pump run per cycle? There is no universal number. The correct baseline is the pump’s own history. A pump that has run for 20 seconds per cycle for two years and now runs for 40 seconds is showing a change, regardless of what the absolute number is. The trend matters more than the value.
What if the pump runs but the water level does not drop? If a current transformer confirms the motor is drawing current and the float sensor confirms the pump is on, but the pit does not clear, the problem is downstream of the motor: a broken impeller, a disconnected discharge, a closed valve, or a frozen line. InterNACHI’s discharge guidance is the place to start.
For a broader look at how these small systems fit together, the audit procedure in How to Audit the Small Systems That Quietly Run Your Week covers the same local-first approach applied to other installed systems.