Eine herstellerneutrale JSON-Schnittstelle für ESL-Updates

Hier ist die Frage, die meist direkt nach dem ersten Electronic-Shelf-Label-Pilotprojekt auftaucht: Die Labels funktionieren, die Preise stimmen, und dann fragt jemand: „Können wir für den Tiefkühlbereich einen anderen Tag-Hersteller verwenden?“ Und niemand will antworten, denn die ehrliche Antwort lautet: „Nur, wenn wir die Integration neu schreiben.“

Genau dieses Problem soll eine herstellerneutrale JSON-Schnittstelle lösen. Nicht, indem die Hardware auf magische Weise austauschbar wird, sondern indem die Content-Pipeline unabhängig davon wird, wer die Tags hergestellt hat. Dieser Artikel erklärt, was diese Schnittstelle eigentlich ist, warum sie eine JSON-Datei und kein API-Aufruf ist und wie eine Plattform wie Next Generation Label Printing System ins Bild passt.

Was ist eine herstellerneutrale JSON-Schnittstelle für ESLs?

Electronic Shelf Labels (ESLs) sind die kleinen digitalen Displays, die an Regalkanten geklemmt werden. Sie ersetzen Papierpreisschilder und werden drahtlos von einer Basisstation aktualisiert, statt dass jemand mit einem Preisauszeichner durch den Gang läuft.

Die Verkabelung ist der Punkt, an dem es unübersichtlich wird. Historisch brachte jeder ESL-Hersteller seine eigene Art mit, ein Update zu übertragen: ein binärer Blob, ein proprietärer REST-Endpunkt, ein Hersteller-SDK, ein serielles Protokoll. Zwei Hersteller bedeuteten zwei Integrationen. Drei Hersteller bedeuteten ein kleines internes Framework, das niemand verantworten wollte, plus eine Tabelle, die Produkt-IDs dem zuordnete, was jedes System einen „Tag“ nannte.

Eine herstellerneutrale JSON-Schnittstelle ersetzt das durch einen einzigen Vertrag: eine dokumentierte JSON-Struktur, die besagt, dass dieses Label mit dieser Kennung diesen Inhalt anzeigen soll. Jedes System, das JSON schreiben kann – ein ERP, ein geplantes Skript, ein Tabellenkalkulations-Export, ein Etikettendesign-Tool – kann sie erzeugen. Jede Basisstation oder Middleware, die JSON lesen kann, kann sie verarbeiten.

Zwei Wörter in diesem Ausdruck tragen die Hauptlast:

• JSON ist ein textbasiertes, menschenlesbares Datenformat. Man kann eine Update-Datei in einem Editor öffnen, zwei Versionen davon vergleichen und auf einen Blick sehen, ob das Preisfeld ein String oder eine Zahl ist. Das klingt banal, bis man um 7 Uhr morgens vor der Ladenöffnung eine binäre Payload debuggt hat.
• Herstellerneutral bedeutet, dass die Schnittstelle nicht an einen bestimmten ESL-Hardwarehersteller gebunden ist. Sie definiert, wie ein Update aussieht, nicht, wessen Funk es überträgt.

Eine Unterscheidung sollte man ausdrücklich treffen, weil sie den Großteil der Arbeit leistet: Eine herstellerneutrale Schnittstelle definiert ein Schema, kein Protokoll. Das Schema ist die Form der Daten. Das Protokoll – wie die Basisstation über Funk mit den Tags spricht – bleibt genau dort, wo es hingehört: beim Hardwarehersteller.

Eine einfache Analogie: Der Universal-Reiseadapter

Denken Sie an Wandsteckdosen. Eine britische Typ-G-Steckdose, eine EU-Typ-F-Steckdose und eine US-Typ-A-Steckdose sind drei inkompatible physische Formate. Ihr Laptop-Netzteil kümmert sich um keines davon; es will Strom bekommen. Also tragen Sie einen Universaladapter mit, und das Netzteil funktioniert überall, wo Sie landen.

Die Übertragung auf ESLs ist direkt:

• Die Wandsteckdose ist die ESL-Hardware und ihre Basisstation.
• Ihr Gerät ist der Inhalt, den Sie anzeigen möchten – Preise, Produktnamen, Barcodes.
• Der Universaladapter ist das JSON-Schema, auf das sich beide Seiten einigen.

Die Analogie lässt sich auf die Wartung übertragen, und das ist der Teil, den die Leute unterschätzen. Den Adapter zu wechseln ist ein Kauf für fünf Euro. Die Wand zu wechseln bedeutet einen Elektriker, ein Loch in der Trockenbauwand und einen Tag Ihres Lebens. In ESL-Begriffen: Der Wechsel des Tag-Herstellers sollte ein Adapterwechsel sein – die neue Basisstation auf dieselbe JSON-Ausgabe zeigen lassen – und keine Neuentwicklung des Systems, das jeden Morgen Ihre Preise erzeugt.

Diese Entkopplung ist der ganze Sinn der Sache. Die Content-Management-Seite muss sich nicht mehr um Hardware kümmern. Die Hardware-Seite muss sich nicht mehr darum kümmern, woher die Daten kamen.

Wie es unter der Haube funktioniert

Die Mechanik ist bewusst langweilig, und das ist ein Feature.

Ein ESL-Update ist eine Datei. Etwas erzeugt eine JSON-Datei; eine ESL-Basisstation oder Middleware liest sie und verteilt den Inhalt an die physischen Tags. Wie diese Datei übertragen wird, bleibt offen: ein HTTP-Upload, ein überwachter freigegebener Ordner, eine Message Queue, ein USB-Stick in einem Laden mit wackeliger Verbindung. Nichts im Schema schreibt den Transportweg vor.

Die Struktur trägt typischerweise drei Arten von Informationen:

• Eine Label- oder Tag-Kennung – welches Regaletikett adressiert wird.
• Inhalt – Textfelder, Bilder, Barcodes.
• Anzeigeattribute – welche Vorlage verwendet wird und welche Darstellungsflags die Hardware unterstützt.

Das folgende Beispiel ist absichtlich vereinfacht, um die Form zu zeigen. Die genauen Feldnamen und zulässigen Werte stammen aus dem Schema, das mit der ESL-Schnittstellendokumentation veröffentlicht wird – prüfen Sie das, bevor Sie etwas in die Produktion schicken.

{
  "label": "SHELF-0421",
  "template": "price-tag-7in",
  "content": {
    "title": "Arabica Beans 1kg",
    "price": "12.49 EUR",
    "unit": "per pack",
    "barcode": {
      "type": "EAN13",
      "value": "4006381333931"
    }
  },
  "display": {
    "highlight": true,
    "validFrom": "2026-11-01"
  }
}

Weil es ein Schema und kein Protokoll ist, kann dieselbe Datei von einem nächtlichen ERP-Job, einem Google-Sheets-Workflow oder einem visuellen Etikettendesigner erzeugt werden. Das erzeugende System muss nicht wissen, welche Marke von Tag im Gang vier hängt.

RSJ LPSNG liefert beide Hälften dieses Modells: eine ESL-Schnittstelle (ESLSEND), die dieses JSON-Format ausgibt, und eine ESL Binding API, die Tags mit Artikeln verknüpft – nützlich für mobile Datenerfassungsgeräte (MDE), die keine eigene Weboberfläche haben.

Warum Herstellerneutralität wichtig ist

Drei praktische Gründe, plus ein Missverständnis, das man ausräumen sollte.

Lock-in vermeiden. Wenn Ihre Content-Pipeline eine neutrale JSON-Datei ausgibt, wird der Wechsel der ESL-Hardware zu einem Hardwareprojekt, nicht zu einem Softwareprojekt. Sie behalten die Preislogik, das Vorlagendesign und den geplanten Job. Sie ändern nur, was die Ausgabe konsumiert.

Zukunftssicherheit. Ständig erscheinen neue ESL-Modelle – andere Größen, andere Batterieprofile, andere Funkstacks. Ein stabiles JSON-Schema absorbiert diese Änderungen auf der Hardware-Seite, während Ihre Pipeline unverändert bleibt.

Einfachere Integration. Ein Format für N Hersteller schlägt N proprietäre APIs. Ein Entwickler, der das Schema einmal lernt, kann einen zweiten Standort, einen zweiten Hersteller oder ein zweites Land integrieren, ohne die Domäne neu zu lernen.

Das Missverständnis: Herstellerneutral bedeutet nicht funktionsarm. Ein neutrales Schema kann trotzdem reichhaltige Inhalte tragen – mehrzeiligen Text, Produktbilder und 1D- oder 2D-Barcodes. Neutralität betrifft die Frage, wer das Format besitzt, nicht, wie viel man hineinpacken kann. (Wenn Sie Barcodes erzeugen, gelten die Prüfungen in How to Check Barcodes Before Printing Labels genauso für Regaletiketts wie für gedruckte Etiketten.)

Wie RSJ LPSNG ESL-Inhalte verwaltet

Next Generation Label Printing System ist eine Plattform für Etikettendesign und -druck, und ESL-Unterstützung ist Teil seiner Cross-Media-Lösung: Dasselbe Etikettendesign, das an einen Drucker geht, kann ein Regaletikett ansteuern. Das ist operativ wichtig – ein Design, ein Satz Feldregeln, zwei Ausgabekanäle, die nicht auseinanderdriften können.

Der Workflow sieht so aus:

1. Das Etikett einmal gestalten in der LPSNG-Weboberfläche, im Label Studio.
2. Tags mit Artikeln verknüpfen über die ESL Binding API, wo Sie eine programmatische Zuordnung brauchen, statt sich auf einem Handheld durch eine Weboberfläche zu klicken.
3. Das System ESLSEND-JSON ausgeben lassen aus diesem Design. Sie schreiben keine Payloads von Hand; die Plattform erzeugt sie aus demselben Layout, das Sie drucken.
4. Den Lauf automatisieren mit dem LPSNG Player, der eigenständigen Kommandozeilen-Druck-Engine: Paket plus Daten rein, PDF, PNG, JSON, Direktdruck oder ESL raus. Ein geplanter Job kann das JSON ohne Browser im Ablauf neu erzeugen und ausliefern.

Sie könnten das JSON von Hand zusammenbauen und Dateien selbst auf eine Basisstation legen – der harte Weg –, aber dann pflegen Sie eine zweite, parallele Definition Ihres Etiketteninhalts, und sie wird innerhalb eines Monats von der gedruckten Version abweichen.

Für Filialketten decken die Enterprise-Funktionen Multi-User-, Multi-Region- und Multi-Device-Umgebungen ab, sodass Inhalte zentral verwaltet und über dieselbe Schnittstelle an viele Standorte verteilt werden können. Auf der Hardware-Seite veröffentlicht RSJ Installationsanleitungen für CATIC ESL als ausgearbeitetes Beispiel dafür, wie man eine bestimmte Tag-Familie in Betrieb nimmt.

Häufige Missverständnisse und praktische Überlegungen

„JSON-Schnittstellen sind nur für Entwickler.“ Nicht wirklich. Entwickler können JSON programmatisch erzeugen, aber jedes System, das Text ausgeben kann, kann es erzeugen, und eine Plattform kann es für Sie aus einem visuellen Design erzeugen. Die Hürde ist niedriger, als das Akronym vermuten lässt.

„Herstellerneutral bedeutet keinen Herstellersupport.“ In der Praxis bedeutet es meist bessere Interoperabilität, weil die Integrationsfläche dokumentiert und geteilt ist statt maßgeschneidert.

Überlegung: Prüfen Sie Ihre Basisstation. Stellen Sie sicher, dass Ihre ESL-Basisstation oder Middleware das ESLSEND-Format verarbeitet oder daran angepasst werden kann. Das ist der eine Schritt, bei dem ein neutrales Schema Ihnen nicht helfen kann – die Empfangsseite muss die Datei verstehen.

Überlegung: Vor dem Deployment validieren. Eine fehlerhafte JSON-Datei schlägt still fehl oder, schlimmer, aktualisiert einen Laden nur halb. Zwei günstige Prüfungen fangen das meiste ab:

jq empty ./out/SHELF-0421.json && echo "valid JSON"

import json
import sys

REQUIRED = ("label", "template", "content")

def check(path: str) -> None:
    with open(path, encoding="utf-8") as f:
        doc = json.load(f)
    missing = [key for key in REQUIRED if key not in doc]
    if missing:
        sys.exit(f"{path}: missing {', '.join(missing)}")
    print(f"{path}: ok")

check("./out/SHELF-0421.json")

Die Syntaxvalidierung fängt kaputte Dateien ab. Die Prüfung auf Pflichtfelder fängt den häufigeren Fehler ab: eine gültige Datei, in der genau das eine Feld fehlt, das die Basisstation tatsächlich brauchte.

FAQ

Was genau ist ESLSEND?

ESLSEND ist eine herstellerneutrale JSON-Dateischnittstelle von RSJ LPSNG zum Aktualisieren von Electronic-Shelf-Label-Displays. Sie definiert eine standardisierte JSON-Struktur für Etiketteninhalte, sodass jedes System, das JSON erzeugen kann, Updates an ESLs senden kann.

Muss ich Code schreiben, um eine herstellerneutrale JSON-Schnittstelle zu nutzen?

Nicht unbedingt. Entwickler können JSON zwar programmatisch erzeugen, aber RSJ LPSNG bietet eine Weboberfläche und Tools wie den LPSNG Player, die das JSON für Sie erzeugen können. Sie können Etiketten visuell gestalten und die JSON-Ausgabe dem System überlassen.

Kann ich RSJ LPSNG mit beliebiger ESL-Hardware verwenden?

RSJ LPSNG unterstützt eine herstellerneutrale JSON-Schnittstelle, was bedeutet, dass es mit ESL-Hardware funktioniert, die das ESLSEND-Format akzeptiert. Sie sollten jedoch prüfen, ob Ihre ESL-Basisstation oder Middleware die JSON-Dateien verarbeiten kann. RSJ LPSNG stellt außerdem Installationsanleitungen für CATIC-ESL-Hardware als Beispiel bereit.

Wie handhabt RSJ LPSNG ESL-Updates für mehrere Filialen?

RSJ LPSNG bietet Enterprise-Funktionen für Multi-User-, Multi-Region- und Multi-Device-Umgebungen. Sie können ESL-Inhalte zentral verwalten und Updates über die ESLSEND-Schnittstelle an mehrere Standorte verteilen, um Konsistenz über alle Filialen hinweg sicherzustellen.

Fazit

Eine herstellerneutrale JSON-Schnittstelle ist kein cleverer technischer Trick – sie ist eine Grenze. Auf der einen Seite steht Ihr Inhalt: Preise, Produktnamen, Barcodes, Vorlagen. Auf der anderen Seite steht die Hardware: Tags, Funk, Basisstationen. ESLSEND zieht diese Grenze als dokumentierte JSON-Datei, sodass sich jede Seite ändern kann, ohne die andere mitzuziehen.

Der praktische Weg ist der kurze: Gestalten Sie das Etikett in Next Generation Label Printing System, lassen Sie die Plattform das JSON aus diesem Design erzeugen, bestätigen Sie, dass Ihre Basisstation das Format akzeptiert, und automatisieren Sie den Lauf mit dem LPSNG Player. Wenn Sie noch entscheiden, wie viel Tooling Sie brauchen, behandeln Label Design Software With Python Scripting: What to Expect und Label Design Software Pricing: A Small Business Guide die angrenzenden Entscheidungen.

Bereit, es an Ihren eigenen Etiketten zu sehen? Starten Sie mit der gehosteten Cloud-Edition, gestalten Sie ein Regaletikett und exportieren Sie die ESL-Ausgabe, bevor Sie sich auf Hardware festlegen.

Verwandte Beiträge

• How to Check Barcodes Before Printing Labels
• Label Design Software Pricing: A Small Business Guide
• Label Design Software With Python Scripting: What to Expect