Electronic shelf labels not updating: how to find the cause

When an electronic shelf label won’t change its price, the cause is in one of five layers: the source data, the software queue, the gateway, the radio link, or the label and its battery. Work from the top down, starting with the checks that don’t need a ladder, and rule out each layer with one specific test.

This article doesn’t cover how to design a rollout; the implementation guide does that. The starting point here is different: the system is installed and a label is showing yesterday’s price.

The usual mistake: looking low for a fault that sits high

When a label doesn’t change, most people think of the label: battery, hardware fault, bad luck. It’s a natural reaction but usually the wrong place to begin, because a label only ever does what a chain of four links has already delivered to it. If link one failed, replacing the battery at link four achieves nothing.

The chain looks like this:

1. The data. The new price exists in the ERP, the POS or the source file.
2. The label software. It receives that price, matches it to a product and a label, and generates an update order.
3. The gateway. It takes the order over the network and broadcasts it by radio. You will also see it called an access point or base station.
4. The radio and the label. The label receives the message, refreshes the display and, in many systems, sends back a confirmation.

According to the general description of the sector, systems built around a communication station that keeps the long-range link stable are the usual architecture, and the reliability of that radio is a basic requirement, not an extra.

How many labels fail tells you where to start

Before you open anything, count and locate. The failure pattern already gives you half the answer.

What you see	Where to look first
Every label shows the old price after a bulk change	Layers 1 and 2: the data never arrived, the sync job didn’t run or the queue is stuck
One product is wrong, and its label responds	Layer 1 or 2: price unchanged at source, or the label is paired to a different code
A whole area (one aisle, the chiller, the back of the store)	Layer 3 or 4: gateway down or off the network, or a dead zone
Scattered labels with no pattern of location	Layer 4 or 5: low battery, fault, a knock, a damaged display
Intermittent: sometimes yes, sometimes no	Radio: interference, busy periods, duty cycle, retries running out
Dashboard says “updated” but the screen didn’t change	Confirmation without a real refresh: wrong label pairing or a display fault
Updates arrive late, minutes or hours	Saturated queue, priorities, a loaded gateway or duty-cycle limits

The table doesn’t replace measuring, but it stops an engineer turning up with a box of batteries for what is really a database problem.

Layer 1: the source data

The cheapest question in the whole process: did the price change where it originates? If the ERP still shows the old price, the label is innocent.

Check three things:

• Effective date and time. Many prices are scheduled. A promotion that starts tomorrow at 00:00 applies tomorrow at 00:00, not today.
• Which price wins. If a product carries a list price, a customer price and a promotional price, the software may be reading a different field from the one you are looking at. Confirm which field feeds the label.
• The export. If the source sends a file or makes a scheduled call, check that the last run actually finished. A half-written file, a format change or an expired password can halt the sync, and nobody notices until someone spots a label.

While you’re here, note a side effect: if the till already has the new price and the shelf doesn’t, you also have a shelf price that differs from the till price, and that can’t wait.

Layer 2: the software and its queue

The label software takes the data, turns it into per-label orders and queues them. It is the layer where the most orders quietly vanish without anything looking broken.

Look in the dashboard for:

• Pending or failed orders for that product or label. An order stuck “queued” for hours is a clear symptom.
• The pairing. Is that label, by its ID, linked to the right product code? A label moved to a new position without being re-assigned shows another item’s price, which is worse than not updating at all.
• Batch size. A bulk change of thousands of prices at a busy moment can take far longer than the demo suggested. Ask what turnaround to expect for your volume and measure it in the pilot, not in production.
• Process logs. If the vendor offers a change history with order time, send time and confirmation time, you can see in one line which layer fell behind.

If the dashboard shows the order went out and was confirmed, layer 2 is cleared and you move down.

Layer 3: the gateway

The gateway connects to your network by cable or, on some models, wirelessly, and broadcasts by radio to the labels. When it fails, everything that depended on it goes dark, which is why the failure shows up by area.

Checks, from least to most effort:

1. Status in the dashboard. A gateway shown as “disconnected”, or with an old last-seen time, tells you most of it.
2. Power and network. Someone unplugged a charger to use the socket, a switch rebooted, a port moved VLAN. It is more common than you would think, because the gateway lives in the ceiling and nobody remembers it.
3. Addressing and network rules. If you renumbered the network or changed the firewall, the gateway may have lost its route to the server or the vendor’s cloud.
4. Load. A gateway serving too many labels responds slowly; the answer lies in the coverage survey and in how many gateways you need.

Layer 4: the radio

This is the hardest layer to see, because you can’t see it. The label exists, it has battery, the gateway works, and yet the signal doesn’t arrive, or arrives only some of the time.

Possible causes:

• New obstacles. A relocated metal shelving unit, a display stand, an extended chiller or a sign on a metal bracket changes how the signal spreads compared with the original site survey. Cold deserves its own mention because it hits the radio, the display and the battery all at once.
• Interference. It depends on the band. 2.4 GHz systems share spectrum with wifi and Bluetooth. Systems on the licence-exempt 863-870 MHz band in Europe are subject to limits: according to the overview of short-range devices, access is governed by a duty cycle of 0.1%, 1% or 10% depending on the sub-band, or by listen-before-talk. That means that even with no third-party interference, a gateway can’t transmit without limit. With many simultaneous changes, some orders have to wait.
• Labels at the edge of range. Labels at the far end of a zone sit at the fringe of coverage and fail more often.
• Retries exhausted. Some systems try a fixed number of times and then flag the label as “no response” until the next cycle.

The useful test is not speculation but moving a test gateway or a control label into the doubtful area and seeing whether it updates. If it does, it’s coverage; if it still doesn’t, it’s the label.

Layer 5: the label and its battery

Only now do you climb the ladder. An e-paper label spends most of its energy when the content changes, so battery life depends on how often it refreshes, on temperature and on the quality of the radio link, as the battery article explains. A poor radio forces more retries and drains the cell earlier than planned, so a group of low-battery labels in one area is not always a battery problem.

Steps:

• Battery level in the dashboard, if shown. Compare it with neighbouring labels.
• Physical inspection. Cracked or stained display, open casing, dirty battery contacts, moisture.
• Swap test. Swap a working label with a failing one. If the fault stays with the label, it’s the label; if it stays with the position, go back to layer 4.
• Reset or re-pair following the manufacturer’s procedure, without improvising.

Log every intervention. If the same label or the same batch keeps turning up, you have grounds to claim a replacement.

What to put in place before it happens

Most of these problems are solved in minutes if the system already reports what is going on. Before accepting a rollout, agree in writing:

• A health dashboard showing unresponsive labels, battery level, gateway status and pending orders.
• Alerts sent to a named person, not a shared mailbox.
• The maximum time between a price change and an updated label, and how it is measured.
• Which replacements the contract covers, how long they take and whether spare labels are kept in store.
• Who owns which layer: your IT team for the data and the network, the supplier for the gateway and the software.

This split matters more than it seems. When nobody knows whose layer it is, the incident bounces between calls for days. If you are still choosing a supplier, these questions belong in the manufacturer comparison alongside the rest of the maintenance questions.

In the meantime: a fallback

Until it is fixed, the shelf price is the price on display, and if it differs from the till price that gap is a consumer-law exposure, not just an operational glitch; in the UK, for example, a misleading price can fall under section 226 of the DMCC Act 2024. A simple procedure avoids the problem: a temporary sign or paper ticket on the affected positions, a spot check of prices that differ, and a record of the incident with start and resolution times.

If any of the above sounds like jargon, the glossary collects the sector’s terms, and the basics are covered in what electronic shelf labels are.