As far as I know Espressif has never officially said what WROOM stands for, so don’t trust the three answers you found. In practice it’s their name for a module family: the chip, flash, crystal and antenna on one shielded board you can solder on.

The suffixes:

• WROOM = module without PSRAM, WROVER = with PSRAM, MINI = smaller footprint.
• -E = ESP32 chip revision 3 (fixes several early silicon bugs). Buy E, not the old plain -32.
• U in the name (32UE) = u.FL connector for an external antenna instead of the PCB antenna.
• N4/N8/N16 = MB of flash, R8 = MB of PSRAM.

For your station: a DevKitC board with a WROOM-32E N4 to start, like Aisha has. 4 MB flash leaves room for two OTA partitions if you ever want to update it over the air. If the box ends up outdoors in a metal housing, switch to the 32UE as Grace said. Wake every 5 minutes, send one HTTPS POST to Hermetry’s device API, sleep: that keeps the board cool too, so it doesn’t heat the sensor.

Did my master’s on state estimation before I drifted into IT, so this one I can answer.

Rahul is right that you check rank, just locally. Linearise at the current estimate: F = df/dx, H = [1 0 0]. Build O = [H; HF; HF^2] and check its rank (or better its condition number) along the trajectory. With your model, the q_in and k columns of HF are dt/A and -dt/A*sqrt(h). They’re independent only if sqrt(h) changes over the window. When the level sits still, O drops to rank 2 and the filter can trade q_in against k forever, which is exactly what you see.

What I’d change:

Give the two states different time scales. k changes over months, q_in over minutes. Make the process noise of k tiny (orders of magnitude below q_in) so the filter only moves k when there is evidence.

Use the excitation you have. When the pump runs, Q_p is known and the level moves, which is when k becomes identifiable. Some people only update k during pump cycles and dry-weather periods where q_in is near zero.

Keep k positive: estimate log(k), or clamp it.

If budget allows, one outlet flow measurement once a week (a portable meter) pins k and the problem goes away.

For the ops board, send the diagnostics too, not just the estimates:

{"h_m": 2.41, "q_in_ls": 38.2, "k_est": 0.0164, "innov_m": 0.004, "obs_cond": 1.2e3}

A chart of the innovation and the condition number tells you when to trust k. An alarm rule on obs_cond above some limit with a duration debounce is a cheap way to flag « k estimate unreliable right now ».