Same physics as David’s speaker, yes. The RF burst gets rectified by the input stage of the ADC (or any semiconductor junction on the line), and that shows up as a DC offset for the length of the burst. 2G-style bursts at 217 Hz are the worst, but LTE uplink bursts do it too. A cabinet I look after at work had exactly your picture, spikes during uploads only.

What fixed ours, cheapest first:

• Get the antenna out of the cabinet. A short-cable antenna on the cabinet roof. Inside a steel box the router is shouting at your wiring from 30 cm.
• Shielded twisted pair for the 4-20 mA run, shield grounded at the controller end only.
• An RC filter right at the ADC pin, 1 k and 100 nF, plus a 100 pF cap close to the pin for the RF itself. Your level doesn’t change in milliseconds, you can afford it.
• A clip-on ferrite on the signal pair where it enters the controller.
• If the router has a setting to lock it to LTE and not fall back to 2G, use it.

After the first two the spikes were gone for us. Old spikes stay in your history, so if anyone set an alarm on that level, check whether they were tripping it. A readings-in-a-row debounce of 2 or 3 on the high-level rule hides any single leftover.

WiFiManager falls back to the portal again if it can’t join, that part’s handled.

For the credential, one shared token is worse than wrong. Hermetry allows one session per device, so 30 boards on one token keep throwing each other off. Use the profile’s provisioning instead. You flash the same firmware with the profile’s provisioning key and secret, and each board asks for its own credential on first start:

// first boot only, after Wi-Fi is up
// MQTT connect: username "provision", empty password, TLS
subscribe("v1/provision/res");
publish("v1/provision/req",
  "{"deviceName":"logger-" + chipId + "","
  ""provisionDeviceKey":"pk_...","provisionDeviceSecret":"ps_..."}");
// answer: {"status":"SUCCESS","credentialsType":"ACCESS_TOKEN","credentialsValue":"..."}
// store credentialsValue in NVS, reconnect with it, never provision again

On the profile’s Provisioning tab you pick a strategy. With Allow creating new devices, each new board lands in quarantine and its data is dropped until an admin activates it. With Only pre-provisioned devices you create logger-<chipId> names beforehand from your 30 boards, and a leaked key can’t add strangers. For 30 units I’d pre-create them. Hermetry never re-issues a credential for an existing name, so keep the token safe in NVS. Details on Adding and claiming devices.

Both of those are your problems, I had the same pair on battery water meter tags last year.

Current: the UART peripheral being enabled keeps the HF clock up, that alone is hundreds of uA when active and tens when idle. Set CONFIG_SERIAL=n and CONFIG_LOG=n in the release build (or CONFIG_PM_DEVICE and suspend the UART). Also enable the DC/DC (CONFIG_BOARD_ENABLE_DCDC=y, needs the inductor fitted on your board), and make sure unused GPIOs aren’t floating. That got us from about 35 uA to 3.

Online status: for child devices Hermetry takes the online state from the gateway’s v1/gw/connect and v1/gw/disconnect messages, so your gateway is telling it the tags are gone. With 60 s advertising and a 60 s timeout, one missed advert means a disconnect. Make the gateway wait for 5 missed adverts before sending disconnect.

For the alarm, set the Device offline rule’s Open after to something like 900 seconds so a short gap doesn’t page anyone. More on how child status works: Gateways and devices behind a gateway.