I Wanted a Clock That Never Needed Setting — So I Built One With Ollama and Llama 3

The Ars Technica story hit a nerve because it starts with the most innocent possible goal: a clock that just knows what time it is. No buttons. No manual setting. It ends with the author buried in OAuth tokens, cloud API rate limits, and a project that breaks every time some third-party service sneezes. Sound familiar?

That story is funny. It's also a perfect X-ray of how most people build with AI right now — stacking dependencies on services they don't control, hoping nothing breaks, and discovering too late that "simple" and "cloud-dependent" are opposites. The alternative isn't difficult. It's just a different starting point: a local AI stack where the model, the logic, and the data all live on hardware you own.

This guide walks through building a self-setting clock using Ollama and Llama 3. You'll get the hardware list, the wiring approach, the actual prompts, and the fallback logic that keeps it running when things go wrong. By the end, the clock is the least interesting part of what you've built.

The Ars Technica Clock Story and What It Reveals About AI Dependency

The Ars Technica piece follows a predictable escalation pattern: one cloud service leads to another, each requiring its own credentials, its own rate limits, its own failure modes. What started as a weekend project becomes a maintenance burden. The clock works — until it doesn't, and then it takes an hour to figure out which upstream dependency broke it this time.

This isn't a story about one bad project. It's the default outcome when you build on services you don't control. Cloud AI APIs are the same. You get convenience up front and fragility later. Your prompt goes out over the internet, hits a server you've never seen, returns an answer through a pipeline you can't inspect, and costs money every time. That's fine for prototyping. It's a poor foundation for anything you want to rely on.

The alternative that the Ars Technica story accidentally points toward: own the full stack. Run the model locally. Keep the logic on hardware you control. Then the only dependencies are the ones you chose.

Why Owning Your Local AI Stack Changes the Equation

"Owning your AI stack" sounds abstract until you price out what you're actually giving up by not doing it.

Cloud AI is rental. You get access; the provider sets the terms. They can change pricing, deprecate a model, add rate limits, or go down at 2am when your project needs to work. You also send your data through their infrastructure, which matters more as your projects get more personal or more sensitive.

A local stack — Llama 3 running via Ollama on a capable host machine — flips that. The model runs on your hardware. Requests never leave your network. There are no API keys to rotate, no per-token costs to track, no outages you can't control. And critically: it works offline, which matters the moment you wire it to physical hardware.

Privacy is a deeper issue than most people treat it. If you want to understand the full picture of what cloud AI actually sees when you use it, this breakdown of cloud AI data exposure and why local models fix it is worth reading before you decide where to run your next project.

The practical difference in a hardware project looks like this. With a cloud API, your time-retrieval prompt goes out over the internet, waits for a server, comes back with an answer, and fails silently if the connection drops. With Llama 3 running locally:

You are a time retrieval agent connected to an RTC module.
Respond with the current date and time in YYYY-MM-DD HH:mm:ss format.
Return only the formatted timestamp. No explanation.

That prompt runs on your device. The response comes back in milliseconds. Nothing leaves your network. The clock keeps working whether or not your ISP is having a bad day.

That's the shift. You stop being a consumer of someone else's AI infrastructure and start being the operator of your own.

Step-by-Step: Building a Self-Setting Clock with Ollama and Llama 3

Here's the full build. It's organized so you can follow it sequentially or jump to the section you need.

Step 1: Hardware Selection

You need four components: a microcontroller or single-board computer, an RTC module, a display, and wiring.

The DS3231 RTC module is the right call for most builds. It's accurate to within a few minutes per year, has battery backup built in (CR2032), and communicates over I2C — two wires to your microcontroller. It's also cheap and widely available.

For the display, an e-ink panel (1.54" or 2.13", SPI interface) makes sense for a clock: it draws power only when updating, holds the image with no current, and is readable in direct light. An OLED works too and is easier to source.

For the main controller, your two real options are a Raspberry Pi or an ESP32:

If you want everything in one box, use a Raspberry Pi 4. If you want a battery-powered display unit with a Pi running Ollama elsewhere on your network, the ESP32 as a thin client works well.

Step 2: Wiring

The DS3231 connects via I2C. On a Raspberry Pi, the I2C SDA and SCL lines are available on the GPIO header — consult the official pinout diagram at pinout.xyz for your specific board revision, and connect those pins to SDA and SCL on the DS3231 along with 3.3V and GND. On an ESP32, SDA and SCL are typically GPIO 21 and GPIO 22 (check your specific board's datasheet to confirm).

E-ink displays use SPI: connect MOSI, MISO, SCK, CS, DC, RST, and BUSY pins per the display's datasheet. Most common e-ink modules from Waveshare include a pinout diagram and Python library — use those directly.

Keep a CR2032 coin cell in the DS3231's battery socket. That's what keeps the RTC running during power outages. Without it, the module loses time the moment power drops.

Step 3: Installing Ollama and Llama 3

On your host machine (a laptop, mini-PC, or any Linux box with enough RAM), installing Ollama takes a single command you can grab from the install page at ollama.com. Run it, and Ollama sets itself up as a local service.

Then pull Llama 3:

ollama pull llama3

Ollama starts a local API server at http://localhost:11434 by default. Your scripts talk to that endpoint — no internet required after the initial model download.

If you haven't run a local model before, the full Ollama installation walkthrough covers the setup in detail, including how to verify the model is running and make your first API call.

For comparison, if you're interested in how other local models stack up for embedded or edge projects, the guide on Phi-4 vs Gemma vs Llama is a useful reference for choosing the right model for your constraints.

Step 4: Initial Time Synchronization

The first time you power the clock, connect it to a network and sync the RTC to an NTP server. In Python on the Pi:

import subprocess
import board
import adafruit_ds3231

# Sync system time via NTP
subprocess.run(["sudo", "ntpdate", "time.google.com"])

# Write synced time to RTC
i2c = board.I2C()
rtc = adafruit_ds3231.DS3231(i2c)

import datetime
rtc.datetime = datetime.datetime.now().timetuple()

After this runs once, the DS3231 holds the time independently. The internet connection is no longer needed for basic operation.

Full Prompts, Fallback Logic, and Hardware Integration

The prompts here do real work. They're not decorative. Each one handles a specific condition the clock might encounter.

Primary Time Retrieval Prompt

You are a time retrieval agent connected to a DS3231 RTC module via I2C.
Your job: read the current date and time from the RTC and return it.
Format: YYYY-MM-DD HH:mm:ss
Return only the formatted timestamp. No explanation, no extra text.

This is the prompt your Python script sends to Llama 3 on every display refresh. The strict output format matters — you're parsing this into a display update, so any extra text breaks the parse.

NTP Fallback Prompt

The RTC module is returning invalid or stale data.
Attempt to connect to time.google.com via NTP.
If the connection succeeds, update the RTC with the corrected time
and return the new timestamp in YYYY-MM-DD HH:mm:ss format.
If the connection fails, return the last valid timestamp stored in
/var/local/last_known_time.txt and flag the response with [STALE].

The [STALE] flag is what your display logic watches for. When it appears, you can show a small indicator on the e-ink screen that the time may be off. That's honest feedback from the device instead of silent failure.

Storing Last Known Good Time

Write a simple cron job that runs every hour and saves the current RTC timestamp to a file:

# /etc/cron.hourly/save_time
#!/bin/bash
date '+%Y-%m-%d %H:%M:%S' > /var/local/last_known_time.txt

The fallback prompt reads from that file if both the RTC and NTP are unavailable. The clock is never completely blind.

Power Management

Two things extend the useful life of this build significantly. First: keep a charged battery in the DS3231 socket at all times. The module draws microamps from it and will hold time accurately through multi-day power outages. Second: if you're running on battery at the device level (ESP32 build), put the microcontroller into deep sleep between display refreshes. E-ink holds its image with zero power — you only need the MCU alive long enough to update the display, which can be once per minute or once per hour depending on your use case.

Connecting an ESP32 to a Raspberry Pi Running Ollama

If your build separates the thin client (ESP32 + display) from the AI host (Raspberry Pi), the ESP32 sends HTTP requests to the Ollama API on the Pi:

// ESP32 Arduino sketch (simplified)
HTTPClient http;
http.begin("http://192.168.1.100:11434/api/generate");
http.addHeader("Content-Type", "application/json");

String payload = "{\"model\": \"llama3\", \"prompt\": \"Return current time from RTC in YYYY-MM-DD HH:mm:ss format. Return only the timestamp.\", \"stream\": false}";

int responseCode = http.POST(payload);
String response = http.getString();

Parse the JSON response, extract the timestamp, and push it to the e-ink display. The Pi never needs to be the device the user sees — it's just the AI brain on your local network.

What This Build Actually Teaches You

The clock is simple. What it represents isn't.

Every piece of this project is yours: the model, the logic, the data, the hardware. Nothing breaks because a third-party API went down. Nothing costs money per request. Nothing leaks to a server you've never seen. And because you built it yourself, you understand every layer — which means you can fix it, extend it, or adapt it to something else entirely.

That's the difference between prompting a cloud model and owning a local AI stack. One is a service you use. The other is infrastructure you control. The clock just happens to be a good first project for learning the distinction.

Once you've built one thing this way, the pattern applies everywhere: local model, hardware interface, prompt for the logic, fallback for when things go sideways. The specific parts change. The approach holds.

Frequently Asked Questions

How do I run Llama 3 locally with Ollama to control hardware?

Install Ollama on a Linux host using the installer from ollama.com. Pull the model with ollama pull llama3. Ollama then runs a local API server at localhost:11434. Your hardware control scripts send POST requests to that endpoint with prompts that describe what the model should do — read sensor data, format a timestamp, evaluate a condition. The model responds with text your script parses and acts on. No internet connection required after the initial download.

Can I make a clock that sets itself without internet after initial setup?

Yes. The DS3231 RTC module keeps time independently using its own oscillator and a coin cell battery. Connect it to the internet once during setup to sync via NTP, and it holds accurate time indefinitely after that — through power outages, network failures, everything. The battery in the DS3231 socket is the only maintenance requirement, and a CR2032 lasts years in that role.

What's the difference between prompting cloud models versus owning a local AI stack?

Cloud models (OpenAI, Anthropic, Google) run on remote servers. Every request goes over the internet, costs money, and depends on the provider's uptime. A local stack runs the model on your hardware. Requests never leave your network. There are no per-token costs, no rate limits, and no outages beyond your own hardware failures. For hardware projects specifically, local is the only practical choice: you need the AI to respond when the device needs it, not when the API is available.

How do I connect Ollama to a Raspberry Pi or microcontroller for physical projects?

Run Ollama on a capable host machine on your local network — a laptop, mini-PC, or similar. Your microcontroller (ESP32 or similar) connects to the same network and sends HTTP requests to the Ollama API endpoint on that host. The host runs the inference, returns the result, and the microcontroller parses it and drives the hardware. If you want everything on one board, wire sensors directly to the Raspberry Pi's GPIO pins and use the Pi as both the display node and the AI host, provided you have enough RAM for the model you're running.

Is it possible to make an always-on device that never needs manual time setting?

Yes, with three pieces working together: a DS3231 RTC with battery backup, NTP sync on first boot, and fallback logic that reads the last known good timestamp if both the RTC and network are unavailable. With those three in place, the device handles power loss, network failures, and RTC drift without any manual intervention.

What Llama 3 model size should I use on a Raspberry Pi 4?

It depends on which Pi 4 you have. The 8GB model can run Ollama directly, and may handle a quantized 7B or 8B model — though inference will be slower than on a dedicated machine, and your results will depend on which quantization level you use. Lower-RAM Pi 4 models (1GB, 2GB, 4GB) will struggle with models that size, and the experience won't be smooth. If you're on a lower-RAM board, the better pattern is to run Ollama on a nearby laptop or mini-PC and use the Pi only for display output and GPIO control, with the ESP32 thin-client approach from Step 3. The guide on Phi-4 vs Gemma vs Llama covers the model-size tradeoffs in detail and can help you pick the right fit for your hardware.

The Ars Technica author wanted a clock that never needed setting. The cloud route got them dependencies, fragility, and a project that required ongoing maintenance. The local route gets you a device that runs on your terms, on your hardware, indefinitely.

If you're ready to go deeper into local AI builds, Ultra Prompt's prompt template library has structured templates for hardware control and automation that take the prompt-design work off your plate.