Prepare a monitoring Pi for an update

Identify the layer being changed

Application code, operating-system packages, firmware and a replacement image are different changes. Read the release instructions and identify exactly which layer the procedure affects. Do not combine unrelated upgrades just because you have opened a terminal.

Raspberry Pi’s configuration documentation covers system and firmware administration. An application image may have its own supported update path, so generic OS commands are not automatically a suitable Sunstead upgrade procedure.

Write the reason and expected result

Record the problem being fixed or capability being added, the current version and the intended version. Read compatibility notes for the board, equipment readers and any data-format changes. If you cannot identify an expected benefit, first establish why the change is needed.

The example does not claim such a release exists. It demonstrates a testable change statement instead of “make everything current.”

Make the recovery option real

Identify where settings and history live and what your backup contains. Confirm that it can be read. Keep the prior release information and a recovery medium if the documented procedure calls for one.

A copied installer is not a copy of current data. An untouched old card may preserve a previous installation, but data collected after that copy will be absent. Write down that time boundary so rollback does not silently erase the meaning of your history.

Choose a maintenance window

Use a time when someone can observe the host and when a temporary monitoring gap will not create confusion. Ensure the normal host power and network are stable. Tell other viewers that readings may stop updating during maintenance.

Follow one documented procedure, record the start and finish times, and preserve exact errors. Avoid repeatedly retrying different commands without noting which changes succeeded. If the process stops, the partial state is important evidence.

Compare behavior after the change

• Reported software version matches the intended release.
• The host starts and the local page is reachable.
• Expected equipment identities respond with current timestamps.
• Units and current direction remain plausible.
• Previously available history is present.
• Authorized remote viewing works if configured.

Check both live readings and stored history. A successful page load proves neither equipment communication nor data continuity. Record any maintenance gap rather than filling it with invented values.

Keep the recovery option until the new version has operated through a representative period. Then update the handover with the final version and any changed behavior. The result should be a controlled installation record, not a sequence of forgotten commands.