Back with the greenhouse Pi (the one I didn’t expose to the internet, thanks again). It now runs RaspAP as a little access point for six ESP8266 sensors. They publish to mosquitto on the Pi, and a Python script forwards everything to Hermetry as a gateway on v1/gw/telemetry, one child per ESP.
Two power cuts in a week and the SD card came back with a corrupted mosquitto.db once. People say use a read-only filesystem. But I also read that RaspAP “locks” the filesystem or doesn’t like overlays? And my forwarder keeps a buffer in a SQLite file for when the 4G drops. If the filesystem is read-only, where does that go?
Sorry, three questions in one.
SD corruption on power loss is the classic Pi failure. Overlay FS through raspi-config (Performance Options > Overlay File System) works well.
How long are the outages usually? Minutes or hours?
4G drops are minutes. Power cuts are the allotment’s fault, a few hours.
RaspAP doesn’t lock anything, it writes its config under /etc/raspap and the hostapd/dnsmasq files. With the overlay on, any change you make in its web UI is gone after reboot. That’s the “it doesn’t like overlays” story.
A small UPS HAT would stop the power cuts being a problem at all.
Would the readings from the outage still show at the right time when they finally get sent?
I run about thirty of these little gateways on substations, same pattern.
Overlay on for the root filesystem, yes. Do your RaspAP changes with the overlay switched off, reboot, switch it back on. Annoying but rare.
The buffer needs a place that survives reboots and power loss: a second partition on the card (or a USB stick) mounted read-write with ext4 and its journal, outside the overlay. Point SQLite there, with PRAGMA journal_mode=WAL and synchronous=NORMAL. A cut then costs you at most the last few writes, not the database. Move mosquitto’s persistence there too, or turn persistence off since your forwarder already buffers.
On Rachel’s question: yes, if you stamp each reading with ts in UTC milliseconds when the ESP sends it (only if the Pi’s clock is synced, which it is once 4G is up, and keep a fake-hwclock so it isn’t 1970 after a power cut). Send the backlog in batches per child:
{"esp-bed3": [{"ts": 1767254400000, "values": {"soil_pct": 41}},
{"ts": 1767254460000, "values": {"soil_pct": 41}}]}Records land at their own time in history. A message whose every record is older than a minute counts as a replay and has to fit the profile’s replay rate, so a long backlog drains over a while. Don’t panic when it doesn’t all appear in one second. And wait for the PUBACK before deleting rows. See Devices behind a gateway.
Overlay on, buffer.db on a USB stick with ext4, WAL mode, mosquitto persistence off. Pulled the plug during a 4G outage on purpose: Pi came back, the 20 minutes of readings drained over about a minute and sit at the right times on the chart. Emily, thanks, I’d have lost my AP settings without knowing why.
- You must be logged in to reply to this topic.
Join the conversation
Sign in to ask and answer, like helpful posts and mark the reply that solved your problem. Every contribution earns points and levels.