Deutschland funkt! - Das BLOG

Nach einigen Experimenten und den Erfahrungen aus meinem letzten Urlaub (siehe hier) habe ich die Notfallbox nun um ein neues Anwendungsszenario erweitern können: Den Betrieb an einem externen Wireless-Access-Point (WAP). Konnte bisher nur der interne Raspberry PI-Chip oder ein USB-WiFi-Dongle genutzt werden, so ist nun der Betrieb in vier verschiedenen Anwendungsszenarien möglich.

Szenario 1: Stand-Alone!

Dies war der ursprüngliche Anwendungszweck, aus welchem die Notfallbox entstanden ist: Ein möglichst kleines Gerät, mit stromsparenden Onboard-WiFi (alternativ USB-WiFi-Dongle), steht "irgendwo herum" und liefert Notfallwissen für Jedermann.

Als Gerät war von Beginn an ein Raspberry PI Zero mit einem externen WiFi-Dongle oder ein Raspberry PI Zero W mit Onboard-Wifi vorgesehen, da diese Geräte einen wirklich nur minimalen Stromverbrauch haben und daher sinnvoll auch mit einer kleiner Solarzelle und einem Akku als Puffer platziert werden konnten.

Eine Konnektierung zu einem anderen Netzwerk etc war weder geplant noch vorgesehen, hätte zwar durch manuelle Eingriffe ermöglicht werden können - erschien aber sinnlos, aufgrund des Einsatzzweckes.

Szenario 2: Stand-Alone - aber mit mehr Rechenpower!

Es stellte sich schnell heraus, dass die Idee zwar ganz toll war - aber der Raspberry Zero (egal ob mit internem oder externem WiFi) doch recht langsam ist und mit zwei oder mehr gleichzeitigen Nutzern unter Umständen schnell überlastet sein würde.

Daher habe ich die Notfallbox in einer "größeren Softwareversion" auf schnelleren Geräten zur Verfügung gestellt. So kann diese nun problemlos auf einem Raspberry PI Zero 2 W, 3, 4, 5 oder einem X86-/x64-kompatiblen PC laufen - ebenfalls mit einem internen WiFi-Chip oder einem externen USB-WiFi-Dongle.

Szenario 3: Mit einem externen WAP

Mein letzter Sommerurlaub brachte mich dann auf die Idee, einen externen Wireless-Access-Point (WAP) ins Spiels zu bringen. Erste Versuche haben ergeben, dass ein WAP im Rahmen der Notfallbox keinesfalls über PoE (Power-over-Ethernet) mit Strom versorgt werden kann, da es keine Geräte gibt, welche mit 5V oder 12V über PoE arbeiten.

Dennoch habe ich WAP-Geräte gefunden, welche über USB-Kabel (also 5V) gespeist werden können. Sprich: Man benötigt dann eben ein LAN-Kabel UND ein USB-Stromkabel, um den WAP mit der Notfallbox zu verbinden - benötigt dafür aber keine zusätzliche Stromquelle - quasi eine ideale Kombination.

Dafür musste lediglich die Netzwerk-Konfiguration der Notfallbox so geändert werden, dass für den LAN-Port entweder ein DHCP-Client die IP-Adresse vom WAP bezieht - oder der LAN-Anschluss mit einer statischen Adresse versehen wird. 

Bei der Gelegenheit habe ich ein Netzwerk-Verwaltungs-Tool geschaffen, welches dem Nutzer die volle Kontrolle über die gesamte Netzwerkkommunikation gibt, ohne dies schon bei der Installation auswählen zu müssen.

Szenario 4: Die Notfallbox in einem Netzwerk

Die Nutzer haben sich aber auch gewünscht, dass die Notfallbox als reiner Server arbeitet und die Kommunikation ausschliesslich über LAN funktioniert - und alles anderen von anderen Geräten übernommen wird.

So ist der "Server Mode" entstanden - welcher im Endeffekt ein früheres Projekt unter dem Namen "Notfunk-Server" wiederbelebt und in den Rahmen der Notfallboxen eingebettet hat.

Nun kann die Notfallbox tatsächlich auch an einem Internet, Intranet oder anderen Wide-Area-Netzwerke (WAN) wie beispielsweise dem HAMNET betrieben werden - und dennoch ihre volle Funktionsvielfalt anbieten.

Natürlich müssen in diesem Fall umfangreiche Sicherungsmaßnahmen getroffen werden, da die Notfallbox selbst niemals eine Verbindung mit dem Internet haben sollte in der ursprünglichen Idee. Aber: Dies überlassen wir eben ganz komfortabel dem Benutzer der Notfallbox.

Fazit: Eine Box, viele Ideen

Wir denken, dass wir die Notfallbox nun so universell wie möglich aufgebaut haben und mehr oder weniger alle potentiellen Einsatzfälle abgedeckt haben. 

Die nächste Version der Notfallbox (150) wird dann die Anbindung an LoRa Mesh (Long Range Radio) mit sich bringen. Wir haben diese zwar schon testweise implementiert, aber waren und noch nicht so genau über den Verwendungszweck im Rahmen der Notfallbox im klaren, da LoRa Mesh ja keinen Download einer OSM-Karte, keinen Blick in eine ZIM-Datenbank oder auch kein Upload in die Mini-Cloud ermöglicht.

Aber wir haben inzwischen die passenden Ideen und werden die eben ab sofort umsetzen.

Im Endeffekt will man seine Notfallbox oder sonstige Systeme nicht direkt unterhalb einer Antenne in einem Outdoor-Gehäuse unterbringen, sondern beispielsweise wettergeschützt in einem Gebäude.

Dabei wiederum hat man das Problem, dass die Standard-Antennen der Wifi-Dongles keine Reichweite mehr bringen und man eine Außenantenne auf einem Mast einsetzen will.

Damit man hier nicht in die Falle tappt und die - sowieso schon mickrige - Sendeleistung des Dongels oder des Access Points im Koaxialkabel verloren gehen, zeige ich Euch in einem Video, wie man mittels eines USB-Kabels die Antenne dennoch bis zu 20m weit von der Notfallbox einsetzen kann - ohne nennenswerte Leistungsverluste der Hochfrequenz-Energie.

Liste der im Video verwendete Bauteile (Beschaffungsbeispiele):

• USB-Wifi-Dongle
• Adapter N-SMA
• Adapter SMA
• USB-Verlängerungskabel
• Antenne (2,4 GHz, 10 dBi, Nebenmastmontage, Salzwasserfest)
• Antennenkabel  (Datenblatt)
• Kunststoff-Installationsrohr => Baumarkt

Camping-Gerüch(t)e

Kürzlich war ich erst im Urlaub - mit dem Wohnmobil. Hin und wieder war ich des Nachts auch auf offiziellen Campingplätzen - manche davon mit Platz-WLAN-Netzwerk. Doch - wie es der Zufall immer so mal wieder will - hat man mich natürlich an der Reichweitengrenze des WiFi-Netzwerkes platziert.

Doch gewusst wie: Als Funkamateur hat man natürlich hier und da so seine Ideen und Ahnungen in Sachen "Funkreichweite"   Und daher habe ich mir noch rechtzeitig vor dem Urlaub einen "WiFi-Extender" gekauft - ein Gerät, welches quasi das Camping-Platz-Netzwerk aufnimmt und für mich lokal verstärkt. So ein "Extender" ist auch nichts anderes als win WiFi-Repeater, allerdings mit eigener Verwaltungsoberfläche, welche man schnell und problemlos konfigurieren kann.

Das Ganze hat übrigens wunderbar getan - wenn das Camping-Platz-eigene-Netz nicht Abends massiv überlastet gewesen wäre Aber dies ist eine andere Geschichte.

Irgendwelche ideen hat man selbst im Urlaub

In diesem Zusammenhang kam mir aber die Idee, solch' ein Gerät auch für meine Notfallbox zu nutzen. Denn:

Der Access-Point eines Raspberry PI ist nicht immer der schnellste. Auch wenn man in der Katastrophe doch vielleicht etwas mehr Geduld aufbringen sollte, könnte mein Camping-Gerät im Access-Point-Betrieb problemlos die komplette drahtlose Kommunikation mit den Nutzern übernehmen - und daher einen Raspberry PI Zero (2) W doch etwas entlasten.

Tolle Idee - nur scheitert dies einmal wieder an den Realitäten.

Es gibt zwar tolle, wetterfeste, sturmsichere und vor allem temperaturbeständige WLAN-Access-Points (z.B. TP-Link EAP-110 Outdoor für 2.4 GHz oder WAVLINK AC1200  für 2,4 & 5 GHz). Die lassen sich wunderbar auch temporär schnell an einer ausziehbaren Teleskop-Stange und einem Wäscheständer befestigen und dann mittels einem LAN-Kabel und einem PoE-Adapter betreiben.

PoE?

PoE bedeutet "Power over Ethernet" und ist ein technischer Standard, durch welchen sich Geräte quasi "Remote" über ein LAN-Kabel gleichzeitig mit Daten UND mit Strom versorgen lassen.

Und hier haben wir das "Knie der Biene":

Gemäß dem Wikipedia-Artikel (abgerufen am 06. Juni 2026 / 20:45 Uhr) gibt es im Endeffekt zum einen mehrere Industrie-PoE-Standards, welche mit einer Spannungsversorgung von 36-57 Volt arbeiten - und eine "PoE Passiv-Standard", welcher im Endeffekt mit beliebigen, Verbraucher-abhängigen Spannungen arbeitet.

Nun Arbeiten aber gerade die oben verlinkten Geräte alle mit 24 Volt Betriebsspannung.

Und das wiederum ist ein echtes Problem. Denn meine Notfallbox arbeitet auf dem Raspberry PI mit 5 Volt und auf PC-Geräten mit 12 Volt-Betriebsspannung.

Realität ... und was vom Traum übrig bleibt

Nach sorgfältiger Analyse der auf dem Markt sich befindlichen Outdoor-WiFi-Access-Points muss ich leider feststellen:

• Alle gefundenen Geräte arbeiten mit PoE!
• Ein Teil der Geräte (ungefähr die teurere Hälfte) nutzen die Industrie-Standards und daher 48 Volt Betriebsspannung.
• Der andere Teil nutzt den PoE Passiv-Standard mit 24 Volt Betriebsspannung.
• Ich habe KEIN Outdoor-Gerät gefunden, welches eine zusätzliche Spannungsversorgungsmöglichkeit hat (und bezahlbar ist).
• bei manchen Geräten wird sogar nur ein 230 Volt-(Wechselspannung)-PoE-Injektor mitgeliefert.

Sprich: All dieser geräte waren für den Einsatz ohne Stromnetz nicht zugebrauchen - zumindest nicht, ohne dass man sich in Sachen Spannungsversorgung selbst etwas basteln muss!

Sprich: kommerzielle Outdoor-Access-Point-Geräte waren und sind für den Einsatz an der Notfallbox nicht geeignet!

Dennoch: Nicht aussichtslos!

Ich habe dann nach Selbstbau-Möglichkeiten gesucht. Natürlich gibt es diverse Anleitungen zu diesem Thema. Diese geräte bestehen in der Regel dann aus mehr oder weniger einfachen LAN-WLAN-"Konvertern" auf Basis des ESP32-Micro-Controllers - und haben leider einen großen Nachteil: Ihr Datendurchsatz ist relativ gering im Vergleich beispielsweise mit den oben verlinkten Geräten.

Dennoch - wer sich hierfür interessiert, sei auf diese Links verwiesen:

• https://www.seeedstudio.com/XIAO-W5500-Ethernet-Adapter-p-6472.html (Kein Selbstbau, aber preisgünstig)
• https://tutorials-raspberrypi.de/esp8266-access-point-guenstigen-wlan-repeater-selber-bauen/ (Selbstbau mit ESP32)

Ich dachte aber in diesem Fall an meine Zielgruppe: Bürger ohne Bastel-Hintergrund. Daher habe ich weitergesurft und die idee aufgefunden, einen WiFi-Router als Access-Point zu verwenden. Diese gibt es so aber nur als "Indoor-Geräte" - haben aber den Vorteil, dass sie sehr klein sein können und mit 5V oder 12V arbeiten können.

Daher habe ich mir nun zwei preisgünstige Indoor-WLAN-Router bestellt (diesen hier, kann OpenWRT, und diesen hier aus der preisgünstigen Industrie-Ecke). Beide Geräte werde ich auf Tauglichkeit hin untersuchen (WiFi-Leistung) und dann schlicht und ergreifend einfach in ein Outdoor-Gehäuse einbauen - genauso, wie ich dies mit meinem Notfallboxen und meinen LoRa-Mesh-Geräten mache!

Denn: Zwei Bohrungen für die Antennen in ein Gehäuse machen, eine Bohrung für den Strom einzubringen und das Ganze dann abdichten, ist wesentlich weniger Aufwand, als mit irgendwelchen Step-Up-Konvertern Spananungen zu konvertieren und diese dann mit massivem Verlust und maximalen Funkstörungen einzusetzen.

Und ... ganz ehrlich? Wenn ein Bürger diesen Aufwand nicht betreiben möchte, so kann man diese Geräte vielleicht auch eines Tages dann kommerziell vertreiben - am besten direkt mit Akku und Solarzelle dabei.

Na - wäre doch was oder?

Ich werde auf jeden Fall hier wieder berichten.

Übrigens: Alle Links sind Beispiel und KEINE Kaufempfehlungen.

Teil 1: ZimaBlade - Von der Personal Cloud zur Notallbox
Teil 2: Vergleich Raspberry PI mit ZimaBlade
Teil 3: Vergleich des ZimaBlade mit einer anderen Intel-Notfallbox

Im Artikel ZimaBlade - Von der Personal-Cloud zur Notfallbox habe ich bereits auf eine neue Möglichkeit hingewiesen, die Notfallbox als Server auf Intel-Hardware zu betreiben. Sprich: Die Server werden immer kleiner, immer leistungsfähiger und nun zur echten Konkurrenz in Sachen "mobile Computing" und vor allem unserer Notfallbox und lohnen daher eine nähere Betrachtung. 

Wir möchten hier nur kurz die Features und die Eignung eines ZimaBlade-Single-Board-Computer mit einem Raspberry PI 4 8GB und einem PI 5 8GB, dem derzeit mit Abstand leistungsstärksten Raspberry-Single-Board-Computer, vergleichen - mit besonderem Augenmerk auf die Eignung für eine Notfallbox.

Technische Daten

	Raspberry PI 4B	Raspberry PI 5	Zima Blade 3760	ZimaBlade 7700
Gehäuse	Muss zugekauft werden		Wird mitgeliefert
Maße (LxBxH)	93x63,5x20 mm (ohne Gehäuse)	88,5x63,5x20 mm (ohne Gehäuse)	107x80x23 mm (mit Gehäuse)
Gewicht	46 g (ohne Gehäuse)	46 g (ohne Gehäuse)	175 g (mit Gehäuse)
Spannung Leerlauf CPU Stresstest	5,212 V 2,90 W / 0,58 A 5,9 W / 1,1 A	5,127 V 3 W / 0,58 A 8 W / 1,5 A	12,11 V 1,27 W / 0,1 A 3,6 W / 0,3 A	nicht getestet
Verwendbare OS	Linux, Android, Windows 10 ARM64		Windows, Linux, OpenWRT, Android
CPU	ARM Cortex A72 Quad-Core 1,5 GHz	ARM Cortex A76 Quad-Core 2,4 GHz	Intel Celeron N3350 Dual Core 1,1 GHz	Intel Celeron N3450/J3455/E3950 Quad Core 1,2 / 1,5 / 1,6 GHz
Arbeitsspeicher	1 / 2 / 4 / 8 GB eingebaut	1 / 2 / 4 / 8 / 16 GB eingebaut	max. 16 GB DDR3L
Boot-Medium	SD-Karte / USB-Stick	SD-Karte / USB-Stick	eMMC 5.1 / 32 GB
Arbeits-Medium	SD-Karte / USB-Stick	SD-Karte / USB-Stick SATA/M.2 über PCIe-HAT
Echtzeituhr	nur per Nachrüstung über GPIO möglich		eingebaut
Anschluss Stromversorgung	USB-C		USB-C PowerDelivery 12V/3A
Anschlüsse USB	2 x USB 2.0 2 x USB 3.0		1 x USB 3.0
Anschlüsse PCIe	nein	1 x PCIe 2.0	1 x PCIe 2.0 x4
Anschlüsse SATA	nein	nur mit PCIe-HAT	2 x SATA 6.0 Gb/s
Anschlüsse LAN	1 x GBe	1 x GBe mit POE+	1 x GBe
Anschlüsse Video	2 x Mini-HDMI		1 x MiniDisplayPort 1.2 / 4k@60 Hz
Anschlüsse Sonstiges	GPIO, Camera, Lüfter		%
WLAN / Wifi	OnBoard		nein
Bluetooth	5. 0 BLE		nein
Kühlung	Passiv, Lüfter oder Kühlkörper empfohlen		Passiv über das eigene Gehäuse
Geeignet für	Notfallbox Xpi Verwendung von externen Sensoren		Notfallbox Xpc, bei Verwendung eines externen LAN/WLAN-Routers
Besonderheiten	nein	EIN-/AUS-Taster!	nein

Benchmarks

Ich habe mir die Mühe gemacht, den Raspberry PI4 und PI5 mit dem ZimaBlade 3760 zu vergleichen. Hier sind die Rohdaten des Vergleichs:

Vergleichstabelle Raspberry PI4 mit einem USB 3.2 Boot- und Arbeitsmedium, Raspberry PI 5 mit einem M.2 NVME-Speicher über PCIe, ZimaBlade mit dem internen eMMC Speicher, ZimaBlade mit einer SSD per SATA und meinem heimischen Desktop als Referenz

Das Fazit aus diesem Vergleich zeigt ganz klar: Die PI-Familie ist mit ihrem Quadcore in allen Rechenoperationen massiv überlegen - und der ZimaBlade gewinnt bei den Schreib-Lese-Operationen. Ist ja auch kein Wunder, da er für den Cloud-Betrieb entwickelt wurde. Der gelistete PC war mein Arbeits-PC, welchen ich als Vergleichswert hinzugenommen habe.

Allerdings: Wie die technischen Daten zeigen, ist der ZimaBlade in Sachen Stromverbrauch einsame Spitze und sticht den Raspberry PI5 locker aus. Da jener sowieso empfindlich ist in Sachen Stromversorgung kommt der ZimaBlade hier deutlich besser weg.

Vergleichbarer Ausbau

Um den ZimaBlade mit einem vergleichbaren Hardware-Ausbau wie beim Raspberry PI 5 zu betreiben, muss man eine SSD über den SATA-Port, ebenso wie einen USB-Hub am USB 3.2- oder PCIe-Anschluss anschliessen (siehe nachfolgendes Bild).

Damit wird der ZimaBlade leider doch recht umfangreich.

Allerdings: In einer Notfallbox Server kann man auf das PCIe-Board verzichten - weil keine Tastatur und keine zusätzlichen USB-Geräte benötigt werden. Zur Not kann man immer noch einen USB-Hub am USB 3.2-Port anschliessen.

Vor-/ und Nachteile des Raspberry PI

+ GPIO / I²C-Bus für Sensorik
+ Umfangreiche Anschlussmöglichkeiten
+ mittlere Leistungsaufnahme
+ Bluetooth und WLAN onboard
+ Sehr klein und leicht (ohne Zusatzgeräte)
+ Quadcore

- Muss unbedingt zusätzlich und am besten aktiv gekühlt werden, da beide PI sehr schnell warm werden
- Großer Massenspeicher nur per USB oder HAT anschliessbar
- Kein eigenes (internes) Boot & Arbeits-Medium
- Wird grundsätzlich ohne Gehäuse verkauft, ein passendes Gehäuse ist abhängig vom verwendeten HAT unter Umständen schwer aufzutreiben
- PI5 Etwas empfindlich in Sachen Stromversorgung
- Keine Echtzeit-Uhr - man muss die Uhr nach jedem Systemstart einstellen oder zumindest kontrollieren
- Hoher Stromverbrauch (QuadCore)
- Langsame Prozessoren

Vor-/Nachteile des ZimaBlade

+ Boot- und Arbeitsmedium bereits eingebaut
+ SATA- und PCIe-Schnittstellen ohne zusätzliche Hardware nutzbar
+ Betrieb mit Windows, Linux oder Android möglich - Mit OpenWRT macht man daraus sogar seinen eigenen Router
+ Benötigt keine zusätzliche Kühlung - Das Geäuse wird nicht einmal so war, dass man sich die Finger verbrennt.
+ Gerät wird mit/im passenden Gehäuse geliefert
+ Echtzeituhr eingebaut
+ Geringer Stromverbrauch (DualCore)
+ Durch 12V-Betrieb kann das Gerät sogar in einem KFZ ohne Spannungswandler betrieben werden - also ideal z.B. auch für Einsatzleitfahrzeuge.

- RAM muss separat gekauft werden
- Nur ein USB-Anschluss - Neues OS kann daher nur mittels eines USB-Hub gebootet werden. Die Notfallbox benötigt aber im Endeffekt keine eigene Tastatur, weil vollständiger Betrieb via SSH möglich ist.
- Läuft leider nicht mit 5V - oder vielleicht "zum Glück" (siehe Raspberry PI 5) 
- Mit 32 GB ist Arbeitsmedium zu klein um ohne zusätzlichen Massenspeicher arbeiten zu können im Falle der Notfallbox.
- Kein WLAN und kein Bluetooth an Board - Arbeitet man an einem Router, ist dies aber kein Problem
- Dualcore-CPU, daher geschwindigkeitsmässig weit unter der Raspberry PI-Familie.

Eignung für die Notfallbox

Tatsächlich sind beide Gerätekategorien mit ihren jeweiligen Vor- und Nachteilen sehr gut für die Notfallbox geeignet. Mangels vorhandener GPIO-Anschlüsse kann man auf dem ZimaBlade leider keine Sensorik (z.B. Wetterstation) nutzen. Da man an diesem Gerät leider auch auf WLAN und Bluetooth ab Haus verzichten muss, eignet es sich aber dennoch hervorragend als Arbeitsgerät in einem Krisenstab, als Dateiserver oder ähnlichem. Einfach per LAN an einen WLAN/LAN-Router anschliessen, und alle Geräte und menschen können dier Notfallbox sofort nutzen.

Da die Notfallbox auf und für Raspberry PI4 entwickelt wurde, ist diese natürlich für alle Anwendungszwecke brauchbar  und zwar besser als der Raspberry PI5 welcher doch sehr hakelig ist in Sachen Stromversorgung über den USB-C-Anschluss. 

Unsere Empfehlung:

Willst Du eine universelle Notfallbox, welche ohne zusätzliche Hardware etc. auskommt? Soll diese viele Nutzer bedienen? Soll diese mehr der Kommunikation dienen, als dem herunterladen und austauschen von Daten?
Dann nutze den Raspberry PI 4 mit einem USB 3.2 Stick (mind. 64 GB).

Willst Du eine Notfallbox, welche im Rahmen eines Arbeitsnetzwerkes im Krisenstab etc. eingebunden wird, z.B. für ein Einsatztagebuch, die Personenregistrierung oder eben als Massenspeicher für jeden? Soll diese einen möglichst geringen Stromverbrauch aufweisen? Willst Du ein Gerät, welches sogar im KFZ ohne zusätzliches Netzteil sofort betriebsbereit ist?
Dann nutze den ZimaBlade mit einer per SATA angeschlossenen SSD.

Den Raspberry PI 5 möchten wir trotz seiner umfangreichen Ausstattungsmöglichkeiten nicht empfehlen für die Notfallbox. Schwankt die USB-Spannung auch nur um 0,1 Volt (was vollkommen normal ist), kann der PI5 schon abstürzen. Für meine Software-Entwicklung ist er ganz brauchbar - aber im Feld möchte ich ihn niemals einsetzen!

Teil 1: ZimaBlade - Von der Personal Cloud zur Notallbox
Teil 2: Vergleich Raspberry PI mit ZimaBlade
Teil 3: Vergleich des ZimaBlade mit einer anderen Intel-Notfallbox

Rein zufällig bin ich in den letzten Tagen auf ein Gerät names ZimaBoard2 gestoßen - ein rund 300 € teures Gerät, welches einen vom Hersteller IceWhale Technology gebauten Single-Board-Computer (SBC) vorstellt, welcher vor allem zum Bau einer persönlichen Cloud gedacht ist. Hierfür produziert der Hersteller zudem noch das ZimaOS, ein auf die Erstellung einer eigenen Cloud ausgerichtetes Debian-Linux-Derrivat. Der hersteller möchte damit den persönlichen Cloud-Speicher Zuhause beim Anwender fördern - eine löbliche Idee, denn so hat man wenigstens seine Daten dort, wo sie hingehören: Zuhause.

Das ZimaBoard2 war mir aber definitiv zu teuer. Dann entdeckte ich auf der Homepage des Herstellers ein Produkt namens "Zima Blade" - eine kleine Variante des ZimaBoard. Preis: Rund 70 € im Herstellereigenen Shop. Damit ist dieses Gerät zumindest preislich konkurrenzfähig zu den bisher von mir für die Notfunkbox favorisierten Raspberry PI Single Board Computern.

Bestellt ... getestet ... für tauglich befunden ... Bericht geschrieben ... keine Werbung gemacht - um es ganz kurz zu machen 

Das lange Ergebnis:

1. Ich habe für mein Gerät 16 GB Arbeitsspeicher bestellt und dieses damit bestückt. Das muss man selbst unternehmen, da der Computer ohne RAM geliefert wird - eine seltsame Vorgehensweise des Herstellers.
2. Das Gerät wird mit installiertem CasaOS geliefert - ein Debian-Linux-Derrivat und der Vorgänger zum bereits erwähnten ZimaOS.
3. Über einen beliegenden Adapter kann ein HDMI-Bildschirm angeschlossen werden. 
4. Der leider einzige USB-Port wird zunächst mit einem Dongle für das Keyboard belegt.
5. Beim ersten Aufstarten bootet der Computer in den textmodus von CasaOS - dem Vorgänger des zuvor erwähnten ZimaOS.
6. Das Booten erfolgt sehr schnell. Mit der Benutzerkennung "casaos" und dem Passwort "casaos" kommt man sofort an den Computer heran - und wenn es nur ist, um diesen herunterzufahren.
7. Danach muss man unbedingt den USB-C-Stecker ziehen, da das Gerät keinen EIN-/AUS-Taster besitzt.
8. Möchte man nun ein neues Betriebssystem installieren, wird ein USB-Hub (am besten >= USB 3.0) benötigt. Man kann aber auch direkt eine PCIe-USB-Karte mit mehreren USB-Anschlüssen bestellen. Diese werden unter Linux einwandfrei erkannt und eingebunden.
9. Einschalten
10. Nach dem gelben "Zima Blade" Bildschirm drückt man schnell die Taste ESC - und gelangt dort ins BIOS.
11. Hier stellt man unter "Boot" die Bootreihenfolge so um, dass der (bereits eingesteckte OS-Bootstick) als erstes Boot-Medium genutzt wird.
12. Im BIOS nun das Gerät neu starten.
13. Nun wird der USB-Bootstick als Startmedium erkannt und genutzt.
14. Ich habe Debian GNU/Linux in der Version 13.3 (Trixie) installiert, da ich in Sachen Notfallbox alles mit Debian bzw. Rapsberry OS, einem Debian Derrivat mache.
15. Nach der kompletten Installation (siehe Hier) bitte unbedingt einmal einloggen (notfallbox/notfallbox) und die IP-Adresse der Schnittstelle enp2s0 abfragen (ip a) und am besten gut merken und notieren 
16. Ab sofort kann man Bildschirm, USB-Stick und Keyboard abstecken - und sich per SSH auf den ZimaBlade verbinden. 
17. Führt man nun die von mir bereits beschrieben menügeführte Installation der Notfallbox durch (siehe Hier) erhält man in kürzester Zeit eine Notfallbox-Installation der aktuellsten Version, welche man problemlos per SSH und Webbrowser im lokalen LAN erreichen kann. Updates bitte nicht vergessen, siehe hier!

Ein paar Daten (Zima Blade 3760):

• Intel Celereon - Quad-Core CPU mit 1,5 GHz
• max. 16 GB DDR3 RAM
• 2x SATA-Port
• LAN, USB 3.0, Mini-Display-Port
• 1 x PCIe Port 2.0 (x4) als Sockel an der Seite
• 32 GB eMMC als Boot- und Arbeitsmedium
• Stromversorgung 12V / 6 Watt ohne Zubehör, max 9 Watt mit SATA-SSD und USB-PCIe-Board
• Extrem geringe Wärmeentwicklung bei Dauerbetrieb

Fazit

Erste Vergleiche mit einem Raspberry PI 5 (separater Artikel folgt) zeigen, dass der ZimaBlade extrem gut für die Verwendung als Notfallbox-Server geeignet ist. Kombiniert man diesen mit einem WLAN-Router, einem USB-Hub und einem großen Speichermedium (SSD mit SATA-Anschluss), so erhält man einen stabilen und sehr schnellen Notfallbox-Server - mit USB-C Anschluss zur Stromversorgung (Dennoch: 12V über USB-C PowerDelivery).

Das Gerät ist ab sofort meine persönliche Empfehlung für den Betrieb der Notfallbox auf Intel-Geräten - schon alleine rein preislich gesehen!!!

Übrigens: Der Stromverbrauch liegt unter 10 Watt. Daher kann das Gerät problemlos (dank seiner 12V Stromversorgung) ohne zusätzlichen Spannungswandler tagelang an einer Autobatterie betrieben werden und ist daher auch für den mobilen Einsatz empfehlenswert.