Die versteckten Kosten der EU-RED-Konformität: eine Fallstudie zum Etikettendrucker

Fangen wir mit einer Geschichte an. Wir haben einen Kunden, für dessen Produktionsanlage wir Software entwickeln. Und da wir es lieben, in unserem Engagement so tief wie möglich zu gehen, überschneiden sich bei uns oft die Welten der Entwicklung und der reinen Hardware-/Software-Integration. In diesem Rahmen haben wir auch eine Lösung zur Automatisierung des Etikettendrucks geliefert. Wir haben dabei auf die Stabilität und Entwicklerfreundlichkeit von Zebra-Druckern gesetzt — der Kunde betreibt eine Handvoll davon, um verschiedene Etikettentypen und die Druckautomatisierung abzudecken. Wir betreiben eine API, generieren ZPL-Code und senden ihn direkt an den Drucker. Das läuft zuverlässig, reibungslos und ziemlich schnell — Aufträge mit Dutzenden von EANs werden innerhalb weniger Sekunden gedruckt. Die Zeitersparnis ist enorm, und der Effizienzgewinn ist jeden Tag sichtbar.

Kürzlich mussten wir einen neuen Drucker hinzufügen, um einen neuen Etikettentyp zu automatisieren. Da wir das schon oft gemacht hatten, klang es nach einem einfachen Job: Drucker bestellen, anschließen, unsere Produktionsanwendung konfigurieren. Nun, diesmal nicht. Das neueste Gerät aus der Zebra-Familie kam mit deren neuestem LinkOS — und war von Haus aus EU-RED-konform.

Was ist EU RED?

Ich will euch nicht mit den Details der Richtlinie langweilen (wer mag, kann sie hier nachlesen). Kurz erklärt: Seit dem 1.8.2025 müssen funkbasierte Geräte die Sicherheit der Nutzer schützen und dürfen unter anderem keine offenen Web-Interfaces mehr haben. Zebra hat diese Richtlinie gründlich umgesetzt.

Wo liegt also das Problem?

Nutzer können den Drucker nach dem ersten Start nicht mehr konfigurieren. Das vorherige Modell, das wir erhalten hatten, war erst vor ein paar Wochen gekauft worden — mit alter Firmware, plug and play. Jetzt verweigert der Drucker das Drucken über das Netzwerk. Der Schutz muss erst entsperrt werden. Dafür braucht man eine spezielle Anwendung, die Zebra auf seiner Website bereitstellt — und zwar genau in dem Moment, in dem man merkt, dass etwas nicht stimmt. Sie heißt Nucleus.

Nucleus bedeutet also Kontrolle, oder?

Nicht ganz. Nach der Installation der App muss man sich mit dem neuen Drucker verbinden — wir haben WLAN ziemlich früh aufgegeben und stattdessen ein ganz normales USB-Kabel eingesteckt. Dann kann man mit der Konfiguration beginnen. Die App selbst ist gar nicht so schlecht, und das Entsperren des geschützten Modus ist relativ einfach. Versucht man aber, das Web-Interface des Druckers über seine IP-Adresse zu öffnen, erscheint nichts. Offenbar ist das ebenfalls geschützt, obwohl der Schutz eigentlich schon entsperrt sein sollte.

Setup Utilities zur Rettung

Laut offiziellen Support-Artikeln vom September 2026 erfordert die Aktivierung des Web-Interfaces Zebra Setup Utilities (eine ältere Anwendung, die Zebra schon vorher bereitgestellt hatte) sowie eine ZPL-Sequenz, die an den Drucker gesendet wird. Der Vollständigkeit halber, hier ist sie:

! U1 setvar "ip.https.enable" "on" <CR>
! U1 setvar "ip.http.enable" "on" <CR>
^XA^JUS^XZ
! U1 do "device.reset" "" <CR>

In Zebra Setup Utilities klickt man auf „Open Communication With Printer", fügt den obigen Schnipsel ein und drückt „Send To Printer". Wir haben es hart versucht, aber ohne Erfolg — das Web-Interface blieb hartnäckig nicht verfügbar. Wir brauchten es aber nicht so dringend, also sind wir weitergezogen, um das Setup abzuschließen.

Es druckt

Nachdem wir mit Nucleus herumgespielt und den Drucker in einen „ungeschützten" Zustand versetzt hatten (dafür muss man ein Profil anlegen, ein Passwort vergeben und speichern), konnten wir unsere ZPL-Etiketten an den Drucker senden. Das angenehme Geräusch eines durchlaufenden Etiketts — es druckt. Bis man sich das Etikett genauer ansieht. Der EAN selbst war einwandfrei, aber der Rest war kaum lesbar. Unsere erste Idee war, die DPI anzupassen. Ging nicht, da die alte WebUI nicht verfügbar war und weder Nucleus noch Setup Utilities diese Einstellung anboten. Kein echtes Problem allerdings — wir kennen ZPL, also haben wir die DPI selbst korrekt gesetzt.

Was fehlt dann noch?

Vielleicht hatte sich die Schriftgröße in der neuen LinkOS-Version geändert. Eine kurze Anpassung im ZPL schien zu helfen, aber das warf eine größere Frage auf: Müssen wir wirklich jedes ZPL-Template, das wir verwenden, ändern? Da musste noch etwas anderes dahinterstecken. Der korrekt dargestellte EAN war ein klarer Hinweis — die Schriftart selbst fehlte auf dem Drucker, und stattdessen wurde eine Ersatzschrift verwendet.

Frühere Versionen der Zebra-Firmware kamen mit vorinstallierten Schriften — wir hatten uns auf Helvetica verlassen. Wenn die also fehlte, wie lädt man neue Schriften hoch? Auch hier geht es über Setup Utilities (man muss zusätzlich einen eigenen Schriften- und Pakete-Downloader installieren, sonst funktioniert es nicht). Klick auf „Download Fonts and Graphics", und der Prozess beginnt. Man muss eine neue Partition (sozusagen) auf dem Flash-Speicher des Druckers anlegen — nicht auf dem DRAM — und sie auf der lokalen Festplatte als MMF-Datei speichern. Das klingt für normale Nutzer schon viel zu kompliziert, aber wir sind mittlerweile an solche Dinge gewöhnt. Von dort aus kann man eine Schrift aus dem angebotenen Dialog auswählen, in die MMF speichern und auf den Drucker hochladen.

In unserem Fall fehlte Helvetica. Im Dialog stehen Dutzende Schriften zur Verfügung, aber genau die, auf der die Etiketten des Kunden aufgebaut waren, war nicht dabei. Das liegt vermutlich an Lizenzgründen, da Helvetica eine lizenzierte Schrift ist — also bestand die Lösung darin, eine Alternative zu wählen, die dem Original möglichst nahekommt.

Schrift gefunden

Gut, wir hatten sie. Von hier an sollte der Prozess einfach sein. War er nicht. Die Partition, die wir angelegt hatten, war zu klein für die Schriftdatei. Zurück an den Start. Wir haben den Upload erneut versucht, und diesmal hat es geklappt. Was nun — drucken probieren? Haben wir, und es hat trotzdem nicht funktioniert. Unser ZPL referenzierte die Schrift explizit als S_HELVETICA_A.TTF, während wir eigentlich LiberationSans hätten referenzieren müssen. Wir haben ein paar naheliegende logische Namen durchprobiert, wie die Schrift im Flash-Speicher des Druckers abgelegt sein könnte. Kein Glück.

Wir fanden keine schnelle Möglichkeit, alle Schriften oder Dateien auf dem Flash-Speicher aufzulisten, also griffen wir auf eine eher umständliche Methode zurück: eine ZPL-Anfrage direkt senden (man erinnere sich, die WebUI ist nicht verfügbar, es gibt also kein „Directory Listing", zu dem man einfach springen könnte).

^XA^HWE:*.*^XZ

gesendet über dasselbe Kommunikationsfenster in Setup Utilities. Ein paar Sekunden später fanden wir LIB000.TTF.

Der Kunde bestätigt, dass es sogar noch besser aussieht

Die Liberation-Schrift kam gut an — wir werden wahrscheinlich alle unsere Drucker und ZPL-Templates darauf umstellen — also haben wir das ZPL noch etwas verfeinert, um ein paar verbleibende Details anzupassen, und der Job war erledigt.

Was als simples „die bestehende Drucklösung um einen neuen Drucker erweitern" begann, wurde zu einer kleinen Schnitzeljagd. Aber nach ein paar Stunden, etwas grauem Haar und ein paar neuen Erkenntnissen ging die Sache gut aus.