Il problema
Ho una pergola Pergolux bioclimatica con lamelle motorizzate. È una di quelle pergole con le lamelle orientabili che si aprono e chiudono per gestire sole e pioggia. Il motore è controllato da un telecomando a 433MHz — modello PX140-D&C, prodotto da A-OK Technology. Nessuna app. Nessuna API. Nessuna integrazione domotica. Solo un telecomando con quattro pulsanti.
Il problema è il vento. Quando arriva una raffica forte con le lamelle aperte, queste sbattono e si stressano meccanicamente. L’ideale sarebbe un sistema che monitora il meteo e chiude automaticamente le lamelle quando il vento supera una certa soglia. Ma Pergolux non offre nulla del genere — il sistema è pensato per essere manuale.
Quindi ho deciso di costruirmelo.
Gli acquisti
La lista della spesa è stata sorprendentemente corta:
- ESP32 DevKit v1 — microcontrollore con WiFi integrato, il cervello del sistema
- CC1101 E07-M1101D-SMA V2.0 — modulo radio 433MHz con antenna SMA, per parlare la stessa lingua del telecomando
- Breadboard e cavi jumper — per il prototipo
Costo totale: circa 15-20 euro. Il bello dell’hardware open source.
L’hardware
Il collegamento è SPI standard tra ESP32 e CC1101: sette fili tra i due moduli. VCC, GND, e poi MOSI, MISO, SCK, CSN e GDO0 — il pin che l’ESP32 usa per controllare direttamente la trasmissione radio.
“ho attacato l’usb”
Il momento in cui colleghi il cavo USB e il LED dell’ESP32 si accende è sempre quello in cui il progetto diventa reale. Prima è teoria. Dopo è un dispositivo.
Reverse engineering del protocollo RF
Questa è stata la parte più interessante. Il telecomando Pergolux usa il protocollo proprietario A-OK: frame da 65 bit con modulazione OOK/ASK, un preambolo AGC, e nessun rolling code. Ogni trasmissione è composta da 8 ripetizioni dello stesso frame, per una durata totale di circa 520 millisecondi.
La codifica è tri-state: ogni bit è rappresentato da due impulsi di durata diversa — 270 microsecondi e 565 microsecondi, alternati a seconda che il bit sia 0 o 1. Il frame contiene un ID fisso del telecomando (24 bit), un indirizzo canale (16 bit), il comando (8 bit) e un checksum.
Il processo è stato iterativo. Prima cattura dei segnali con il CC1101 in modalità ricezione, poi analisi dei pattern con script Python, poi identificazione del protocollo tramite i report FCC del dispositivo e un repository GitHub che documentava lo standard A-OK.
“no il telecomando funzionava benissimo lo stop, scusa ma se ho cliccato apri tre volte e poi stop e ha funzionato il segnale è giusto ma sicuro non sia lo stato?”
Questo prompt a Claude è stato un punto di svolta. Il telecomando originale funzionava perfettamente — il segnale RF era corretto. Il problema era nel software, non nel protocollo. A volte la risposta è più semplice di quello che pensi.
Il software
Una volta che il protocollo RF funzionava, ho costruito il sistema completo sul firmware dell’ESP32:
Un web server per il controllo manuale — cinque pulsanti per aprire, chiudere, stoppare le lamelle e controllare le luci LED. Collegamento alle API meteo di Open-Meteo per monitorare vento, raffiche e pioggia a Monterotondo ogni cinque minuti. Un sistema di protezione automatica con isteresi: chiusura delle lamelle quando le raffiche superano i 40 km/h o la pioggia supera 0.5mm, riapertura quando il vento scende sotto i 25 km/h. DuckDNS per l’accesso remoto, notifiche Telegram per sapere cosa sta facendo il sistema, e aggiornamenti OTA per non dover smontare l’ESP32 ogni volta che modifico il firmware.
“il web server lo vedo, ma se clicco meno luce, non fa nulla e neanche se apro e chiudo la pergola”
“quello che noto io è che il web server sembra sempre reattivo, ma i comandi no”
Due osservazioni che mi hanno portato a capire il problema principale: il web server rispondeva, ma i comandi RF non venivano eseguiti. Il motivo? Le chiamate di rete (fetch meteo, invio Telegram, aggiornamento DuckDNS) bloccavano il loop principale, e i segnali RF — che richiedono timing preciso nell’ordine dei microsecondi — non potevano essere trasmessi mentre il processore era impegnato con il WiFi.
“ma secondo me non ha senso tenere nessuno stato e mandare solo i segnali al click”
Un’intuizione architetturale che ha semplificato tutto. Invece di tracciare lo stato delle lamelle nel software, semplicemente inviare il comando RF e lasciare che l’hardware facesse il suo lavoro. Meno stato, meno bug.
Il debugging
Il debugging è stato la parte più formativa — e più frustrante.
“controlla questo progetto, poi abbiamo due bug, quando la pergola si apre o si chiude lo stop non sembra funzionare sempre”
Così è iniziata la sessione di debugging con Claude. Due bug: lo stop non funzionava sempre, e le luci avevano un sistema di intensità a livelli invece di un semplice acceso/spento.
“ho provato dal cell e ora va, secondo me è lo stesso bug dello stop”
“cmq certe volte stop funziona”
Bug intermittenti — il tipo peggiore. Funziona tre volte, poi la quarta no. Senza un pattern chiaro, è facile perdersi nelle ipotesi.
“io direi di trovare un modo per testare le tue ipotesi, altrimenti stiamo qui ad ipotizzare”
“ma dei log non ti aiuterebbero?”
Alla fine il problema era il blocking I/O: le chiamate HTTP bloccanti nel main loop impedivano la trasmissione RF al momento giusto. La soluzione è stata spostare i comandi RF in una coda e eseguirli nel contesto del loop principale, fuori dalle interrupt WiFi. 70 test unitari scritti per coprire tutti i casi — manuale, automatico, isteresi, cooldown, scenari reali.
Collaborare con un’AI
“voglio scrivere un articolo linkedin su come ho hackerato la pergola, rivedi codice, steps, commits e docs per generarlo”
Questo progetto è stato costruito in collaborazione con Claude Code dall’inizio alla fine. Non nel senso che l’AI ha scritto il codice e io ho copiato. Nel senso che io avevo il problema, la pergola fisica, la comprensione del dominio — e Claude aveva i pattern tecnici, le librerie, la conoscenza dei protocolli RF e dell’architettura embedded.
Il risultato è stato poter affrontare un dominio completamente nuovo per me — sistemi embedded, protocolli radio, firmware per microcontrollori — in un weekend. Vent’anni di esperienza nel software, ma mai toccato un ESP32 prima di questo progetto. L’AI ha colmato il gap tra “so programmare” e “so programmare questo”.
Non è che l’AI abbia fatto il lavoro difficile. Il lavoro difficile è stato capire perché lo stop non funzionava, isolare il problema del blocking I/O, decidere l’architettura del sistema di protezione. L’AI ha accelerato tutto il resto — il boilerplate, la sintassi di PlatformIO, le API di Open-Meteo, la configurazione del CC1101.
Riflessione
L’AI ci sta dando opportunità che prima non avremmo avuto. Non parlo solo di velocità — parlo di accessibilità. Domini che avrebbero richiesto settimane di studio ora sono raggiungibili in giorni. È un nuovo modo di impostare i problemi, di ragionare sulla fattibilità, di esplorare territori sconosciuti con una rete di sicurezza.
Ma ogni volta che chiudo una sessione con Claude, mi resta una sensazione ambivalente. Sì, ho costruito qualcosa che funziona. Sì, ho imparato. Ma ho imparato quanto avrei imparato senza l’AI? Ho davvero capito i timing del protocollo OOK, o ho solo verificato che il codice generato funzionasse?
Il progetto è stato soddisfacente proprio perché ha richiesto comprensione reale — non solo prompt. Ma il confine si assottiglia. E mi chiedo: in un mondo dove l’AI può colmare qualsiasi gap di conoscenza in tempo reale, quanto è importante mantenere la capacità di concentrarsi e ragionare in modo profondo?