Raspberry Pi on site: when it is a sound choice

When it is fine

When the device collects and forwards data but controls nothing. A gateway polling meters over Modbus and pushing readings upstream is a good case: if it hangs for ten minutes you lose ten minutes of chart, not a batch of product.

When someone nearby can restart it. A staffed site within an hour’s drive is an acceptable risk.

When the solution is still being found. While it is unclear which data actually matters, a Pi lets you test the idea in a week instead of a quarter of approvals. Replacing it with industrial hardware later is routine work; a quarter spent building the wrong feature is not refundable.

When it is a firm no

When human safety or equipment integrity depends on the device. Emergency stops, interlocks and protection are the job of a certified controller, and no saving justifies otherwise.

When the site is unmanned and out of reach. A device four hours away has to bring itself back up after any failure — and at that point the price difference in hardware stops mattering.

Three things that kill a Pi on site

Power. A cheap supply is the most common cause of "unexplained freezes". Under voltage sag the board behaves unpredictably, and it looks exactly like a software bug that it is not.

The SD card. Continuous log writing wears a card out in months. The fix is buffering writes in memory and flushing rarely — or a proper drive instead of a card.

Heat and dust. An outdoor cabinet in summer is not room conditions. An enclosure, ventilation and a filter cost less than a single site visit.

Doing it properly

The device must recover on its own: a service with autostart, restart after failure, a watchdog timer. Updates go remotely and must be reversible, otherwise one bad update becomes a road trip.

Above all, the device must report its own trouble. One that silently stopped sending data is worse than one sending an error.

Frequently asked