La banda non è mai stata il numero interessante

La casa di Kapfenberg dipende da un’antenna 5G esterna. Quando la linea è diventata lenta, la mia prima domanda non è stata cosa non va, ma con che cosa lo misuro.

Sembra una domanda preliminare. Era quella vera.

Perché non quello che è già incluso

Home Assistant porta con sé una misura della velocità. A Merano è stato il primo tentativo, e mi sarebbe costato un reclamo al fornitore:

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

Un fattore quattro di scarto, e un ping di mezz’ora. Stessa linea, stesso minuto. La storia completa sta nella parte meranese — qui conta solo la conseguenza: a Kapfenberg l’integrazione inclusa non è stata nemmeno installata.

Il motivo probabile dello scarto è una cattiva scelta del server. Non è un’accusa all’integrazione, è una sua proprietà: prende quello che le capita, e non dice se sia stata una buona scelta.

Che cosa gira al suo posto

Un progetto della comunità che richiama il client ufficiale a riga di comando di Ookla — soulripper13/hass-speedtest-ookla, versione 3.1.2. Installato a mano, senza HACS, come altre tre integrazioni in questa casa.

Impostazione	Valore
Cadenza	ogni 30 minuti
Scelta del server	automatica, il più vicino, con ripiego
Misura della latenza	attiva

La differenza rispetto alla soluzione inclusa non sono tre numeri migliori, ma 17 sensori invece di tre: download, upload, ping a vuoto, in scaricamento e in invio — ciascuno con minimo e massimo —, più jitter, un voto di bufferbloat, il server, l’operatore e l’orario.

Sono stati proprio questi valori in più a fornire il dato vero. La banda no.

Quanto costa, scritto onestamente

48 misure al giorno. Ognuna tira dati veri sulla linea e la occupa per venti o quarantacinque secondi.

Con una tariffa a volume limitato sarebbe da ripensare. E uno speed test in mezzo a una videochiamata disturba proprio quella videochiamata.

Uno strumento che occupa la linea non è un osservatore neutrale. Fa parte del traffico che misura.

Sembra un’osservazione di passaggio. È la frase che più tardi mi è costata quattro settimane — ed è l’argomento della seconda parte.

La prima misura ha mostrato qualcosa che non cercavo

29.08.2026, ore 22:09:

Download	21,87 Mbit/s
Upload	14,62 Mbit/s
Ping a vuoto	28,87 ms
Jitter	8,05 ms
Ping in invio, picco	1.697 ms
Bufferbloat	C

Il valore che salta all’occhio non è la banda, è la latenza sotto carico. 28,9 millisecondi a vuoto, 1.697 in invio — quasi due secondi.

Questo è il bufferbloat: buffer che preferiscono accettare tutto piuttosto che scartare qualcosa, e che così costruiscono una coda attraverso cui ogni pacchetto interattivo deve passare. È il motivo per cui una videochiamata può scattare anche se la banda basta.

Ed è una misura, non un verdetto. A Merano una misura su quattro sbagliava di un fattore quattro. Solo la serie su più giorni dice qualcosa.

Il fattore che è peggiorato mentre tutto migliorava

Una settimana dopo la linea era crollata a 20 Mbit/s. Uno scollegamento dell’antenna dalla corrente l’ha risolto — un fattore otto-dieci in un minuto.

La mia lettura di prima era stata: una linea che sotto carico dilata il tempo di risposta di quindici volte ha un ingorgo nei buffer, e nel 5G questo di solito deriva da una tratta radio in difficoltà.

La prima metà è giusta. La seconda no, e il reset l’ha smentita:

	a vuoto	picco sotto carico	fattore
prima, 20 Mbit/s	43,6 ms	699 ms	16
dopo, 240 Mbit/s	21,2 ms	1.714 ms	81

Con dieci volte la portata gli stessi buffer si riempiono più in fretta. Se la mia catena causale fosse stata giusta, il fattore avrebbe dovuto migliorare insieme alla portata. È quintuplicato.

L’errore non era l’osservazione, era il collegamento: da «la latenza esplode sotto carico» e «la portata è bassa» ho ricavato una causa. Sono due. Una era una sessione mobile incastrata, che uno sbalzo di corrente risolve. L’altra è una proprietà permanente di questa tratta, e dopo il reset era peggiore di prima.

Con una linea lenta prima lo scollegamento, poi la diagnosi. Dura un minuto. Leggere i valori radio sarebbe durato un’ora e non avrebbe trovato nulla.

Il quarto strumento era il dispositivo stesso

Fin qui avevo misurato la linea. Mancava l’antenna — e con essa la risposta alla domanda se 240 Mbit/s siano quello che la tratta radio può dare.

Tutte le fonti dicevano che in modalità bridge l’interfaccia dell’unità esterna non è raggiungibile. Due tentativi falliti, entrambi istruttivi:

1. Ho scandagliato gli indirizzi di gestione noti — dall’interno di un contenitore add-on, non dalla rete di casa. Ho raggiunto solo il router. Una prova fatta dal posto sbagliato non dimostra niente.
2. L’indirizzo ovvio qui è occupato dal router. Sembrava «l’unità non risponde», ma era «lì risponde qualcun altro».

A trovarla è stato il tracciamento del percorso — lo strumento che nomina ogni salto verso l’esterno:

1   router di casa
2   <- l'unità esterna, visibile in piena modalità bridge
3   primo salto pubblico

Era lì da sempre, solo a un indirizzo diverso da quello che tutti dichiarano.

Due stranezze che costano tempo

Bloccato non è sempre bloccato. I file JavaScript dell’interfaccia vengono serviti solo con l’intestazione di provenienza giusta, il foglio di stile sempre. Senza quella riga sembra un’interfaccia sbarrata. È un file sbarrato — e senza il JavaScript non si trovano i nomi dei comandi.

I percorsi indovinati non portano da nessuna parte. Ho provato i soliti sospetti di altri tre produttori, tutti con risposta non trovato. Il percorso giusto stava nel JavaScript che prima non riuscivo a caricare.

Indovinare è costato tre tentativi, leggere uno.

L’offuscamento della password non è tale

L’interfaccia cifra la password prima di inviarla. La funzione porta il nome di un algoritmo riconosciuto, ed è la cosa più gentile che se ne possa dire.

La chiave sta fissa nel JavaScript consegnato. Viene passata senza espansione, e con quella lunghezza il ciclo dei round gira zero volte. Resta un unico round degenere con una chiave che ogni visitatore dell’interfaccia si ritrova in mano.

Ricostruito e verificato con un calcolo a mano, byte per byte. La password vera sta quindi dove deve stare: in un file leggibile solo dal proprietario, inserito a mano.

Un offuscamento la cui chiave viaggia insieme non è cifratura. È una forma di cortesia.

E poi i numeri che hanno deciso tutto

Valore	misurato	lettura
RSRP, potenza ricevuta	−71 dBm	sopra −80 è considerato ottimo
RSRQ, qualità ricevuta	−11 dB	utilizzabile
SINR, segnale contro rumore	16,5 dB	sopra 13 è considerato buono
RSSI	−40 dBm	molto forte

La tratta radio è in ottime condizioni. La mia ipotesi della sera prima — segnale debole, molte ritrasmissioni — è quindi smentita non solo dal reset, ma proprio da quella misura che allora avevo preteso e non avevo.

Che cosa limita davvero la portata

Nella stessa risposta ci sono tre valori che nessuno guarda, perché non sembrano valori di qualità: una portante attiva, nessuna cella secondaria configurata, nessuna attivata.

Una sola portante, nessuna aggregazione.

Questo spiega i 240 Mbit/s senza dare la colpa al segnale: con una portante senza aggregazione è all’incirca quanto si può ottenere. Chi ne vuole di più ha bisogno di più portanti, non di più segnale.

Orientare meglio l’antenna qui non avrebbe quasi cambiato nulla — una misura che senza questi numeri sarebbe stata la prima da provare, e sarebbe costata un fine settimana.

Quello che non so spiegare

Due valori della stessa risposta non hanno senso: il numero di banda riportato non è valido, ma pare una codifica propria del produttore, e il numero di canale appartiene all’ancora LTE, non alla portante 5G.

Annotati, non interpretati. Un numero che non si capisce va nella documentazione, non nell’argomentazione.

Una trappola in fase di installazione, che colpisce in silenzio

I sensori si appoggiano a chiamate a riga di comando. La loro notazione in Home Assistant è cambiata: dal 2023 sono un blocco a sé al livello più alto.

La forma vecchia viene ignorata in silenzio. Il controllo della configurazione dice «riuscito», il sensore semplicemente non nasce, e tutto ciò che vi si appoggia resta non disponibile. Ci sono caduto in pieno — mentre l’esempio giusto stava da sempre in un file accanto.

Che cosa ti consiglio

1. Confronta il tuo strumento di misura con altri due, una volta. Una volta, all’inizio, un quarto d’ora. Dopo sai se puoi credere ai tuoi numeri.
2. Non guardare solo la banda. La latenza sotto carico ti dice di più sul perché una linea sembra lenta.
3. Scrivi quanto costa la tua misura. 48 test al giorno sono consumo di dati e una linea occupata.
4. Interroga il dispositivo prima di modificarlo. Quattro valori radio e il numero di portanti rispondono in cinque minuti se un intervento possa servire a qualcosa.
5. Separa osservazione e collegamento. Due valori strani non sono automaticamente una causa sola. I miei due erano due.
6. Nel mobile prima lo scollegamento. Una sessione incastrata somiglia in tutto a una cattiva posizione, e si esclude in un minuto.

E questo che cosa significa?

Davo per scontato che misurare fosse la parte facile e interpretare quella difficile. Era il contrario.

Ognuno dei quattro strumenti ha detto qualcosa che gli altri non potevano dire: l’integrazione inclusa, che a uno strumento di misura non si crede senza verificarlo. Il CLI di Ookla, che la banda non era il problema. Il reset, che la mia catena causale era sbagliata. E l’antenna stessa, che la radio non è mai stata in colpa.

Il numero da cui ero partito — megabit al secondo — era il meno interessante di tutti. Era solo quello che gridava più forte.