Bandwidth was never the interesting number

The house in Kapfenberg hangs off a 5G outdoor antenna. When the line went slow, my first question was not what is wrong with it, but what do I even measure it with.

That sounds like a preliminary. It was the actual question.

Why not the thing that comes bundled

Home Assistant ships with a speed test. In Merano it was the first attempt, and it would have cost me a complaint to the provider:

Source	Download	Upload	Ping
speedtestdotnet, bundled	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

Off by a factor of four, and a ping of half an hour. Same line, same minute. The full story is in the Merano piece — what matters here is the consequence: in Kapfenberg the bundled integration was never installed in the first place.

The likely reason for the outlier is a poor server choice. That is not an accusation against the integration, it is a property of it: it takes what it gets, and it does not tell you whether that was a good pick.

What runs instead

A community project that calls the official Ookla command-line client — soulripper13/hass-speedtest-ookla, release 3.1.2. Installed by hand, without HACS, like three other integrations in this house.

Setting	Value
Interval	every 30 minutes
Server choice	automatic, closest, with fallback
Latency measurement	on

The difference to the bundled solution is not three better numbers but 17 sensors instead of three: download, upload, ping idle, while downloading and while uploading — each with a minimum and a maximum —, plus jitter, a bufferbloat grade, the server, the provider and the timestamp.

Those extra values delivered the actual finding. Bandwidth did not.

What it costs, written down honestly

48 measurements a day. Each one pulls real data over the line and occupies it for twenty to forty-five seconds.

On a tariff with a data cap that would need rethinking. And a speed test in the middle of a video call disturbs exactly that video call.

A measuring device that occupies the line is not a neutral observer. It is part of the traffic it measures.

That reads like an aside. It is the sentence that later cost me four weeks — which is what part two is about.

The first measurement showed something I had not been looking for

29.08.2026, 22:09:

Download	21.87 Mbit/s
Upload	14.62 Mbit/s
Ping idle	28.87 ms
Jitter	8.05 ms
Ping while uploading, peak	1,697 ms
Bufferbloat	C

The conspicuous value is not the bandwidth, it is the latency under load. 28.9 milliseconds idle, 1,697 while uploading — nearly two seconds.

That is bufferbloat: buffers that would rather accept everything than drop anything, building a queue that every interactive packet has to pass through. It is why a video call can stutter while there is plenty of bandwidth.

And it is one measurement, not a finding. In Merano every fourth measurement was off by a factor of four. Only the series over days says anything.

The factor that got worse as everything got better

A week later the line had collapsed to 20 Mbit/s. A power cycle at the antenna fixed it — a factor of eight to ten in one minute.

My reading before that had been: a line that blows its response time up fifteenfold under load has bufferbloat, and with 5G that is usually the result of a struggling radio path.

The first half of that is right. The second is not, and the reset disproved it:

	idle	peak under load	factor
before, 20 Mbit/s	43.6 ms	699 ms	16
after, 240 Mbit/s	21.2 ms	1,714 ms	81

At ten times the throughput the same buffers fill faster. Had my causal chain been right, the factor should have improved along with throughput. It quintupled.

The mistake was not the observation, it was the link: I made one cause out of “latency blows up under load” and “throughput is low”. There are two. One was a stuck mobile session that a power cycle clears. The other is a permanent property of this path, and after the reset it was worse than before.

With a slow line, power cycle first, diagnose second. It takes a minute. Reading the radio values would have taken an hour and found nothing.

The fourth tool was the device itself

Up to here I had measured the line. What was missing was the antenna — and with it the answer to whether 240 Mbit/s is what the radio path can give at all.

Every source said the outdoor unit’s interface is unreachable in bridge mode. Two failed attempts, both instructive:

1. I scanned known management addresses — from inside an add-on container, not from the house network. All I reached was the router. A trial run from the wrong place proves nothing.
2. The obvious address is taken by the router here. That looked like “the unit does not answer” but was “somebody else answers there”.

What found it was a traceroute — the tool that names every hop outward individually:

1   router in the house
2   <- the outdoor unit, visible in the middle of bridge mode
3   first public hop

It had been there all along, just at a different address than everyone claims.

Two quirks that cost time

Blocked is not the same as blocked. The interface’s JavaScript files are only served with a matching referrer header, the stylesheet always. Without that one header it looks like a locked interface. It is a locked file — and without the JavaScript you cannot find the command names.

Guessed paths lead nowhere. I tried the usual suspects from three other manufacturers, all answered with not found. The right path was in the JavaScript I could not load before.

Guessing cost three attempts, reading cost one.

The password obfuscation is not one

The interface encrypts the password before sending it. The function is named after a recognised cipher, and that is the kindest thing that can be said about it.

The key sits hard-coded in the shipped JavaScript. It is passed on without key expansion, and at that key length the round loop runs zero times. What is left is a single degenerate round with a key that every visitor to the interface is handed.

Rebuilt and verified against a hand calculation, byte by byte. The actual password therefore lives where it belongs: in a file only the owner may read, entered by a human.

An obfuscation whose key ships with it is not encryption. It is a form of politeness.

And then the numbers that settled everything

Value	measured	reading
RSRP, received power	−71 dBm	above −80 counts as very good
RSRQ, received quality	−11 dB	usable
SINR, signal against noise	16.5 dB	above 13 counts as good
RSSI	−40 dBm	very strong

The radio path is in excellent condition. My guess from the night before — weak signal, many retransmissions — is therefore disproved not only by the reset but by exactly the measurement I had demanded at the time and did not have.

What actually limits throughput

The same request carries three values nobody looks at, because they do not look like quality: one active carrier, no secondary cells configured, none activated.

A single carrier, no carrier aggregation.

That explains 240 Mbit/s without blaming the signal: with one carrier and no aggregation, that is roughly what is available. Anyone who wants more needs more carriers, not more signal.

Aiming the antenna better would have achieved almost nothing here — a measure that would have been the obvious move without these numbers, and would have cost a weekend.

What I cannot explain

Two values from the same request make no sense: the reported band number is not a valid one but apparently a vendor-specific encoding, and the channel number belongs to the LTE anchor, not to the 5G carrier.

Noted, not interpreted. A number you do not understand belongs in the documentation, not in the argument.

One trap during installation that strikes silently

The sensors are backed by command-line calls. Their notation changed in Home Assistant: since 2023 they are a top-level block of their own.

The old form is silently ignored. The configuration check reports “successful”, the sensor simply does not come into existence, and everything built on top of it reads unavailable. Stepped right into it — while the correct example sat in a neighbouring file the whole time.

What I would advise

1. Compare your measuring tool against two others, once. Once, at the start, fifteen minutes. After that you know whether you may believe your own numbers.
2. Do not look at bandwidth alone. Latency under load tells you more about why a line feels slow.
3. Write down what your measurement costs. 48 tests a day are data usage and an occupied line.
4. Ask the device before you rebuild it. Four radio values and the number of carriers answer in five minutes whether a measure can achieve anything at all.
5. Separate observation from linkage. Two conspicuous values are not automatically one cause. My two were two.
6. On mobile, power cycle first. A stuck session looks exactly like a bad location and is ruled out in a minute.

So what?

I had assumed measuring was the easy part and interpretation the hard one. It was the other way round.

Each of the four tools said something the others could not: the bundled integration, that you must not believe a measuring device unchecked. The Ookla CLI, that bandwidth was not the problem. The reset, that my causal chain was wrong. And the antenna itself, that the radio was never at fault.

The number I started with — megabits per second — was the least interesting of them all. It just shouted the loudest.