Die Bandbreite war nie die interessante Zahl

Das Haus in Kapfenberg hängt an einer 5G-Außenantenne. Als die Leitung lahm wurde, war meine erste Frage nicht woran liegt es, sondern womit messe ich das überhaupt.

Das klingt nach einer Vorfrage. Es war die eigentliche.

Warum nicht das, was mitgeliefert wird

Home Assistant bringt eine Geschwindigkeitsmessung mit. In Meran war sie der erste Versuch, und sie hätte mich eine Beschwerde gekostet:

Quelle	Download	Upload	Ping
speedtestdotnet, mitgeliefert	23,15	12,19	1.800.000 ms
misurainternet.it	74,15	18,3	19,9 ms
Ookla-CLI	100,95	20,2	21,77 ms

Faktor vier daneben, und ein Ping von einer halben Stunde. Dieselbe Leitung, dieselbe Minute. Die ganze Geschichte dazu steht im Meraner Teil — hier zählt nur die Folge: In Kapfenberg wurde die mitgelieferte Integration deshalb gar nicht erst genommen.

Der wahrscheinliche Grund für den Ausreißer ist eine schlechte Serverwahl. Das ist keine Anklage gegen die Integration, sondern eine Eigenschaft: Sie nimmt, was sie bekommt, und sagt nicht dazu, ob das eine gute Wahl war.

Was stattdessen läuft

Ein Gemeinschaftsprojekt, das den offiziellen Ookla-Befehlszeilenclient aufruft — soulripper13/hass-speedtest-ookla, Fassung 3.1.2. Von Hand installiert, ohne HACS, wie drei weitere Integrationen in diesem Haus.

Einstellung	Wert
Takt	alle 30 Minuten
Serverwahl	automatisch, nächstgelegener, mit Rückfall
Latenzmessung	an

Der Unterschied zur mitgelieferten Lösung sind nicht drei bessere Zahlen, sondern 17 Sensoren statt drei: Download, Upload, Ping unbelastet, beim Laden und beim Senden — jeweils kleinster und größter Wert —, dazu Jitter, eine Bufferbloat-Note, der Server, der Anbieter und der Zeitpunkt.

Genau diese Zusatzwerte haben den eigentlichen Befund geliefert. Die Bandbreite war es nicht.

Was das kostet, ehrlich aufgeschrieben

48 Messungen am Tag. Jede zieht echte Daten über die Leitung und belegt sie für zwanzig bis fünfundvierzig Sekunden.

Bei einem Tarif mit Datenbegrenzung wäre das zu überdenken. Und ein Geschwindigkeitstest mitten in einem Videoanruf stört genau den Videoanruf.

Ein Messgerät, das die Leitung belegt, ist kein neutraler Beobachter. Es gehört zum Verkehr, den es misst.

Das liest sich wie eine Nebenbemerkung. Es ist der Satz, der mich später vier Wochen gekostet hat — davon handelt der zweite Teil.

Die erste Messung zeigte etwas, das ich nicht gesucht hatte

29.08.2026, 22:09 Uhr:

Download	21,87 Mbit/s
Upload	14,62 Mbit/s
Ping unbelastet	28,87 ms
Jitter	8,05 ms
Ping beim Senden, Spitze	1.697 ms
Bufferbloat	C

Der auffällige Wert ist nicht die Bandbreite, sondern die Latenz unter Last. 28,9 Millisekunden im Leerlauf, 1.697 beim Senden — fast zwei Sekunden.

Das ist Bufferbloat: Puffer, die lieber alles annehmen als etwas zu verwerfen, und dabei eine Warteschlange aufbauen, durch die jedes interaktive Paket hindurchmuss. Es ist der Grund, warum ein Videoanruf ruckeln kann, obwohl die Bandbreite reicht.

Und es ist eine Messung, kein Befund. In Meran lag jede vierte Messung um den Faktor vier daneben. Erst die Reihe über Tage sagt etwas.

Der Faktor, der schlechter wurde, als alles besser wurde

Eine Woche später war die Leitung auf 20 Mbit/s eingebrochen. Ein Stromstoß an der Antenne hat das behoben — Faktor acht bis zehn in einer Minute.

Meine Deutung davor hatte gelautet: Eine Leitung, die unter Last die Antwortzeit um das Fünfzehnfache aufreißt, hat Pufferstau, und bei 5G ist das in der Regel die Folge einer kämpfenden Funkstrecke.

Der erste Halbsatz stimmt. Der zweite nicht, und der Reset hat ihn widerlegt:

	Leerlauf	Spitze unter Last	Faktor
vorher, 20 Mbit/s	43,6 ms	699 ms	16
nachher, 240 Mbit/s	21,2 ms	1.714 ms	81

Bei zehnfachem Durchsatz füllen sich dieselben Puffer schneller. Wäre meine Ursachenkette richtig gewesen, hätte sich der Faktor mit dem Durchsatz verbessern müssen. Er hat sich verfünffacht.

Der Fehler war nicht die Beobachtung, sondern die Verknüpfung: Ich habe aus „die Latenz reißt unter Last auf“ und „der Durchsatz ist niedrig“ eine Ursache gemacht. Es sind zwei. Die eine war eine festgefahrene Mobilfunksitzung, die ein Stromstoß löst. Die andere ist eine dauerhafte Eigenschaft dieser Strecke und war nach dem Reset schlimmer als vorher.

Bei lahmer Leitung zuerst der Stromstoß, dann die Diagnose. Er dauert eine Minute. Die Funkwerte auszulesen hätte eine Stunde gedauert und nichts gefunden.

Das vierte Werkzeug war das Gerät selbst

Bis hierher habe ich die Leitung gemessen. Was fehlte, war die Antenne — und damit die Aussage, ob 240 Mbit/s das sind, was die Funkstrecke überhaupt hergibt.

Alle Quellen sagten, im Brückenmodus sei die Oberfläche der Außeneinheit nicht erreichbar. Zwei Fehlversuche, beide lehrreich:

1. Ich habe bekannte Verwaltungsadressen abgetastet — aus einem Add-on-Behälter heraus, nicht aus dem Hausnetz. Erreicht wurde nur der Router. Ein Probelauf vom falschen Ort beweist nichts.
2. Die naheliegende Adresse ist hier vom Router besetzt. Das sah aus wie „die Einheit antwortet nicht“, war aber „da antwortet jemand anderer“.

Gefunden hat es die Wegverfolgung — das Werkzeug, das jeden Sprung nach draußen einzeln benennt:

1   Router im Haus
2   <- die Außeneinheit, mitten im Brückenmodus sichtbar
3   erster öffentlicher Sprung

Sie war die ganze Zeit da, nur an einer anderen Adresse als überall behauptet.

Zwei Eigenheiten, die Zeit kosten

Gesperrt ist nicht gleich gesperrt. Die JavaScript-Dateien der Oberfläche werden nur mit passender Herkunftsangabe ausgeliefert, das Stylesheet dagegen immer. Ohne diese eine Kopfzeile sieht es aus wie eine verriegelte Schnittstelle. Es ist eine verriegelte Datei — und ohne das JavaScript findet man die Befehlsnamen nicht.

Geratene Pfade führen ins Nichts. Ich habe die üblichen Verdächtigen von drei anderen Herstellern probiert, alle mit nicht gefunden beantwortet. Der richtige Pfad stand in dem JavaScript, das ich vorher nicht laden konnte.

Raten kostete drei Anläufe, Lesen einen.

Die Kennwortverschleierung ist keine

Die Oberfläche verschlüsselt das Kennwort, bevor sie es schickt. Die Funktion ist nach einem anerkannten Verfahren benannt, und das ist das Freundlichste, was sich über sie sagen lässt.

Der Schlüssel steht fest im ausgelieferten JavaScript. Er wird ohne Schlüsselexpansion weitergereicht, und die Rundenschleife läuft bei dieser Schlüssellänge null Mal. Übrig bleibt eine einzige entartete Runde mit einem Schlüssel, den jeder Besucher der Oberfläche mitgeliefert bekommt.

Nachgebaut und an einer Handrechnung geprüft, Byte für Byte. Das eigentliche Kennwort liegt deshalb dort, wo es hingehört: in einer Datei, die nur der Eigentümer lesen darf, von Hand eingetragen.

Eine Verschleierung, deren Schlüssel mitgeliefert wird, ist keine Verschlüsselung. Sie ist eine Höflichkeitsform.

Und dann die Zahlen, die alles entschieden haben

Wert	gemessen	Einordnung
RSRP, Empfangsleistung	−71 dBm	über −80 gilt als sehr gut
RSRQ, Empfangsqualität	−11 dB	brauchbar
SINR, Signal gegen Rauschen	16,5 dB	über 13 gilt als gut
RSSI	−40 dBm	sehr stark

Die Funkstrecke ist in bestem Zustand. Damit ist meine Vermutung vom Vorabend — schwaches Signal, viele Wiederholungen — nicht nur durch den Reset widerlegt, sondern durch genau die Messung, die ich damals selbst gefordert und nicht gehabt hatte.

Was den Durchsatz wirklich begrenzt

Im selben Abruf stehen drei Werte, die niemand beachtet, weil sie nicht nach Qualität aussehen: ein aktiver Träger, keine konfigurierten Nebenzellen, keine aktivierten.

Ein einziger Träger, keine Trägeraggregation.

Das erklärt 240 Mbit/s, ohne dem Signal etwas vorzuwerfen: Bei einem Träger ohne Aggregation ist das etwa das Erreichbare. Wer mehr will, braucht mehr Träger, nicht mehr Signal.

Die Antenne besser auszurichten hätte an dieser Stelle fast nichts gebracht — eine Maßnahme, die ohne diese Zahlen naheliegend gewesen wäre und ein Wochenende gekostet hätte.

Was ich nicht erklären kann

Zwei Werte aus demselben Abruf ergeben keinen Sinn: Die gemeldete Bandnummer ist keine gültige, sondern offenbar eine herstellereigene Kodierung, und die Kanalnummer gehört zum LTE-Anker, nicht zum 5G-Träger.

Notiert, nicht ausgelegt. Eine Zahl, die man nicht versteht, gehört in die Dokumentation und nicht in die Argumentation.

Eine Falle beim Einbauen, die still zuschlägt

Die Sensoren hängen an Befehlszeilenaufrufen. Deren Schreibweise hat sich in Home Assistant geändert: Sie sind seit 2023 ein eigener Block auf oberster Ebene.

Die alte Form wird stillschweigend ignoriert. Die Konfigurationsprüfung meldet „erfolgreich“, der Sensor entsteht einfach nicht, und alles, was auf ihm aufbaut, steht auf nicht verfügbar. Genau darauf getreten — während das richtige Vorbild die ganze Zeit in einer Nachbardatei lag.

Was ich dir rate

1. Vergleich dein Messwerkzeug einmal mit zwei anderen. Einmal, am Anfang, eine Viertelstunde. Danach weißt du, ob du deinen Zahlen glauben darfst.
2. Schau nicht auf die Bandbreite allein. Die Latenz unter Last sagt dir mehr darüber, warum sich eine Leitung langsam anfühlt.
3. Schreib dazu, was deine Messung kostet. 48 Tests am Tag sind Datenverbrauch und eine belegte Leitung.
4. Frag das Gerät, bevor du es umbaust. Vier Funkwerte und die Zahl der Träger beantworten in fünf Minuten, ob eine Maßnahme überhaupt etwas bringen kann.
5. Trenne Beobachtung und Verknüpfung. Zwei auffällige Werte sind nicht automatisch eine Ursache. Meine zwei waren zwei.
6. Bei Mobilfunk zuerst der Stromstoß. Eine festgefahrene Sitzung sieht genauso aus wie ein schlechter Standort und ist in einer Minute ausgeschlossen.

Und was heißt das?

Ich hatte angenommen, die Messung sei der einfache Teil und die Deutung der schwere. Es war umgekehrt.

Jedes der vier Werkzeuge hat etwas gesagt, das die anderen nicht sagen konnten: die mitgelieferte Integration, dass man einem Messgerät nicht ungeprüft glauben darf. Das Ookla-CLI, dass die Bandbreite nicht das Problem war. Der Reset, dass meine Ursachenkette falsch war. Und die Antenne selbst, dass der Funk nie schuld gewesen ist.

Die Zahl, mit der ich angefangen hatte — Megabit pro Sekunde —, war von allen die uninteressanteste. Sie hat nur am lautesten geschrien.