When every reading is zero

The same symptom, five causes

Pick what you are seeing.

Almost everything on this page is a working sensor. That is the difficulty: an ultrasonic module has no error to report, so every failure arrives as a zero, and a zero is also a perfectly valid thing for the sketch to compute.

Start with a wall

Before any debugging at all, point it at something flat, hard and about a metre away.

Most reports of a dead sensor are a sensor aimed at a ceiling, a carpet, a curtain or the open room. All four return nothing, and nothing converts to zero. If a wall produces sensible numbers, the sensor is fine and the project needs to handle no-echo rather than the sensor needing replacing.

Then check the three wires that are not the signal

In order: is GND connected, is VCC on a rail that is actually live, and are ECHO and TRIG the right way round. Swapping the two signal pins gives silence, not an error — your board triggers the pin that was going to answer, and listens to the pin that was meant to be asked.

Count from the square pad. Once the board is in a breadboard the printed labels are face down, and being one position out looks exactly like a dead sensor.

Zero is not a distance, and neither is the maximum

This is the fault that survives into finished projects.

pulseIn returns 0 when it times out, and 0 µs converts to 0.0 cm without complaint. A library that returns a distance instead may hand back its maximum. Either way the project receives a confident number about a measurement that did not happen — and "0 cm" means "something is touching the sensor", which is usually the state that triggers whatever the project does.

Check for the timeout before converting, and give it a value the rest of your code can recognise:

unsigned long us = pulseIn(ECHO_PIN, HIGH, 25000UL);
if (us == 0) {
  // Not a distance. Nothing came back, and there is no way to tell
  // "absorbed" from "angled away" from "there is nothing there".
  return -1.0;
}
return (us / 2.0) * 0.0343;

And the timeout itself

Without that third argument, pulseIn waits a full second. A sketch that also drives a display or answers a network will visibly freeze every time the sensor sees nothing — and seeing nothing is not an edge case here, it is Tuesday.

The library Lonely Binary's documentation points at calls pulseIn with no timeout in both its GPIO and 1-Wire paths, so this is inherited by anyone who starts from the vendor example. It is a one-argument fix and it is worth making before anything else.

If you changed a jumper

Power-cycle, then inspect. Those two, in that order, account for nearly every report of a board that stopped working after a visit from the soldering iron — and the two solder bridges has the detail on which pad is which.