Raspberry Pi automation in the field: lessons from a camera-to-gate integration

The project: cameras, a registry, and a gate

A local producer asked for a system that connects software and hardware around IP cameras with image recognition. The cameras recognise vehicles. The company wanted the entry gate to open for specific, known vehicles and stay closed for the rest.

My part was the link between the systems. The recognition software on one side, the registration tables on the other, and the gate in the middle. I wrote the service that relays information between them. It presents the registration tables and stores them in a registry, and it automates the gate for the known vehicles.

Nothing failed after launch. The reason was less about clever code and more about preparation, and most of that preparation happened before I wrote a line.

Start with network access

The producer’s network was protected by enterprise-grade firewalls. Every connection between the cameras, the relay, the registry, and the gate had to be allowed in advance. Ports, directions, and addresses all needed approval, and the people who approve them work on their own schedule.

If I had waited until the service was ready, the project would have stalled at the first connection test. Instead I asked early:

1. Which systems need to talk to which, and in which direction?
2. Which ports and protocols does each connection use?
3. Who approves firewall changes, and how long does it take?
4. Which environment can I test in before the real devices exist on site?

Write the answers as a one-page diagram with the approvals next to each line. It is the cheapest document in the project, and it prevents the longest delays.

A script is a system once it runs unattended

Many Raspberry Pi projects start with one useful script, one device, and one process that saves time. It works at the desk with the terminal open. Then the device moves into a cabinet, a workshop, or a client site, and nobody is watching.

A gate controller falls into that second group. Nobody will restart it by hand when a visitor is waiting. That decided how I built the service.

The reboot test

For small automation projects the most useful acceptance test is simple: unplug the device, plug it back in, and wait. Then check:

• Does the service start without a keyboard?
• Does it reconnect to the network?
• Does it find its configuration and files?
• Does it keep credentials outside the repository?
• Does it recover after an API timeout?

If any answer is “only when I start it manually”, the project is not ready to run alone. It does not need enterprise architecture. It needs a few disciplined habits.

Habits that keep a small system dependable

1. Run it as a service. A systemd unit starts the process on boot, restarts it on failure, shows its status, and gives you one normal place to look when something goes wrong.
2. Keep configuration out of the code. Paths, tokens, URLs, device names, and thresholds belong in a config file. Secrets stay out of the repository.
3. Write logs for the person who reads them tomorrow. Timestamps, clear event names, and error context matter more than clever output.
4. Expect an imperfect network. Timeouts, retries, backoff, and offline behaviour are normal in the field.
5. Document the recovery path. A one-page note with service names, config paths, restart commands, and known failure modes can save hours.

What a useful log line looks like

A log line should answer what happened, to which object, and what the system did next. For this kind of integration, one event might read: a vehicle was recognised, the registry was checked, the vehicle was found, the gate command was sent, and the gate confirmed.

Each of those steps gets its own line with a timestamp and a short identifier for the event. When someone asks why the gate did not open for a particular vehicle, you can follow one identifier through the chain and see where it stopped. Without that, the same question turns into guessing.

Observability can stay light

A small system does not need a full monitoring stack. It does need to answer three questions quickly:

• Is the process running?
• When did it last do useful work?
• If it failed, what failed first?

Sometimes that means structured logs and a health endpoint. Sometimes a status file, a daily email, or a small dashboard is enough. The goal is less guessing once the device is out of reach.

Keep the registry in one place

The registration tables are the most sensitive part of the setup, because they decide who gets through the gate. I kept them in one registry and made the relay read from it, instead of copying lists to several devices. One source means one place to update, one place to audit, and no moment when two devices disagree about who is allowed in.

The business value is continuity

The best automation projects feel quiet after launch. They move data, trigger actions, and connect tools that used to need a person. The value shows up as fewer interruptions and fewer messages asking someone to check something by hand.

A fragile script saves time only while someone watches it. A dependable service saves attention, and that is what a gate, a report, or a sensor needs.

If this sounds familiar

Send a short note through the contact section on the home page with the data source, the device context, and the outcome you need. We can map the smallest reliable version first, including the network access it requires, and then decide whether the project needs a dashboard, an integration, or a deployment checklist.