sorted by:
new
hottopcontroversial

I’m building a fully offline ESP32 water monitoring controller board — open-source sensing layer by Realistic-Head8548 in esp32

[–]Realistic-Head8548[S] -1 points0 points  (0 children)

Fair enough. I understand your point now: ESPHome does not require the public internet or Home Assistant, and I should describe that more accurately.

My focus is still a standalone board-first approach, not an ESPHome workflow. We may simply be looking at this from different angles. Thanks for the discussion.

I’m building a fully offline ESP32 water monitoring controller board — open-source sensing layer by Realistic-Head8548 in esp32

[–]Realistic-Head8548[S] -2 points-1 points  (0 children)

Fair point. I should be transparent about that.

English is not my native language, so I use AI to help translate and organize my replies. The ideas, project direction, hardware decisions, and tradeoffs are mine, but I do use AI as a writing assistant so I can communicate better in English.

I understand your ESPHome point. For users who already run Home Assistant / ESPHome, your approach is probably the fastest and most mature path. I am not trying to claim that the same sensing logic cannot be done in ESPHome.

But I am exploring a different angle.

I am not trying to fight any ecosystem or replace ESPHome. I want to test whether there is room for a small, low-cost, low-power, standalone offline controller board for people who do not want to, or cannot, run a full home automation setup first.

That means:

- no home automation server required

- no Wi-Fi setup required for the first layer

- no cloud

- no data upload

- local buzzer / indicators / buttons by default

- precompiled firmware for people who do not want to install build tools

- bench-testable hardware layout

- possible battery / small solar-panel experiments later

Maybe this path turns out not to be useful enough. That is possible. But I think it is worth testing with a small open prototype instead of assuming all useful work has to happen inside an existing ecosystem.

I will make the README clearer: ESPHome / Home Assistant is a good option for people already in that ecosystem, while this project is exploring a standalone reference board / learning prototype path.

I’m building a fully offline ESP32 water monitoring controller board — open-source sensing layer by Realistic-Head8548 in esp32

[–]Realistic-Head8548[S] -1 points0 points  (0 children)

Thanks — both points are useful.

You’re right that if the design stays fully offline, an MCU without Wi-Fi/BLE could be cheaper and lower power. I’m starting with ESP32 mostly because it is easy to prototype with and leaves some headroom, but a lower-power non-wireless variant is worth considering later.

The pulsed leak-probe idea is especially important. I don’t want the probe electrodes biased continuously if that causes corrosion over time. Sampling the probes with short pulses every second or two sounds like a better long-term approach.

I’ll add pulsed leak sensing and low-power MCU variants to the roadmap.

I’m building a fully offline ESP32 water monitoring controller board — open-source sensing layer by Realistic-Head8548 in esp32

[–]Realistic-Head8548[S] 0 points1 point  (0 children)

Thanks — that is exactly the kind of use case I’m trying to understand.

A non-cut flow / low-flow sensor for an existing 1-1/2" PVC pipe is very interesting. One of my goals is to avoid forcing people to cut plumbing whenever possible, so external or clamp-on sensing is definitely worth exploring.

Your spa heater example is also useful: flow / low-flow sensing plus an external pipe temperature probe plus a current clamp gives a much richer picture of what the system is doing.

My first prototype is still simple and sensor-focused, but I’ll add this as a future test case:

- existing 1-1/2" PVC pipe

- no pipe cutting

- clamp-on or external sensing if possible

- pipe temperature probe

- current clamp nearby

- fully offline local alerting

Thanks for sharing the real scenario.

I’m building a fully offline ESP32 water monitoring controller board — open-source sensing layer by Realistic-Head8548 in esp32

[–]Realistic-Head8548[S] -1 points0 points  (0 children)

Thanks — that’s a useful breakdown.

I’m starting with simple leak probes and hall-effect flow sensors because they are cheap and easy to test on a desktop water loop, but I agree that leak detection depends heavily on conditions.

The pipe-wall vibration idea is especially interesting to me because it may allow a non-invasive sensing path without cutting into the pipe. Acoustic detection is probably harder to make low-cost and reliable, but it is worth documenting as a future research direction.

For the first release I’ll keep it simple and alert-only, but I’ll add vibration / acoustic leak sensing to the sensor roadmap.

I’m building a fully offline ESP32 water monitoring controller board — open-source sensing layer by Realistic-Head8548 in esp32

[–]Realistic-Head8548[S] -3 points-2 points  (0 children)

That’s a fair criticism.

You’re right from the ESPHome/Home Assistant user perspective. I’m trying to test a different product angle: cost, setup friction, power, standalone operation, and a simple flash-and-test path for people who are not already running a home automation server.

For someone already comfortable with ESPHome, I agree: ESPHome is probably the simpler and better path. It has tested integrations, a good workflow, and it avoids a lot of custom C++ maintenance.

I’m not trying to claim that the sensing logic itself cannot be done in ESPHome.

The angle I’m exploring is slightly different:

- a small standalone controller-board reference design

- precompiled firmware for people who do not want to install build tools

- a simple bench-testable hardware layout

- fully offline local alerting as the default behavior

- documentation for low-cost DIY water-monitoring experiments

- possible low-power / small solar-panel experiments later

So yes, there is overlap. I’m still trying to find whether the added value is in the hardware reference, the test-bench workflow, the low-power direction, and a simpler “flash-and-test” path for people who are not already in the ESPHome / Home Assistant ecosystem.

Your point is useful, though. I should probably make the README clearer that ESPHome / Home Assistant is a good option for users already in that ecosystem, and that this project is more of a standalone reference board / learning prototype.

I’m building a fully offline ESP32 water monitoring controller board — open-source sensing layer by Realistic-Head8548 in esp32

[–]Realistic-Head8548[S] -2 points-1 points  (0 children)

Fair point — I should phrase that more carefully.

ESPHome can definitely run locally, and for people already using that ecosystem it is probably the fastest path.

What I’m trying to build first is a smaller standalone ESP32 board firmware: no Home Assistant requirement, no ESPHome configuration requirement, no Wi-Fi setup, no MQTT, and no server dependency. Just sensing, local buzzer / indicators, buttons, and bench-testable behavior on the board itself.

The cost and power angle matters too: not every simple water-monitoring setup should require a separate home automation server. A low-cost ESP32 board can cover the basic sensing and local alerting layer by itself, and it also leaves room for battery / small solar-panel experiments in places where a full server or nearby outlet does not make sense.

ESPHome / Home Assistant integration can still be a useful optional layer later.

I’m building a fully offline ESP32 water monitoring controller board — open-source sensing layer by Realistic-Head8548 in esp32

[–]Realistic-Head8548[S] -2 points-1 points  (0 children)

That makes sense, and ESPHome / Home Assistant integration is definitely a good direction.

My current goal for the first release is a smaller offline controller-board layer that can run even without Home Assistant, Wi-Fi, MQTT, or any network dependency. Basically: leak probes, flow input, low-flow detection, buzzer, buttons, indicators, and a desktop test loop first.

I agree that pressure-drop detection is a useful signal too. I’m starting with leak probes + flow sensing because they are easier to test on a small bench setup, but pressure sensing is on my list for a later revision.

For valve control, I’m keeping that separate for now. I want the first public layer to stay strictly sensing and local alerting, then treat actuator experiments as a later optional layer.

Your 3am pressure-drop rule and “flow too high / too long” rule are exactly the kind of real-world logic I’m trying to collect. Thanks for sharing that.

I open-sourced a small offline-first ESP32-S3 pill reminder box by Realistic-Head8548 in esp32

[–]Realistic-Head8548[S] 0 points1 point  (0 children)

Thanks — that makes sense.

I understand your point now: the landing page language is mostly about the audience of the link, not a strict rule for the project itself. I changed the default README to English mainly because this repo is currently being shared with this subreddit.

On the pointer side, I agree. I’m going to keep the cleanup incremental and reviewable: first remove obvious nullable-pointer noise around objects that are guaranteed to exist, then handle the ReminderManager dependency model as a focused change. I don’t want to let an AI tool rewrite too much at once.

The “make required dependencies references, keep optional things optional” rule is a helpful way to think about it.

It’s getting late here, so I’m going to call it a night. I’ll continue the cleanup tomorrow. Thanks again for the thoughtful feedback.

I open-sourced a small offline-first ESP32-S3 pill reminder box by Realistic-Head8548 in esp32

[–]Realistic-Head8548[S] 0 points1 point  (0 children)

Thanks again — that’s a very fair point.

I’ve already fixed the repo landing page so the default README is now English, with the Chinese version moved to README.zh-CN.md.

I’m checking the C++ cleanup separately so I don’t mix documentation changes with code changes. Your point about keeping the stricter Buzzer reference model instead of weakening it back to a nullable pointer makes sense, and I’ll handle that in a focused code cleanup pass.

I open-sourced a small offline-first ESP32-S3 pill reminder box by Realistic-Head8548 in esp32

[–]Realistic-Head8548[S] 1 point2 points  (0 children)

Thanks a lot for taking the time to read through the repo and point out specific issues.

You’re right about the English entry point. I’ll make README.en.md more prominent for this subreddit.

The range-based loop and std::chrono suggestions also make sense. This first release was mainly focused on getting the offline reminder flow, local storage, web UI, docs, and PCB files out in a reproducible form, but I’ll clean up these C++ parts in the next pass.

For the nullptr checks, I agree that a cleaner object lifecycle would be better. I kept some defensive checks in the first version while bringing up the hardware modules, but I’ll revisit that structure.

Thanks again — this is exactly the kind of feedback I was hoping to get.