Il tornello è la parte facile: il gestionale su misura dietro il controllo accessi di una palestra italiana

In breve

Una palestra italiana di dimensioni medie mi ha contattato per un tornello. Il problema vero non era il tornello: era che la reception controllava a mano se un socio avesse l’abbonamento in regola, tesseramenti e certificati medici finivano su fogli sparsi, e le soluzioni di controllo accessi già pronte sul mercato sono quasi sempre sistemi chiusi, proprietari, che non parlano con il resto della gestione.

Ho costruito il contrario. Un gestionale in cloud che tiene anagrafica soci, abbonamenti, pagamenti e prenotazione corsi in un unico posto. E una postazione fisica in palestra, un Raspberry Pi collegato a tastiera, monitor e a un Arduino che pilota il relè del tornello, che parla con quel gestionale in tempo reale a ogni ingresso. Il socio digita un codice, il sistema in cloud controlla se l’abbonamento è attivo e pagato, e solo allora il tornello si apre.

Non c’è niente di esotico nei singoli componenti: un Raspberry Pi, un Arduino, un router, un server cloud. Quello che vale la pena raccontare è come questi pezzi sono stati messi insieme, e le scelte fatte per tenere il sistema semplice, affidabile, senza sorprese quando la reception ha una giornata di code.

Il problema: un tornello non è mai solo un tornello

Quando un titolare di palestra pensa “controllo accessi”, di solito pensa al tornello. Ma il tornello è la parte facile. Il vero problema è tutto quello che deve succedere prima che il tornello riceva l’ordine di aprirsi:

• Verificare che l’abbonamento sia attivo. Mensile, annuale, pacchetto lezioni: ogni socio ha una scadenza diversa, e quella scadenza cambia ogni volta che rinnova.
• Verificare che sia pagato. Un abbonamento attivo ma con una rata insoluta non dovrebbe far entrare nessuno, ma è esattamente il caso che un controllo manuale in reception sbaglia più spesso, soprattutto nelle ore di punta.
• Tenere tutto sincronizzato con il resto della gestione: iscrizioni nuove, rinnovi, sospensioni, corsi prenotati. Se il controllo accessi vive in un sistema separato dal gestionale soci, prima o poi i due dati divergono.

La richiesta del cliente non era “mettici un tornello”. Era: fai in modo che il tornello sappia sempre, in tempo reale, chi può entrare e chi no, usando gli stessi dati che uso per gestire abbonamenti, pagamenti e corsi.

Questo ha spostato il progetto da “hardware con un’app di corollario” a “gestionale completo con un endpoint hardware”.

L’architettura: cloud al centro, hardware leggero in periferia

La decisione architetturale di fondo è stata questa: tutta l’intelligenza sta nel software in cloud, l’hardware in palestra fa il minimo indispensabile.

Il sistema si divide in due metà.

Il software gestionale, in cloud

Un server dedicato ospita il gestionale, che copre:

• Anagrafica soci: dati, tesseramento, certificato medico e relative scadenze.
• Abbonamenti: mensili, annuali, pacchetti, con stato attivo, scaduto o sospeso.
• Pagamenti e incassi: lo stato del saldo di ogni socio, così un abbonamento formalmente “attivo” ma con una rata non pagata blocca comunque l’ingresso.
• Corsi e prenotazioni: calendario lezioni, iscrizioni, capienza.

Da reception, un computer connesso a Internet accede a questo software per tutta l’operatività quotidiana (nuove iscrizioni, rinnovi, gestione corsi) e usa una webcam per scattare la foto tessera del socio in fase di iscrizione, associata all’anagrafica.

Questa è la parte del sistema che assomiglia a un normale SaaS gestionale verticale. Niente di insolito, tranne che diventa anche l’autorità che decide, in tempo reale, se un tornello fisico a decine o centinaia di chilometri di distanza deve aprirsi.

La postazione in palestra: Raspberry Pi + Arduino

Fisicamente accanto al tornello c’è un Raspberry Pi, collegato a:

• una tastiera USB, con cui il socio digita il proprio codice di accesso;
• un monitor (HDMI o VGA), che mostra un feedback immediato: ingresso concesso, abbonamento scaduto, pagamento da regolarizzare;
• un Arduino, collegato via seriale/USB, che riceve dal Raspberry Pi l’ordine di aprire e pilota fisicamente il relè del tornello.

Ho separato deliberatamente questi due ruoli invece di far fare tutto a un solo device.

Il Raspberry Pi fa da client applicativo: gestisce l’input da tastiera, parla in HTTP con l’API del gestionale in cloud attraverso il router WiFi della palestra, e mostra il risultato a monitor. È un piccolo computer general-purpose, e si comporta come tale.

L’Arduino fa da controllore hardware: riceve un comando semplice dal Raspberry Pi (aprire o non aprire) e si occupa della parte elettromeccanica, il relè che sblocca fisicamente il tornello. Non sa niente di abbonamenti, soci o codici. Sa solo chiudere un contatto quando gli viene detto di farlo.

Questa separazione non è decorativa. Il Raspberry Pi fa girare Linux, un sistema operativo completo, con tutta la superficie che questo comporta: rete, processi, un OS che può bloccarsi o va aggiornato. Non è il posto giusto per pilotare direttamente un relè che comanda un varco fisico. L’Arduino, con il suo firmware minimale e deterministico, è molto più adatto a quel compito specifico: riceve un segnale, aziona un pin, punto. Se il Raspberry Pi si impalla o va in riavvio per un aggiornamento, l’Arduino resta comunque un componente semplice e prevedibile, isolato dal resto della complessità software.

Il flusso di un ingresso, passo per passo

1. Il socio si presenta al tornello e digita il proprio codice sulla tastiera collegata al Raspberry Pi.
2. Il Raspberry Pi invia il codice, via WiFi interno alla palestra, a un endpoint dell’API del gestionale in cloud.
3. Il server in cloud verifica: il codice corrisponde a un socio esistente, l’abbonamento è attivo, il saldo è regolare.
4. Il server risponde: ingresso concesso o negato, insieme a un messaggio (es. “abbonamento scaduto”, “saldo da regolarizzare”).
5. Il Raspberry Pi mostra il messaggio sul monitor e, se l’esito è positivo, invia il comando di apertura all’Arduino via seriale.
6. L’Arduino aziona il relè, il tornello si sblocca per il tempo di un passaggio.

Ogni passaggio produce un log dell’accesso, che finisce nel gestionale insieme all’anagrafica del socio: chi è entrato, quando, con quale esito. Questo dato torna utile alla reception per rispondere a domande banali ma frequenti, tipo “sono venuto martedì scorso?”, senza dover andare a memoria.

La scelta di tenere il sistema sempre online, e cosa comporta

Una decisione precisa che ho preso: niente cache locale sul Raspberry Pi. Ogni verifica di accesso passa dal cloud, sempre. Non c’è una copia locale della lista soci validi che permetta al tornello di continuare a funzionare se la connessione internet della palestra cade.

È un trade-off, e vale la pena essere onesti su cosa significa. Il vantaggio è che non esiste mai un disallineamento tra quello che il tornello pensa e quello che il gestionale sa davvero: se un socio rinnova l’abbonamento alle 9:03, alle 9:04 può già entrare, senza bisogno di sincronizzare nessuna cache locale. Un pagamento appena regolarizzato in reception si riflette immediatamente sul tornello, perché reception e tornello leggono esattamente la stessa fonte di verità.

Lo svantaggio, altrettanto reale, è che il sistema dipende dalla connettività della palestra. Se il router o la linea internet vanno giù, il tornello smette di rispondere finché la connessione non torna. Per il contesto di questo cliente (una singola struttura, con una connessione internet standard e un profilo di rischio in cui qualche minuto di disservizio occasionale è accettabile) questo compromesso ha senso: la semplicità di un’unica fonte di verità supera il costo di un’interruzione rara. Per un cliente con vincoli diversi, più sedi su connessioni meno affidabili, o un requisito esplicito di continuità operativa, la risposta sarebbe stata diversa, con una cache locale e una logica di riconciliazione: più complessità, in cambio di resilienza. La scelta giusta dipende dal cliente, non da un principio universale.

Perché non un sistema chiuso “chiavi in mano”

Sul mercato esistono soluzioni di controllo accessi già pronte per palestre: badge RFID proprietari, terminali dedicati, software di gestione accessi in bundle con l’hardware. Per molte palestre sono la scelta giusta, perché costano meno in partenza e richiedono zero sviluppo.

Il motivo per cui in questo caso non erano la strada giusta è lo stesso motivo che ricorre in quasi tutti i progetti che costruisco: il cliente non voleva un sistema di accessi isolato che poi doveva integrare a mano con la gestione soci. Voleva un solo posto dove vivono anagrafica, abbonamenti, pagamenti, corsi e accessi, e un tornello che è semplicemente un’estrinsecazione fisica di quel dato, non un sistema parallelo da tenere sincronizzato.

Costruire da zero il gestionale e la postazione hardware ha richiesto più lavoro iniziale rispetto a comprare un pacchetto chiuso. Il ritorno è un sistema dove non esiste doppia registrazione, dove aggiungere un nuovo canale di verifica (un domani, per dire, un QR da app invece del tastierino) è un endpoint API in più, non un’integrazione forzata tra due prodotti di fornitori diversi che non erano pensati per parlarsi.

Cosa porta a casa un titolare di palestra da questo tipo di progetto

Se stai leggendo questa pagina perché gestisci una palestra, un centro fitness, o qualsiasi struttura con soci, abbonamenti e un varco fisico da controllare, i punti di questo case study che contano di più sono:

• Il tornello è la parte facile. La parte che vale la pena costruire bene è il gestionale che decide chi può entrare: anagrafica, abbonamenti, pagamenti, tutto in un solo posto.
• Separare il ruolo applicativo da quello hardware paga. Un device general-purpose (Raspberry Pi) per la logica e la connettività, un controllore dedicato (Arduino) per l’azione fisica sul relè: meno superficie di rischio sulla parte che comanda fisicamente un varco.
• La scelta “sempre online, niente cache” non è pigrizia, è una decisione esplicita in base al profilo di rischio del cliente, e va rivalutata se il contesto cambia (più sedi, connettività meno affidabile).
• Un sistema costruito su misura evita la doppia registrazione tra “software per gli accessi” e “software per la gestione soci”, che è il problema più comune quando si comprano due prodotti chiusi e si prova a farli parlare dopo.

Se hai una struttura con problemi simili, controllo accessi, gestione abbonamenti, o qualsiasi punto in cui hardware fisico deve prendere decisioni basate su dati che vivono altrove, è esattamente il tipo di lavoro che faccio. Una call di scoping di trenta minuti basta per capire se ha senso lavorare insieme.