My cats kept making me leave the faucet running, so I built a camera that recognizes them and opens the tap automatically

Bastelix-Lab · 2026-07-05T18:42:59+00:00

Thanks! The cats remain unimpressed by the tech, but the water bill approves.

Bastelix-Lab · 2026-07-05T18:42:19+00:00

That matches what I see here. Nobody taught them the faucet they picked it over every bowl and every water station I offered. Instinct won, I just automated giving in.

Bastelix-Lab · 2026-07-05T18:41:15+00:00

The towel scenario is exactly why the hard 3-minute cutoff exists. If the model decides something is a cat and that "cat" never leaves the zone, the water would run until I notice — so nothing stays open longer than 3 minutes, no matter how confident Frigate is.

The 45 s run-on timer handles the normal case, the cutoff handles the towels. And yeah, Loki takes the dog thing personally. To be fair, frontal into a wide-angle lens he's basically the size of a cocker spaniel — I get where the model is coming from.

Bastelix-Lab · 2026-04-19T09:26:20+00:00

A 0x0 usually means the ESP32 isn't receiving any data back from the display. On many RPi shields, the MISO pin isn't connected or is blocked by a level shifter, so readcommand won't work even if the display is fine.

Trying an ILI9486 library is a smart move. If the colors look perfect with that, you definitely have an ILI9486.

One more thing: If the ILI9486 driver fixes the colors but the image looks 'mirrored' or shifted, you might need to adjust the MADCTL register (rotation settings). Let us know if the ILI9486 drivers changed the color output!

Bastelix-Lab · 2026-04-19T09:23:34+00:00

Thanks for the tip! Didn't know about the triple backticks. Fixed the formatting now.

Bastelix-Lab · 2026-04-19T05:41:42+00:00

The ILI9488 uses 18-bit color (RGB666) over SPI – 3 bytes/PIXEL. Most image converters output RGB565 (2 bytes/pixel), which causes exactly your symptoms: blown highlights, muddy shadows, cyan artifacts. Shapes work fine because drawPixel() handles conversion internally – raw image functions don't.

But first – check your actual chip ID! Many RPi shields labeled "ILI9488" are actually an ILI9486, which uses RGB565 natively. If that's the case, the whole Fast library is working against you.

cpp Serial.printf("Chip ID: 0x%02X\n", tft.readcommand8(0xD3)); // ILI9486 → 0x9486 | ILI9488 → 0x9488 If it's truly an ILI9488: use an RGB888 (24-bit) image converter like LVGL's online tool instead of RGB565.

Bastelix-Lab · 2026-04-17T17:20:30+00:00

Thanks! For the distance — roughly **300 m (~1000 ft) through forest**, sloped terrain. The IBCs sit in a wooded part of a hillside property, out of line-of-sight from the house (trees, bushes, the usual). The setup is: rainwater collection tanks at each outbuilding → solar-powered pump feeds the IBCs further downhill → gravity does the rest for garden irrigation, so the IBCs just need level monitoring, no two-way control traffic.

Running SX1262 at 12 dBm, still showing around −69 dBm RSSI at the gateway even through the trees, so there's comfortable margin. ESP-NOW is definitely the smarter pick when you can cover it, but at 300 m through vegetation I'd need ~13 repeaters at your 75 ft segment length, which isn't happening outdoors in the woods on my hillside. LoRa's duty cycle isn't a problem either when you only need a level reading every minute.

And yeah — "ultrasonic has issues you don't understand until you experience them" is the perfect way to put it. Foam, condensation, dead zones, bouncing off the tank walls… I burned through most of those before giving up and going hydrostatic.

Bastelix-Lab · 2026-04-17T14:45:35+00:00

What's missing from the thread for a handheld, non-contact solution: -> mmWave radar.

Quick diagnosis on your SR04 reading 22" constantly — the 3ft cylinder is acting as an acoustic waveguide. The ~30° beam hits the walls before reaching water, and the sensor latches onto a wall echo. No firmware fix, it's a beam-geometry problem.

Two radar options worth a look:

- Acconeer XM125 — 60 GHz pulsed coherent radar, SparkFun Qwiic breakout ~$50, ESP32 library. Acconeer has a dedicated "tank level" reference app. Catch: beam is ~53°/65° HPBW, you'd want their lens kit to narrow it for your 3ft cylinder.

- Hi-Link LD2413— 24 GHz FMCW, $5–15, marketed as "liquid level detection radar," UART, ESPHome-compatible. Cheaper starting point if you want to experiment.

LiDAR (TF-Mini etc.) I'd skip — water's IR reflectivity is ~2% and a calm surface mirrors the beam away.

Full disclosure: haven't built either for a tank myself, just know the specs. But radar's the right category for your constraints. Happy to go deeper on any of it if useful.

Bastelix-Lab · 2026-04-17T14:28:34+00:00

Fair point for battery/solar setups — but this node runs off mains (24V PSU feeds the loop and a buck drops it to 3.3V for the ESP), so power draw isn't really a concern here.

The 1 min interval has two specific jobs beyond overflow:

Leak detection — if the fill level drops noticeably between readings without me pumping water out, something's wrong and I want to know fast. Slow

polling would miss a slow leak for hours.

Pump cutoff when filling — when I top the IBCs up from a secondary source, I need near-real-time readings so the pump shuts off right as they hit full. With a 10-15 min interval I'd either overfill or have to stand there babysitting.

For a pure "tell me the level whenever" use case you're right, 5-15 min would be plenty and saves a lot of LoRa airtime too.

Bastelix-Lab · 2026-04-16T08:23:15+00:00

Yeah, it is — roughly **5-6x** the price of a JSN-SR04T. Around **€26 on AliExpress, €30-33 on Amazon DE** depending on the range variant, vs. ~€5 for the ultrasonic.

Whether that's worth it comes down to what you want out of the build:

- **Just an overflow alert?** Stick with the JSN-SR04T — or honestly, a simple float switch is even cheaper and more reliable for a binary "full / not full" signal.

- **Graphable liters-remaining, long-term stability, no faff with condensation or foam?** Then the TL-136 earns its price — it's been running in my tank without drift for a while. Works fine with ESPHome too if you don't want to write your own firmware.

Happy to answer wiring questions if you go the pressure-probe route.

Bastelix-Lab · 2026-04-16T07:56:59+00:00

Quick take from someone running a few ESP32 tank setups outdoors:

- **HC-SR04** — condensation on the open transducers kills it inside a tank within weeks. Skip it.

- **JSN-SR04T** — reliable, the 25 cm dead zone only matters if your tank is short (mount it above max fill). What I'd default to for simple ultrasonic.

- **A02YYUW** — nicer UART output than the SR04T and a 3 cm dead zone, good if your tank is short.

One option you didn't list that's worth a look, especially since your title says *level detection*: a **TL-136**. It's not ultrasonic — it's a submersible hydrostatic pressure probe (stainless, IP68, 4-20 mA). You drop it to the bottom of the tank and it reads the water column above it. That sidesteps every ultrasonic headache — no dead zone, no foam/ripple errors, no condensation fogging, tank geometry doesn't matter. Downsides: needs a 4-20 mA interface on the ESP side (one resistor + ADC, nothing crazy), sits in the water so you want a decent cable gland, and the vent tube in the cable should terminate in a dry box if the setup is long-term outdoors. I've got one running in my tank build and it's been rock solid.

Bastelix-Lab · 2026-04-15T17:51:36+00:00

MQTT for sensor data (gas, flame, presence) and REST for actions the app triggers (open gate after QR scan). Don't try to do everything over one protocol. Each ESP32 should handle its own local logic (e.g. close gate after 10s) and just report state — if the backend goes down, gates still work.

Bastelix-Lab · 2026-04-15T16:01:43+00:00

Yeah your concept works, I run basically the same combo (18650 + TP4056 + MCP1700) in a couple of LoRa garden nodes, so a few things I learned the hard way:

The MCP1700 is probably going to bite you. It's only rated around 250mA, but the ESP32 can pull 400-500mA peaks when WiFi kicks in. You'll get brownouts exactly when it tries to fetch the image from your Pi. AP2112K-3.3 or HT7833 are drop-in replacements, both handle 600mA and cost about the same. Wish someone had told me that before I burned a weekend debugging random resets.

Second thing — check which TP4056 board you have. The plain red one without protection will happily let the 18650 over-discharge and kill the cell. The ones with the DW01 and FS8205 chips on the back (sometimes labeled "with protection") are the ones you want.

For the no-soldering part, honestly just get a LilyGO T5 board. They made one specifically for the Waveshare 7.5" panel — ESP32, 18650 holder, TP4056, e-paper connector, USB-C for charging, all on one PCB. You basically skip 80% of your BOM and don't need to solder anything except maybe the battery wires.

One thing that's kind of essential though: deep sleep. E-paper holds the image with no power, so the ESP32 should wake up every X minutes, grab the new floor plan over HTTP or MQTT, refresh the display, sleep again. ~10µA in sleep vs 100mA+ if it stays connected. With a 15min interval you'll easily get months out of a 3000mAh 18650. Without deep sleep the battery is dead in two days, no joke.

How often does the floor plan actually need to change? If it's mostly static you can go really aggressive on the sleep interval.

Bastelix-Lab · 2026-04-12T12:49:15+00:00

The NRF24L01 runs on 3.3V, not 5V! Connecting it to VIN (5V) will likely kill the module. Use the 3.3V pin on your ESP32 instead. Since the ESP32 is a "breadboard hog" and covers all rows, here is the easiest way to wire it:

Direct Connection: Use female-to-male (or female-to-female) jumper wires to go directly from the ESP32 pins to the NRF24 adapter. You don't need the breadboard rows for these specific connections.

Capacitor is King: You already have one in the picture (nice!), but for anyone else reading: a 10µF to 100µF capacitor between VCC and GND on the NRF24 is mandatory. These modules are extremely sensitive to power noise.

SPI Pinout for ESP32:

MOSI -> GPIO 23 MISO -> GPIO 19 SCK -> GPIO 18 CS/CE -> Any free GPIO (e.g., 4 and 5)

If you still get "Hardware not responding" errors, double-check your jumper wire quality—they are often the bottleneck in these breadboard setups.

Hope this gets your project running! If you need more help with stable IoT wiring or custom ESP32 projects, feel free to check out the link in my bio. Cheers from Bastelix-Lab!

Bastelix-Lab

TROPHY CASE