When the scan finds nothing

Run the scanner first

Before any sensor sketch, run an I²C scanner. It answers a question the sensor sketch cannot: is this a wiring problem or a code problem?

#include <Wire.h>

void setup() {
  Serial.begin(115200);
  while (!Serial) delay(10);
  Wire.begin();

  Serial.println("scanning");
  for (uint8_t a = 1; a < 127; a++) {
    Wire.beginTransmission(a);
    if (Wire.endTransmission() == 0) {
      Serial.print("found 0x");
      Serial.println(a, HEX);
    }
  }
  Serial.println("done");
}

void loop() {}

A healthy TK120 reports found 0x44, and nothing else on the board can produce that line. If you get it, the wiring is right and any remaining problem is in your sketch or your library.

If you do not, the next question is which of four things is wrong — and they are told apart by the lines, not by the sketch.

What the lines should be doing

With power on and nothing talking, both SDA and SCL should sit at VCC. That is what the board's two pull-up resistors are for, and it is the resting state every I²C exchange starts from. Put a multimeter on each in turn against ground: 3.3 V, or 5 V if that is what you fed it.

That one measurement splits the failures in half.

Both lines at VCC and the scan finds nothing. The bus is electrically fine, so it is a wiring mistake that preserves the pull-ups. In practice it is SDA and SCL swapped — both still have a resistor on them, so both still idle high, and the board looks flawless. Swap them back, counting from the square pad.

Lines wandering, or well below VCC. Nothing is pulling them up. Either the board is not powered at all, or the I2C PULL-UP jumper has been cut, or GND is not connected — which leaves the sensor with no reference and can still let the power light glow, borrowing a return path through the signal lines' protection diodes.

The two failures that answer

Two more get as far as an acknowledgement, and both need the scan plus a sketch to spot.

The scan finds 0x44 and the readings are rubbish. Two of these boards are on the bus with both ADDR jumpers open. They are both at 0x44, both acknowledge in the same slot, and a scanner cannot count them — it sees one device where there are two. Bridge one board's ADDR pads and rescan; you should see two addresses.

The scan finds 0x44 and every read fails. The sensor is there and answering and its six bytes are not surviving the journey: one of the two checksums did not match, so the library threw the reading away rather than printing a number that was wrong by eighty degrees. That is the bus being marginal — long wires, too much capacitance, or a clock faster than the wiring can manage.

The order to check things in

1. Is the power light on? If not, VCC and GND before anything else.
2. Do both signal lines read VCC? If not, GND, then the pull-up jumper, then the supply.
3. Does the scanner find 0x44? If not, SDA and SCL are swapped.
4. Does it find 0x45 instead? Somebody bridged the ADDR pads. Either unbridge them or pass 0x45 to begin().
5. Does the sketch read but fail? Shorten the wires, drop to 100 kHz, and retry failed reads instead of treating one as a fault.

None of those five steps needs code you have not already got, and four of them are faster than recompiling.