ideas.
October 08, 2026 3 min read hardwareb2bautomation

Electronic shelf labels for one small shop

Battery e-paper price tags and a tiny gateway, so an independent shop can reprice a whole aisle from a spreadsheet.

The idea

A kit of e-paper shelf labels for independent retailers: a few hundred battery-powered tags, a USB gateway that sits behind the counter, and a web page where the owner edits prices. Change a price in the sheet, and the tag under that product updates within a minute. Each tag runs years on a coin cell or a single AA because e-paper draws nothing while it holds an image.

Commercial electronic shelf label systems exist, but they are sold as multi-year contracts to chains, priced per tag per month, and locked to the vendor's cloud. A single hardware shop, bakery, or garden centre with 400 SKUs cannot buy one.

Why build this

Paper labels are the quiet tax on a small shop. Repricing an aisle means printing, cutting, and walking the shelves, so owners put it off — which means the shelf says one thing, the till says another, and the customer catches it. Anything that moves with supplier cost (timber, feed, coffee, fresh produce) is wrong most of the week.

The parts finally make this a weekend-scale build. A 2.9" e-paper panel costs a few dollars in small quantities, an ESP32-C6 or nRF52840 is cheap and sleeps at single-digit microamps, and ESP-NOW or BLE advertising moves a 5KB image update without any Wi-Fi association or IP stack. The hard problems are battery life and provisioning, not radio.

Stack sketch

  • Tag: ESP32-C6 + 2.9" SPI e-paper (GDEY029T94 or similar), driven with the epdiy-style refresh path; deep sleep between scheduled wakes, with a wake window every 60s.
  • Transport: ESP-NOW from gateway to tag. No pairing handshake per update; tags filter on a shop-scoped key.
  • Gateway: second ESP32 on USB, acting as a serial bridge to a small Go daemon on the shop's existing PC or a Raspberry Pi.
  • Server: Go + SQLite. One table of products, one of tag assignments, one of pending renders.
  • Rendering: server-side 1-bit PNG per tag via fogleman/gg, so layout and fonts live in one place and tags stay dumb.
  • Price source: CSV upload and a Google Sheets poll on day one; Square and Lightspeed catalog APIs after.
  • Assignment: print a QR per tag during flashing; the owner scans tag then product barcode in a phone web app to bind them.

Scope for v1

In:

  • One label size, one layout (name, price, unit price, last-updated date).
  • CSV/Sheets import, 250 tags per gateway, 60-second update latency.
  • Battery voltage reported on each wake, with a "replace these tags" list.
  • Local-only operation — the daemon needs no internet once prices are in.

Out:

  • Promotional graphics, multiple sizes, colour e-paper.
  • Real-time POS sync, inventory counts, NFC or customer-facing interaction.
  • Cloud hosting. v1 is a box on the shop's own network.

Where it could go

The obvious next step is the POS integration, because once prices flow from the till system the shelf can never disagree with the receipt — that is the actual sales pitch, not the labels. From there, the same tags carry anything short and textual: bin locations in a warehouse aisle, table numbers, feeding instructions in an animal shelter, "last serviced" dates on equipment in a workshop.

The second path is selling the gateway and server as the product and the tags as a commodity. Several Chinese ESL tags can be reflashed with open firmware, and a project that reliably drives second-hand chain-store tags would be worth more to builders than one that only talks to a board you solder yourself.

Watch out for

Battery life is the whole product, and it is set by how often tags wake, not by how often prices change — get the wake schedule wrong and you are replacing 400 cells a year. Also check your radio duty cycle against local ISM band rules before shipping anything to another country.