handle_gpio_topic (mqtt_listener.py:272) inserts one gpio_events row per rising/falling MQTT message, with no debounce, dedup, or rate cap. FPP emits an edge event per GPIO transition, so a floating/noisy configured input pin (unwired pin, long unshielded run, failing button) can produce tens–hundreds of edges/sec continuously.
At ~150–200 B/row including the two indexes (idx_gpio_timestamp, idx_gpio_pin), 1.2 GB is roughly 6–8M rows — a couple of days of a stuck pin, or a chattery pin over a season. Each insert also triggers a second write transaction via update_daily_stats() (stats_db.py:49).
Suggested: coalesce repeat edges on the same pin within a short window (e.g. 50–100 ms); optionally cap inserts per pin per second; ignore pins not present in gpio.json; batch the daily_stats update instead of one txn per edge.
Related: retention gaps mean these rows are never pruned afterward (filed separately).
handle_gpio_topic(mqtt_listener.py:272) inserts onegpio_eventsrow perrising/fallingMQTT message, with no debounce, dedup, or rate cap. FPP emits an edge event per GPIO transition, so a floating/noisy configured input pin (unwired pin, long unshielded run, failing button) can produce tens–hundreds of edges/sec continuously.At ~150–200 B/row including the two indexes (
idx_gpio_timestamp,idx_gpio_pin), 1.2 GB is roughly 6–8M rows — a couple of days of a stuck pin, or a chattery pin over a season. Each insert also triggers a second write transaction viaupdate_daily_stats()(stats_db.py:49).Suggested: coalesce repeat edges on the same pin within a short window (e.g. 50–100 ms); optionally cap inserts per pin per second; ignore pins not present in
gpio.json; batch thedaily_statsupdate instead of one txn per edge.Related: retention gaps mean these rows are never pruned afterward (filed separately).