Tutto è partito da una raffica di vento.
Ho una pergola Pergolux bioclimatica — una di quelle con le lamelle orientabili che si aprono e chiudono per gestire sole e pioggia. Il motore è controllato da un telecomando a 433MHz. Nessuna app. Nessuna API. Nessuna integrazione domotica. Solo quattro pulsanti su un telecomando di plastica.
Il problema è che 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 le lamelle automaticamente. Ma Pergolux non offre nulla del genere — il sistema è pensato per essere manuale. Così ho deciso di costruirmelo da solo.
“ho una pergola con le lamelle motorizzate, il telecomando è a 433mhz. voglio costruire un sistema che chiude le lamelle automaticamente quando c’è vento. cosa mi serve?”
Capire con cosa ho a che fare
La prima sfida è stata capire che protocollo usasse il telecomando. Non c’era documentazione, non c’era un modello scritto sulla pergola. Ho girato il telecomando, fotografato l’etichetta sul retro, e da lì è partita l’indagine.
Sull’etichetta c’era scritto PX140-D&C e una frequenza: 433.92MHz. Ho cercato ovunque — Google, database FCC, forum di domotica. Niente. Il PX140-D&C è un prodotto OEM cinese white-label, praticamente invisibile su internet. Nessun datasheet, nessuna documentazione pubblica. Ci sono voluti diversi tentativi incrociando il modello con la marca stampata in piccolo — A-OK Technology — e cercando nei cataloghi B2B cinesi per cominciare a capire con cosa avevo a che fare.
“ti mando la foto del retro del telecomando, dimmi tutto quello che riesci a trovare su questo modello e su come comunica con il motore”
Una volta confermato che era un protocollo a 433MHz, la scelta dell’hardware è stata quasi obbligata: un ESP32 DevKit v1 perché serviva un microcontrollore con WiFi integrato — il sistema doveva collegarsi a internet per le API meteo — e un modulo radio CC1101 con antenna SMA, uno dei pochi chip capaci sia di ricevere che trasmettere a 433.92MHz con controllo preciso della modulazione. Circa 15-20 euro in tutto.
Il primo tentativo è stato sniffare il segnale del telecomando con il CC1101 in modalità ricezione. Ma non ricevevamo niente di sensato. Ore a provare configurazioni diverse, a cambiare parametri, a dubitare del cablaggio. Alla fine il problema era molto più banale: il telecomando aveva la batteria scarica. Una CR2450 da due euro ci ha fatto perdere mezza giornata.
“non riceviamo nulla, il CC1101 è configurato giusto? ho provato a premere tutti i pulsanti del telecomando e non arriva niente. controlla se il problema è nel codice o nella configurazione del modulo”
Con il telecomando funzionante, il segnale è arrivato subito. E cercando il modello nei report FCC e su GitHub, abbiamo trovato un progetto open source che documentava il protocollo A-OK. Da lì tutto ha iniziato ad avere senso.
Decifrare il protocollo
Il protocollo A-OK usa frame da 65 bit con modulazione OOK/ASK, un preambolo AGC, e nessun rolling code. Ogni volta che premi un pulsante, il telecomando trasmette 8 ripetizioni dello stesso frame per circa 520 millisecondi.
“ok il segnale arriva ma non capisco la struttura. cerca nei report FCC del PX140-D&C e trova se qualcuno ha già documentato il protocollo A-OK. se esiste un repo con la decodifica usiamo quello come base”
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, un indirizzo canale, il comando e un checksum. Ma arrivare a capire tutto questo è stato un processo iterativo fatto di tentativi e false piste.
Prima la cattura dei segnali, poi l’analisi dei pattern con script Python — dal confronto OOK contro FSK (la svolta: RSSI -29dBm contro -77dBm, OOK confermato), alla cattura dei timing via interrupt.
“gli 8 impulsi che catturiamo sono sempre uguali indipendentemente dal pulsante che premo. secondo me non stiamo leggendo i dati veri, solo il preambolo. prova a cambiare il data rate del CC1101 e catturare il raw”
Un dettaglio che mi ha fatto perdere un bel po’ di tempo: gli “8 impulsi” che catturavo inizialmente erano solo il preambolo AGC, non i dati veri. Il CC1101 in modalità demodulazione a 4.8kbps filtrava i bit dati. Ci sono volute diverse iterazioni di script Python — dalla versione 10 alla 16 — per capirlo.
Quattro ore
Una volta che il protocollo RF funzionava, con Claude abbiamo disegnato lo schema dei collegamenti — SPI standard tra ESP32 e CC1101, sette fili in tutto — e da lì è partita una sessione di quattro ore in cui è nato tutto il resto.
“ora che il protocollo funziona voglio il sistema completo: web server per controllo manuale, API meteo per vento e pioggia, e protezione automatica. usa isteresi per le soglie così non impazzisce col vento variabile”
Web server per il controllo manuale. Collegamento alle API meteo di Open-Meteo per monitorare vento, raffiche e pioggia ogni cinque minuti. Sistema di protezione automatica con isteresi — soglie diverse per la chiusura (40 km/h) e la riapertura (25 km/h), per evitare che le lamelle si aprano e chiudano in continuazione con vento variabile.
DuckDNS per l’accesso remoto, notifiche Telegram, aggiornamenti OTA per non dover smontare l’ESP32 ogni volta che modifico il firmware. 35 test unitari — non per disciplina, ma per necessità: il sistema di protezione ha troppi edge case per essere testato solo sulla pergola vera.
“aggiungi DuckDNS per l’IP dinamico, notifiche Telegram quando il sistema chiude o apre, e OTA updates. e scrivi i test: l’isteresi ha troppi edge case, non posso testare tutto sulla pergola vera”
Quattro ore. Dall’hardware collegato sulla breadboard a un sistema completo con web UI, protezione automatica, accesso remoto e notifiche.
Quando niente funziona
Ma non tutto è filato liscio. Il debugging è stato la parte più formativa e più frustrante.
“il web server risponde sempre ma i comandi alla pergola funzionano una volta su tre. lo stop è il peggiore. secondo me c’è un problema di timing, le interrupt WiFi stanno corrompendo il segnale RF”
Il problema centrale era subdolo: i segnali OOK richiedono timing preciso nell’ordine dei microsecondi — 270us e 565us per ogni bit. Ma quando il web server gestisce una richiesta HTTP, le interrupt WiFi/TCP interrompono la trasmissione RF e corrompono il segnale. I comandi arrivavano, ma a volte sì e a volte no. Lo stop funzionava una volta su tre. Il sistema sembrava reattivo — il web server rispondeva sempre — ma i comandi alla pergola si perdevano nel rumore.
La soluzione è stata spostare tutti i comandi RF in una coda e eseguirli nel loop principale, dove non ci sono interrupt di rete. Un pattern semplice, ma arrivarci ha richiesto di capire davvero come funziona il multitasking su un microcontrollore single-core.
“sposta tutta la trasmissione RF nel loop principale con una coda. i comandi HTTP non devono toccare il radio direttamente. e anche Telegram — quella POST HTTPS blocca tutto per secondi”
Anche Telegram bloccava: una POST HTTPS verso i server Telegram richiedeva 2-5 secondi, durante i quali il web server non rispondeva. Stesso pattern, stessa soluzione: buffer asincrono.
L’AI nella stanza
Ogni commit di questo progetto porta la firma Co-Authored-By: Claude Opus 4.6. Non perché l’AI ha scritto il codice e io ho copiato, ma perché 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. 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”.
Il lavoro difficile è rimasto mio: 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, lo schema dei collegamenti.
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 sono ora raggiungibili in ore. È 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?