Portare un microcontrollore sulla rete via cavo è una scelta molto concreta: meno interferenze, meno riconnessioni casuali, più prevedibilità quando la scheda deve restare accesa a lungo. Qui chiarisco quando conviene usare Ethernet con Arduino, quale hardware scegliere, come assegnare l’indirizzo IP e quali errori evitano ore di debug. Alla fine avrai un quadro pratico, adatto sia a un progetto domestico sia a un piccolo nodo di automazione.
Le decisioni che contano davvero prima di mettere Arduino in rete
- Per i progetti fissi, l’Ethernet è spesso più affidabile del Wi-Fi.
- La scelta più lineare oggi, per molti setup RJ45, è una shield con W5500.
- DHCP è il modo più veloce per partire; l’IP statico serve quando vuoi un indirizzo sempre uguale.
- Su molte schede classiche la rete passa dallo SPI, quindi il chip select e il cablaggio contano più di quanto sembri.
- Se qualcosa non funziona, i colpevoli più comuni sono MAC duplicato, libreria sbagliata e alimentazione debole.
Quando l’Ethernet su Arduino ha senso davvero
Io la considero la soluzione giusta quando il progetto deve essere stabile, ripetibile e facile da diagnosticare. Se devo far parlare un Arduino con un dashboard locale, un server interno, un sistema di logging o un impianto che deve restare acceso per mesi, il cavo vince quasi sempre sulla radio: niente problemi di copertura, meno dipendenza dal traffico wireless e un comportamento più lineare quando qualcosa si guasta.
Questo non significa che il Wi-Fi sia “peggiore” in assoluto. Vuol dire solo che, per alcuni scenari, l’Ethernet riduce le variabili inutili. È una differenza che si sente subito nei progetti fissi: una centralina in cantina, un pannello di controllo in laboratorio, un nodo di sensori vicino al router, una piccola interfaccia web per comandare relè o leggere valori in tempo reale. Se invece il dispositivo deve spostarsi o stare lontano da ogni cavo, allora il discorso cambia e il cablato perde gran parte del suo vantaggio.
Per questo, prima ancora di parlare di schede e librerie, io mi chiedo sempre: il progetto deve essere comodo o deve essere prevedibile? Se la risposta è la seconda, l’Ethernet merita attenzione. Da qui in poi conta scegliere bene l’hardware.
Cosa serve davvero per partire
La parte bella è che l’avvio è più semplice di quanto molti immaginino. Nella configurazione classica bastano una scheda compatibile, un controller Ethernet, un cavo RJ45 e un router o switch che assegni gli indirizzi. L’unico punto da non trattare con superficialità è la compatibilità tra chip e libreria: sembra un dettaglio, ma spesso è lì che si perde tempo.
| Componente | Perché serve | Osservazione pratica |
|---|---|---|
| Shield o modulo Ethernet | Gestisce la connessione di rete | La Shield Rev2 usa un W5500; se recuperi hardware più vecchio, potresti incontrare un W5100. |
| Cavo RJ45 | Porta il segnale fino a router o switch | Per i test basta un cavo corto e integro; per un’installazione fissa conviene un cablaggio ordinato. |
| Router o switch | Assegna indirizzi e collega i dispositivi | Se usi DHCP, verifica che la rete lo consenta davvero. |
| Libreria corretta | Fa parlare Arduino con il controller Ethernet | Per moduli basati su W5500, Arduino documenta Ethernet2; per altri chip conviene controllare la compatibilità. |
| Alimentazione stabile | Evita reset e cadute improvvise | Molti problemi che sembrano di rete nascono in realtà dall’alimentazione. |
Un dettaglio utile: la Ethernet Shield Rev2 integra anche uno slot microSD, comodo se vuoi registrare dati localmente senza aggiungere altra elettronica. Se invece il progetto deve stare lontano da una presa, esistono versioni con PoE, ma io le considero una scelta da fase successiva, non il punto di partenza.
Quando l’hardware è chiaro, la parte davvero importante diventa la configurazione dell’indirizzo e della rete locale.
Configurare la rete senza perdere tempo
Io parto quasi sempre da DHCP, perché è il modo più rapido per capire se tutto funziona. Con la chiamata base della libreria, Arduino chiede al router un indirizzo IP, e se la rete risponde correttamente la scheda entra subito in linea. È la strada giusta per il primo test e, spesso, anche per il funzionamento definitivo se non hai bisogno di un indirizzo fisso.
#include
#include
byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED };
IPAddress ip(192, 168, 1, 50);
IPAddress dns(192, 168, 1, 1);
IPAddress gateway(192, 168, 1, 1);
IPAddress subnet(255, 255, 255, 0);
void setup() {
Serial.begin(115200);
if (Ethernet.begin(mac) == 0) {
Ethernet.begin(mac, ip, dns, gateway, subnet);
}
delay(1000);
Serial.print("IP: ");
Serial.println(Ethernet.localIP());
}
void loop() {
} Il senso del frammento è semplice: prima provo DHCP, poi passo a un IP statico se il router non assegna nulla. Questa logica è molto utile nei test, ma anche nei piccoli impianti dove vuoi un comportamento di fallback sensato. La cosa davvero importante, però, è che il MAC sia unico: due dispositivi con lo stesso MAC sulla stessa rete generano conflitti strani, difficili da leggere se non li conosci già.
Con l’IP in mano, puoi decidere se la scheda debba fare la client, il server o entrambe le cose. Ed è qui che entra in gioco la scelta delle librerie e del ruolo di rete.
Librerie e ruoli di rete che contano davvero
Quando progetto un nodo Ethernet, non penso prima alla pagina web o al protocollo: penso al ruolo. Deve chiamare un servizio esterno o deve esporsi sulla LAN? Da questa risposta dipende il tipo di oggetto che userò, e spesso anche la semplicità del codice.
| Scenario | Classe o libreria | Quando la uso |
|---|---|---|
| Il dispositivo invia dati a un servizio | EthernetClient |
Client HTTP, API interne, broker MQTT o un endpoint locale. |
| La scheda espone una pagina di stato | EthernetServer |
Dashboard minimaliste, pannelli di diagnostica, controllo relè. |
| Serve traffico leggero e rapido | EthernetUDP |
Discovery, telemetria semplice e pacchetti brevi. |
| Hai uno shield W5500 moderno | Ethernet2 |
Scelta coerente con i moduli W5500 indicati da Arduino. |
| Riusi hardware più vecchio | Libreria Ethernet compatibile | Controlla sempre il chip sulla scheda, perché W5100 e W5500 non si trattano allo stesso modo. |
In pratica, io tendo a partire dal minimo indispensabile: un server HTTP essenziale se devo controllare qualcosa dal browser, un client se devo spedire dati a un backend, UDP solo quando il progetto richiede messaggi leggeri e nessuna connessione continua. È un approccio più pulito di quanto sembri, perché evita di portarsi dietro complessità inutili fin dal primo sketch.
Questa distinzione aiuta anche a capire perché alcuni progetti rendono meglio su cavo che su radio. E su quello conviene essere molto concreti.
I progetti che rendono meglio su cavo
Non tutti i casi d’uso traggono lo stesso vantaggio dall’Ethernet, ma alcuni ne beneficiano in modo evidente. Quando vedo questi scenari, il cavo è spesso la scelta che riduce più problemi di quanti ne introduca.
- Web server locale - Perfetto per una pagina di stato con sensori, relè, allarmi o comandi base. La latenza percepita è bassa e non devi dipendere da servizi esterni.
- Data logger con microSD - La scheda registra i dati in locale e, se vuoi, li rende disponibili in rete. Qui lo slot microSD della Shield Rev2 ha un senso molto pratico.
- Gateway per sensori - Se devi raccogliere dati e inviarli a un server interno, l’Ethernet è più lineare del wireless, soprattutto in ambienti pieni di disturbi.
- Automazione con Modbus TCP - In ambito industriale o semi-industriale la rete cablata è spesso la base più sensata per scambiare comandi e stati in modo prevedibile.
- Controllo remoto di piccoli impianti - Luci, pompe, ventole, serrande: tutto ciò che deve funzionare sempre beneficia di una connessione che non dipende dal segnale radio.
Un aspetto che spesso sottovalutano i principianti è questo: l’Ethernet non è solo una questione di velocità. È una questione di manutenibilità. Quando torni sul progetto dopo settimane, un cavo, una rete locale e un IP ben documentato sono molto più facili da riprendere in mano di una configurazione wireless improvvisata.
Naturalmente, quando qualcosa non parte, i sintomi si ripetono quasi sempre negli stessi modi. E riconoscerli in fretta fa risparmiare tempo vero.
Gli errori che vedo più spesso
La buona notizia è che i guasti più comuni sono anche i più leggibili, se sai dove guardare. Nella maggior parte dei casi non c’è un “mistero” nel codice: c’è un dettaglio di rete, di cablaggio o di alimentazione che va rimesso a posto.
| Sintomo | Probabile causa | Come lo risolvo |
|---|---|---|
| Nessun IP assegnato | DHCP non disponibile, cavo difettoso o shield non inizializzata bene | Provo un IP statico, cambio cavo e verifico che il router assegni indirizzi alla LAN. |
| Lo sketch compila ma la rete non risponde | Libreria non adatta al chip o configurazione SPI errata | Controllo se la scheda usa W5100 o W5500 e verifico che il codice includa le librerie corrette. |
| Conflitti strani o dispositivi che “spariscono” | MAC duplicato o IP statico già occupato | Assegno un MAC unico e pianifico gli IP nel progetto, invece di improvvisarli. |
| Reset casuali o comportamento instabile | Alimentazione debole o contatto meccanico imperfetto | Verifico la corrente disponibile, il fissaggio della shield e la qualità del cavo. |
| La pagina web è visibile solo da un dispositivo | Sottorete errata, isolamento client o regole del router | Controllo gateway, subnet e impostazioni della rete locale. |
Qui c’è una regola che applico sempre: prima controllo il fisico, poi la rete, poi il codice. È sorprendente quante volte la causa reale stia in un dettaglio banale, come un cavo poco affidabile o un indirizzo scelto male. Quando il debug segue questo ordine, il tempo perso cala parecchio.
Prima di lasciare il progetto acceso per davvero, io faccio sempre tre verifiche finali.
I tre controlli che faccio prima di lasciare il progetto acceso
- Documento tutto - MAC, IP, gateway, subnet e porta fisica del router finiscono nelle note del progetto, perché dopo qualche settimana nessuno li ricorda a memoria.
- Testo la rete reale - Non mi accontento del banco prova: provo il sistema con il cavo, lo switch e la rete che userò davvero.
- Controllo la stabilità - Lascio girare il codice e faccio più richieste consecutive, così intercetto subito i problemi che compaiono solo dopo un po’.
Se questi tre punti sono a posto, l’Ethernet su Arduino smette di essere un esperimento e diventa una base solida per automazione, monitoraggio e piccoli servizi di rete. Ed è esattamente il tipo di soluzione che, secondo me, vale la pena tenere in cassetta quando il progetto deve funzionare davvero.
