Controllo PTZ ONVIF di una Telecamera C21A in Home Assistant con Picture Glance

Se utilizzi una telecamera PTZ compatibile ONVIF e vuoi controllarla direttamente dalla dashboard di Home Assistant, puoi creare una card con i pulsanti direzionali integrati sull’immagine live della telecamera.

Nel mio caso ho utilizzato una C21A configurata tramite integrazione ONVIF. Dopo varie prove ho scelto la modalità RelativeMove, che garantisce uno spostamento preciso ad ogni pressione del pulsante.

Risultato finale

La card mostra:

  • Streaming live della telecamera
  • Pulsante Su
  • Pulsante Giù
  • Pulsante Sinistra
  • Pulsante Destra

Ogni clic genera uno spostamento relativo della telecamera.

Codice YAML completo

type: picture-glance
title: Telecamera C21A
camera_image: camera.c21a_mainstream

entities:
  - entity: camera.c21a_mainstream
    icon: mdi:arrow-up
    name: Su
    tap_action:
      action: perform-action
      perform_action: onvif.ptz
      target:
        device_id: ff8e451cca5103ba81271e631a2b89ba
      data:
        move_mode: RelativeMove
        tilt: UP
        distance: 0.3
        speed: 1

  - entity: camera.c21a_mainstream
    icon: mdi:arrow-down
    name: Giù
    tap_action:
      action: perform-action
      perform_action: onvif.ptz
      target:
        device_id: ff8e451cca5103ba81271e631a2b89ba
      data:
        move_mode: RelativeMove
        tilt: DOWN
        distance: 0.3
        speed: 1

  - entity: camera.c21a_mainstream
    icon: mdi:arrow-left
    name: Sinistra
    tap_action:
      action: perform-action
      perform_action: onvif.ptz
      target:
        device_id: ff8e451cca5103ba81271e631a2b89ba
      data:
        move_mode: RelativeMove
        pan: RIGHT
        distance: 0.3
        speed: 1

  - entity: camera.c21a_mainstream
    icon: mdi:arrow-right
    name: Destra
    tap_action:
      action: perform-action
      perform_action: onvif.ptz
      target:
        device_id: ff8e451cca5103ba81271e631a2b89ba
      data:
        move_mode: RelativeMove
        pan: LEFT
        distance: 0.3
        speed: 1

Regolazione della sensibilità

Il parametro più importante è:

YAML

distance:

Più il valore è alto, maggiore sarà lo spostamento della telecamera per ogni click.

Esempi pratici:

YAML

distance: 0.05

Movimento molto piccolo.

YAML

distance: 0.2

Movimento medio.

YAML

distance: 0.3

Buon compromesso per la maggior parte delle PTZ.

YAML

distance: 0.5

Movimento molto evidente.

Attenzione alle direzioni

Alcune telecamere interpretano i comandi ONVIF in modo invertito. Nel mio caso ho dovuto invertire i valori:

YAML

pan: RIGHT

per il pulsante Sinistra e

YAML

pan: LEFT

per il pulsante Destra.

Se la telecamera si muove nella direzione sbagliata, è sufficiente invertire questi due parametri.

Considerazioni finali

Dopo diversi test ho verificato che il problema non era Home Assistant ma la regolazione dello spostamento. Riducendo troppo il valore distance la telecamera sembrava “lentissima” perché ogni click produceva un movimento minimo.

Con:

YAML

distance: 0.3

speed: 1

il controllo risulta molto più fluido e pratico per l’uso quotidiano dalla dashboard di Home Assistant.

Configurazione testata con telecamera PTZ ONVIF integrata in Home Assistant usando una card Picture Glance per il controllo diretto dei movimenti Pan/Tilt.

Monitoraggio Corrente Batteria con ESP32, ADS1115 e Sensore Hall QNHCK2-16 da 100A

Se stai realizzando un sistema di monitoraggio energetico per Home Assistant o ESPHome, una soluzione economica e precisa consiste nell’utilizzare un ESP32 insieme a un convertitore ADC ADS1115 e un sensore di corrente Hall QNHCK2-16.

In questo articolo vedremo passo passo:

  • Come funziona il sensore Hall
  • Come collegare ESP32, ADS1115 e QNHCK2-16
  • Come leggere la corrente di carica e scarica della batteria
  • Il codice ESPHome completo e funzionante
  • Come calibrare il sensore

Materiale utilizzato

ESP32

Scheda WiFi utilizzata per ESPHome e Home Assistant.

ADS1115

Convertitore ADC a 16 bit.

Vantaggi:

  • Risoluzione molto superiore all’ADC interno dell’ESP32
  • Comunicazione I²C
  • Elevata precisione
  • 4 ingressi analogici disponibili

Sensore Hall QNHCK2-16

Modello acquistato:

QNHCK2-16
100A
2.5V ±0.625V
Alimentazione 5V
Corrente nominale: ±100A
Tensione a 0A: 2.5V
Tensione a +100A: 3.125V
Tensione a -100A: 1.875V
Sensibilità: 6.25mV/A

Come funziona il sensore Hall

Il sensore non richiede il contatto elettrico diretto con il cavo.

È sufficiente far passare il cavo all’interno della finestra del sensore.

Esempio:

Batteria (+)
      │
      │
      ▼
 ┌───────────┐
 │ QNHCK2-16 │
 └───────────┘
      │
      │
      ▼
 Inverter

Il sensore genera una tensione proporzionale alla corrente.

Per il modello da 100A:

CorrenteTensione
-100A1.875V
-50A2.1875V
0A2.500V
+50A2.8125V
+100A3.125V

Piedinatura del sensore

Dal corpo del sensore escono 4 fili.

ColoreFunzione
Rosso+5V
NeroGND
VerdeVOUT
BluVREF

Utilizzeremo solamente:

Rosso
Nero
Verde

Collegamenti ESP32 ↔ ADS1115

ADS1115ESP32
VDD3.3V
GNDGND
SDAGPIO21
SCLGPIO22

Collegamenti Sensore ↔ ADS1115

Sensore HallADS1115
VOUT (verde)A0
GND (nero)GND

Alimentazione Sensore

Sensore HallESP32
Rosso5V
NeroGND

Schema completo

                 ESP32
            ┌─────────────┐
            │             │
            │ GPIO21 SDA  ├──────────── SDA ADS1115
            │ GPIO22 SCL  ├──────────── SCL ADS1115
            │ 3.3V        ├──────────── VDD ADS1115
            │ GND         ├──────────── GND ADS1115
            │ GND         ├──────────── GND Sensore
            │ 5V          ├──────────── +5V Sensore
            │             │
            └─────────────┘

                          ADS1115
                    ┌─────────────┐
                    │             │
                    │ A0          ├────────── VOUT Sensore
                    │             │
                    └─────────────┘

                     QNHCK2-16
                   ┌────────────┐
                   │ Rosso +5V  │
                   │ Nero GND   │
                   │ Verde VOUT │
                   └────────────┘

Formula di conversione

Per il modello acquistato:

0A = 2.5V

Sensibilità:

0.625V / 100A

= 0.00625V/A

Formula:

Corrente = (Tensione - 2.5) / 0.00625

Codice ESPHome completo

# Board: ESP32 DevKit V1 (Espressif)
# Definition: definitions/boards/esp32-devkit-v1/manifest.yaml

esphome:
  name: esp32-shunt
  friendly_name: ESP32 shunt

esp32:
  variant: esp32
  flash_size: 4MB
  framework:
    type: esp-idf

logger:

api:
  encryption:
    key: "6nWLRhmkOvM2QjtcRAAtkBXzZ1XVOB+e+8XU8HcuLV8="

ota:
  - platform: esphome

wifi:
  ssid: xx
  password: xx
  ap:
    ssid: ESP32 shunt Fallback Hotspot
    password: "xxxx"

i2c:
  sda: GPIO21
  scl: GPIO22
  scan: true

ads1115:
  - address: 0x48

sensor:
  - platform: ads1115
    multiplexer: A0_GND
    gain: 4.096
    sample_rate: 860  # Portato a 860 sps per mediare via l'effetto ripple dell'inverter
    id: hall_voltage_raw
    name: "Hall Voltage"
    update_interval: 500ms
    unit_of_measurement: "V"
    accuracy_decimals: 3

  - platform: template
    name: "Corrente Batteria"
    id: corrente_batteria
    unit_of_measurement: "A"
    device_class: current
    state_class: measurement
    accuracy_decimals: 2
    update_interval: 500ms

    lambda: |-
      float volts = id(hall_voltage_raw).state;
      if (isnan(volts)) return {};
      return volts;
    filters:
      # 1. Zero centrato sul punto medio esatto del rumore (2.495V)
      - calibrate_linear:
          - 1.876 -> -100.0   # (1.881 - 0.005)
          - 2.495 -> 0.0      # Punto medio reale tra 2.494V e 2.496V
          - 3.126 -> 100.0    # (3.131 - 0.005)

      # 2. Elimina i picchi spuri
      - median:
          window_size: 5
          send_every: 1

      # 3. Media mobile per la massima stabilità
      - exponential_moving_average:
          alpha: 0.05
          send_every: 1

      # 4. Zona morta portata a 0.25A per assorbire l'oscillazione +/- 0.16A
      - lambda: |-
          if (std::abs(x) < 0.25) {
            return 0.0;
          }
          return x;

Calibrazione dello zero

Ogni sensore presenta una piccola tolleranza.

Con batteria senza carica e senza scarica controllare il valore:

Hall Voltage

Potresti leggere:

2.503V


oppure:

2.497V

In tal caso modificare:

const float VZERO = 2.500;

con:

const float VZERO = 2.503;

oppure:

const float VZERO = 2.497;

ottenendo una lettura molto più precisa.

Monitoraggio carica e scarica separatamente

Per un impianto fotovoltaico è consigliabile utilizzare due sensori.

Sensore 1

MPPT → Batteria

Misura la corrente di carica.

Sensore 2

Batteria → Inverter

Misura la corrente di scarica.

Collegamenti:

Sensore 1 → A0 ADS1115
Sensore 2 → A1 ADS1115

In questo modo Home Assistant mostrerà separatamente:

  • Corrente di carica
  • Corrente di scarica
  • Potenza di carica
  • Potenza di scarica

Una soluzione molto interessante per il tuo impianto Victron perché permette di avere un monitoraggio locale tramite ESPHome e confrontare i dati con quelli dello SmartShunt e degli SmartSolar.

Boot EFI errato su proxmox



In questo articolo descrivo un caso reale di malfunzionamento EFI su un nodo Proxmox, dove il sistema avviava dalla partizione sbagliata invece che dalla ESP corretta. Questo causava avvii incoerenti, kernel non aggiornati e potenziali rischi di boot failure.

## Sintomi del problema

Il comando `efibootmgr -v` mostrava:

- BootCurrent: 0003 → avvio da fallback `BOOTX64.EFI`
- BootOrder: `0003,0004,0002,0000`
- Due ESP presenti:
  - **CE60** (GUID `0c569779-e73f-4c73-b97f-e8594cb4868d`)
  - **11A4** (GUID `40e24607-4ca2-4f4a-926c-7792a0f3dc72`)

La ESP corretta (CE60) conteneva:
- `Boot0002` → systemd‑boot (entry primaria)
- `Boot0004` → fallback `BOOTX64.EFI`

La ESP secondaria (11A4) conteneva:
- `Boot0000` → systemd‑boot
- `Boot0003` → fallback `BOOTX64.EFI`

Il problema era chiaro: il BIOS avviava dalla entry `0003`, cioè dalla fallback della ESP sbagliata.

## Analisi tecnica

Proxmox utilizza **systemd‑boot** e sincronizza i kernel nella ESP montata in `/boot/efi`.  
La partizione corretta era **CE60**, ma il BootOrder dava priorità alla fallback `0003`, portando il sistema a caricare `BOOTX64.EFI` invece dei kernel aggiornati.

## Soluzione

La soluzione è stata correggere l’ordine di boot, impostando:

1. `Boot0002` → CE60 systemd‑boot (primaria)
2. `Boot0004` → CE60 fallback
3. `Boot0003` → 11A4 fallback
4. `Boot0000` → 11A4 systemd‑boot

Comando utilizzato:

```bash
efibootmgr -o 0002,0004,0003,0000

Verifica dopo il riavvio

Dopo il reboot:

  • BootCurrent: 0002 → avvio corretto dalla ESP CE60
  • BootOrder: 0002,0004,0003,0000 → ordine sicuro e coerente

Il nodo ora avvia correttamente dalla ESP principale, con fallback attivi e una catena di sicurezza completa.

Conclusione

Il problema era causato da un BootOrder errato che privilegiava una fallback EFI invece della ESP principale. Correggendo l’ordine con efibootmgr, Proxmox torna a utilizzare i kernel aggiornati e garantisce un avvio stabile e sicuro. Questa procedura è utile in tutti i casi in cui Proxmox presenta avvii incoerenti o fallback EFI attivi come primaria.

Erorre EFI no space left on node proxmox

# Procedura adattata al mio nodo Proxmox per pulizia ESP e fix kernel

## 1. Verificare l’UUID della ESP
cat /etc/kernel/proxmox-boot-uuids
# Output nel mio caso:
# 67D6-E50C

## 2. Verificare quale device corrisponde all’UUID
ls -al /dev/disk/by-uuid/67D6-E50C
# Output nel mio caso:
# /dev/disk/by-uuid/67D6-E50C -> ../../nvme0n1p2
# La mia ESP è quindi /dev/nvme0n1p2

## 3. Montare manualmente la ESP
mkdir /tmp/myesp
mount /dev/nvme0n1p2 /tmp/myesp

## 4. Elencare i kernel presenti nella ESP
ll /tmp/myesp/*/*
# Qui individuo le directory dei kernel vecchi da rimuovere:
# /tmp/myesp/.../5.15.108-1-pve
# /tmp/myesp/.../6.2.16-5-pve

## 5. Rimuovere SOLO i kernel vecchi
rm -rf /tmp/myesp/*/*/5.15.108-1-pve
rm -rf /tmp/myesp/*/*/6.2.16-5-pve

## 6. Smontare la ESP
umount /tmp/myesp

## 7. Riparare dpkg e completare l’installazione del kernel
apt-get -f install

Eliminazione manuale (riveduta)

###############################################
# SEQUENZA CORRETTA PULIZIA ESP + RIMOZIONE KERNEL 6.x
# Adattata ESATTAMENTE a ciò che ha scritto l’utente
###############################################

echo "=== 1) Identifica ESP ==="
cat /etc/kernel/proxmox-boot-uuids
ls -al /dev/disk/by-uuid/B130-7F39   # -> ../../sda2

echo "=== 2) Monta ESP ==="
mkdir -p /tmp/myesp
mount /dev/sda2 /tmp/myesp

echo "=== 3) Elenca kernel presenti nell'ESP ==="
ls -l /tmp/myesp

echo "=== 4) Cancella TUTTI i kernel vecchi (serie 6.x) ==="
rm -f /tmp/myesp/initrd.img-6*
rm -f /tmp/myesp/vmlinuz-6*

echo "=== 5) Verifica che NON ci siano più file 6.x ==="
ls -l /tmp/myesp

echo "=== 6) Controlla spazio ESP ==="
df -h /tmp/myesp
du -ah /tmp/myesp

echo "=== 7) Smonta ESP ==="
umount /tmp/myesp

echo "=== 8) Ripara dpkg se necessario ==="
apt-get -f install

echo "=== 9) Rimuovi i kernel 6.x ==="
apt purge proxmox-kernel-6.*

echo "=== 10) Verifica kernel installati ==="
dpkg -l | grep proxmox-kernel

echo "=== 11) Verifica boot configuration ==="
proxmox-boot-tool status

echo "=== COMPLETATO ==="

🔥 Comandi di Amministrazione Linux ↔ macOS — La Tabella Definitiva per Dominare Ogni Sistema

FunzioneLinuxmacOSNote
Gestione Servizi
Avviare un serviziosystemctl start nomelaunchctl start nomemacOS usa launchd
Fermare un serviziosystemctl stop nomelaunchctl stop nomeOllama: launchctl stop io.ollama
Riavviare un serviziosystemctl restart nomeStop + StartmacOS non ha restart diretto
Stato serviziosystemctl status nomelaunchctl print system/nomeEsempio: launchctl print system/io.ollama
Abilitare all’avviosystemctl enable nomeAutomatico se .plist presentemacOS non ha “enable”
Disabilitare all’avviosystemctl disable nomelaunchctl unload /Library/LaunchDaemons/nome.plistOppure rimuovere il .plist
Processi e Sistema
Lista processips auxps auxUguale
Kill processokill -9 PIDkill -9 PIDUguale
Monitor risorsehtoptophtop installabile via brew
File System
Spazio dischidf -hdf -hUguale
Spazio directorydu -sh *du -sh *Uguale
Permessichmod 755 filechmod 755 fileUguale
Proprietariochown user:group filechown user:group fileUguale
Rete
IP configurazioneip aifconfigmacOS non ha “ip”
Routingip routenetstat -rnUguale
Pingping -c 4 hostping -c 4 hostUguale
Traceroutetraceroute hosttraceroute hostUguale
DNS lookupdig dominiodig dominioUguale
Flush DNSN/Asudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
macOS ha DNS aggressivo
ARP tablearp -narp -nUguale
Netcatnc -lvp 4444nc -lvp 4444Perfetto per test porte
Test porta TCPnc -zv host 22nc -zv host 22Uguale
TCPDumptcpdump -i eth0tcpdump -i en0Interfacce diverse
Firewall
Regole firewalliptables -LN/AmacOS usa Application Firewall
NATiptables -t nat -LN/AmacOS non espone NAT via CLI

Replica ZFS in Proxmox: perché lo spazio su disco sembra “esplodere”?

Molti utenti che iniziano a sperimentare la replica ZFS in ambienti Proxmox si trovano davanti a una situazione curiosa: una VM da 700 GB sembra occupare oltre 1,2 TB di spazio su ogni nodo. Ma come è possibile? In questo articolo analizziamo le cause reali, sfatiamo alcuni miti e offriamo strumenti pratici per monitorare e ottimizzare lo spazio.

🧠 Cos’è la replica ZFS in Proxmox?

La replica ZFS in Proxmox è un meccanismo che consente di copiare i dischi virtuali (vDisks) di una VM da un nodo a un altro, sfruttando le potenzialità di ZFS:

  • Replica incrementale basata su snapshot temporanei
  • Trasferimento solo dei blocchi modificati
  • Nessuna copia automatica del file .conf della VM (serve manualmente o via HA)

📦 Perché lo spazio occupato è maggiore della dimensione della VM?

1. Overhead ZFS

ZFS non memorizza solo i dati, ma anche:

  • Metadati per ogni blocco
  • Checksum per l’integrità
  • Struttura interna dei dataset
  • Intent log (ZIL) e cache (ARC/L2ARC)

Ogni disco virtuale è un dataset ZFS, quindi l’overhead si moltiplica.

2. Scritture reali vs spazio nominale

Una VM da 700 GB può scrivere molti più dati nel tempo (log, swap, file temporanei). ZFS conserva i blocchi modificati, anche se il file originale è stato cancellato.

3. Snapshot manuali

Se l’utente crea snapshot manuali e non li elimina, ZFS conserva i blocchi differenziali, aumentando lo spazio usato.

4. Snapshot di replica

Proxmox crea snapshot temporanei per la replica, con nomi tipo:

__replicate_<VMID>-<replicaID>_<timestamp>__

Questi snapshot non vengono conservati a lungo, ma se la replica è frequente o fallisce, possono accumularsi temporaneamente.

5. Compressione inefficace

Se ZFS ha compression=off o i dati sono poco compressibili (es. video, immagini), lo spazio occupato sarà vicino al reale.

🔍 Come analizzare lo spazio occupato

Ecco alcuni comandi utili da eseguire via terminale:

zfs get compression,compressratio rpool/data/subvol-100-disk-0

Verifica se la compressione è attiva e quanto è efficace.

zfs list -o name,used,refer,mountpoint

Confronta lo spazio totale usato con quello referenziato.

zfs get usedbysnapshots rpool/data/subvol-100-disk-0

Controlla quanto spazio è occupato dagli snapshot.

zfs list -t snapshot

Visualizza tutti gli snapshot attivi.

🧊 QCOW2 vs RAW: impatto sullo spazio

FormatoTipoSpazio inizialeSnapshotPerformance
QCOW2ThinSolo spazio usato✅Buona
RAWThickSpazio pieno❌Ottima

Su ZFS, anche i dischi RAW possono essere “thin” grazie alla compressione e ai blocchi sparsi, ma QCOW2 è nativamente più flessibile.

✅ Conclusione

Se vedi uno spazio ZFS occupato superiore alla dimensione della VM, non è un bug: è il risultato di come ZFS gestisce i dati, la replica e la protezione. Per tenere sotto controllo lo spazio:

  • Monitora gli snapshot manuali
  • Verifica la compressione
  • Analizza i blocchi modificati
  • Evita di duplicare VM con ID diversi che puntano agli stessi dischi

Rocky limux Join AD 2008

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

Bene , premessa a quanto scritto do per scontato che la date e l’ora di sistema sia corretti e che il resolv.conf punti correttmente al server AD con relativo search .

search internal2.lan
nameserver 192.168.3.123 

Eseguire la procedura classica di join tramite il comando:

realm join -u administartor ad.internal2.lan

Ecco a seguire il file sssd.conf modificato e funzionante .

[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” .

📘 DIARIO TECNICO COMPLETO — TOP‑BALANCE LiFePO₄ (BasenGreen 16s/200Ah)

—

📅 12 giugno — INIZIO LAVORI

  • V_MAX: 3,589 V
  • V_MIN: 3,380 V
  • ΔV: 0,207–0,215 V
  • Celle 1–2 alte, 8–13 basse
  • Pacco sano ma fortemente sbilanciato

—

📅 13 giugno — PRIMO RECUPERO

  • ΔV: ~0,132 V
  • Bleed efficace
  • Delta dimezzato
  • Celle alte meno polarizzate

—

📅 21 giugno — STABILIZZAZIONE

  • ΔV: ~0,130 V
  • Cella 8 e 13 recuperano
  • Pacco più uniforme

—

📅 23 giugno — MIGLIORAMENTO COSTANTE

  • ΔV: 0,123–0,130 V
  • Bleed su 6–7 celle
  • Punta stabile

—

📅 25 giugno — SOTTO 0,10 V

  • ΔV: 0,092–0,101 V
  • Pacco quasi uniforme
  • SOC 100%

—

📅 27 giugno — PRIMO CICLO COMPLETO

  • ΔV: ~0,094 V
  • 56,60 V per 1h → 55,20 V float
  • Cella 8 ancora bassa ma stabile

—

📅 29 giugno — COMPATTAZIONE

  • ΔV: 0,089 V
  • Pacco più compatto
  • Cella 8 vicina al gruppo

—

📅 30 giugno — SVOLTA

  • ΔV: 0,078–0,080 V
  • Nessuna cella sotto 3,40 V
  • Cella 8 finalmente in banda
  • Pacco molto stabile

—

📅 1 luglio — PUNTA

  • ΔV: ~0,119 V
  • Celle alte meno polarizzate
  • Cella 8 stabile

—

📅 1 luglio — FLOAT

  • ΔV: ~0,070 V
  • Pacco compatto
  • Comportamento ripetibile

—

📅 2 luglio — PUNTA

  • ΔV: 0,105 V
  • Punta stabile
  • Cella 8 in recupero continuo

—

📅 2 luglio — FLOAT (MIGLIOR GIORNO)

  • ΔV: 0,061–0,064 V
  • Profilo piatto
  • Cella 8 perfettamente integrata
  • Pacco ufficialmente bilanciato

—

📅 8 luglio — STATO ATTUALE (TOP ASSOLUTO)

🔋 Dati reali di oggi

  • V_SUM: 55,19–55,21 V
  • V_MAX: 3,453–3,455 V
  • V_MIN: 3,430–3,431 V
  • ΔV: 0,022–0,024 V → MIGLIOR DELTA DI SEMPRE
  • Cella 8: 3,430–3,431 V → stabile, prevedibile, perfettamente integrata
  • MOSFET: apertura regolare
  • Full_Cha_Prot: gestito perfettamente
  • Temperatura: 34–36 °C → ideale
  • SOH: 100%
  • Comportamento: ripetibile, stabile, senza deriva

🎯 Significato tecnico

  • Il pacco ha raggiunto la stabilità definitiva.
  • La curva di scarica è perfetta: la 8 scende più veloce (normale), ma resta sempre in banda.
  • La curva di punta è pulita: nessuna cella scappa, bleed efficace.
  • Il delta è da laboratorio (20–24 mV).
  • Il pacco è ora super potente, super stabile, super prevedibile.

—

📊 SINTESI TECNICA (12 giugno → 8 luglio)

  • Delta iniziale: ~0,21 V
  • Delta attuale: 0,022–0,024 V
  • Miglioramento totale: ~0,185 V
  • Cella 8: 3,380 V → 3,430–3,431 V
  • Profilo celle: piatto, nessuna deriva
  • Stabilità: massima
  • Comportamento: ripetibile
  • Pacco: ufficialmente bilanciato e maturo

—

🧠 Conclusione finale (8 luglio)

👉 Il pacco è entrato nella sua forma definitiva.

👉 Bilanciamento completato.

👉 Delta da 20–24 mV: livello premium.

👉 Cella 8 perfettamente integrata.

🗺️ Guida Completa: Padronanza con Gobuster

🎯 Obiettivo di Gobuster
Scoprire la struttura nascosta di un sito web. In pratica, se il proprietario ha messo file importanti come /backup, /config o /admin ma non li ha linkati nel menu principale, Gobuster li trova per te.

⚙️ Prerequisiti

  1. Gobuster installato: (Su Linux/macOS: sudo apt install gobuster oppure scaricandolo da GitHub).
  2. Un Target Web: Un indirizzo IP o un dominio che vuoi testare (es. http://192.168.8.17).
  3. Un File di Wordlist: Una lista di nomi comuni per directory e file. Il più famoso è dirb/common.txt o le liste contenute in pacchetti come SecLists.

🚀 Livello 1: La Scansione Base (Directory Enumeration)
Questo è il comando che userai il 90% delle volte per iniziare. Stai dicendo a Gobuster: “Prova tutti questi nomi di cartelle su questo indirizzo.”

gobuster dir -u http://[TARGET_URL] -w /path/to/wordlist.txt

Spiegazione dei parametri:

  • -d (o –directory-list): Indica che vuoi cercare directory e file.
  • -u: Specifica l’URL del target web (es. http://192.168.8.17).
  • -w: Wordlist. Questo è il cuore dello strumento. Devi puntare al percorso della lista di parole che contiene migliaia di nomi comuni (admin, backup, api, ecc.).

Esempio Pratico:

gobuster dir -u http://192.168.8.17 -w /usr/share/wordlists/dirb/common.txt

🔬 Livello 2: Scansione di File Specifiche (File Enumeration)
A volte non cerchi una cartella, ma un file specifico che potrebbe essere nascosto. Puoi usare la stessa logica cambiando il tipo di ricerca o usando liste più mirate.

Esempio: Se sospetti che ci sia un backup in formato ZIP:

gobuster dir -u http://192.168.8.17 -w /usr/share/wordlists/dirbuster/directories.jbrofuzz

⚙️ Livello 3: Scansione di Protocolli Diversificati (Versatilità)
Gobuster non è solo per HTTP! Puoi usarlo anche su altri protocolli, come FTP o SMB, se hai le liste appropriate.

Esempio (FTP):

gobuster dir -u ftp://[TARGET_URL] -w /path/to/ftp_wordlist.txt

💡 Consigli dell’Esperto per la Padronanza:

  1. Non usare solo una wordlist: Se il primo tentativo con common.txt non dà risultati, prova liste più specifiche (es. quelle contenenti nomi di versioni software o termini legati al tuo settore).
  2. Analizza i Risultati: Gobuster ti restituirà un codice di stato HTTP per ogni tentativo:
    • 200 OK: TROVATO! Questa è una directory/file accessibile e pubblica. È il risultato più importante.
    • 403 Forbidden: Il server sa che la risorsa esiste, ma ti impedisce di vederla (potrebbe essere protetta da un firewall o autenticazione). È un indizio prezioso!
    • 404 Not Found: La directory/file non esiste.

In sintesi: Gobuster è il tuo “occhio” che spia ogni angolo del sito web, mentre Nmap è la tua “radar” che vede se le porte sono aperte. Usali in sequenza!

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