Tre città, tre fonti dati, una domanda: quando devo uscire?

In ognuna delle mie tre case si pone la stessa domanda: quando devo uscire?

La risposta l’ho costruita tre volte — prima a Merano, poi a Kapfenberg, infine a Vienna. Ogni volta sullo stesso modello, ogni volta con una fonte dati diversa, e ogni volta ho sbagliato in un punto diverso.

Gli errori sono la parte interessante, perché non si sono ripetuti. Si sono spostati.

Tre volte la stessa idea, tre tecnologie diverse

	Costruito	Fonte
Merano	09.08.2026	Südtirolmobil, interfaccia EFA
Kapfenberg	30.08.2026	Verbundlinie Steiermark, la stessa interfaccia EFA
Vienna	06.09.2026	dati aperti in tempo reale di Wiener Linien, formato proprio

Due sedi condividono un protocollo, la terza no. È la norma in Austria e in Italia: non esiste un formato comune, ma esistono due grandi famiglie — e con fortuna la seconda sede ricade nella stessa.

Kapfenberg è stata quindi pronta in un pomeriggio. Vienna ha richiesto una ricostruzione.

L’unica idea che fa la differenza

Tutti e tre i monitor hanno una caratteristica che non si trova su nessun orario affisso alla fermata: conoscono il tragitto a piedi.

Ogni sensore sa quanto tempo serve per raggiungere la sua fermata, e le partenze più vicine di così non entrano nemmeno in elenco.

Un treno che parte tra 8 minuti mentre te ne servono 15 per arrivare in stazione non è un’informazione, è una trappola.

Sembra poco e cambia tutto. Un normale monitor mostra la prossima partenza. Uno utile mostra la prossima partenza raggiungibile.

Dove sta il tempo è una decisione

Il tragitto a piedi sta nel sensore, non nella visualizzazione. Così vale per ogni scheda e per ogni automazione futura allo stesso modo, e c’è un solo punto da modificare.

Le schede scrivono il valore solo nell’intestazione — e per farlo lo leggono dal sensore. Così l’etichetta non può divergere dal filtro. Un monitor con «15 minuti a piedi» in testa che filtra a 10 è peggio di nessun monitor.

E una conseguenza che non avevo considerato

Alla stazione, di 18 autobus interrogati dopo il filtro ne restavano tre. Nel primo quarto d’ora semplicemente parte molto.

I limiti di interrogazione sono dovuti salire parecchio — fino a 34 partenze per una fermata. Chi allunga il tragitto a piedi deve alzarli di conseguenza, altrimenti la scheda si svuota. Non è un difetto del filtro, è la sua conseguenza logica.

Tre trappole nei template

Tutte e tre mi sono costate tempo, e tutte e tre sono invisibili: il controllo della configurazione passa pulito.

Primo: le variabili non vengono tracciate. La prima stesura costruiva l’elenco in un blocco di variabili e lo leggeva solo per nome. Controllo pulito, dati grezzi pieni — e i sensori sono rimasti vuoti in permanenza. Home Assistant ricava gli inneschi per il ricalcolo dalle entità che compaiono nello stato stesso. Se l’accesso sta solo in una variabile, il sensore non conosce alcuna fonte e non ricalcola mai. Il ciclo va direttamente nello stato — anche se così lo si scrive due volte.

Secondo: la fonte ordina per orario previsto, non per tempo reale. Una sera un autobus con tre minuti di ritardo stava davanti a quello puntuale che partiva allo stesso minuto. In realtà è partito prima il puntuale. Per questo i sensori ordinano da sé — sul campo che già contiene il ritardo.

Terzo: i numeri arrivano come stringhe. Un ordinamento su di essi dà "1" < "12" < "4". Prima si converte in numero, poi si ordina.

E un’aggiunta che non entrava nell’elenco dei tre ma è della stessa specie: gli attributi devono essere stringhe. Un valore numerico è stato scartato in silenzio — il controllo passava, l’attributo semplicemente mancava nello stato.

L’errore che ho fatto due volte

Ed ecco quello che si è davvero spostato.

A Vienna avevo concluso da una misura che la fonte fornisce al massimo circa cinque partenze per linea. È finito nella documentazione e nell’intestazione della dashboard.

Sbagliato. Rimisurato il mezzogiorno successivo:

	per linea e direzione	portata
notte, intervallo 15 min	3–5	—
mezzogiorno, intervallo 7 min	7	fino a circa un’ora avanti

Misurato su undici linee: sempre al massimo sette, e sempre circa un’ora avanti. Il limite non è il numero ma la finestra temporale. Con un intervallo di 15 minuti, in un’ora ce ne stanno solo quattro.

Avevo misurato di notte — e quindi avevo misurato la finestra notturna.

Lo stesso errore mi era già capitato a Kapfenberg, dove avevo misurato di domenica l’orario domenicale scambiandolo per quello normale. E di nuovo è emerso solo quando qualcuno ha guardato in un altro momento della giornata.

La lezione è scomoda perché richiede pazienza: una misura su una rete di trasporto è una misura solo quando è stata presa in più momenti della giornata. Tutto il resto è un’istantanea che sembra un riscontro.

Il coniglio

Su tutte e tre le dashboard corre un coniglietto. Ogni minuto salta una riga più avanti, attraverso tutte le schede.

Ha esattamente uno scopo: mostra che la visualizzazione è ancora viva. Un monitor congelato sembra funzionante — gli orari ci sono. Te ne accorgi solo quando non si muove più nulla, e a quel punto hai perso l’autobus.

Calcolato male due volte

A Kapfenberg si distribuisce su 24 posizioni fisse: quattro schede da sei righe. Questo presuppone che ogni scheda abbia sempre sei righe.

A Vienna non è così. Una scheda la prima notte è arrivata a una sola riga.

Primo tentativo: a due stadi — prima si sceglie la scheda, poi la riga entro la sua lunghezza. Risolve il problema della lunghezza e cade non appena una scheda è vuota:

  Fermata · Linea (7 min a piedi)
  niente più raggiungibile

Conigli: 0

Il coniglio stava, per calcolo, sulla scheda che non aveva nulla da mostrare. Su tutta la dashboard non ce n’era nessuno.

Lo stesso errore di ragionamento di Kapfenberg, un livello più in alto: scegliere una scheda senza sapere se ha qualcosa da mostrare.

E come è emerso

È questa la parte che mi sono tenuto.

È emerso solo perché durante il rendering si contava — una riga che stampa quanti conigli ci sono sulla dashboard.

Guardando non ce ne si sarebbe accorti. Un coniglio mancante sembra un coniglio che in quel momento è altrove.

La soluzione ora è un unico calcolo su tutte le schede insieme: ogni scheda legge le lunghezze di tutti gli elenchi e mette le posizioni una dopo l’altra. Così il coniglio finisce sempre dove una riga esiste davvero.

Cosa ti consiglio

1. Filtra sul tragitto a piedi, non sull’orologio. La prossima partenza raramente è quella che ti serve. Il tempo va nel sensore, non nell’etichetta.
2. Misura in più momenti della giornata. Ogni interfaccia di trasporto si comporta di notte diversamente che a mezzogiorno, di domenica diversamente che nei feriali. Ci sono cascato due volte.
3. Ordina da solo. Se la fonte ordina per orario previsto, l’autobus in ritardo sta davanti a quello puntuale. Il campo con il tempo reale è quello giusto.
4. Inserisci un segnale di vita. Qualcosa che si muove visibilmente. Una dashboard con numeri congelati è più pericolosa di una vuota.
5. E conta quello che produci. Un errore che si noterebbe solo guardando non si nota.

E quindi?

Costruire tre volte la stessa cosa sembra uno spreco. È stato il contrario: la seconda costruzione è durata un pomeriggio perché il protocollo era lo stesso. La terza ha richiesto una fonte nuova, ma tutte le decisioni erano già prese — filtro sul tragitto, ordinamento proprio, segnale di vita.

Quello che non si è trasferito sono le ipotesi. Ogni città ha il suo comportamento, ed è esattamente dove ho dedotto da un posto all’altro che stava l’errore.

L’idea si trasferisce. La misura no.