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”.

Hermetry takes MQTT 3.1.1 and HTTPS from devices, plus LoRaWAN through its own network server and polled SNMP and cameras. No MQTT-SN, no CoAP. So for anything non-IP the answer is a gateway on site that speaks the field side and talks MQTT up. Two ways I’ve done it:

Licensed gateway with Hermetry Edge. It reads Modbus RTU over RS-485 and Modbus TCP (depends on the model), dials out over TLS with its own certificate, buffers during outages, and each inverter appears as its own child device. You claim it with the code on its local Cloud page, nobody types credentials on site.

Your own gateway. A Pi or industrial PC reads the buses with pymodbus, reads the weather station’s serial radio and a 433 MHz receiver, and publishes for all of them on v1/gw/connect and v1/gw/telemetry:

{"INV-07": {"ts": 1793000000000, "values": {"p_ac_kw": 41.2, "e_day_kwh": 188.4}},
 "WX-1":   {"values": {"irradiance": 612, "t_amb": 9.8}}}

Mark the device “This device is a gateway” when you add it, or every v1/gw message is refused and the session gets closed after three. If the inverters ever need commands, you send them to the child device and the gateway receives them on v1/gw/rpc. Your own gateway has to pass them on to the bus, a licensed one does that for you.

For a site that is probably unattended for weeks, I’d pay for the licensed box.