Machine Monitoring Case Study: Overheat Alarm Handled on the Sensor While Wi-Fi Was Down
A temperature sensor on a machine takes one reading a second. When the machine runs hot, the fan has to come on right away, whether or not the plant’s Wi-Fi is working. In the Alpha demo this device runs the AltSql engine on 64 KB of flash with 1,048 bytes of engine RAM, and it makes that call by itself.
The run covers one simulated hour. Wi-Fi drops out from minute 20 to minute 35. Two gateways listen: gateway A receives every record, and gateway B, which stands in for a constrained link, receives only the minute summaries and the fan state.

The hour as the engine stored it: one reading a second, the 60 °C rule, the three times the sensor switched the fan on, and the Wi-Fi outage.
The Set-Up
| Machine sensor | |
|---|---|
| Device | 64 KB of flash in 16 sectors of 4 KB; 1,048 bytes of engine RAM on a 32-bit chip |
| Readings | One a second for an hour, in the series raw (time, temp) |
| Kept on the device | Raw readings, a minute summary (minute: min, avg, max) and the fan state as a key-value setting |
| Rule on the device | Above 60 °C for 10 seconds: alarm raised, fan on. Back under 55 °C: alarm cleared, fan off |
| Link | Wi-Fi, down from minute 20 to 35. Gateway A gets every record; gateway B gets minute summaries and the fan state |
The rule is a few lines of C on the sensor. The device reads its own last ten seconds from its own database:
altsql_append(db, "raw", (int64_t)t, temp);
altsql_ts_window(db, "raw", "temp", t - 9, &hot); /* the last 10 seconds */
if (!fan && hot.count == 10 && hot.min > 60.0) {
altsql_put(db, "alarm", msg, strlen(msg));
altsql_put(db, "fan", "on", 2); /* decided on the device */
}
What Happened
- 05:31. Above 60 °C for ten seconds: the sensor raised the alarm and switched the fan on. At 06:19 the temperature was back to normal, and the sensor cleared the alarm and switched the fan off.
- 20:00. Wi-Fi down. The sensor kept measuring and kept its readings in flash.
- 26:59. The machine overheated again, with Wi-Fi still down. The sensor decided on its own, exactly as before, and switched the fan off again at 28:19.
- 35:00. Wi-Fi back. The sensor caught up in one go: 24,128 bytes to gateway A and 702 bytes to gateway B.
- 48:21. A third hot spell, fan on; back to normal at 48:54.
At the end of the hour gateway A held all 3,600 readings, including the 900 taken during the outage. Messages lost on the way were simply sent again, and the sequence numbers let the gateways skip anything they already had.
What the Gateways Can Answer
Gateway B never received a single raw reading. From the minute summaries alone it can still find every hot minute:
gateway-B> SELECT time AS minute, max FROM minute WHERE max > 60
minute max
5 64.99
6 64.74
26 67.35
27 67.96
28 67.97
48 64.98
Gateway A has the full detail, stored exactly as the sensor wrote it, so it can answer at once with no conversion step in between:
gateway-A> SELECT COUNT(*) AS readings, AVG(temp) AS avg, MAX(temp) AS max FROM raw
readings avg max
3600 46.45 67.97
These are the answers the demo gives after a run without power cuts. Both queries are among its ready-made questions.
The Numbers
| Over one hour | Bytes |
|---|---|
| Sent to gateway B, the constrained link | 2,533 |
| Every record, as stored (what gateway A received) | 96,133 |
| Every reading as lean JSON | 190,800 |
| Saving from deciding on the device (records ÷ sent) | 38 times |
| Saving from the format (JSON ÷ records) | 2.0 times |
| Flash written on the device | 104,204 |
| Sector erases | 25 |
What the Alpha Revealed: Flash Wear
This device is also the Alpha’s warning. One reading a second into 64 KB of internal flash rated for 10,000 erase cycles would wear the flash out in about nine months (computed from the bytes written in the demo). The fix is in the set-up, and the engine stays the same: storing 10-second summaries instead stretches that to about 4.5 years, 100,000-cycle external NOR flash to about 7 years, and 1 MB of it to over 100 years. The Alpha page has the numbers.
Next: On Real Hardware
In the Beta the machine sensor becomes an ESP32-C6 board (RISC-V) with a temperature probe on a motor or heater and a relay for the fan, reporting to a Linux gateway over Wi-Fi. The access point gets switched off and on to make the outages real, and the board’s power gets cut while it writes. The target is 10,000 real cuts with no acknowledged write lost.
Later: With the Learned Query Optimizer
A fixed 60 °C rule is blunt. It misses a bearing running 8 °C hot at half load, yet fires on a machine that always runs warm in summer. The planned Learned Query Optimizer would learn each machine’s normal temperature for its load, keep the 60 °C rule as a hard limit, store full detail around incidents and summaries otherwise, and send alarms first after an outage. These are expectations, to be tested after the Beta.
Try It Yourself
Open the live demo, press Play and pull the plug on the machine sensor during a hot spell. The hour goes by in under a minute, so Pause and Resume help to catch one. The sensor reboots, checks every record it had saved, reads its fan state back from its own database and carries on.