Home Miner hasht nicht? Komplette Troubleshooting-Bibel 2026

Durchsuche an einem beliebigen Tag irgendeine Home-Mining-Community und du findest dieselben Beiträge: ein Bitaxe, der startet, aber bei 0 GH/s stehen bleibt, ein NerdQaxe, der sich alle zwei Minuten neu startet, ein Gamma, der nach einem Firmware-Update die halbe Hashrate verloren hat, eine Maschine, die behauptet zu hashen, während der Pool nichts sieht. Diese Geräte sind Open-Source-Hardware mit Open-Source-Firmware auf geerntetem Industriesilizium, und diese Kombination ist leistungsfähig, günstig und auf eine Weise wirklich empfindlich, wie es ein Haushaltsgerät nie wäre.

Diese Anleitung ist die Referenz, die wir uns jedes Mal gewünscht haben, wenn wir jemandem beim Debuggen geholfen haben. Sie deckt die sechs Fehlerdomänen ab, die nahezu jedes tote oder fehlerhafte Gerät erklären, bringt dir bei, Logs so zu lesen wie eine Reparaturwerkstatt, und endet mit einer Master-Symptomtabelle sowie einem Wörterbuch der tatsächlichen Fehlerzeilen, die dir begegnen werden. Sie gilt für die gesamte AxeOS-Familie: jeden Bitaxe (Max, Ultra, Supra, Gamma, Gamma 601/602, GT, Hex), die NerdAxe- und NerdQaxe-Reihen inklusive der ++ und Hydro-Varianten, den NerdOctaxe und damit jedes ESP-Miner-Derivat, einschließlich der neuen BM1373-Maschinen aus unserer BM1373-Ära-Referenz.

Ein Grundsatz vor allem anderen: diagnostizieren, bevor du anfasst. Die Reihenfolge in dieser Anleitung existiert, weil jeder Schritt eine ganze Klasse von Ursachen ausschließt. Direkt zum Neuflashen der Firmware zu springen, während das eigentliche Problem ein einbrechendes Netzteil ist, kostet dich einen Abend und kann dir statt einem Problem zwei bescheren.

Wenig Zeit? Die fünf Lösungen für die meisten Fälle

Bevor du irgendetwas anderes liest, probiere diese der Reihe nach. Zusammen lösen sie die Mehrheit aller „mein Miner ist tot”-Meldungen ohne Werkzeug, ohne Logs und ohne das Gehäuse zu öffnen.

1. KALTSTART, RICHTIG GEMACHT.
   Zieh den STROMSTECKER (nicht den Schalter der Steckdose).
   Zähle volle 60 Sekunden. Wieder anstecken.
   Warum: Reglerfehler RASTEN EIN und überleben jeden
   Software-Neustart; nur echtes Trennen loescht sie.

2. PRUEFE, WAS DAS GERAET WIRKLICH VERSORGT.
   USB-C betreibt das Dashboard, kann aber den ASIC NICHT
   speisen. Ein Miner nur an USB-C zeigt dauerhaft 0 GH/s
   und ~2 W. Stelle sicher, dass das echte Netzteil
   (Hohlstecker/XT30) steckt und fest sitzt - und dass es
   die RICHTIGE SPANNUNG hat (5 V vs 12 V: die falsche
   zerstoert die Platine).

3. TIPPE http:// AUSDRUECKLICH.
   Browser wechseln still auf https:// und scheitern.
   http://MINER-IP - mit Praefix - jedes Mal.

4. GIB IHM 2,4 GHz.
   Diese Funkmodule sprechen nie 5 GHz. Bei Mesh-Routern
   eine reine 2,4-GHz- oder IoT-SSID anlegen, WPA2-AES,
   und AP-Isolation AUS.

5. FRAGE DEN POOL, NICHT DEN MINER.
   Die Zeit seit dem letzten akzeptierten Share im POOL-
   Dashboard ist der einzige ehrliche Online-Test. Ueber
   10 Minuten = jetzt tot, egal was die Miner-Oberflaeche
   behauptet.

Geloest? Gut, Tab schliessen. Nicht geloest? Die Triage
unten findet deinen Abschnitt in 60 Sekunden.

Finde dein Problem schnell

Zwanzig Abschnitte sind viel. Drei Wege, direkt zu deinem zu springen:

Über die Suche: Jede Fehlermeldung in dieser Anleitung steht wortwörtlich so da, wie die Firmware sie ausgibt. Drücke Strg+F (Cmd+F auf dem Mac), füge deine Fehlermeldung ein, und du landest darauf: Das ist eine Design-Entscheidung, kein Zufall.

Über das Symptom:

Über den Lesestil: Der nächste Abschnitt teilt die Anleitung in einen Einsteiger- und einen Profi-Pfad.

Wähle deinen Pfad

Diese Anleitung bedient zwei sehr unterschiedliche Leser, und du solltest sie nicht gleich lesen.

Erster Miner, erstes Problem? Folge dem nummerierten Weg und überspringe nichts: die zwei Sicherheitsregeln, der eingebaute Selbsttest, die 60-Sekunden-Triage und dann nur der Abschnitt, zu dem die Triage dich schickt. Jeder Codeblock ist zum Kopieren bereit, jeder Begriff, den du vielleicht nicht kennst, steht im Mini-Glossar direkt darunter, und nichts auf dem Einsteigerpfad erfordert, das Gehäuse zu öffnen oder ein Multimeter zu besitzen.

Vertraut mit Terminal und Messgerät? Deine Überholspur: der API-Abschnitt für Log-Abrufe aus der Ferne und Flottenprüfungen, das Wörterbuch der roten Zeilen, um direkt von einer Fehlermeldung zur Ursache zu springen, die Tabelle der modellspezifischen Eigenheiten und der professionelle Werkbank-Abschnitt am Ende, wo die Schaltpläne, die Messpunkt-Methode und die Ressourcen auf Platinenebene liegen. Mit PRO markierte Abschnitte setzen voraus, dass du einen Schaltplan lesen und eine spannungsführende Platine sicher messen kannst.

Mini-Glossar für Einsteiger

Zehn Begriffe, je zehn Sekunden, und der Rest der Anleitung liest sich doppelt so schnell.

ASIC        der Mining-Chip selbst - das einzige Bauteil,
            das tatsaechlich Hashes berechnet
ESP32       der kleine Controller fuer alles andere:
            WLAN, Dashboard, Kommunikation mit dem ASIC
AxeOS       die Firmware + das Web-Dashboard auf dem ESP32
VCORE       die ~1,0-1,3 V Versorgung des ASIC-Kerns -
            wird auf der Platine aus deinen 5 V oder 12 V
            erzeugt
VRM / TPS546  die Reglerschaltung, die VCORE erzeugt und
            den Chip durch Abschalten bei Fehlern schuetzt
Stratum     das Protokoll, mit dem dein Miner zum Pool
            spricht
Share       ein eingereichter Arbeitsnachweis; der Pool
            zaehlt sie, um zu wissen, dass du lebst
HW-Fehler % Ergebnisse, die der Chip FALSCH berechnet hat -
            die ehrliche Gesundheitszahl (unter 2% halten)
OTA         Update "over the air" ueber das Dashboard,
            im Gegensatz zum Flashen ueber USB
NVS         der Einstellungsspeicher, der Neuflashen
            ueberlebt - deshalb gibt es den Werksreset

Vor allem anderen: zwei Sicherheitsregeln und ein eingebautes Werkzeug

Die zwei Regeln, die tote Platinen verhindern

Regel eins: rate niemals die Spannung. Standard-Bitaxe mit einem Chip nehmen 5 V; GT, Hex, NerdQaxe++ und NerdOctaxe nehmen 12 V. Hohlstecker beider Familien sind physisch austauschbar, und ein 12-V-Netzteil an einer 5-V-Platine zerstört sie dauerhaft in unter einer Sekunde. Lies vor jedem Anschließen das Etikett auf dem Netzteil, nicht die Form des Steckers. Das ist der teuerste Einzelfehler in diesem Hobby.

Regel zwei: ein heißer Stecker heißt Stopp. Warm ist eine Warnung; heiß, verfärbt oder nach Kunststoff riechend heißt sofort ausschalten und das Kabel vor dem nächsten Einschalten ersetzen. Alles andere in dieser Anleitung kann bis morgen warten. Das hier nicht.

Führe den eingebauten Selbsttest aus

AxeOS bringt einen Einschalt-Selbsttest mit, von dessen Existenz die meisten Besitzer nichts wissen. Er prüft fünf Subsysteme nacheinander und meldet den ersten Fehler auf dem Display, was ihn zu einer kostenlosen Hardwarediagnose in dreißig Sekunden macht, die dir die fehlerhafte Domäne benennt:

WAS GEPRUEFT WIRD (Reihenfolge)  BEI FEHLER ZEIGT DAS DISPLAY
  Eingangsspannung                 POWER FAIL
  Kernspannungsregler              VCORE FAIL
  I2C-Sensorbus                    (bleibt im Test haengen)
  Luefter-Drehzahlrueckmeldung     FAN FAIL
  ASIC-Erkennung                   ASIC FAIL
  kurzer Hash-Burst                HASHRATE FAIL

WIE MAN DAS ERGEBNIS LIEST
  POWER / VCORE FAIL   -> Abschnitt Stromprobleme. Der Test
                          lehnt eine Eingangsspannung mehr
                          als 10% neben dem Nennwert ab -
                          miss das Netzteil.
  ASIC FAIL            -> Abschnitt ASIC-Probleme.
  FAN FAIL             -> Luefter nicht gesteckt, blockiert
                          oder Drehzahlleitung defekt.
  HASHRATE FAIL        -> Chip erkannt, rechnet aber nicht:
                          meist grenzwertige Stromversorgung
                          oder Einstellungen; auf Werk
                          zuruecksetzen.

WENN DER TEST SELBST HAENGT
  Display bleibt ueber 30 Sekunden auf SELF TEST oder
  endlose SELF TEST -> Neustart-Schleife: ab AxeOS v2.12
  die BOOT-Taste 2 Sekunden waehrend des SELF-TEST-Bildes
  halten, um ihn zu ueberspringen und ins Dashboard zu
  kommen, dann von dort diagnostizieren. Eine Selbsttest-
  Schleife nach einem Firmware-Flash bedeutet meist ein
  falsches Image fuer die Platine.

Der Selbsttest läuft beim ersten Start automatisch und lässt sich in den Einstellungen auslösen. Führe ihn nach jedem Hardware-Ereignis aus: nach einem Transport, einer Kühlkörpermontage, einem Netzteilwechsel. Er verwandelt „irgendwas stimmt nicht” in ein benanntes Subsystem, bevor du ein einziges Log geöffnet hast.

Was dir das Display sagt

Bei Modellen mit Display ist das OLED ein Statusinstrument, keine Dekoration. Es wechselt alle paar Sekunden durch Informationsbilder; die BOOT-Taste schaltet manuell weiter und weckt ein abgeschaltetes Display. Die Zustände, die du kennen solltest: der Startbildschirm (Firmware lebt), der Setup-Hotspot-Bildschirm (nicht konfiguriert oder WLAN-Zugangsdaten verloren), der IP-Adress-Bildschirm (deine Tür zum Dashboard), die Selbsttest- und FAIL-Codes von oben, eine Überhitzungswarnung und die Block-gefunden-Animation, der du hoffentlich eines Tages begegnest. Ein dunkles Display ist kein Beweis für eine tote Platine: Prüfe, ob schlicht die Display-Zeitabschaltung gegriffen hat und ob der Pool weiterhin ankommende Shares zeigt.

Die 60-Sekunden-Triage

Bevor du ein einziges Log öffnest, beantworte fünf Fragen. Sie teilen den gesamten Problemraum auf.

F1  Geht ueberhaupt irgendetwas an? (LED, Display, Luefter)
      NEIN -> STROM-DOMAENE. Zum Abschnitt: Stromprobleme.
      JA   -> F2

F2  Erreicht das Geraet das AxeOS-Dashboard / zeigt es eine IP?
      NEIN -> F2a: Sendet es seinen Setup-Hotspot?
              JA   -> WLAN-DOMAENE. Zu: Netzwerkprobleme.
              NEIN -> BOOT-DOMAENE. Zu: Firmware-Probleme.
      JA   -> F3

F3  Zeigt das Dashboard eine Hashrate ueber null?
      NEIN -> F3a: Zeigt es einen Power Fault, ein
              Ueberhitzungs-Banner oder 0 ASIC-Chips?
              Power Fault  -> Stromprobleme
              Ueberhitzung -> Temperaturprobleme
              0 Chips      -> ASIC-Probleme
      JA   -> F4

F4  Zeigt der POOL akzeptierte Shares in den letzten 10 Minuten?
      NEIN -> STRATUM-DOMAENE. Zu: Pool-Probleme.
      JA   -> F5

F5  Sind Hashrate/Fehlerrate/Temperatur so, wie sie sein sollten?
      NEIN -> Temperaturprobleme oder Overclocking-Fehler.
      JA   -> Nichts ist kaputt. Browser-Tab schliessen.

Beachte, dass F4 den Pool fragt, nicht das Gerät. Die häufigste Sackgasse im Home Mining ist das Debuggen eines Miners, dessen Oberfläche perfekt aussieht, während der Pool seit einer Stunde nichts mehr von ihm gehört hat. Gerät und Pool sehen jeweils die Hälfte des Bildes, und diese Anleitung kommt immer wieder auf diese Asymmetrie zurück.

Wie man die Logs liest

Alles andere in dieser Anleitung geht schneller, wenn du Logs lesen kannst, deshalb kommt dieser Abschnitt zuerst. Es gibt zwei Log-Oberflächen, und sie beantworten unterschiedliche Fragen.

Das AxeOS-Weblog

Öffne das Dashboard unter der IP-Adresse des Miners und suche die Log-Ansicht. Sie zeigt das Laufzeit-Log in Echtzeit: Stratum-Verkehr, eingereichte Shares, Difficulty-Änderungen, Temperaturereignisse. Das ist das richtige Werkzeug, wenn das Gerät sauber startet und die Frage lautet, was es gerade tut. Seine Grenze: Es beginnt erst, wenn das Netzwerk steht, kann dir also keinen Startfehler zeigen, und es stirbt mit dem Webserver, kann dir also keinen Absturz zeigen.

Die serielle Konsole: die Wahrheit

Für alles rund um Start, Abstürze, ASIC-Erkennung oder WLAN-Anmeldung brauchst du die serielle Konsole. Das ist dieselbe Ausgabe, die die Entwickler lesen, und sie beginnt beim allerersten Befehl.

1. Verbinde ein USB-C-DATENKABEL (kein reines Ladekabel)
   vom Miner zum Computer. Bei manchen Bitaxe-Platinen
   scheitert eine native USB-C-zu-USB-C-Verbindung bei der
   Aushandlung; nimm ein einfaches USB-A-auf-USB-C-Kabel
   oder einen Adapter, der klassische 5V erzwingt.

2. Oeffne ein serielles Terminal mit 115200 Baud, 8N1:

   Windows:  PuTTY -> Serial -> COMx -> 115200
   Linux:    sudo minicom -D /dev/ttyACM0 -b 115200
             (oder: screen /dev/ttyACM0 115200)
   macOS:    screen /dev/tty.usbmodem* 115200

3. Druecke die RST-Taste auf der Platine (oder Strom neu
   anstecken). Das komplette Boot-Log laeuft von vorne durch.

ESP-IDF-Logzeilen tragen einen Schweregrad-Buchstaben: I für Info, W für Warnung, E für Fehler. Die meisten Terminals stellen E-Zeilen rot dar. Ein gesunder Start hat null E-Zeilen. Das ist die gesamte Kunst des Log-Lesens in einem Satz: den Start durchscrollen, das erste E finden und im Wörterbuch am Ende dieser Anleitung nachschlagen. Der erste Fehler zählt am meisten, denn spätere Fehler sind meist Folgeschäden des ersten.

Wie ein gesunder Start aussieht

Kommentiert und gekürzt. Deiner wird sich im Detail unterscheiden, muss aber dieselben Meilensteine in derselben Reihenfolge treffen.

rst:0x1 (POWERON_RESET), boot:0x8 (SPI_FAST_FLASH_BOOT)
        <- Reset-Grund. POWERON ist normal. Wiederholte
           RTC_WDT- oder BROWNOUT-Resets hier sind dein
           erstes Warnsignal.

I (xx) main: Found device config: <dein Platinenmodell>
        <- Firmware hat die Platine erkannt. Ein falscher
           Modellname hier heisst: falsches Firmware-Image
           geflasht.

I (xx) TPS546: Found TPS546D24A          (TPS-Platinen)
I (xx) Power: VCORE set to 1150 mV
        <- der Kernregler hat ueber I2C geantwortet und die
           ASIC-Schiene steht. Fehlt dieser Block oder wirft
           er Fehler, kann nichts danach funktionieren.

I (xx) bm13xx: Found 1 chip(s)
        <- DIE Zeile. Die Zahl muss der Chipzahl deiner
           Platine entsprechen: 1 bei Einzelchip, 2 beim GT,
           4 beim NerdQaxe, 6 beim Hex, 8 beim NerdOctaxe.

I (xx) wifi: connected, IP: 192.168.x.x
        <- Netzwerk steht. Fehlgeschlagene Anmeldungen geben
           hier Grundcodes aus (Woerterbuch unten).

I (xx) stratum_task: Connected to pool ...
I (xx) stratum_task: mining.subscribe / authorize OK
I (xx) stratum_task: Set difficulty to ...
I (xx) create_jobs_task: New Work: ...
        <- der Pool hat den Login akzeptiert und Arbeit
           geschickt.

I (xx) asic_result: Nonce found, diff xxx of yyy
        <- der ASIC liefert Ergebnisse. Innerhalb ein bis
           zwei Minuten solltest du sehen, wie Shares
           oberhalb der Pool-Difficulty eingereicht und
           akzeptiert werden.

Präge dir die Reihenfolge der Meilensteine ein: Reset-Grund → Platinenkonfiguration → Regler → Chipzahl → WLAN → Stratum → Nonces. Welcher Meilenstein zuerst ausfällt, benennt den Abschnitt dieser Anleitung, den du brauchst.

Stromprobleme: die Ursache Nummer eins für alles

Hätten Home-Miner-Fehler eine Rangliste, würde die Stromversorgung die ersten drei Plätze belegen. Diese Platinen betreiben 3-nm- und 5-nm-Silizium mit hohem Strom aus Consumer-Netzteilen über Consumer-Steckverbinder, und die Reserven sind knapp.

Kenne deine Stromarchitektur

Einzelchip-Bitaxe (Max/Ultra/Supra/Gamma)
  Eingang:   5 V ueber Hohlstecker (5,5x2,1mm) oder USB-C
  Strom:     bis ~5 A beim Gamma ab Werk, mehr uebertaktet
  Regler:    TPS546D24A Digital-Buck (aeltere Platinen:
             DS4432U DAC + INA260 Monitor) setzt 5V auf
             ~1,1-1,3V ASIC-Kern bei sehr hohem Strom herab
  Fenster:   Regler startet ~4,8 V, faellt unter ~4,5 V aus

12-V-Familie (GT, Hex, NerdQaxe++, NerdOctaxe)
  Eingang:   12 V ueber XT30-Stecker oder Hohlstecker
  Strom:     NerdQaxe++ ~8+ A unter Volllast; Octaxe mehr
  Risiko:    Steckererwaermung; Netzteileinbruch unter Last

KRITISCHE TATSACHE: USB-C dient auf aktuellen Bitaxe-
Platinen NUR dem ESP32 und dem Flashen. Es kann den ASIC
nicht versorgen. Eine Platine nur an USB-C startet, zeigt
das Dashboard und hasht mit exakt 0 GH/s bei ~2 W. Das
ahmt einen defekten Regler perfekt nach und kostet die
Community jede Woche Stunden.

Power Fault Detected: was tatsächlich passiert ist

Der TPS546-Regler überwacht vier Schutzfunktionen: Überstrom, Überspannung, Unterspannung, Übertemperatur. Löst eine aus, rastet der Regler ab und AxeOS zeigt das Power-Fault-Banner. Der ASIC verliert seine Schiene; der separat versorgte ESP32 hält die Oberfläche am Leben. Zwei Tatsachen bestimmen die Lösung:

• Die Verriegelung überlebt Software-Neustarts. Der Fehlerzustand liegt im Statusregister des Reglers selbst, bis die Eingangsspannung physisch entfernt wird. Ein Neustart über die Weboberfläche, ein Aufruf der Restart-API oder das Drücken der ESP32-Reset-Taste löscht ihn nicht. Das ist dokumentiertes Verhalten, kein Bug, und genau deshalb existiert eine ganze Klasse von GitHub-Issues: BM1370-Platinen, die bei 0 GH/s und 5 W feststecken, wo der Restart-Endpunkt nichts bewirkt, ein Stromzyklus aber alles löst.
• Das Auslösen ist ein Symptom; die Ursache liegt davor. Der Regler schützt einen Chip, der mehr wert ist als die Platine um ihn herum. Die überwältigende Mehrheit wiederkehrender Auslösungen geht auf die Eingangsspannung zurück, nicht auf den Regler.

Die Lösungsreihenfolge:

1. KALTSTART. Zieh den Stromstecker selbst (nicht den
   Wandschalter). Zaehle volle 10 Sekunden. Manche
   Platinen brauchen 60 Sekunden, damit sich die Puffer-
   kondensatoren entladen und ein ESP32-Brownout-Halte-
   zustand geloescht wird. Wieder anstecken. Das allein
   loest die Mehrheit einmaliger Power Faults.

2. USB-C ENTFERNEN. Ist etwas an USB-C gesteckt, zieh es
   ab und pruefe, ob das echte Netzteil (Hohlstecker/XT30)
   sitzt. Schliesse die oben beschriebene USB-C-Falle aus.

3. UNTER LAST MESSEN. Multimeter auf DC am Eingangs-
   stecker, WAEHREND DER MINER HASHT:
     5-V-Platinen:  4,9-5,3 V dauerhaft erwartet.
                    Unter 4,8 V = das Netzteil ist schuld.
     12-V-Platinen: 11,8-12,2 V dauerhaft erwartet.
                    Unter 11,4 V = das Netzteil ist schuld.
   Eine Messung ohne Last beweist nichts: billige Netzteile
   zeigen im Leerlauf perfekte 5,0 V und brechen unter Last
   auf 4,4 V ein.

4. DEN PFAD AUSSCHLIESSEN. Steck das Netzteil direkt in
   eine Wandsteckdose: keine Steckdosenleisten, keine
   Verlaengerungen, keine Ketten. Billige Leisten erzeugen
   messbaren Spannungsabfall. Wackle am Hohlstecker: wenn
   das Display flackert, sind Buchse oder Kabel verschlissen.

5. NETZTEIL AUFRUESTEN. Ehrliche Mindestangabe:
     Einzelchip 5-V-Platinen:  gutes 5 V / 5 A, dediziert
     NerdQaxe++ Klasse 12 V:   12 V / 10 A (120 W) minimum
   Handy-Ladegeraete und Universaladapter sind die mit
   Abstand haeufigste Grundursache in dieser Anleitung.

Die XT30-Warnung

Die 12-V-Familie schiebt 8 oder mehr Ampere durch einen XT30. Der Stecker ist dafür ausgelegt; die handgelöteten Kabelenden dahinter oft nicht. Prüfe auf verfärbte Kontakte, einen fühlbar warmen Stecker, kalte Lötstellen oder lose Crimps. Eine hochohmige Stelle bei 8 A erwärmt sich, oxidiert, wird noch hochohmiger und erwärmt sich weiter: Das ist der eine Fehlermodus im Home Mining, der in geschmolzenem Kunststoff endet. War der Stecker je heiß genug, um sich zu verfärben, ersetze das Kabel, benutze es nicht weiter. NerdQaxe-Geräte, die mit einem PSU-Fehler und einem Guru-Meditation-Code abstürzen, gehen genau auf diese unter Last einbrechende Schiene zurück.

Brownout: der Absturz, der keiner ist

Der ESP32 hat einen Hardware-Brownout-Detektor. Bricht die 3,3-V-Schiene ein, gibt er Brownout detector was triggered aus und startet neu. Ein Miner, der sich alle paar Minuten neu startet, besonders wenn der ASIC auf Volllast hochfährt, hat fast nie ein Firmware-Problem: Es ist die Versorgung, die im Moment der maximalen Aufnahme einbricht. Die Lösung sind die Schritte 3 bis 5 oben. Jage bei einer Brownout-Schleife nicht der Firmware hinterher.

ASIC-Probleme: der Chip antwortet nicht

Die Zeile im Boot-Log, auf die es ankommt, ist die Chipzahl. Die Firmware zählt die ASIC-Kette über UART durch und gibt aus, wie viele Chips geantwortet haben. Alles außer der vollen Zahl für deine Platine gehört in diesen Abschnitt.

Null Chips erkannt

Das Dashboard zeigt ASIC-Anzahl 0 oder das Log zeigt einen Init-Fehler. Ursachen, nach beobachteter Häufigkeit:

1. Eingerasteter Regler oder gehaltener Brownout-Zustand. Ein Chip ohne Kernspannung kann sich nicht melden. Mach vor allem anderen die volle 60-Sekunden-Kaltentladung: Hauptnetzteil, USB-C und jedes Zubehör abziehen, eine volle Minute warten, wieder einschalten. Das allein erledigt einen erheblichen Anteil der Fälle.
2. Falsches Firmware-Image. Das Image einer anderen Platine zu flashen, auch nur einmal, kann eine falsche Gerätekonfiguration im nichtflüchtigen Speicher hinterlassen, die weitere Flash-Vorgänge überlebt. Passt die Modellzeile im Boot-Log nicht zur physischen Platine, mach einen vollen Werksreset und flashe dann das richtige Image. Ein BM1366-Image auf einer BM1370-Platine findet den Chip nie.
3. Mechanisches Ereignis. Die klassische Abfolge: Das Gerät wurde bewegt, fallen gelassen, verschickt oder der Kühlkörper wurde nachgezogen, und es hat nie wieder gehasht. Unter dem ASIC liegt ein BGA-Kugelraster aus Lötstellen; Verbiegen reißt sie. Ungleichmäßiger Anpressdruck des Kühlkörpers tut dasselbe. Passt der Zeitverlauf, ist es eine Werkstattreparatur (Reflow), kein Einstellungsproblem.
4. Fabrikfehler. Ein fabrikneues Gerät, das nie auch nur einmal gehasht hat, ist überdurchschnittlich oft eine kalte Lötstelle aus der Fertigung. Verbring kein Wochenende mit Software: Mach die Kaltentladung und die Firmware-Prüfung, dann nutze die Herstellergarantie.

Teilweise Chipzahl: die Mehrchip-Signatur

Ein Hex meldet 3 von 6, ein NerdQaxe 2 von 4, ein GT 1 von 2. Mehrchip-Platinen zählen die ASICs als Kette durch, ein einzelner toter oder getrennter Chip bricht die Erkennung also an genau dieser Stelle der Kette ab: Die Zahl sagt dir ungefähr, wo der Bruch sitzt. Eine Vierchip-Platine, die 2 zeigt, hat ein Problem bei Chip 3. Die Ursachen sind dieselben wie oben (knappe Stromversorgung, gerissene Lötstelle) plus eine mehrchip-spezifische: ein schwacher Chip in der Kette, der erst bei höherer Frequenz ausfällt. Kehrt die volle Zahl bei Werkstakt zurück, verschwinden aber Chips beim Übertakten, hast du den schwächsten Die deiner Silizium-Lotterie gefunden, und seine Grenze ist die Grenze der ganzen Platine.

I2C-Fehler: der Sensorbus, nicht der Miner

Eine verwirrende Klasse: Der Miner hasht normal, während Power, ASIC Temp und Input Voltage als Striche, null oder Nullwerte erscheinen und das Log I2C-Sende-/Empfangsfehler oder Timeouts zeigt. Der Hash-Pfad (UART zum ASIC) und der Telemetrie-Pfad (I2C zum PMBus des Reglers, zum Temperatursensor, zum Strommonitor) sind getrennte Busse. Einer kann ausfallen, während der andere läuft. Bekannter Auslöser: ein Firmware-Regressionsband um AxeOS v2.13/v2.14, bei dem der Sensor-Lesepfad auf einem Teil der Geräte stillschweigend ausfällt. Ebenfalls verursacht durch jedes Zubehör am I2C-Header: ein nachgerüstetes OLED oder ein externer Sensor mit wackligem Stecker kann den Bus für die Onboard-Sensoren blockieren. Auf Serienzustand zurückbauen, Kaltstart, und wenn es das Firmware-Band ist, vorwärts aktualisieren oder eine Version zurückgehen.

Die gefährliche Nebenwirkung: Ohne Temperaturrückmeldung kann die Lüfterkurve nicht arbeiten, der Lüfter bleibt also auf einer Drehzahl stehen. Ist die Telemetrie tot, betrachte auch den Überhitzungsschutz als tot und lass das Gerät nicht unbeaufsichtigt, bis es behoben ist.

Temperaturprobleme: Wärme ist ein Budget, kein Ereignis

Die Zahlen, auf die es ankommt

ASIC-Kerntemperatur  Ziel:    55-62 C dauerhaft
                     Sorge:   ueber 65 C konstant
                     Abschaltung: ~75 C -> Overheat Mode

VREG-Temperatur      laeuft unter Last 10-15 C heisser als
                     der Kern; auf BM1370/BM1373-Platinen
                     oft der begrenzende Sensor, nicht der
                     Kern

Overheat Mode        Hashing stoppt, Luefter auf 100%, die
                     Oberflaeche bleibt aktiv; loest sich
                     mit Hysterese, wenn die Temperatur auf
                     etwa 65 C faellt

Diagnose nach Muster

Überhitzt sofort aus dem kalten Zustand — Montageproblem. Der Kühlkörper hat keinen Kontakt: fehlendes oder gerissenes Wärmeleitpad, eingetrocknete oder fehlende Paste, ungleichmäßiges Anzugsmoment oder ein beim Transport gelockerter Kühlkörper. Ein Chip ohne Kühlkörperkontakt geht in Sekunden von Raumtemperatur auf Abschaltung. Neu montieren, ein reiskorngroßes Stück Qualitätspaste auftragen, Schrauben gleichmäßig über Kreuz anziehen.

Überhitzt nach 10 bis 30 Minuten — Kapazitätsproblem. Der Kontakt stimmt, aber das System kann die Wärme nicht so schnell abführen, wie es sie erzeugt. Die Ursachen stapeln sich: Umgebungstemperatur über etwa 27 C, Gerät in einem Schrank, einer Schublade oder einem geschlossenen Gehäuse, Zu- oder Abluft blockiert, Staubfilz auf den Lamellen, oder eine Übertaktung, für die die Kühlung nie ausgelegt war. Gib ihm 10 cm freie Luft auf beiden Seiten, reinige die Lamellen, und wenn es nach einer Frequenzänderung begann, war diese Änderung zu weit.

Langsame Drift über Wochen — Wartungsproblem. Gleiche Einstellungen, Temperatur kriecht Grad für Grad nach oben: Staubansammlung oder eintrocknende Wärmeleitpaste. Paste ist auf diesen Platinen ein Verbrauchsmaterial; sie alle 6 bis 12 Monate zu erneuern ist normal.

Überhitzung nach einem Firmware-Update — Kurvenproblem. Lüfter- und Wärmekurven ändern sich zwischen Versionen; ein dokumentiertes Beispiel um v2.11 verschob das Standard-Lüfterverhalten so weit, dass Geräte bei Werkseinstellungen mehrere Grad wärmer und etwas langsamer liefen. Lies die Release Notes, stell die Lüfterdrehzahl manuell eine Stufe höher, oder passe die Zieltemperatur an, wenn deine Firmware PID-Regelung anbietet.

Der Lüfter selbst

Ein Lüfter, der bei jeder Temperatur 0 U/min meldet, ist nicht gesteckt, durch ein Kabel blockiert oder defekt. Ein Lüfter, der dauerhaft bei 100% kreischt, bedeutet entweder einen wirklich heißen Chip (siehe oben) oder tote Temperaturtelemetrie, die die Kurve blind steuert (siehe I2C-Abschnitt). Ersatzlüfter in 40 mm und 60 mm sind günstig; hochwertige leise Modelle (die übliche Community-Wahl ist ein Noctua) drücken den Geräuschpegel unter 40 dB und sind das preiswerteste Hardware-Upgrade für jedes dieser Geräte.

Netzwerkprobleme: das WLAN-Weltbild des ESP32

Das Funkmodul in jeder dieser Maschinen spricht ausschließlich 2,4 GHz. Nicht 5 GHz, nicht 6 GHz, keine Ausnahmen, keine Firmware-Lösung. Ein enormer Anteil aller Einrichtungsprobleme lässt sich darauf zurückführen, dass dieser Satz mit dem Verhalten moderner Router kollidiert.

Das Mesh-Router-Problem

Moderne Mesh-Systeme senden eine kombinierte SSID und steuern Clients zwischen den Bändern. Der ESP32 kann sich nicht in die 5-GHz-Seite einbuchen, und Band Steering kann verhindern, dass er sich auf 2,4 GHz festlegt. Die zuverlässigen Lösungen, die meisten Router unterstützen mindestens eine:

Variante A  Eine reine 2,4-GHz-SSID anlegen (am besten)
Variante B  Die "IoT-Netzwerk"-Funktion des Routers nutzen -
            mehrere Hersteller haben sie genau fuer solche
            Geraete eingebaut
Variante C  Band Steering / "Smart Connect" deaktivieren,
            damit die Baender als getrennte SSIDs erscheinen

Dann auf der 2,4-GHz-SSID pruefen:
  Sicherheit     WPA2-Personal, nur AES (nicht TKIP, und
                 reine WPA3-Netze scheitern)
  Kanal          fest 1, 6 oder 11 in belegten Umgebungen,
                 nicht Auto
  Kanalbreite    20 MHz
  AP-Isolation   AUS  <- eingeschaltet verbindet sich das
                 WLAN, aber das Dashboard ist aus deinem LAN
                 nicht erreichbar, was exakt wie ein totes
                 Geraet aussieht
  MAC-Filter     aus, oder die MAC des Miners eintragen

WLAN-Fehler im seriellen Log lesen

Die serielle Konsole gibt bei jeder fehlgeschlagenen Anmeldung einen Trennungsgrund aus, und der Grund benennt die Lösung:

AUTH_EXPIRE / auth failed      falsches Passwort (PSK). Neu
                               eintippen; auf typografische
                               Anfuehrungszeichen achten,
                               wenn vom Handy kopiert.
NO_AP_FOUND                    SSID auf 2,4 GHz nicht
                               sichtbar: Band Steering,
                               versteckte SSID, ausser
                               Reichweite oder nur 5 GHz.
beacon timeout                 Signal zu schwach oder Kanal
                               ueberfuellt; Geraet umstellen
                               oder Kanal fixieren.
ASSOC_TOOMANY                  Client-Limit des Routers
                               erreicht.
Brownout detector triggered    gar kein WLAN-Problem - die
                               Stromspitze des Funkmoduls
                               bei der Anmeldung laesst eine
                               schwache Versorgung einbrechen.
                               Repariere den Strom, nicht das
                               Netzwerk.

Der letzte Punkt verdient Nachdruck: WLAN-Senden ist die größte kurzzeitige Lastspitze, die der ESP32 erzeugt. Eine grenzwertige Versorgung, die den Leerlauf überlebt, stirbt bei der Anmeldung, ein Gerät, das „beim WLAN-Verbinden abstürzt”, ist also meist ein Stromproblem im Netzwerkkostüm.

Erreichbarkeit ohne WLAN-Fehler

Zwei Router-Sicherheitsfunktionen verdienen besondere Erwähnung, weil sie Miner absichtlich blockieren. ASUS AiProtection und das Äquivalent bei manchen TP-Link-Modellen stufen Stratum-Verkehr als verdächtig ein und verwerfen ihn stillschweigend: Der Miner meldet sich perfekt am WLAN an und erreicht dann keinen Pool. Wenn ein Gerät sich mit dem WLAN verbindet, aber jede Pool-Verbindung scheitert, und derselbe Pool über einen Handy-Hotspot funktioniert, deaktiviere die Schutzfunktion des Routers oder trage den Miner auf die Whitelist, bevor du irgendetwas anderes anfasst.

Und eine Browser-Eigenheit, die endlose Fehlalarme erzeugt: AxeOS liefert einfaches HTTP auf Port 80 aus. Moderne Browser wandeln nackte Adressen still in HTTPS um, was scheitert, und der Miner wirkt tot. Tippe das Präfix ausdrücklich: http:// vor die IP, jedes Mal. Scheitert es weiterhin, probiere einen anderen Browser und deaktiviere Werbeblocker für lokale Adressen.

Hat der Miner eine IP, aber du kannst das Dashboard nicht öffnen: AP-Isolation (siehe oben), eine Client-Listen-Eigenheit des Routers oder mDNS. Das Gerät meldet sich als .local-Hostname an; nutzen mehrere Geräte denselben Hostnamen, hängt moderne Firmware automatisch ein MAC-basiertes Suffix an, aber veraltete mDNS-Caches auf deinem Rechner können weiterhin auf das falsche Gerät zeigen. Im Zweifel nimm die rohe IP aus der DHCP-Tabelle des Routers und gib jedem Gerät einen eigenen Hostnamen.

Stratum- und Pool-Probleme: die letzte Meile

Das Gerät startet, es hasht, und der Pool ist der Ort, an dem die Wahrheit entschieden wird. In diesem Abschnitt müssen die Sicht des Miners und die Sicht des Pools zusammen gelesen werden.

Verbindung abgelehnt oder nicht erreichbar

In dieser Reihenfolge pruefen:
1. URL exakt:  stratum+tcp://host:port - kein https://,
               kein Schraegstrich am Ende, Port vorhanden
               und korrekt
2. DNS:        kann ein anderes Geraet im selben LAN den
               Host aufloesen? Manche Provider-Router und
               DNS-Filter (oder Pi-hole-artige Blocker)
               schlucken Mining-Domains stillschweigend.
3. Port:       manche Netze blockieren ungewoehnliche
               ausgehende Ports. Teste ueber einen Handy-
               Hotspot: klappt es dort, filtert das
               Heimnetz.
4. Pool-Region: probiere den anderen regionalen Endpunkt -
               moeglicherweise siehst du eine Stoerung in
               nur einer Region.

Authorize schlägt fehl

Der Pool hat den Login abgelehnt. Bei einem Solo-Pool ist der Benutzername deine Wallet-Adresse plus Worker-Name, und die Adresse ist die gesamte Identität: Es gibt kein Konto, bei dem man sich vertippen könnte. Ursachen: eine Adresse mit Tippfehler (ein Zeichen genügt), eine Adresse von der falschen Chain (siehe unten), ein Worker-Name mit Leerzeichen oder Sonderzeichen, oder ein Passwortfeld, das der Pool nicht leer erwartet (nimm x).

Die Adresse der falschen Chain: der stille Killer

Der schädlichste Konfigurationsfehler im Multi-Chain-SHA-256-Mining, und er kann auf zwei Arten scheitern:

• Lauter Fehlschlag: Der Pool prüft das Adressformat je Chain und lehnt die Anmeldung oder jeden Share ab. Ärgerlich, aber sicher: Du merkst es binnen Minuten.
• Stiller Fehlschlag: Eine Adresse, die auf mehr als einer Chain formal gültig ist, oder ein Pool, der nicht tief validiert, akzeptiert deine Shares den ganzen Tag, und dann erreicht dich die Auszahlung nicht. Bei einem nicht-verwahrenden Solo-Pool werden Blockbelohnungen coinbase-direkt an die von dir konfigurierte Adresszeichenkette gezahlt. Es gibt kein Support-Ticket, das eine Coinbase an eine Adresse rückgängig macht, über die du nicht verfügen kannst.

Die Regel: die Adresse muss zu der Chain gehören, auf die du zeigst, von einer Wallet dieser Chain erzeugt und geprüft. Wenn du einen physischen Miner zwischen Chains wechselst, führe eine schriftliche Tabelle Chain-zu-Adresse und prüfe das Benutzernamenfeld jedes einzelne Mal, wenn du die Stratum-URL änderst. Das ist mehr wert als alle anderen Tipps dieses Abschnitts zusammen.

Abgelehnte Shares: die Ablehnungsgründe lesen

Ablehnungen sind nicht ein Problem; die Grundzeichenkette im Log sagt dir, welches von vier Problemen du hast.

"job not found" / stale       Du hast Arbeit fuer einen Job
  in kleinen Schueben direkt  eingereicht, den der Pool
  nach neuen Bloecken         schon ersetzt hat - bei Block-
                              wechseln normal. Unter ~1-2%
                              gesamt: ignorieren. Dauerhaft
                              hoeher: Netzwerklatenz oder
                              WLAN-Paketverlust - RSSI
                              pruefen, naehere Pool-Region
                              versuchen.

"above target" /              Der Share erreicht die vom
"low difficulty share"        Pool zugewiesene Difficulty
                              nicht. Dauerhafte Faelle: ein
                              Versatz nach einer Difficulty-
                              Aenderung, oder Hardware-
                              fehler, die das Ergebnis
                              verfaelschen. Pruefe die
                              HW-Fehlerrate.

"duplicate"                   Dieselbe Nonce zweimal
                              eingereicht. Gelegentlich:
                              harmloses Wiederholungs-
                              artefakt. Ein Strom davon:
                              bekannter Fehlerzustand, bei
                              dem der ASIC auf einer Nonce
                              festhaengt - der Chip haengt.
                              Stromzyklus; wiederholt es
                              sich bei deinem Takt, nimm
                              die Uebertaktung zurueck.

alles abgelehnt               Konfiguration, kein Pech:
                              Adresse der falschen Chain,
                              fehlerhafter Worker-Name oder
                              falscher Port (z.B. ein Port
                              mit hoher Difficulty, gedacht
                              fuer grosse ASICs).

Hardware-Fehlerrate: die ehrliche Zahl

Die Dashboard-Hashrate ist eine Behauptung; die Hardware-Fehlerrate ist ein Geständnis. Sie zählt Ergebnisse, die der ASIC geliefert hat und die die Prüfung nicht bestehen. Unter 2 Prozent ist gesund. Steigende Fehlerrate bei steigender Temperatur heißt Thermik; steigende Fehlerrate bei konstanter Temperatur nach einer Einstellungsänderung heißt, dass der Frequenz-/Spannungspunkt jenseits des Siliziums dieses Chips liegt. Ein Chip mit 5 Prozent Fehlern kann eine stolze Hashrate anzeigen, während deine effektive Hashrate still unter das fällt, was ein niedrigerer Takt liefern würde. Optimiere beim Tuning auf akzeptierte Shares pro Stunde, niemals auf die Dashboard-Zahl. Die vollständige Methode steht im Tuning-Abschnitt der BM1373-Referenz, und Hintergründe zur Share-Difficulty in der Best-Share-Erklärung.

„Der Miner sagt, er hasht, aber der Pool zeigt nichts”

Das am häufigsten gepostete Symptom in jeder Community, deshalb hier der vollständige Lösungsweg:

1. POOL-SEITE, Zeit seit dem letzten akzeptierten Share:
   ueber 10 Minuten = die Verbindung ist JETZT tot, egal
   was die Miner-Oberflaeche sagt. Dashboard-Durchschnitte
   fallen ueber ~eine Stunde ab und verbergen frische
   Abbrueche. "Hashrate ueber null" ist KEIN Online-Test;
   "kuerzlicher letzter Share" schon.

2. MINER-SEITE, Live-Log:
   Werden Shares EINGEREICHT? Findet der ASIC Nonces, aber
   nichts wird eingereicht, haengt der Stratum-Socket -
   Miner neu starten.
   Werfen die Einreichungen FEHLER? Lies die Tabelle der
   Ablehnungsgruende.

3. IDENTITAET: ist das Pool-Dashboard, auf das du starrst,
   auf dieselbe Wallet-Adresse UND dieselbe Coin gefiltert,
   fuer die der Miner konfiguriert ist? Erstaunlich oft ist
   ein BTC-Dashboard offen, waehrend der Miner auf BCH
   zeigt, oder eine Statistikseite der gestrigen Testadresse.

4. FALLBACK: ist ein Fallback-Pool konfiguriert, und ist
   der Miner still dorthin gewechselt? Deine Hashrate kommt
   vielleicht beim ANDEREN Pool an. Pruefe dessen Statistik.

Konfiguriere immer den Fallback

Jedes Gerät der AxeOS-Familie unterstützt einen Fallback-Pool. Ein Miner ohne Fallback, der um 2 Uhr nachts seinen Stratum-Socket verliert, tut nichts, bis du es bemerkst, und der abfallende Dashboard-Durchschnitt sorgt dafür, dass du es spät bemerkst. Setze den Fallback auf eine zweite Region deines Pools, damit ein regionales Problem die Maschine nie stilllegt. Region-Hosts und Ports für jede Chain stehen auf der Verbindungsseite.

Firmware-Probleme: flashen, blockieren, wiederherstellen

Das Zwei-Datei-OTA und der halbe Brick

AxeOS-Updates bestehen aus zwei Artefakten: der Firmware-Binärdatei und dem Weboberflächen-Image (www.bin). Ein dokumentierter Fehlermodus ist ein OTA, das in der www.bin-Phase hängen bleibt und Firmware und Oberfläche außer Takt lässt: Das Gerät startet und mint, aber das Dashboard ist leer oder defekt. Das ist kein Brick. Rufe direkt die Wiederherstellungs-URL auf:

http://<miner-ip>/recovery

und lade das Web-Image erneut hoch. Startet das Gerät nach einem fehlgeschlagenen Update gar nicht mehr, schreibt der USB-Web-Flasher (Chrome oder Edge, USB-C-Datenkabel) das vollständige Factory-Image neu und rettet praktisch jeden Soft-Brick. Drei Regeln machen aus dem Flashen etwas Langweiliges statt etwas Beängstigendes:

• Das Image muss exakt zur Platine passen, bis auf die Revision. Die Revisionsnummer ist auf der Platine selbst aufgedruckt und wird im AxeOS-Systembereich angezeigt: Ein Supra 401 braucht das 401-Image, nicht das 402. Kenne die zwei Dateitypen auf der Releases-Seite: das vollständige esp-miner-factory-REV-vX.X.X.bin (Bootloader + Partitionen + Oberfläche + Firmware, für USB-Flashen und vollständige Wiederherstellung) und das kleinere esp-miner.bin (nur Firmware, für OTA über das Dashboard). Eines dort zu verwenden, wo das andere hingehört, ist ein klassisches Halb-Brick-Rezept. Gamma-Image auf einen Gamma, Ultra auf einen Ultra. Ein falsches Image kann eine falsche Gerätekonfiguration im NVS hinterlassen, die normale Flash-Vorgänge überlebt; die Heilung ist Werksreset plus richtiges Image.
• Flashe niemals über WLAN bei schwacher Verbindung oder grenzwertiger Stromversorgung. Der Hänger in der www.bin-Phase korreliert genau mit diesen beiden.
• Kenne dein Rollback-Ziel. Regressionen kommen vor: ein Telemetrie-Ausfallband um v2.13/v2.14, eine Lüfterkurvenänderung um v2.11, die Geräte heißer laufen ließ, ein Update-Pfad um v2.4.3, der auf manchen Hardware-Revisionen einfror, bis Nutzer zurückgingen. Notiere vor dem Update deine aktuelle Version; verhält sich die neue schlecht, ist die vorherige nur einen Web-Flash entfernt auf der Releases-Seite des Projekts.

Absturzschleifen: eine Guru Meditation lesen

Ein Guru Meditation Error ist der Kernel-Panic des ESP32. Das Wort in Klammern ist der Hinweis:

Guru Meditation Error: Core X panic'ed (GRUND)

LoadProhibited /       Firmware-Bug greift auf ungueltigen
StoreProhibited        Speicher zu - Version notieren,
                       Issue-Tracker pruefen, eine Version
                       zurueckgehen
IllegalInstruction     beschaedigter Flash oder ueber-
                       schriebener Stack - vollstaendiges
                       Neuflashen ueber USB
Cache error /          folgt meist auf PSRAM-Probleme (unten)
DoubleException
Interrupt wdt timeout  ein Task haengt - oft netzwerkbezogen;
                       auf bekannte Issues deiner Version
                       pruefen

Ein einzelner Panic: ignorieren. Eine Schleife: Prüfe, ob es jedes Mal derselbe Grund ist (Firmware- oder Hardwarefehler: nach Tabelle handeln) oder ob Brownout-Meldungen dazwischenliegen (dann ist es der Strom: hör auf, Panics zu lesen, und repariere die Versorgung).

PSRAM-Fehler: die Nerd-Familien-Besonderheit

NerdQaxe, NerdOctaxe und andere Platinen auf Basis des ESP32-S3-WROOM-1-Moduls nutzen externes PSRAM. Ein Start-Banner mit einem PSRAM-ID-Lesefehler oder Init-Fehler, gefolgt von einem StoreProhibited-Panic, sobald die Firmware externen RAM anfasst, hat fünf bekannte Wurzeln: gefälschte Module ohne PSRAM-Die, eine Firmware mit falschem PSRAM-Modus (Octal statt Quad), kalte Lötstellen unter dem Modul, Brownout während des Init-Fensters oder ein alternder Die. Die praktische Triage: zuerst den Strom ausschließen (wie immer), das exakte herstellerspezifische Image für deine Platine flashen (es kodiert den richtigen PSRAM-Modus), und bleibt der Fehler bei sauberem Strom und korrekter Firmware bestehen, ist das Modul selbst schuld, was ein Garantie- oder Werkstattfall ist.

Übertakten schiefgelaufen: Rettung und Vorbeugung

Die Fehlersignatur: Frequenz oder Spannung erhöht, und nun stürzt das Gerät ab, fällt nach Minuten bis Stunden flach, drosselt, oder ein Chip einer Mehrchip-Platine verschwindet. Die Physik ist in einer bestimmten Hinsicht unnachgiebig: Instabilität durch zu hohen Takt zeigt sich oft erst mit Verzögerung. Eine Einstellung, die einen 10-Minuten-Test übersteht, kann in Minute 40 scheitern, wenn die Platine vollständig durchgewärmt ist, weshalb jede Stabilitätsaussage unter 24 Stunden vorläufig ist.

RETTUNG (wenn das Geraet noch startet):
  Weboberflaeche -> Frequenz und Spannung auf Werkswerte
  zuruecksetzen -> speichern -> Kaltstart (loescht einen
  eventuell eingerasteten Fehler).

RETTUNG (wenn es in einer Absturzschleife haengt):
  Factory-Image per USB-Web-Flash - das stellt die
  Werkseinstellpunkte wieder her. Danach Werksreset, um
  das NVS zu leeren.

VORBEUGUNG (die ganze Methode in fuenf Zeilen):
  - eine 25-MHz-Stufe auf einmal, Spannung unberuehrt
  - mindestens 30 Minuten pro Stufe, HW-Fehlerrate im Blick
  - Fehler ueber 2% = eine Stufe zurueck; das ist die Wand
  - erst dann Spannung in 25-mV-Schritten anheben, wenn du
    die zusaetzliche Waerme akzeptierst; im Fenster
    1100-1300 mV bleiben
  - 24 Stunden auf der finalen Einstellung, bevor du sie
    stabil nennst

Und eine ehrliche Anmerkung: Untervolten für Effizienz scheitert genauso wie Übertakten für Tempo, nur in die andere Richtung: zu wenig Spannung für den Takt erzeugt dieselben Fehler und Hänger. Die Silizium-Lotterie gilt an beiden Rändern.

Diagnose über die API: die Abkürzung für Fortgeschrittene

Jeder Miner der AxeOS-Familie stellt eine REST-API auf Port 80 bereit, und das verändert, wie Fehlersuche aussieht: kein Display nötig, kein Klicken durch Dashboards, und es skaliert von einem Gerät bis zur Flotte. Die vollständige Spezifikation liegt in der Datei openapi.yaml im ESP-Miner-Repository; dies sind die Aufrufe, die für die Diagnose zählen.

Die fünf Diagnose-Aufrufe

# Alles auf einmal: Hashrate-Durchschnitte, Temperaturen,
# Spannung, Leistung, Luefterdrehzahl, Shares, beste
# Difficulty, WLAN-RSSI, Laufzeit, Firmware-Version, Heap
curl http://MINER-IP/api/system/info

# ASIC-Zustand: Chipmodell, Anzahl, Frequenz, Spannung
curl http://MINER-IP/api/system/asic

# Zeitreihen, aus denen die Dashboard-Diagramme entstehen
curl "http://MINER-IP/api/system/statistics?columns=hashrate,asicTemp,vrTemp,power"

# DER UNTERSCHAETZTE: die Geraetelogs aus der Ferne laden.
# Kein serielles Kabel, kein PuTTY - das Log ueber das Netz
# holen und nach den roten Zeilen des Woerterbuchs greppen.
curl http://MINER-IP/api/system/logs

# Welches Geraet ist welches? Laesst das Geraet sich selbst
# zu erkennen geben (Display/LED) - unbezahlbar in einem
# Regal voller identischer Kaesten
curl -X POST http://MINER-IP/api/system/identify

Dieser Logs-Endpunkt verdient einen eigenen Satz: Der größte Teil des Abschnitts zur seriellen Konsole lässt sich mit diesem einen Aufruf vom Sofa aus erledigen, solange das Gerät weit genug startet, um HTTP auszuliefern. Das serielle Kabel bleibt nur für Startzeit- und Absturzschleifen-Fehler nötig.

/api/system/info lesen wie ein Mechaniker

Sechs Felder in diesem JSON beantworten die meisten Anfragen, bevor sie gestellt werden:

FELD (uebliche Bezeichnung) WAS ES DIR SAGT
hashRate / hashrate_10m   die Behauptung - mit dem Pool
                          vergleichen
temp / asicTemp           das 55-62 C Budget aus dem
                          Temperaturabschnitt
vrTemp                    die Reglerseite - oft der echte
                          Begrenzer bei BM1370/BM1373
voltage                   die Eingangsschiene, WIE DIE
                          PLATINE SIE SIEHT: ein Software-
                          Multimeter. Faellt sie unter Last
                          unter 4,9 V = Netzteil, bewiesen
                          ohne das Gehaeuse zu oeffnen
power                     aufgenommene Watt - 2 W bei einem
                          "hashenden" Geraet = die USB-C-Falle
sharesAccepted /          das Wahrheitspaar; steigende
sharesRejected            Ablehnungen = Ablehnungstabelle
wifiRSSI                  staerker als -70 dBm ist gesund;
                          schwaecher erklaert stale Shares
freeHeap                  ueber Tage langsam schrumpfend =
                          die Speicherleck-Klasse von
                          Firmware-Bugs; Version notieren,
                          Tracker pruefen

Flottengesundheit in einer Schleife

Ab mehr als einem Gerät hör auf, Dashboards zu prüfen. Diese Schleife gibt pro Miner eine einzeilige Zusammenfassung aus und markiert die toten:

#!/bin/bash
# fleet-check.sh - IPs an deinen Schwarm anpassen
for IP in 192.168.1.101 192.168.1.102 192.168.1.103; do
  J=$(curl -s -m 5 "http://$IP/api/system/info")
  if [ -z "$J" ]; then
    echo "$IP  NICHT ERREICHBAR"
    continue
  fi
  echo "$J" | python3 -c "
import sys, json
d = json.load(sys.stdin)
print('$IP  %-10s %6.1f GH/s  %4.1fC  %4.1fW  acc:%s rej:%s' % (
  d.get('hostname','?'),
  d.get('hashRate',0),
  d.get('temp',0),
  d.get('power',0),
  d.get('sharesAccepted','?'),
  d.get('sharesRejected','?')))"
done

Lass sie per Cron alle fünf Minuten laufen, leite sie an eine Benachrichtigung deiner Wahl weiter, und aus einem Ausfall um 2 Uhr nachts wird ein Alarm um 2:05 Uhr statt einer Überraschung am Morgen. Die Feldnamen unterscheiden sich leicht zwischen Firmware-Versionen; gib das rohe JSON einmal aus und passe an.

Die API kann auch reparieren

# Neustart, ohne die Hardware anzufassen
curl -X POST http://MINER-IP/api/system/restart
#   (denk daran: das loescht KEINEN eingerasteten TPS546-
#    Power-Fault - dafuer braucht es weiter das physische
#    Abziehen)

# Ein Uebertaktungsexperiment aus der Ferne zurueckdrehen
curl -X PATCH http://MINER-IP/api/system \
  -H "Content-Type: application/json" \
  -d '{"frequency": 525, "coreVoltage": 1150}'

# Eine vertippte Pool-Konfiguration ohne Weboberflaeche fixen
curl -X PATCH http://MINER-IP/api/system \
  -H "Content-Type: application/json" \
  -d '{"stratumUser": "DEINE_WALLET.worker1"}'

Eine ehrliche Einschränkung: Die API hat keine Authentifizierung. Jeder in deinem LAN kann deine Miner auslesen und umkonfigurieren. In einem Heimnetz ist das meist akzeptabel; in einem geteilten oder gastzugänglichen Netz gehören die Miner in ein eigenes VLAN oder IoT-Segment: was praktischerweise dieselbe Lösung ist, die der WLAN-Abschnitt bereits empfohlen hat.

Modellspezifische Eigenheiten: kenne den Charakter deiner Platine

Jenseits der universellen Fehlermodi hat jede Platinenfamilie charakteristische Verhaltensweisen, die man vor der Fehlersuche kennen sollte.

Die Master-Symptomtabelle

Das Wörterbuch der roten Zeilen

Die Fehlermeldungen, die dir tatsächlich begegnen, an einem Ort, wortwörtlich so geschrieben, dass Strg+F sie findet. Finde deine Zeile, bekomme deine Richtung.

ZEILE IM LOG                       BEDEUTUNG -> WOHIN
---------------------------------------------------------------
Brownout detector was triggered    Versorgung eingebrochen -> Strom
rst:0x.. (BROWNOUT_RESET)          dasselbe, im Reset-Banner
Power Fault Detected               TPS546 eingerastet -> Strom
TPS546 status / regulator fault    gleiche Familie -> Strom
VCORE init failed /                Firmware kann den Regler nicht
  device ID mismatch               programmieren: falsches Image
                                   oder I2C -> ASIC + Firmware
i2c_master_transmit_receive err /  Sensorbus tot -> ASIC-
  ESP_ERR_TIMEOUT near boot          Abschnitt, I2C-Unterpunkt
Found 0 chip(s) / ASIC init fail   Chip antwortet nicht -> ASIC
Chip count N of M                  Kettenbruch bei N+1 -> ASIC
Device has overheated /            75 C Abschaltung -> Temperatur
  Overheat Mode
VREG temp over limit               Reglerseite heiss -> Temperatur
wifi: NO_AP_FOUND                  2,4-GHz-Sichtbarkeit -> Netzwerk
wifi: AUTH_EXPIRE / auth fail      falsches Passwort -> Netzwerk
wifi: beacon timeout               schwaches Signal/Kanal -> Netzwerk
wifi_disconnect reason: N          N nachschlagen; je Grund loesen
Stratum connection failed /        Pool nicht erreichbar -> Stratum
  connect errno
authorize failed                   Login abgelehnt -> Stratum,
                                   Adresse & Worker pruefen
job not found (beim Einreichen)    stale Share -> Stratum
above target / low diff share      Difficulty-Versatz oder HW-Fehler
duplicate share                    haengende Nonce -> Stromzyklus,
                                   dann Takt reduzieren
Guru Meditation Error: (GRUND)     Panic -> Firmware, das
                                   Grundwort lesen
esp_psram: PSRAM ID read error /   PSRAM-Init -> Firmware,
  Failed to init external RAM        Nerd-Familien-Unterpunkt
E (xx) esp_image: checksum failed  Flash beschaedigt -> USB-Reflash
[www.bin / leere UI nach Update]   Recovery-URL -> Firmware

Vorbeugende Wartung: das 15-Minuten-Monatsritual

Fast alles oben ist billiger zu verhindern als zu debuggen.

MONATLICH
  [ ] Staub: Lamellen und Luefterblaetter (Druckluft,
      Luefter dabei festhalten)
  [ ] Pool-seitige Kontrolle: Trend akzeptiert vs.
      abgelehnt, und HW-Fehler % weiter unter 2
  [ ] Blick auf die Temperaturen: Drift gegenueber dem
      Vormonat?
  [ ] Stromstecker anfassen: warm ist eine Warnung,
      heiss ist ein Stopp

ALLE 6-12 MONATE
  [ ] Waermeleitpaste erneuern (Verbrauchsmaterial)
  [ ] XT30-/Hohlstecker-Kontakte auf Verfaerbung pruefen
  [ ] Netzteil unter Last mit dem Multimeter nachmessen

BEI JEDEM FIRMWARE-UPDATE
  [ ] Release Notes VOR dem Flashen lesen
  [ ] Aktuelle Version notieren (dein Rollback-Ziel)
  [ ] Bei stabiler Stromversorgung flashen, moeglichst
      nah am Router
  [ ] Pool-Konfiguration danach pruefen: Updates koennen
      Felder zuruecksetzen

IMMER
  [ ] Fallback-Pool konfiguriert (zweite Region)
  [ ] Eindeutige Worker-Namen in der ganzen Flotte
  [ ] Schriftliche Tabelle: Chain -> Wallet-Adresse
  [ ] Werkseinstellungen notiert, bevor du tunst

Wenn es wirklich Hardware ist: was reparierbar ist

Du hast kaltgestartet, werksresettet, das richtige Image auf nachweislich guter Stromversorgung neu geflasht, und der Fehler bleibt. Das ist die Definition eines Hardwareproblems. Die realistische Reparaturkarte:

• Auf der Werkbank reparierbar (Heißluft, Mikroskop, ruhige Hände oder ein Profi): defekter TPS546 oder Buck-Stufen-Bauteile, gerissene Keramikkondensatoren, kalte Lötstellen unter dem ASIC oder dem ESP32-Modul (Reflow), verschlissene Stromstecker, tote Lüfter. Das ist Routine für jede ASIC-Reparaturwerkstatt.
• Manchmal zu retten: eine Platine mit Kurzschluss auf der 5-V-Schiene (nahezu null Ohm gegen Masse, stromlos gemessen) — leg keine Spannung mehr an; der Kurzschluss muss erst gefunden und beseitigt werden.
• Meist endgültig: ein ASIC, der länger als ein paar Sekunden ohne Kühlkörperkontakt lief, die Folgen eines thermischen Durchgehens, oder ein Chip, dem bei einer improvisierten VRM-Reparatur die falsche Kernspannung zugeführt wurde. Auf einer Einzelchip-Platine steckt der größte Teil des Werts im Chip: ab einem bestimmten Punkt schlägt Ersatz die Reparatur.

Hilfe aus der Community gibt es im OSMU-Discord und im ESP-Miner-GitHub-Issue-Tracker: durchsuche vor dem Melden zuerst den Tracker, denn ein auffälliger Anteil der Meldungen „mein Gerät ist kaputt” sind bekannte Issues mit einem bereits gemergten Fix in der nächsten Version. Beim Melden wird ein vollständiger Bericht in Stunden beantwortet, während ein vager Bericht still verhungert. Kopiere diese Vorlage:

PLATINE:    (exaktes Modell + Revision, z.B. Gamma 602)
FIRMWARE:   (AxeOS-Version, aus Dashboard oder /api/system/info)
NETZTEIL:   (Spannung, Ampere, Marke - und: unter Last gemessen?)
POOL:       (URL + Port + Coin)
SYMPTOM:    (ein Satz: was passiert, seit wann)
AUSLOESER:  (was sich direkt davor geaendert hat: Update?
             Transport? OC? Kuehlkoerper neu montiert? nichts?)
VERSUCHT:   (Kaltstart 60s? Werksreset? Reflash? Werkstakt?
             Selbsttest-Ergebnis?)
LOG:        (Boot-Log aus seriell 115200 oder aus
             curl http://IP/api/system/logs einfuegen -
             mindestens die erste E-Zeile und zehn Zeilen
             drumherum)

Diese Vorlage ist keine Bürokratie: Es sind genau die Informationen, die eine Reparaturwerkstatt zuerst erhebt, in der Reihenfolge, in der sie sie erhebt.

PRO: der Werkbank-Abschnitt — Schaltpläne, Messpunkte und das Messgerät

Dieser Abschnitt setzt voraus, dass du einen Schaltplan lesen und eine spannungsführende Platine messen kannst, ohne benachbarte Pins zu überbrücken. Wenn dieser Satz dich zögern lässt, hör hier auf: Alles oberhalb dieser Zeile ist ohne Öffnen des Gehäuses lösbar, und eine abrutschende Messspitze auf einer stromführenden 3-nm-Platine macht aus einem Problem zwei. Für alle anderen: Hier zahlt sich offene Hardware aus.

Warum diese Platinen anders sind als jeder andere Miner

Bitaxe-Hardware ist unter CERN-OHL-S lizenziert und in KiCad entworfen, und jeder Schaltplan, jedes Platinenlayout und jede Stückliste ist öffentlich. Das heißt, du rätselst nie, was ein Bauteil ist oder wo eine Schiene verläuft: Du kannst den exakten Schaltplan für deine exakte Platinenrevision öffnen, das Netz finden und messen. Kein Antminer-Besitzer hatte je dieses Privileg. Jedes Hardware-Repository trägt außerdem einen Bereich, den fast niemand öffnet: die HW-Issues-Seite mit bekannten Fehlern, Reworks und Errata je Revision. Bevor du irgendeinen Fehler auf Platinenebene diagnostizierst, prüfe, ob deine Revision ein dokumentiertes Erratum hat: Ein auffälliger Anteil „mysteriöser” Hardwarefehler steht dort bereits samt der Änderung, die sie behebt.

Die Multimeter-Methode: drei Schienen erzählen die ganze Geschichte

Fehler im Strompfad lokalisiert man mit drei Gleichspannungsmessungen in dieser Reihenfolge. Zuerst Masse anlegen, die Reihenfolge einhalten und dort unter Last messen, wo angegeben.

SCHIENE 1 - EINGANG (5 V oder 12 V je nach Familie)
  Wo:        Eingangsstecker / Eingangspads (siehe Schaltplan)
  Erwartet:  5-V-Familie:  4,9 - 5,3 V  WAEHREND DES HASHENS
             12-V-Familie: 11,8 - 12,2 V WAEHREND DES HASHENS
  Nur unter Last zu niedrig -> Netzteil oder Kabel (meist)
  Zeigt 0 bei gutem Netzteil -> Eingangsschutz durch oder
                                Kurzschluss dahinter: Wider-
                                stand gegen Masse STROMLOS
                                messen - nahe null Ohm =
                                Kurzschluss, keine Spannung
                                mehr anlegen, ihn suchen

SCHIENE 2 - 3,3 V (die Versorgung des ESP32)
  Wo:        3,3-V-Netz laut Schaltplan (ESP32-Modul)
  Erwartet:  3,2 - 3,4 V stabil
  Fehlt bei gutem Eingang -> der kleine 3,3-V-Regler oder
  seine Passivbauteile: erklaert "komplett tot, keine USB-
  Erkennung" trotz nachweislich gutem Netzteil

SCHIENE 3 - VCORE (die Versorgung des ASIC)
  Wo:        Ausgang der TPS546-Buck-Stufe / ASIC-Kernnetz
  Erwartet:  etwa 1,0 - 1,3 V, passend zum in AxeOS
             eingestellten Wert
  Fehlt bei gutem Eingang und guten 3,3 V -> die Buck-
  Stufe: eingerasteter Fehler (immer zuerst Kaltstart)
  oder defekter TPS546 / Spule / umgebende Passivbauteile
  Vorhanden, aber falscher Wert -> Reglerprogrammierung
  oder PMBus-Kommunikation: gegenpruefen, was AxeOS
  gesetzt zu haben glaubt

BESTAETIGUNGSMESSUNGEN
  Durchgang Eingangsstecker -> Reglereingang: findet
  unterbrochene Leiterbahnen und gerissene Buchsenloetungen
  TPS546-Chiptemperatur laut Dashboard vs. Handprobe: ein
  Regler, dem man sich im Leerlauf nicht naehern kann, geht
  kaputt

Diese drei Schienen teilen jeden Stromfehler auf: Eingang schlecht = vor der Platine; Eingang gut, 3,3 V schlecht = der kleine Regler; beide gut, VCORE schlecht = die Buck-Stufe; alle drei gut = der Fehler ist kein Stromfehler, zurück zum ASIC-Abschnitt. Zehn Minuten mit einem 20-Dollar-Messgerät ersetzen Stunden der Spekulation.

Was eine Reparaturwerkstatt kann und was nicht

ROUTINE (Heissluft + Mikroskop + ruhige Haende)
  - Austausch von TPS546 / Buck-Stufen-Bauteilen
  - gerissene Keramikkondensatoren (optisch: Haarriss ueber
    den Koerper; elektrisch: Kurzschluss oder Unterbrechung)
  - BGA-Reflow unter ASIC oder ESP32-Modul (die Fehlerklasse
    nach Sturz und nach Neumontage)
  - Steckertausch (verschlissene Buchse, gekochter XT30)

MIT GEDULD MOEGLICH
  - Jagd auf einen Kurzschluss der 5-V-Schiene (Waermebild-
    kamera oder der Isopropanol-Verdunstungstrick ueber
    verdaechtigen Bereichen)
  - Tausch des ESP32-S3-Moduls (danach Neuflashen noetig)

NICHT LOHNEND / ENDGUELTIG
  - ASIC-Tausch auf Einzelchip-Platinen: der Chip ist der
    groesste Teil des Platinenwerts und Spenderchips sind
    ohnehin geerntet - eine neue Platine gewinnt bei Kosten
    und Sicherheit
  - alles nach thermischem Durchgehen oder verpolter
    Eingangsspannung ueber die ganze Schiene

Den Schaltplan wie ein Reparaturtechniker lesen

Drei Gewohnheiten, die die offenen Schaltpläne wirklich nützlich machen. Erstens: Suche die Seite mit dem Stromversorgungsbaum und verfolge einmal auf Papier den Weg vom Eingang zu VCORE, bevor du irgendetwas misst: Danach kennst du jedes Bauteil, das die Schiene töten kann. Zweitens: Notiere die Bauteilbezeichner (R12, C34, U3) der Buck-Stufe: Forenbeiträge und Errata verweisen über diese Bezeichner auf Bauteile, und sie deiner Platine zuzuordnen dauert mit offener Layout-Datei Sekunden. Drittens: Vergleiche Revisionen, wenn ein Fehler revisionsspezifisch ist: Das Änderungsprotokoll zwischen etwa einem Gamma 600 und 601 sagt dir genau, was die Entwickler behoben haben, und das ist oft genau das, was beim älteren ausfällt.

Die Open-Source-Ressourcenbibliothek

Alle Primärquellen in einer Tabelle. Setz ein Lesezeichen auf diesen Abschnitt: Der halbe Wert offener Hardware liegt darin, zu wissen, wo die Originale liegen, und jeder Link unten ist die offizielle Quelle, kein Spiegel.

Die wichtigsten Erkenntnisse

• Sechs Domänen decken nahezu jeden Fehler ab: Strom, ASIC, Temperatur, Netzwerk, Stratum, Firmware. Die 60-Sekunden-Triage sagt dir, in welcher du bist, bevor du irgendetwas anfasst.
• Strom ist die Ursache Nummer eins und der Hochstapler Nummer eins: Er tarnt sich als WLAN-Absturz, Firmware-Panic, hängender Chip und tote Platine. Miss den Eingang unter Last, bevor du irgendeiner anderen Theorie glaubst.
• Ein eingerasteter Reglerfehler überlebt jeden Software-Neustart. Physisches Abziehen für 10 bis 60 Sekunden ist ein echter Diagnoseschritt, kein Aberglaube.
• USB-C versorgt den ESP32, niemals den ASIC. Eine Platine nur an USB-C imitiert perfekt einen toten Miner bei 0 GH/s.
• Lerne die serielle Konsole mit 115200 Baud. Die erste E-Zeile in einem Boot-Log benennt dein Problem schneller als jeder Forenthread.
• Der eingebaute Selbsttest benennt das fehlerhafte Subsystem in 30 Sekunden, und die REST-API holt Logs, Telemetrie und sogar die Lösung über das Netz: nutze beides, bevor du zum seriellen Kabel greifst.
• Schließe niemals ein 12-V-Netzteil an eine 5-V-Platine an. Die Stecker sind austauschbar; die Platinen nicht.
• Der ESP32 spricht nur 2,4 GHz; Band Steering und AP-Isolation sind die zwei Router-Funktionen, die die meisten Setups zerstören.
• Die Wahrheit auf Pool-Seite schlägt den Optimismus auf Miner-Seite: die Zeit seit dem letzten akzeptierten Share ist der einzige ehrliche Online-Test, und 10 Minuten sind die Schwelle.
• Die Wallet-Adresse muss zur geminten Chain gehören. Bei einem nicht-verwahrenden Pool ist das der eine Fehler ohne Rückweg.
• Die Hardware-Fehlerrate ist die ehrliche Leistungszahl; die Dashboard-Hashrate ist eine Behauptung. Tune auf akzeptierte Shares und verlange 24 Stunden, bevor du eine Einstellung stabil nennst.
• Ein heißer Stromstecker ist das eine Symptom, das jetzt sofort aufhören heißt, nicht später debuggen.

Zusammengestellt aus dem ESP-Miner-Issue-Tracker und den Release Notes, der ESP-IDF-Dokumentation zu fatalen Fehlern, der Dokumentation von Reparaturwerkstätten der Community und den wiederkehrenden Fehlermustern, die in den Bitaxe-, NerdAxe- und NerdQaxe-Communities gemeldet werden, Stand 20. Juli 2026. Das hier beschriebene Firmware-Verhalten (Fehlerverriegelung, Überhitzungsschwellen, Recovery-URLs, bekannte Regressionsbänder) entspricht den zum Zeitpunkt der Veröffentlichung aktuellen AxeOS-/ESP-Miner-Versionen; prüfe die Release Notes deiner Version. Diese Anleitung wird als lebende Referenz gepflegt: Wenn du auf einen hier nicht behandelten Fehler stößt, schreib uns über die Kontaktseite und wir nehmen ihn auf.