Gabriele Baldassarre

Il cielo in salotto, parte 2: Sol

Sun, 17 May 2026 00:00:00 +0200

Nella prima parte abbiamo costruito il modulo Terra-Luna. Ora ci spostiamo verso il centro del sistema solare: il Sole.

Il Sole non è un oggetto statico. È una stella attiva, percorsa da correnti di plasma, squarciata periodicamente da eruzioni gigantesche, capace di lanciare nello spazio ondate di particelle che raggiungono la Terra in pochi giorni e interferiscono con le nostre reti elettriche, le comunicazioni radio e, nei casi più spettacolari, producono aurore boreali visibili anche alle latitudini italiane. Monitorare l’attività solare non è puro esercizio accademico: è space weather, e può avere conseguenze molto concrete per un astrofilo e un astrofotografo.

Questa sezione della dashboard raccoglie tutto questo in un unico colpo d’occhio.

Intanto, vi ricordo, questo è quello che ci prefiggiamo di ottenere e oggi ci concentreremo sulla colonna centrale

NASA Eyes on the Solar System

Prima di entrare nei dati quantitativi, ho voluto includere un elemento puramente visivo e divulgativo: NASA Eyes on the Solar System, un simulatore 3D interattivo sviluppato dalla NASA che mostra la posizione in tempo reale di pianeti, lune, sonde e asteroidi nel sistema solare.

È uno strumento straordinario per visualizzare le distanze cosmiche in modo intuitivo: puoi seguire la traiettoria del Voyager 1, ora a più di 23 miliardi di chilometri dalla Terra, oppure vedere dove si trova in questo momento il James Webb Space Telescope. Tutto in scala e in tempo reale.

Si incorpora nella dashboard tramite una card iframe che punta all’applicazione web della NASA. Non è esattamente l’integrazione più elegante che si sia mai vista in Lovelace, ma funziona:

type: iframe
url: "https://eyes.nasa.gov/apps/solar-system/#/home?featured=JUNO"
aspect_ratio: 75%

Nota: l’applicazione richiede WebGL e su dispositivi mobili può risultare pesante o non interattiva. È pensata principalmente per una visualizzazione su schermo desktop o su un tablet di buona potenza.

Immagini live del Sole

Qui non usiamo API Rest o servizi complessi, ma ci limitiamo a visualizzare gli stream media messi a disposizione della NASA o dal NOAA, manipolati con CSS per conformarmi visivamente all’aspetto del dashboard.

Riutilizzare il markup Lovelace: button_card_templates

Per le immagini live ho scelto un approccio basato sui template globali di custom:button-card. L’idea è definire una volta sola uno stile “tile con immagine di sfondo” e riutilizzarlo per tutte le sorgenti visive, così da definire il markup una sola volta, in perfetto stile DRY. I template si definiscono nella configurazione globale del dashboard Lovelace e, nel momento in cui scrivo, devono per forza essere definite in Yaml:

button_card_templates:
  live_tile_card:
    show_icon: false
    show_name: true
    show_label: false
    styles:
      card:
        - border-radius: 12px
        - overflow: hidden
        - height: 180px
    custom_fields:
      picture: true

  live_tile_with_picture:
    template: live_tile_card
    custom_fields:
      picture: |
        [[[
          return `<div style="
            width: 100%;
            height: 100%;
            background-image: url('${variables.picture}');
            background-size: cover;
            background-position: center;
          "></div>`;
        ]]]
    styles:
      custom_fields:
        picture:
          - position: absolute
          - top: 0
          - left: 0
          - width: 100%
          - height: 100%

Ogni tile con immagine live diventa poi solo poche righe di configurazione, con la variabile picture che riceve l’URL dell’immagine. Vediamo subito gli esempi che popolano il nostro dashboard.

Nota: non tutti sanno che effettivamente è possibile accedere al file Yaml complessivo di un intero dashboard. Lo si fa dal menù modifica dashboard in alto a destra, da dove è raggiungibile l’editor di configurazione testuale. I templati vanno direttamente nel root node.

SOHO Lasco C3

SOHO (Solar and Heliospheric Observatory) è un satellite congiunto ESA-NASA in orbita attorno al punto di Lagrange L1 tra Terra e Sole, a circa 1,5 milioni di chilometri dalla Terra. Uno dei suoi strumenti più famosi è LASCO C3, un coronagrafo che oscura il disco solare (come un’eclissi artificiale) per rendere visibile la corona solare esterna. Le immagini vengono aggiornate ogni pochi minuti e rese disponibili pubblicamente dalla NASA.

Perché è utile? Il LASCO C3 è lo strumento primario per il rilevamento delle CME (Coronal Mass Ejection): espulsioni di miliardi di tonnellate di plasma che, quando sono dirette verso la Terra, possono causare tempeste geomagnetiche. Forse più utili per chi fa radioastronomia che astrofotografia, ma sono proprio belle da vedere in dashboard, questo è sicuro.

type: custom:button-card
template:
  - live_tile_card
  - live_tile_with_picture
name: "SOHO Lasco C3"
color_type: icon
variables:
  picture: "https://sohowww.nascom.nasa.gov/data/realtime/c3/512/latest.jpg"
tap_action:
  action: none

GOES-16 SUVI

GOES-16 è il satellite meteorologico geostazionario americano. Oltre ai dati meteo, ospita a bordo il SUVI (Solar Ultraviolet Imager), che fotografa il Sole in ultravioletto a sei diverse lunghezze d’onda. La banda da 195 Å (Angstrom), che corrisponde a temperature coronali di circa 1,5 milioni di Kelvin, è quella standard per individuare le regioni attive, i filamenti e i brillamenti solari.

L’URL delle immagini più recenti è pubblico e aggiornato in tempo reale da NOAA:

type: custom:button-card
template:
  - live_tile_card
  - live_tile_with_picture
name: "GOES-16 (SUVI)"
color_type: icon
variables:
  picture: "https://services.swpc.noaa.gov/images/animations/suvi/primary/195/latest.png"
tap_action:
  action: none

Aurora OVATION

Il modello OVATION (Oval Variation, Assessment, Tracking, Intensity and Online Nowcasting) di NOAA è il sistema di nowcasting più usato per la previsione delle aurore boreali e australi. Produce ogni 30 minuti una mappa globale della probabilità di avvistamento aurorale basandosi sul vento solare misurato dai satelliti.

Per chi vive nell’Europa settentrionale, questa mappa è preziosissima: durante le tempeste geomagnetiche più intense (indice Kp ≥ 7), le aurore diventano visibili anche a latitudini sorprendentemente basse. Certo, la probabilità di osservare una aurora boreale, chessò, in Lombardia rimane piuttosto bassa (ma meno bassa di quanto si credi) e proprio per questo avere questo indicatore in dashboard è importante per evitare di perdersi i momenti giusti.

type: custom:button-card
template:
  - live_tile_card
  - live_tile_with_picture
name: "Aurora Boreale (OVATION)"
color_type: icon
variables:
  picture: "https://services.swpc.noaa.gov/images/animations/ovation-north/latest.jpg"
styles:
  custom_fields:
    picture:
      - background-size: "110% 110%"
tap_action:
  action: none

Il background-size: 110% 110% applica un leggero zoom che taglia il bordo bianco dell’immagine originale NOAA, migliorando la resa visiva nel tile.

Le tre tile vengono raggruppate in un horizontal-stack:

type: horizontal-stack
cards:
  - # SOHO Lasco C3
  - # GOES-16 SUVI
  - # Aurora OVATION

Immagini della superficie del Sole e indicatori NOAA Space Weather

NOAA Space Weather: i KPI dello spazio meteorologico

Le immagini raccontano la situazione qualitativa. Per avere numeri precisi, ho aggiunto tre sensori chiave del NOAA Space Weather Prediction Center, mostrati come semplici tile.

Radio Flux F10.7

Il flusso radio a 10,7 cm (F10.7) è l’indice più longevo e affidabile del ciclo di attività solare: viene misurato ogni giorno alle 17:00 UTC dall’Osservatorio di Penticton (Canada) dal 1947. Valori tipici vanno da ~70 (minimo solare) a ~300+ (massimo solare). Siamo (maggio 2026) attualmente nel Ciclo Solare 25, in fase di massimo, quindi i valori sono elevati.

Velocità del Vento Solare

Il vento solare è un flusso continuo di particelle cariche che il Sole emette in tutte le direzioni. La velocità tipica è 400-600 km/s, ma durante le CME può raggiungere i 3.000 km/s. Un aumento improvviso di velocità è spesso il primo segnale di un’onda d’urto in arrivo.

Indice Kp

L’indice Kp misura le perturbazioni del campo magnetico terrestre su scala globale da 0 (calma assoluta) a 9 (tempesta geomagnetica estrema). È l’indice di riferimento per le previsioni aurorali:

Kp	Visibilità aurora
≤ 3	Solo circolo polare
5	Scandinavia meridionale
7	Germania, Francia settentrionale
9	Mediterraneo

Configurazione multiscrape

I dati vengono recuperati tramite l’integrazione Multiscrape (disponibile anche su HACS), che permette di interrogare una API REST (o in generale qualsiasi cosa), in questo caso l’API NOAA, e mappare ogni campo su un sensore separato in un’unica operazione. Al momento in cui scrivo, il setup va necessariamente fatto in Yaml:

multiscrape:
  - name: "NOAA Space Weather"
    resource: "https://services.swpc.noaa.gov/json/solar-cycle/observed-solar-cycle-indices.json"
    sensor:
      - unique_id: noaa_space_weather_noon_10_7cm_radio_flux
        name: "NOAA Space Weather - Noon 10.7cm Radio Flux"
        value_template: null
        unit_of_measurement: "sfu"

      - unique_id: noaa_space_weather_solar_wind_speed
        name: "NOAA Space Weather Solar Wind Speed"
        value_template: ""
        unit_of_measurement: "km/s"

Per l’indice Kp, NOAA espone un endpoint dedicato:

  - name: "NOAA Kp Index"
    resource: "https://services.swpc.noaa.gov/json/planetary_k_index_1m.json"
    sensor:
      - unique_id: noaa_kp_index_current
        name: "NOAA Kp Index Current"
        value_template: ""
        icon: mdi:sine-wave

Le tre tile nella dashboard:

type: horizontal-stack
cards:
  - type: tile
    entity: sensor.noaa_space_weather_noon_10_7cm_radio_flux
    name: "Radio Flux F10.7"
  - type: tile
    entity: sensor.noaa_space_weather_solar_wind_speed
    name: "Vento Solare"
  - type: tile
    entity: sensor.noaa_kp_index_current
    name: "Indice Kp"
    icon: mdi:sine-wave
    color: purple

Grafici del vento solare: BT e BZ

Il vento solare ha due parametri magnetici che determinano se una tempesta geomagnetica sarà intensa o meno:

BT (Intensità totale del campo magnetico interplanetario) — quanto è forte il campo, in nanoTesla
BZ (Componente Sud del campo) — la componente più critica: quando BZ è fortemente negativo (campo rivolto verso Sud), la magnetosfera terrestre si apre e le particelle solari entrano, causando aurore e tempeste geomagnetiche

Monitorare l’andamento di BZ nelle ultime ore è fondamentale: un BZ negativo prolungato è il segnale che una tempesta è in corso o imminente.

NOAA SWPC pubblica queste misure (aggiornate ogni minuto dal satellite DSCOVR al punto L1) in formato JSON, tanto per cambiare:

https://services.swpc.noaa.gov/products/solar-wind/mag-1-day.json

Per grafici molto densi che possono richiedere la visualizzazioni di più serie di dati, in genere preferisco ApexCharts, che ha una fantastica card per Lovelace:

La linea orizzontale a y=0 è il riferimento visivo chiave: quando BZ scende sotto quella linea e ci rimane, è il momento di controllare le previsioni aurorali.

type: custom:apexcharts-card
graph_span: 6h
header:
  show: true
  title: "Vento Solare — BT / BZ"
series:
  - entity: sensor.noaa_solar_wind_bt
    name: BT
    color: orange
    stroke_width: 2
  - entity: sensor.noaa_solar_wind_bz
    name: BZ
    color: "#5b9ec9"
    stroke_width: 2
    show:
      in_chart: true
yaxis:
  - id: main
    min: -30
    max: 30
    apex_config:
      tickAmount: 6
apex_config:
  chart:
    type: line
  annotations:
    yaxis:
      - y: 0
        borderColor: "#666"
        strokeDashArray: 4

ApexChart è estremamente flessibile e consente di ottenere layout e combinazioni molto complesse, anche se, ammetto, raramente mi trovo a rappresentare grafici diversi da istogrammi, scatterplot o spezzate...che ci volete fare, sono un tradizionalista!

Nella terza parte chiudiamo il cerchio con lo spazio profondo: l’immagine astronomica del giorno della NASA (APOD), la posizione in tempo reale della ISS e il bollettino prossimi lanci spaziali.

Prova a prendermi: come ho insegnato al mio blog a farsi trovare

Sat, 16 May 2026 00:00:00 +0200

Pubblicare un articolo su un blog personale è facile. Assicurarsi che venga trovato dai motori di ricerca — e, sempre più, dai crawler AI — è un’altra storia. Per anni ho fatto come fanno tutti: scrivevo, applicavo il buon senso SEO di base, pubblicavo. Ogni tanto aprivo Google Search Console e se qualcosa era cambiato, o non stava funzionando, prendevo qualche contromisura seguendo, un po’ svogliatamente, le raccomandazioni di questo o quel tool di auditing.

Ecco, il fatto è che io, in quanto appassionato di divulgazione, trovo piacere a spiegare la scienza, e raggiungere l’audience più ampia possibile è parte del gioco. Ma il desiderio di scrivere, in me, vince sempre. L’ottimizzazione e, soprattutto, il monitoraggio arrivano irrimediabilmente dopo.

Così, oggi mi sono detto: perché non automatizziamo anche la componente SEO?

In un modo moderno, perbacco, già che siamo nel 2026?

…e possibilmente utilizzando solo strumenti open source o, al più, con un generoso free tier mensile?

In effetti, ogni volta che pubblico o modifico un post su questo blog, parte già una catena di eventi organizzata nel workflow di authoring e pubblicazione: Jekyll builda il sito, Cloudflare Pages lo pubblica, Cloudinary (la mia CDN) genera le immagini hero e scalda la cache con gli altri formati (quelli, ad esempio, per i microformati social). Tutto automatico, tutto già funzionante.

Si tratta solo di espandere il concetto.

Così è nata la mia pipeline di SEO automatica, la prima di una serie che nella mia testa avrà, in definitiva, questi tre blocchi:

Il supporto all’autorialità. Quello che vedremo oggi: una pipeline che alla pubblicazione di un nuovo articolo effettua una serie di audit ed altre operazioni sullo stesso, proponendo eventuali azioni migliorative.
Il supporto al monitoraggio. Un workflow periodico che, anche in assenza di nuovi articoli, monitora i parametri SEO ed evidenzia problemi o cambiamenti peggiorativi nello stato di salute del blog nel suo complesso.
L’applicazione automatica delle migliorie. In cui agenti LLM andranno ad analizzare le proposte di migliorie SEO emerse nel blocco 1 e applicheranno automaticamente i correttivi, per poi valutarne l’effetto grazie al monitoraggio del blocco 2.

Il workflow di supporto autoriale: l’idea

Banalmente, una volta terminato il processo di pubblicazione di un articolo, il suo permalink viene passato a una serie di servizi che lo analizzano e lo notificano ai motori di ricerca. Il tutto orchestrato da un unico file YAML. Zero servizi a pagamento, zero login da fare, zero dashboard da aprire, zero notifiche da controllare manualmente — tutto descritto programmaticamente dal contenuto del repository git e guidato da CICD.

In questo articolo non andrò a riportare il codice nella sua interezza, per non appesantire la lettura, ma solo i suoi principi di base e le sue caratteristiche più istruttive. Chiaramente, sentitevi liberi di riutilizzare il workflow secondo le vostre esigenze: ne sarei felice!

Come funziona

Innanzitutto, il workflow si aggancia a workflow_run, cioè parte automaticamente al completamento del workflow precedente, quello di pubblicazione, appunto. Può, però, anche essere lanciato manualmente passando gli URL da verificare mediante una clausola di workflow_dispatch.

Questo, nello YAML del workflow, è espresso tramite questo blocco in testa:

on:
  workflow_run:
    workflows: ["Deploy blog on Cloudflare Pages"]
    types: [completed]
    branches: [main, master]
  workflow_dispatch:
    inputs:
      urls:
        description: 'URL da verificare (separati da spazio)'
        required: false
        type: string

Ogni job avrà sempre una clausola if di questo tipo:

if: ${{ github.event_name == 'workflow_dispatch' || github.event.workflow_run.conclusion == 'success' }}

Ma la parte più elegante è il modo in cui trova i post da analizzare:

git diff --name-only HEAD~1 HEAD -- '_posts/**.md' '_posts/**.Rmd'

In pratica, prende solo i file .md e .Rmd modificati nell’ultimo commit e di questi estrae la categoria e lo slug dal nome file, costruisce la lista di URL da testare e poi uno ad uno chiama i vari servizi passandogli la lista, oppure un URL alla volta in un loop bash. Nessun inventario da mantenere.

Gli url di chiamata sono costruiti tramite operazioni su stringhe, i servizi li chiamo tutti tramite curl, e formatto i risultati con jq e li mostro a console. È tutto scritto in bash, insomma.

Se la maggior parte dei tool producono solo un po’ di informazioni in stdout che io riformatto e stampo, altri producono output molto più ricchi. Per questi ultimi, salvo i report come artifact del workflow, accessibili dalla pagina dell’azione su GitHub per 30 giorni. Un esempio:

- name: Salva report Lighthouse
  if: always()
  uses: actions/upload-artifact@v4
  with:
    name: lighthouse-reports
    path: |
      lighthouse-results/
      .lighthouseci/*.html
      .lighthouseci/*.json
    retention-days: 30

Ma adesso scendiamo nel dettaglio pratico su ciò che facciamo e perché lo facciamo.

Le cose che contano davvero

Ho colto l’occasione di questa pipeline per sistemare diversi aspetti di SEO strutturale (layout) che erano in arretrato da tempo. Non sono interventi appariscenti, ma sono quelli che fanno la differenza tra un blog tecnicamente solido e uno che spera di essere trovato. Prima i fondamentali, insomma.

Parte 1 — Crawlability e l’arte di farsi trovare

Trovarsi su Google non basta più. Nel 2026, una fetta crescente del traffico verso i contenuti tecnici arriva dai crawler AI — ChatGPT, Perplexity, Claude, Gemini, Copilot. Questi sistemi non navigano il web come un browser: arrivano, leggono l’HTML e se ne vanno. Se il tuo contenuto non è immediatamente accessibile, per loro non esiste.

Secondo AI Advisors, i crawler AI cercano tre cose: contenuti ben strutturati, segnali di autorità chiari, e una gerarchia di heading che renda ovvio di cosa parla ogni sezione. Non è diverso da ciò che vuole Google, ma è più esigente in termini di pulizia strutturale e metadati.

Ne ho approfittato quindi per sistemare, lato template Jekyll, questi elementi statici:

robots.txt per crawler AI. GPTBot, CCBot, anthropic-ai, PerplexityBot, Google-Extended e altri: tutti possono accedere ai contenuti testuali ma non agli asset binari. Con l’esplosione del traffico da AI crawler, è diventato rilevante. Ma attenzione a non stressare troppo la CDN: il traffico da AI può essere davvero invadente.

llms.txt e llms-full.txt. Il primo è un indice strutturato dei post in formato Markdown — una specie di sitemap per LLM. Il secondo è l’intero corpus del blog in un unico file markdown, generato automaticamente a ogni build da un semplicissimo plugin Jekyll. Lo standard è ancora acerbo e usato da pochi attori (solo OpenAI, al momento in cui scrivo), ma adottarlo costa talmente poco che non farlo sarebbe pigrizia.

Core Web Vitals sotto controllo. Lighthouse CI e PageSpeed Insights verificano a ogni deploy che LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift) e TBT (Total Blocking Time) restino entro soglie accettabili. Le mie pagine sono statiche, quindi i valori sono naturalmente buoni, ma il controllo automatico mi avvisa se qualcosa degenera — un’immagine troppo pesante, un font che blocca il rendering, un layout che slitta, un javascript che crea problemi.

PSI è un po' più old school e da molto peso agli aspetti tecnici

Parte 2 — Schema.Org e l’arte di farsi riconoscere

I microformati sono il modo in cui dici ai motori di ricerca cosa stai dicendo. Non “questa è una stringa di testo”, ma “questo è il titolo di un articolo, questo è l’autore, questo è un termine tecnico definito e questo sono io”.

Sul mio blog, ogni post ha già un blocco JSON-LD BlogPosting con titolo, descrizione, data di pubblicazione, autore. Quello che ho aggiunto con questa pipeline è:

author.sameAs. I link ai profili social dell’autore (GitHub, LinkedIn, Mastodon, Goodreads, Printables) ora appaiono nel markup strutturato. Per i motori di ricerca, questo collega inequivocabilmente i contenuti a una persona reale con una presenza online verificabile.

{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "Gabriele Baldassarre",
  "url": "https://gabrielebaldassarre.com",
  "image": "https://gabrielebaldassarre.com/assets/images/gabriele-baldassarre.png",
  "sameAs": [
    "https://github.com/theclue",
    "https://www.linkedin.com/in/gabrielebaldassarre",
    "https://mastodon.social/@gabriob",
    "https://goodreads.com/theclue",
    "https://www.printables.com/@GabrioB_1701666"
  ]
}

Ho creato un glossario YAML (_data/glossary.yml) con i termini tecnici che uso più spesso nel blog — spin quantistico, autovettore, illuminamento, legge di potenza, ecc. — ciascuno con definizione e URL sotto forma di entità DefinedTerm e DefinedTermSet. . Ogni post ora ha un blocco about che linka i termini del glossario pertinenti alla categoria. Sulle pagine indice (homepage, categorie), un DefinedTermSet elenca l’intero glossario.

{
  "@type": "DefinedTermSet",
  "name": "Glossario di Gabriele Baldassarre",
  "hasDefinedTerm": [
    {
      "@type": "DefinedTerm",
      "termCode": "Spin quantistico",
      "name": "Spin quantistico",
      "description": "Proprietà intrinseca delle particelle elementari...",
      "url": "https://gabrielebaldassarre.com/fisica/stati-spin/"
    }
  ]
}

L’obiettivo è costruire un mini knowledge graph semantico, così che un motore di ricerca — o un LLM — che atterra su una mia pagina possa risalire al contesto tecnico in cui si inserisce.

Dopo aver definito il proprio modello di metadati di schema, mon fa male fare un passaggio su Schema Validator

Parte 3 — GEO e l’arte di farsi capire

La Generative Engine Optimization (GEO) è la pratica di strutturare i contenuti perché vengano citati dai motori di ricerca AI — ChatGPT, Perplexity, Claude, Gemini. Non si tratta di ranking. Si tratta di citation rate: quanto spesso il tuo brand appare nelle risposte generate.

Secondo LLMrefs, la sovrapposizione tra i link di Google e le fonti citate dagli AI è scesa dal 70% a meno del 20%. In particolare, le AI citano tranquillamente risultati che, invece, nelle SERP dei motori di ricerca sono ben lontane dalla prima pagina di risultati, senza timore. I due mondi si stanno separando. E i criteri che usano gli AI per scegliere cosa citare sono diversi.

Cosa ho fatto, in concreto, per applicare GEO al mio blog:

Heading gerarchici puliti. Ogni sezione ha un H2, ogni sottosezione un H3. Un argomento per sezione. Gli AI usano la struttura per decidere cosa è rilevante.
Risposte prima del contesto. In ogni sezione, la risposta arriva subito, il contesto dopo. Gli AI estraggono informazioni, non leggono romanzi. E qui la sfida per me sta proprio nello scrivere un testo un minimo sospensivo che crei pathos per il lettore, ma che non sia penalizzato dalle AI. Spoiler: non è per niente facile (ma ci si riesce).
Paragrafi corti. Due o tre frasi al massimo. I blocchi di testo lunghi sono più difficili da processare, meno probabili da citare e occupano più contesto (“Che, signora mia, di contesto non ce n’è mai abbastanza!”).
Liste puntate e numerate. Per processi, checklist, confronti.
Segnali di autorità espliciti. L’autore è indicato con nome, biografia e link social. Le fonti sono citate. I dati hanno attribuzione. I microformati rafforzano l’ancoraggio identitario. Molto utile.
Freschezza dei contenuti. Gli AI hanno un recency bias fortissimo: dopo 3 mesi, le citation crollano. Per questo motivo il workflow di monitoraggio (blocco 2) includerà un check periodico sulla freschezza.

Non ho dovuto snaturare il mio modo di scrivere. Ho solo applicato un po’ di disciplina strutturale. Che, a ben vedere, migliora la lettura anche per gli umani.

Parte 4 — SEO Auditing e l’umiltà di farsi consigliare

Arriviamo al cuore pratico della pipeline. Una volta che il workflow ha trovato i post da analizzare, per ognuno chiama in sequenza questi quattro servizi.

IndexNow

È il più semplice: un POST JSON con {host, key, urlList} a api.indexnow.org. La chiave è un file .txt servito alla root del dominio che dimostra la proprietà del sito — niente registrazioni, niente dashboard. Il protocollo è adottato da Bing, e questo ci basta:

curl -X POST "https://api.indexnow.org/indexnow" \
  -H "Content-Type: application/json; charset=utf-8" \
  -d '{"host":"gabrielebaldassarre.com","key":"b8f09512...","urlList":["https://gabrielebaldassarre.com/fisica/stati-spin/"]}'

La risposta è un 200 se l’URL è stato accettato, 202 se è in attesa di validazione della key (la prima volta che si usa). Dopo il primo invio, la key è verificata e le risposte successive sono tutte 200 (quindi si, se usate il mio workflow la prima volta la pipeline fallirà. Sappiatelo).

🚀 Invio notifica IndexNow per 1 URL...
📥 Risposta IndexNow: HTTP 200
✅ URL notificati con successo ai motori di ricerca

Hermes SEO Audit

Un’API pubblica (con key opzionale per limiti più alti — 5 req/giorno anonimo, 50 con key gratuita). Restituisce un JSON con score, grade, issues, warnings e passed. Lo uso per avere un quadro immediato dello stato SEO di una pagina.

curl -s "https://hermesforge.dev/api/seo?url=https://gabrielebaldassarre.com/fisica/stati-spin/&key=YOUR_KEY"

Output a console dopo parsing con jq:

📋 [1/2] https://gabrielebaldassarre.com/fisica/stati-spin/
  Punteggio: 94/100 (A)
  Problemi: 0 | Warning: 2 | OK: 10
  🟡 Warning:
    - [title] Title may be truncated in search results (114 chars)
    - [meta] Meta description may be truncated (213 chars)
  📊 Riepilogo: 94/100 (A) | 🔴 0 | 🟡 2 | ✅ 10

📋 [2/2] https://gabrielebaldassarre.com/home-assistant/illuminanza-smartworking/
  Punteggio: 85/100 (B)
  Problemi: 1 | Warning: 3 | OK: 8
  🔴 Problemi:
    - [images] 1 of 1 images missing alt text (high)
  🟡 Warning:
    - [title] Title too short (38 chars, recommend 50-60)
    - [meta] Meta description short (89 chars)
    - [performance] Page size excessive (1.2 MB)
  📊 Riepilogo: 85/100 (B) | 🔴 1 | 🟡 3 | ✅ 8

Hermes è, in realtà, una suite ben più grande — offre anche screenshot API, chart rendering, dead link check e performance audit — con caratteristiche davvero intriganti e su cui sicuramente scriverò in futuro.

PageSpeed Insights

L’API ufficiale Google per Core Web Vitals. Richiede una API key gratuita da Google Cloud Console. Restituisce le categorie performance, accessibility, SEO e best-practices, sia per mobile che per desktop.

curl -s "https://www.googleapis.com/pagespeedonline/v5/runPagespeed?url=https://gabrielebaldassarre.com/&strategy=mobile&category=performance&category=accessibility&category=seo&category=best-practices&key=YOUR_KEY"

Nota bene: bisogna passare esplicitamente le quattro categorie con &category=, altrimenti l’API restituisce solo performance. Ci ho perso due ore a capirlo e vi risparmio volentieri questo strazio.

Output a console:

🔍 Analisi: https://gabrielebaldassarre.com/
  📱 Mobile  | Perf: 89% | A11y: 92% | SEO: 83% | LCP: 3.8 s | TBT: 10 ms | CLS: 0
  🖥️  Desktop | Perf: 98% | A11y: 92%

🔍 Analisi: https://gabrielebaldassarre.com/fisica/stati-spin/
  📱 Mobile  | Perf: 82% | A11y: 88% | SEO: 79% | LCP: 4.3 s | TBT: 60 ms | CLS: 0.104
  🖥️  Desktop | Perf: 100% | A11y: 88%
  ⚠️  PERFORMANCE MOBILE SOTTO SOGLIA CRITICA: 82%

Il report JSON completo — ben più ricco della sintesi a console — viene salvato come artifact del workflow, accessibile per 30 giorni.

Per utilizzare le API di PageSpeed Insights è necessario un progetto su Google Cloud Platform. Questa cosa non mi fa impazzire, ma se non altro sono gratuite

Lighthouse CI

Qui cominciamo a calare i pezzi grossi. Lighthouse CI non è un servizio remoto con una API REST, ma un headless Chrome eseguito in locale sulla VM del runner di GitHub Actions. Naviga le pagine, raccoglie metriche, e produce report HTML con screenshot, waterfall di rete e diagnostica.

npm install -g @lhci/cli --quiet

npx lhci collect --url="https://gabrielebaldassarre.com/fisica/stati-spin/" \
  --settings.chromeFlags="--no-sandbox --headless --disable-gpu" \
  --numberOfRuns=1

npx lhci assert --config=.github/lighthouse/lighthouserc.json

Le assertion sono configurate in un file lighthouserc.json che definisce le soglie minime:

{
  "ci": {
    "assert": {
      "assertions": {
        "categories:performance": ["warn", {"minScore": 0.50}],
        "categories:accessibility": ["warn", {"minScore": 0.80}],
        "categories:seo": ["warn", {"minScore": 0.70}],
        "largest-contentful-paint": ["warn", {"maxNumericValue": 4000}],
        "total-blocking-time": ["warn", {"maxNumericValue": 500}],
        "cumulative-layout-shift": ["warn", {"maxNumericValue": 0.25}]
      }
    }
  }
}

Essendo un tool locale, ipoteticamente potrebbe anche essere eseguito a build time prima della pubblicazione, e magari bloccarla se il post non raggiunge una soglia minima di score. All’atto pratico, però, questo scenario non è facile da implementare.

Nel mio caso, ad esempio, che uso una CDN per le immagini, durante il build gli asset non sono ancora pubblici e i loro URL non sono ancora risolti. L’audit pre-deploy soffrirebbe di falsi positivi. Eseguo quindi Lighthouse post-deploy, quando il sito è live e Cloudinary ha già cachato tutte le immagini.

Lighthouse CI fornisce un report molto dettagliato. Come vedete, già non sono messo così male come scoring

I report HTML e JSON sono salvati come workflow artifact con timestamp e commit hash nel nome (assertions-20260516-164500-a1b2c3d.json), da dove li recupero per un’ispezione ad oggi manuale. Sono incredibilmente ricchi di informazioni. Forse anche troppe, per un umano… se capite dove voglio arrivare.

Gestire secrets e API key

Molti di questi servizi richiedono una API key, spesso passata come parametro nelle chiamate curl. Come le si passa al workflow senza committare in chiaro sul repository?

Ma con le Secrets ovviamente! Anche Github, infatti, ha questa funzionalità che non può mancare ad un orchestratore di CICD. Si configurano in Settings → Secrets and variables → Actions.

Quanto costa

Zero. Ecco il conto, servizio per servizio:

GitHub Actions — illimitato per repository pubblici. 2000 minuti/mese di esecuzione; ne consumo forse 30.
PageSpeed Insights — 25.000 query al giorno. Ne faccio 4 o 5 a deploy.
IndexNow — completamente gratuito e senza limiti.
Hermes SEO — 5 richieste al giorno in anonimo, 50 con API key gratuita.
Lighthouse CI — eseguito localmente sul runner di GitHub Actions, nessun servizio esterno.

Prossimi passi

Questo era il blocco 1: supporto all’autorialità. Nel prossimo articolo della serie affronterò il blocco 2, il monitoraggio periodico: un workflow schedulato con cron che testa tutti i post del blog una volta al mese, produce un report aggregato, e — se necessario — apre automaticamente una issue su GitHub per segnalare regressioni.

Poi, nel blocco 3, arriverà la parte più ambiziosa: un agente LLM che analizza i report SEO, propone modifiche ai post, le applica in una pull request, e verifica l’effetto grazie ai dati del monitoraggio.

Ma per oggi va bene così.

Il cielo in salotto, parte 1: Sistema Terra-Luna

Sun, 10 May 2026 00:00:00 +0200

Ci sono progetti che iniziano con un’idea semplice e finiscono per diventare qualcosa di più grande. Questo è uno di quelli. Tutto è partito da una domanda banale: posso sapere dalla mia dashboard di Home Assistant in che fase è la Luna stasera? La risposta è ovviamente sì — ma una volta aperta quella porta, è difficile fermarsi.

Quello che descrivo in questa serie di articoli è una dashboard di astrometria — una parola un po’ altisonante per dire: uno schermo dedicato a tutto quello che succede sopra la nostra testa, dai cicli lunari all’attività solare, dalle aurore boreali ai prossimi lanci spaziali. Non è un progetto per astronomi professionisti e il suo scopo è sicuramente divulgativo, in particolare per incuriosire i miei due bambini. Tuttavia, non è nemmenod el tutto inutile: astrofili, appassionati di astrofotografia, o semplicemente chi vuole sapere se stasera vale la pena alzare lo sguardo potrebbero trovarvi informazioni utili.

La dashboard è divisa in tre sezioni:

Sistema Terra-Luna — la Luna, il sole che tramonta (questa prima parte)
Sol — immagini live del Sole, aurora boreale, vento solare (parte 2)
Spazio profondo e bollettini — l’immagine del giorno NASA (APOD), posizione della ISS, prossimi lanci (parte 3)

Al termine di questa serie di articoli, l'aspetto del dashboard sarà - speriamo - più o meno questo

La Luna

La Luna è l’oggetto celeste più osservato e fotografato da sempre. Per un astrofilo o un appassionato di astrofotografia, la fase lunare è una variabile critica: la notte di luna piena è splendida da guardare a occhio nudo, ma rende quasi inutili le sessioni di deep sky a causa della luce diffusa. Sapere in anticipo la fase e l’orario del tramonto del sole (che definisce l’inizio della notte astronomica) permette di pianificare le sessioni di osservazione con precisione.

L’integrazione `moon` nativa

Home Assistant include di serie un’integrazione chiamata semplicemente Moon che calcola localmente, senza dipendenze esterne, la fase lunare corrente. Si abilita da Impostazioni → Dispositivi e servizi → Aggiungi integrazione cercando “Moon”.

Questo crea l’entità sensor.moon con stati come new_moon, waxing_crescent, first_quarter, waxing_gibbous, full_moon, waning_gibbous, last_quarter, waning_crescent.

È la base dati, ma da sola non basta per visualizzare il disco lunare attuale, esteticamente molto più gradevole da mostrare in dashbard. Per quello, ci serve una fonte fotografica.

Il disco lunare in tempo reale: API NASA SVS

La NASA mette a disposizione un’API pubblica e gratuita nel suo set di endpoint SVS (Scientific Visualization Studio) e che restituisce, per ogni ora, l’immagine esatta del disco lunare vista dalla Terra, completa di angolo di librazione, illuminazione e fase. L’endpoint è:

https://svs.gsfc.nasa.gov/api/dialamoon/{YYYY-MM-DDTHH:MM}

dove la data e l’ora vanno passate in formato ISO 8601. La risposta JSON contiene, tra le varie cose, proprio l’informazione che ci serve:

{
  "image": {
    "url": "https://svs.gsfc.nasa.gov/vis/a000000/a005100/a005190/frames/730x730_1x1_30p/moon.XXXX.jpg"
  }
}

Quindi value_json.image.url è l’URL dell’immagine PNG del disco lunare per quell’istante.

Il problema è il formato della data: l’API si aspetta 2026-05-10T14:00, ma i template Jinja2 di HA hanno now() che restituisce un oggetto datetime completo. Serve un passo intermedio.

Il sensore template per la data

Creo un template sensor che formatta la data corrente nel formato esatto richiesto dall’API:

template:
  - sensor:
      - unique_id: datetime_universal_nasa
        name: "Data e Ora (formato REST NASA)"
        state: >
          {{ now().strftime('%Y-%m-%dT%H:%M') }}
        attributes:
          template: space

Questo crea sensor.datetime_universal_nasa che aggiorna il suo stato ogni minuto con il timestamp corrente nel formato giusto. L’attributo template: space è un’etichetta libera che uso per raggruppare logicamente i sensori legati al tema astronomico — non ha impatto funzionale, ma torna utile per filtrare le entità nella UI. Come spesso accade, la scelta se realizzare il sensore template da UI piuttosto che da Yaml è molto personale e del tutto equivalente.

Il REST sensor per il disco lunare

Ora uso questo sensore come parte dell’URL nella resource_template del REST sensor. Questo, invece, ad oggi può essere solo configurato tramite Yaml:

rest:
  - platform: rest
    unique_id: nasa_moon_phase
    resource_template: >-
      https://svs.gsfc.nasa.gov/api/dialamoon/{{
        states('sensor.datetime_universal_nasa')
        if states('sensor.datetime_universal_nasa') not in ['unknown', 'unavailable']
        else now().strftime('%Y-%m-%dT%H:%M')
      }}
    name: Nasa Moon Phase Info
    value_template: "{{ value_json.image.url }}"
    json_attributes:
      - image

Due cose degne di nota:

Il fallback: se il sensore della data non è ancora disponibile al boot, uso now().strftime(...) direttamente nella resource_template. Questo evita che il sensore vada in unavailable durante l’avvio di HA, sporcando il log di avvio.
json_attributes: [image]: salvo l’intero oggetto image come attributo del sensore, non solo l’URL. Questo mi permette di accedere a tutti i campi restituiti dall’API in futuro senza modificare la configurazione.

Il sensore sensor.nasa_moon_phase_info avrà come state l’URL dell’immagine del disco lunare aggiornata all’ora corrente.

Generic Camera: mostrare l’immagine

Un REST sensor restituisce testo (l’URL), non l’immagine stessa. Per mostrare l’immagine nella dashboard serve una Generic Camera.

L’integrazione Generic Camera (o Still Image Camera) di Home Assistant crea un’entità camera.* che scarica periodicamente un’immagine da un URL statico o dinamico e la espone come stream video o still image. La si aggiunge da Impostazioni → Dispositivi e servizi → Generic Camera e nel campo Still Image URL si inserisce un template Jinja2 molto semplice:

{{ states('sensor.nasa_moon_phase_info') }}

oppure, equivalentemente:

{{ state_attr('sensor.nasa_moon_phase_info', 'value') }}

Questo crea camera.fasi_lunari_nasa (il nome si può scegliere in fase di configurazione). La camera aggiorna l’immagine ogni volta che lo stato del sensore cambia — che avviene ogni ora, allineato con l’ora astronomica.

Nella dashboard, una card picture-entity che punta a questa camera mostra il disco lunare aggiornato:

type: picture-entity
entity: sensor.fasi_lunari
camera_image: camera.fasi_lunari_nasa
camera_view: auto
show_name: true
show_state: true

Ho completato aggiungendo nell’heading della sezione un badge con sensor.sun_next_dusk: l’orario del prossimo crepuscolo astronomico. È una piccola aggiunta, ma molto pratica: guardando la dashboard so immediatamente a che ora inizia il buio utile per l’osservazione. Il sensore sun.sun espone automaticamente questi attributi tramite l’integrazione sole nativa di HA. Questo, per praticità, l’intero codice dell’intestazione di sezione

type: heading
icon: mdi:earth
heading_style: title
heading: "Sistema Terra-Luna"
badges:
  - type: entity
    entity: sensor.sun_next_dusk

La foto della Luna può finalmente essere visualizzata in dashboard utilizzando una qualsiasi card che possa visualizzare un flusso di fotocamera.

La custom:lunar-phase-card

Il disco lunare è già un buon punto di partenza, ma la custom:lunar-phase-card aggiunge un livello di informazione in più: mostra l’arco celeste con la posizione della Luna, il grafico dell’altitudine nelle prossime ore, e i dati di fase, prossimo plenilunio, distanza dalla Terra e percentuale di illuminazione.

Si installa da HACS (Repository: lunar-phase-card). La configurazione per Milano:

type: custom:lunar-phase-card
use_default: true
show_background: true
selected_language: it
default_card: horizon
moon_position: left
compact_view: false
12hr_format: false
number_decimals: 0
latitude: 45.4668
longitude: 9.1457
location:
  city: Milano
  country: Italia
graph_config:
  y_ticks: true
  x_ticks: true
  show_time: true
  show_current: true
  show_legend: false
  show_highest: true
  y_ticks_position: left
  y_ticks_step_size: 55
  time_step_size: 30

Card di sintesi della Luna

use_default: true dice alla card di calcolare autonomamente la fase senza affidarsi a un sensore esterno — il che la rende indipendente dal REST sensor NASA e dal sensore moon. Questo è utile per avere ridondanza: anche se l’API NASA fosse irraggiungibile, la card continua a mostrare la fase calcolata internamente.

Sensore fasi lunari con icona e immagine

Il sensore sensor.moon_phase dell’integrazione Moon restituisce valori interni in inglese (new_moon, waxing_crescent, ecc.). Per i badge e le Mushroom card — che mostrano nome, icona e immagine in modo visivamente curato — conviene costruire un template sensor dedicato che traduca questi valori in italiano, abbini l’icona MDI corretta e usi l’immagine NASA come picture dell’entità. Il risultato è un piccolo tocco di classe, esteticamente gradevole.

template:
  - sensor:
      - unique_id: moon_phase_anime
        name: "Fasi Lunari"
        state: >
          {% set phase = states('sensor.moon_phase') %}
          {% set moon_phases = {
              'new_moon': 'Luna nuova',
              'waxing_crescent': 'Primo crescente',
              'first_quarter': 'Primo quarto',
              'waxing_gibbous': 'Gibbosa crescente',
              'full_moon': 'Luna piena',
              'waning_gibbous': 'Gibbosa calante',
              'last_quarter': 'Ultimo quarto',
              'waning_crescent': 'Ultimo crescente'
            }
          %}
          {{ moon_phases[phase] if phase in moon_phases.keys() else 'Sconosciuto' }}
        picture: "{{ states('sensor.nasa_moon_phase_info') }}"
        icon: >
          {% set phase = states('sensor.moon_phase') %}
          {% set moon_icons = {
              'new_moon': 'mdi:moon-new',
              'waxing_crescent': 'mdi:moon-waning-crescent',
              'first_quarter': 'mdi:moon-first-quarter',
              'waxing_gibbous': 'mdi:moon-waxing-gibbous',
              'full_moon': 'mdi:moon-full',
              'waning_gibbous': 'mdi:moon-waning-gibbous',
              'last_quarter': 'mdi:moon-last-quarter',
              'waning_crescent': 'mdi:moon-waning-crescent'
            }
          %}
          {{ moon_icons[phase] if phase in moon_icons.keys() else 'mdi:moon-new' }}

Badge costruito a partire dal sensore. Notare l'immagine e le descrizioni in italiano

Alcune note:

picture: l’attributo speciale picture di un template sensor sovrascrive l’icona con un’immagine. In questo caso punta allo stato di sensor.nasa_moon_phase_info, che come abbiamo visto contiene l’URL del disco lunare attuale. Mushroom card e chip card mostrano automaticamente questa immagine tonda al posto dell’icona — il risultato, come dicevo, è visivamente molto efficace.
icon: mappa ogni fase sulla corrispondente icona mdi:moon-*. La libreria MDI include tutte le otto fasi. Quando picture è valorizzata la card usa quella, ma l’icona rimane disponibile come fallback o in contesti che non supportano picture.
Fallback 'Sconosciuto' / 'mdi:moon-new': il filtro if phase in moon_phases.keys() else protegge da stati transitori (unknown, unavailable) al boot o durante riavvii.
Relazione con gli altri sensori: questo sensore è un aggregatore — non interroga API esterne, si limita a leggere sensor.moon_phase (nativo) e sensor.nasa_moon_phase_info (REST). Se l’API NASA fosse irraggiungibile, lo stato in italiano e l’icona continuerebbero a funzionare; mancherebbe solo l’immagine.

Riepilogo

In questa prima parte abbiamo costruito il modulo Sistema Terra-Luna:

Nella seconda parte ci sposteremo sul Sole: immagini live da SOHO e GOES-16, la previsione delle aurore boreali OVATION, e i dati dello spazio meteorologico con grafici BT/BZ in tempo reale.

Illuminanza intelligente per lo smartworking: fisica, modelli e controllo in Home Assistant

Sat, 09 May 2026 00:00:00 +0200

Chi lavora da casa conosce il problema: la luce cambia continuamente durante la giornata, e spesso ci si ritrova a lavorare al computer con una illuminazione inadeguata senza rendersene conto. Troppa luce crea abbagliamento sullo schermo, troppa poca affatica gli occhi. La soluzione ideale è un sistema che compensi automaticamente la luce naturale con quella artificiale, mantenendo l’illuminamento costante.

In questo articolo descrivo come ho costruito questo sistema in Home Assistant, partendo da zero sensori di luminosità fisici — che non ho — fino a una automazione che stabilizza l’illuminamento del soggiorno durante le ore di lavoro.

Il problema: non ho sensori di luce

I sensori di illuminanza fisici esistono, costano poco e funzionano bene. Ma non mi andava di acquistarli e di aggiungere altri dispositivi alla mia già piuttosto affollata costellazione Zigbee. Ho provato, allora, a volevo capire se fosse possibile stimare l’illuminamento con quello che già avevo: la posizione geografica della mia casa, le caratteristiche geometriche delle finestre, e le integrazioni meteo già presenti in Home Assistant.

La risposta è sì, con qualche compromesso.

Il modello fisico: soleggiamento

Il punto di partenza è sun.sun, l’entità built-in di Home Assistant che espone in ogni momento l’elevazione e l’azimuth del sole. A questi aggiungo un sensore di illuminanza esterna (sensor.luminanza_esterna) che viene da un’integrazione che ha esattamente questo scopo e misura i lux al suolo nelle condizioni meteo attuali — già corretta per la copertura nuvolosa la cui misura proviene tipicamente dall’integrazione meteo.

Il contributo della luce solare all’interno di una stanza dipende da tre fattori geometrici:

L’angolo di incidenza della luce sulla finestra
La trasmittanza del vetro ($\tau_g$)
Il rapporto tra area finestra e area stanza ($A_f / A_{room}$)

La formula per il componente diretto è quella standard della fotometria degli interni:

E_{dir} = E_{ext} \cdot \tau_g \cdot \cos\theta \cdot \frac{A_f}{A_{room}}

dove:

$E_{ext}$ è l’illuminanza esterna al suolo in condizioni di cielo sereno (in lux, da sensore meteo)
$\tau_g$ è la trasmittanza del vetro, ovvero la frazione di luce che attraversa il vetro (tipicamente 0.15–0.30 per doppi vetri con trattamento)
$A_f$ è l’area della finestra in m²
$A_{room}$ è l’area della stanza in m²
$\cos\theta$ è l’angolo di incidenza del raggio solare sulla superficie della finestra, calcolato a partire da elevazione e azimuth del sole:

\cos\theta = \sin(\alpha) \cdot \cos(\beta) + \cos(\alpha) \cdot \sin(\beta) \cdot \cos(\Delta\phi)

con $\alpha$ = elevazione solare, $\beta$ = inclinazione della finestra (90° per una finestra verticale), $\Delta\phi$ = differenza di azimuth tra sole e normale alla finestra.

Correzione per la copertura nuvolosa. Il modello appena descritto assume implicitamente che la luce solare sia direzionale: tutti i raggi arrivano dalla stessa direzione (quella del sole) e $\cos\theta$ cattura correttamente quanto di quella luce passa attraverso la finestra. Questa ipotesi è buona sotto cielo sereno.

Sotto cielo coperto, invece, la situazione cambia radicalmente. Le nuvole diffondono la radiazione solare in tutte le direzioni: la luce non ha più una provenienza privilegiata ma arriva isotropicamente da tutta la volta celeste, con intensità approssimativamente uniforme su ogni direzione. Questo è il modello di cielo diffuso isotropo (Liu e Jordan, 1960), la formulazione più semplice e più usata per la componente diffusa: si assume che la luminanza del cielo sia la stessa in ogni punto dell’emisfero. In questo regime, il fattore geometrico rilevante non è più $\cos\theta$ — che descrive l’angolo tra il raggio direzionale e la normale alla finestra — ma il view factor della finestra verso il cielo: la frazione dell’emisfero celeste che la finestra “vede”.

Per una finestra piana verticale con inclinazione $\beta$ rispetto all’orizzontale, il view factor verso la metà superiore dell’emisfero è un risultato standard della radiometria:

FV = \frac{1 + \cos\beta}{2}

Per una finestra verticale ($\beta = 90°$) questo vale esattamente $0.5$: la finestra vede metà cielo, e con luce isotropa raccoglie esattamente la metà dell’irradianza disponibile. Non è un’approssimazione né una costante empirica — è pura geometria.

Ora, nella realtà quotidiana il cielo è raramente completamente sereno o completamente coperto: si trova quasi sempre in uno stato intermedio. Molte integrazioni meteo, però, come dicevo offrono una stima sulla presenza di nubi. Io, per esempio, posso avvalermi del sensor.tomorrow_io_casa_cloud_cover, che fornisce in tempo reale la copertura nuvolosa $f_c \in [0,1]$ (0 = sereno, 1 = coperto). È naturale usarlo come peso per interpolare linearmente tra i due regimi:

\cos\theta_{eff} = (1 - f_c)\cdot\cos\theta + f_c \cdot 0.5

Quando $f_c = 0$ si recupera la formula originale, puramente direzionale. Quando $f_c = 1$ il termine $\cos\theta$ scompare del tutto e rimane solo il view factor isotropo. Per valori intermedi si ottiene una transizione continua tra i due comportamenti limite. Sempre che ci accontentiamo, come al solito, di una semplificazione lineare.

Il guadagno pratico è più evidente nelle situazioni in cui i due regimi producono risultati molto diversi: tipicamente al mattino presto o in inverno, quando il sole è basso ($\cos\theta$ piccolo) ma il cielo è parzialmente coperto — il modello senza correzione sottostimerebbe sensibilmente la luce disponibile. Al contrario, a mezzogiorno estivo con sole alto ma cielo coperto, il modello originale sovrastimerebbe. La correzione riduce l’errore in entrambe le direzioni, senza aggiungere nessun parametro da calibrare.

A questo si aggiunge un componente indiretto (luce diffusa dal cielo e riflessa dalle superfici):

E_{ind} = E_{ext} \cdot DF_{ind}

dove $DF_{ind}$ è un fattore di daylight indiretto, calibrato empiricamente in base all’ambiente.

In Jinja2 per Home Assistant, per la finestra del mio soggiorno orientata a sud (azimuth 180°), nel mio appartamento a Milano:

{% set lux_ext = states('sensor.luminanza_esterna') | float / 10 %}
{% set elev_deg = state_attr('sun.sun','elevation') | float %}
{% set azimut_sun = state_attr('sun.sun','azimuth') | float %}

{% set azimut_window = 180 %}
{% set tilt_deg = 90 %}

{% set elev_rad = elev_deg * 3.14159 / 180 %}
{% set tilt_rad = tilt_deg * 3.14159 / 180 %}
{% set delta_raw = (azimut_sun - azimut_window) | abs %}
{% set delta_azimut = [delta_raw, 360 - delta_raw] | min %}
{% set delta_azimut_rad = delta_azimut * 3.14159 / 180 %}

{% set cos_theta =
  (sin(elev_rad) * cos(tilt_rad)) +
  (cos(elev_rad) * sin(tilt_rad) * cos(delta_azimut_rad)) %}
{% set cos_theta = [cos_theta, 0] | max %}
{% set fc = states('sensor.tomorrow_io_casa_cloud_cover') | float / 100 %}
{% set cos_theta = (1 - fc) * cos_theta + fc * 0.5 %}

{% set tau_g = 0.18 %}
{% set Af = 2.7 %}
{% set A_room = 25 %}
{% set DF_indiretto = 0.005 %}

{% set lux_diretto = lux_ext * tau_g * cos_theta * (Af / A_room) %}
{% set lux_indiretto = lux_ext * DF_indiretto %}
{{ (lux_diretto + lux_indiretto) | round(0) }}

Un dettaglio non banale: il calcolo di delta_azimut deve usare la distanza angolare minima sul cerchio, non il valore assoluto della differenza. Senza questa correzione, una finestra orientata a nord (azimuth 0°) con il sole a 350° calcolerebbe un delta di 350° invece di 10°, producendo un coseno quasi nullo e un soleggiamento falsamente azzerato.

La correzione è sintetizzata in questa parte di codice:

{% set delta_raw = (azimut_sun - azimut_window) | abs %}
{% set delta_azimut = [delta_raw, 360 - delta_raw] | min %}

L’illuminamento totale della stanza

Il soleggiamento è solo metà dell’equazione. L’altra metà è la luce prodotta dalle sorgenti artificiali. Io ho diverse lampadine Philips Hue dimmerabili che dichiarano esplicitamente 806 lm, quindi:

E_{lamp} = \frac{lm \cdot (brightness / 255)}{A_{room}}

La linearità brightness → lumen è un’approssimazione (i LED non sono perfettamente lineari), ma sufficiente per questo scopo.

Per le striscie LED prese su Aliexpress, invece, ho usato un modello linearizzato che tiene conto delle caratteristiche (approssimate a dir poco) del dispositivo. A titolo d’esempio, per la striscia LED che illumina la mia zona pranzo (2 m di COB, per un totale di 960 LED CRI90, alimentati a 24VDC → ~15 W/m) la stima del flusso luminoso sarà:

\Phi_{LED} = 2 \, m \times 15 \, W/m \times 93 \, lm/W \approx 2800 \, lm

In generale e per qualsiasi tipologia di striscia LED, una volta ricavata la potenza assorbita dal dispositivo, non dovrebbe essere difficile risalire al flusso luminoso emesso (purché, ripeto, ci si accontenti della semplificazione lineare).

Il sensore finale sensor.illuminamento_soggiorno somma tutti i contributi:

{% set area_stanza = 25 %}
{% set lumen_per_lampadina = 806 %}
{% set lumen_led_tavolo = 2800 %}

{% set lux_sol = states('sensor.soleggiamento_soggiorno') | float %}

{% set lux_lamp_1 = (lumen_per_lampadina * (state_attr('light.lampadina_soggiorno_1', 'brightness') | float / 255) / area_stanza) if is_state('light.lampadina_soggiorno_1', 'on') and state_attr('light.lampadina_soggiorno_1', 'brightness') is not none else 0 %}
{% set lux_lamp_2 = (lumen_per_lampadina * (state_attr('light.lampadina_soggiorno_2', 'brightness') | float / 255) / area_stanza) if is_state('light.lampadina_soggiorno_2', 'on') and state_attr('light.lampadina_soggiorno_2', 'brightness') is not none else 0 %}
{% set lux_lamp_3 = (lumen_per_lampadina * (state_attr('light.lampadina_soggiorno_3', 'brightness') | float / 255) / area_stanza) if is_state('light.lampadina_soggiorno_3', 'on') and state_attr('light.lampadina_soggiorno_3', 'brightness') is not none else 0 %}
{% set lux_lamp_4 = (lumen_per_lampadina * (state_attr('light.lampadina_soggiorno_4', 'brightness') | float / 255) / area_stanza) if is_state('light.lampadina_soggiorno_4', 'on') and state_attr('light.lampadina_soggiorno_4', 'brightness') is not none else 0 %}
{% set lux_lamp_ingresso = (lumen_per_lampadina * (state_attr('light.lampadina_ingresso', 'brightness') | float / 255) / area_stanza * 0.75) if is_state('light.lampadina_ingresso', 'on') and state_attr('light.lampadina_ingresso', 'brightness') is not none else 0 %}
{% set lux_led_tavolo = (lumen_led_tavolo * (state_attr('light.led_tavolo', 'brightness') | float / 255) / area_stanza) if is_state('light.led_tavolo', 'on') and state_attr('light.led_tavolo', 'brightness') is not none else 0 %}

{{ (lux_sol + lux_lamp_1 + lux_lamp_2 + lux_lamp_3 + lux_lamp_4 + lux_lamp_ingresso + lux_led_tavolo) | round(0) }}

La lampadina dell’ingresso ha una particolarità: riceve, infatti, un coefficiente di abbattimento (spillover) di 0.75 perché illumina un’area attigua e non contribuisce esclusivamente al soggiorno.

Quanta luce artificiale serve? Un controllo feedforward

La letteratura ergonomica indica 300–500 lux come range ottimale per il lavoro al videoterminale (norma UNI EN 12464-1, che, tra le altre cose, è una vera miniera di idee per possibili espansioni di questo modello). Ho scelto 400 lux come target default, regolabile tramite un helper input_number, così da facilitare eventuali fine tuning successivi.

Dirò una ovvieta, ma ci tengo a far notare che questo non è un sistema retroazionato in senso stretto. In un vero sistema a ciclo chiuso si misurerebbe l’illuminamento effettivo della stanza con un sensore fisico, si calcolerebbe l’errore rispetto al target, e si userebbe quell’errore per correggere l’intensità delle sorgenti luminose. Qui invece l’illuminamento reale non è mai misurato e non entra mai nel calcolo (che, poi, era la premessa dell’articolo!): si misura solo la perturbazione (la luce naturale stimata), e si usa un modello del processo (i lumen noti delle lampade) per calcolare preventivamente l’azione correttiva. È un controllo feedforward: efficiente e senza oscillazioni, ma che non si autocorregge se il modello è impreciso.

Qui c’è solo algebra: se la luce naturale copre già 200 lx, ho bisogno di altri 200 lx artificiali. Conoscendo il flusso massimo producibile dalle sorgenti disponibili ($E_{max,art} \approx 249 \, lx$ a piena potenza), la brightness necessaria è:

brightness\% = \min\!\left(100, \frac{\max(0,\; E_{target} - E_{naturale})}{E_{max,art}} \times 100\right)

A questo punto nond dovrebbe essere complicato realizzare una automazione che si adatti alle specifiche esigenze di ognuno. Il mio consiglio è, però, quello di utilizzare, all’interno dell’automazione delle variables, per praticità:

variables:
  lux_target:   "{{ states('input_number.smartworking_target_illuminamento') | float }}"
  lux_naturale: "{{ states('sensor.soleggiamento_soggiorno') | float }}"
  lux_gap:      "{{ [lux_target - lux_naturale, 0] | max }}"
  lux_max_art:  "{{ (4 * 806 + 2800 + 806 * 0.25) / 25 }}"
  brightness_pct: "{{ ([lux_gap / lux_max_art * 100, 100] | min) | round(0) | int }}"

Ad oggi l’aggiunta delle variables è, credo, ancora prerogativa del codice Yaml. Bisogna, quindi, passare a questa modalità durante la stesura dell’automazione per inserirle. Poi, si puòà tranquillamente tornare in modalità visuale e riprendere il lavoro.

Convivenza con Adaptive Lighting

Ho già Adaptive Lighting attivo sul soggiorno, che gestisce la temperatura colore in funzione della posizione del sole, e ti consiglio di fare lo stesso…è davvero divertente! Il fatto, però, è che l’integrazione può gestire anche la brightness, ma per lo smartworking questo crea un conflitto: AL vuole abbassare la luminosità al mattino presto o alla sera, mentre il compensatore feedforward vuole alzarla.

La soluzione è disabilitare temporaneamente il controllo brightness di AL durante le ore di smartworking, lasciandogli solo il controllo della temperatura colore:

sequence:
  - action: switch.turn_off
    target:
      entity_id: switch.adaptive_lighting_adapt_brightness_adaptive_zona_giorno
  - action: light.turn_on
    data:
      brightness_pct: ""
    target:
      entity_id:
        - light.luci_soggiorno
        - light.led_tavolo
        - light.lampadina_ingresso

Al termine dell’orario di lavoro, o se la luce naturale diventa sufficiente, AL riprende il controllo completo. Anche questo può essere fatto tramite una automazione che viene invocata al cambiamento di stato di una entità di tipo Scheduler.

Limiti del modello e sviluppi futuri

Il sistema funziona bene, ma ci sono alcune approssimazioni di cui è bene essere consapevoli:

Ombreggiamento da edifici: la formula non considera edifici o ostacoli che bloccano il sole a certe ore. Se il palazzo di fronte proietta ombra sulla finestra dal primo pomeriggio, il modello sovrastima il soleggiamento. In linea di principio è possibile costruire un modello di occlusione degli ostacoli a partire dai dati di OpenStreetMaps, ma più come curiosità scientifica. I dati cartografici OSM, infatti, pur avendo quasi sempre i dati planimetrici degli edifici, mancano spesso dei dati di altezza, quindi il modello risultante avrebbe scarsa utilità pratica. Il modello di ray tracing sarebbe, quindi, bidimensionale: basterebbe, se le sorgenti luminose fossero basse sull’orizzonte, ma chiaramente avendo a che fare con il sole l’approssimazione non regge più.
Latenza meteo: sensor.luminanza_esterna potrebbe aggiornarsi con frequenza limitata. L’integrazione Tomorrow.io che utilizzo cattura i cambi di copertura nuvolosa esplicitamente da un sensore del tipo sensor.tomorrow_io_casa_cloud_cover, che si aggiorna più spesso, ma un ritardo residuo rimane durante i transitori veloci — per esempio, una nuvola solitaria che transita davanti al sole nel giro di pochi minuti.
Linearità brightness/lumen: i LED dimmerabili non hanno una curva perfettamente lineare. Per una stima più precisa si potrebbe usare una curva gamma, ma la differenza pratica è trascurabile per questo scopo.
E, ovviamente, parte dall’assunto (super semplicistico) che la volta celeste sia isotropa.

Nonostante questi limiti, il risultato è un sistema che si comporta in modo fisicamente coerente e che migliora misurabilmente il comfort visivo durante le ore di lavoro, senza richiedere alcun intervento manuale o un sensore esterno.

La quantità di moto e l'impulso (fisica classica)

Sat, 08 May 2021 00:00:00 +0200

Come quasi tutti ricorderanno dalla fisica studiata a scuola, Newton ci ha insegnato che la quantità di moto è una grandezza vettoriale data dal prodotto della massa del corpo per la sua velocità e si indica con p:

\vec{p} = m\vec{v}

e si misura, di conseguenza, in $[kg][m]/[s]$ . Viene, talvolta, anche chiamato momento lineare anche se, tecnicamente, non si tratta del momento di un vettore. Questa dicitura è un anglicismo dovuto al fatto che la quantità di moto in inglese è chiamata momentum. E questa è una prima causa di confusione, dato che in italiano il momento meccanico, o coppia di forze, è un concetto totalmente distinto (e che, in inglese, si dice moment o torque, appunto). È una grandezza vettoriale che ha direzione e verso del vettore velocità e modulo pari al modulo della velocità moltiplicato per la massa (che è una grandezza scalare sempre positiva).

Dalla meccanica classica, sappiamo che un corpo in movimento imprime una forza sul corpo che tenti di fermarlo. Tanto maggiori sono la massa e la velocità del corpo in movimento, tanto maggiore è la forza impressa. Per questo motivo un proiettile, che pur avendo inerzia ridotta per via della sua piccola massa, ma gran velocità, quando colpisce una piccola area di tessuto trasferisce una forza tale da generare molti danni (ma non abbastanza da far sbalzare violentemente il corpo del cattivo sulla vetrata retrostante così da farlo precipitare su una inferriata appuntita, come si vede nei film d’azione). Ugualmente, urtare contro un camion di grande massa, anche se si muove lentamente, ci provocherà ben più di un mal di testa.

Ebbene, questo fenomeno è ben espresso dalla quantità di moto che, in effetti, per la seconda legge della dinamica, può essere espressa anche in $[N][s]$ e quindi rappresentare la forza trasferita per unità di tempo.

Ma qual’è questa forza impressa?

Per rispondere a questa domanda, supponiamo che un corpo di massa $m$ e avente velocità iniziale $v_i$ subisca una forza per un intervallo di tempo t durante il quale ha un’accelerazione che lo porta alla velocità finale $v_f$ (ignoriamo tutti gli effetti di attrito sul sistema): Abbiamo quindi le quantità di moto iniziale

\vec{p_i} = m\vec{v_i}

e finale

\vec{p_f} = m\vec{v_f}

Pertanto, la variazione per unità di tempo della quantità di moto sarà:

\frac{\vec{p_f} - \vec{p_i}}{t} = \frac{m\vec{v_f} - m\vec{v_i}}{t} = m\frac{\vec{v_f} - \vec{v_i}}{t}

Passando alle variazioni infinitesime

\frac{d\vec{p}}{dt} = m\frac{d\vec{v}}{dt}

Poiché la variazione di velocità nell’intervallo di tempo infinitesimo rappresenta l’accelerazione, al secondo membro possiamo sostituire con la forza $\vec{F}$ e quindi:

\vec{F} = \frac{d\vec{p}}{dt}

Ovvero, la forza che agisce su un corpo produce una variazione della quantità di moto dello stesso. È una formulazione più generale della seconda legge del moto che tiene conto anche delle situazioni in cui la massa del corpo in moto varia, come ad esempio un razzo lanciato verso lo spazio, che brucia carburante riducendo la sua massa complessiva.

In questo caso, il secondo principio della dinamica andrebbe più correttamente scritto in forma differenziale (derivata della quantità di moto rispetto al tempo):

\vec{F} = \frac{d\vec{p}}{dt}

dove la variazione della quantità di moto può rappresentare una variazione di velocità, di massa, o entrambe. Se la massa non varia, essa è costante rispetto alla derivazione per il tempo:

\vec{F} = m\frac{d\vec{v}}{dt} = m\vec{a}

che è quanto già sappiamo.

L’impulso

L’impulso è un’altra grandezza molto utile in fisica classica: rappresenta la quantità di moto effettivamente trasmessa da un corpo all’altro a seguito di un urto o, più in generale, gli effetti di una forza che agisce per un intervallo di tempo molto piccolo rispetto all’intero fenomeno osservato (sarebbe più corretto dire che un urto tra due corpi rigidi comporta l’intervento di una forza impulsiva). Ad esempio, un tennista che colpisce una pallina durante il servizio, imprime alla stessa una forza molto intensa e vi trasferisce una grande quantità di moto in un intervallo molto breve. Oppure la polvere da sparo che, esplodendo, causa l’espulsione del proiettile ad alta velocità dalla canna della pistola in pochi centesimi di secondo, e così via.

Poiché le forze di questo tipo non sono costanti nel tempo, pur agendo per intervalli di tempo molto piccoli, in questi casi, più che con il secondo principio della dinamica è conveniente lavorare con una quantità che è il prodotto tra la forza agente e l’intervallo in cui agisce. L’impulso, appunto.

\vec{I} = \vec{F}\Delta t

Questa grandezza, come si può vedere, si misura in [N][s], come la quantità di moto. Rappresenta, come dicevamo, la quantità di moto trasmessa da una cosiddetta forza impulsiva. Questo è l’enunciato del cosiddetto teorema dell’impulso:

\vec{I} = \Delta \vec{p}

Quando la forza varia nel tempo, ha variazioni infinitesime:

\vec{F} = \frac{d\vec{p}}{dt}

Integrando ambo i membri nell’intervallo di azione della forza abbiamo l’impulso:

\Delta p = \int_{t_1}^{t^2} Fdt

Che cos'è l'elettronvolt

Thu, 06 May 2021 00:00:00 +0200

L’elettronvolt (simbolo eV) è un’unità di misura dell’energia particolarmente adatta, per via del suo valore, a misurarne i valori su scale atomiche e subatomiche. In pratica, esso coincide con il lavoro compiuto dalla forza elettrostatica agente su un elettrone che si muove nel vuoto in un campo elettromagnetico quando la particella si sposta da un punto iniziale e finale aventi differenza di potenziale di 1 Volt. È, quindi, l’energia cinetica guadagnata (o persa) dall’elettrone accelerato dal campo caratterizzato da quel potenziale.

Poiché il lavoro del campo elettromagnetico è dato dal prodotto del potenziale per la carica e la carica dell’elettrone è pari a $e = 1,602\times10^{-19}C$ :

1V = \frac{1J}{1C} \Rightarrow 1eV = \frac{1J}{1C}(1,602\times10^{-19}C) = \boxed{1{,}602\times10^{-19}\,\text{J}}

Ricordando come 1 J sia il lavoro compiuto da una forza per spostare una massa di 1kg per un metro (o in alternativa di sollevare a 1m di altezza una massa di poco più di 100gr soggetta alla gravità terrestre), ne consegue che un elettronvolt sia una quantità di energia molto piccola. Per questo motivo, spesso si utilizza uno dei suoi multipli come il megaelettronvolt (MeV) o il gigaelettronvolt (GeV), soprattutto quando si utilizzà l’elettronvolt come unità di misura per la massa.

Ciò che, infatti, genera più spesso confusione nell’uso dell’elettronvolt è il fatto che, soprattutto in fisica delle alte energia, questo sia utilizzato anche come unità di misura per la massa. Ricorderete, infatti, che quando fu scoperto il Bosone di Higgs, i ricercatori dichiararono di averlo “trovato” all’incirca dove si aspettavano che fosse, ovvero avente una massa di circa $125 GeV/c^2$ . Cosa significa questo?

Per rispondere alla domanda, vediamo la definizione dimensionale dell’energia:

[J] = \frac{[kg][m]^2}{[s]^2}

se si divide per la dimensione della velocità $[m]/[s]$ si ottiene:

[J] = \frac{[kg][m]}{[s]}

che è la dimensione della quantità di moto. Quindi, dividendo l’energia espressa in eV per c, quello che otteniamo è effettivamente una quantità di moto espressa in eV/c.

Andando ora a dividere l’espressione ancora una volta per la velocità. Nell’equazione dimensionale rimane solo la misura della m massa. Quindi, per misurare la massa si può usare come unità di misura $eV/c^2$ .

Ma perché proprio c?

Per rispondere a questa domanda, basti ricordare l’equazione dell’equivalenza di massa-energia, ovvero la famosissima $E = mc^2$ della relatività ristretta, che esprime il legame tra la massa a riposo e l’energia, attraverso la costante rappresentata dalla velocità della luce nel vuoto. Dimensionalmente, i conti tornano: $eV/c^2$ è una massa.

Facciamo un esempio. L’equivalente in massa di 1eV è:

1eV/c^2 = \frac{1eV}{c^2} = \frac{1{,}602 \times 10^{-19}}{(2{,}99 \times 10^8)^2} = \boxed{1{,}78 \times 10^{-36}\,\text{kg}}

Ad esempio, la massa dell’elettrone:

m_e = 9,109 \times 10^{-31} kg = \frac{9,109 \times 10^{-31}}{1,78 \times 10^{-36}} = 0,511 \times 10^6 eV/c^2 = 0,511 MeV/c^2

Per creare un elettrone è quindi necessario spendere $0,511 MeV$ di energia, o, in altri termini, l’annichilimento dell’elettrone provoca l’emissione di $0,511 MeV$ di energia).

C’è da dire, infine, che soprattutto in fisica teorica, per semplificare la notazione (e i calcoli) i fisici usano un sistema di riferimento in cui la velocità della luce del vuoto c è adimensionale e pari a 1. In questi sistemi, chiaramente, l’unità di misura della massa diventa semplicemente l’eV. Quando anche la costante di Plank ridotta ħ è adimensionale e pari ad uno, anche spazio e tempo sono esprimibili con l’inverso dell’energia, cioè $eV^{-1}$ , e quindi l’elettronvolt, in questi sistemi, può esprimere anche distanze e intervalli di tempo.

Il teorema dell'energia cinetica

Wed, 06 Nov 2019 00:00:00 +0100

All’atto pratico, come l’elettromagnetismo parte dalle leggi di Maxwell, la dinamica classica parte dalle equazioni di Lagrange, che a loro volta sono semplicemente una riscrittura delle leggi di Newton in forma generale e universale, cioè che non dipende dal sistema di riferimento e di coordinate (es. cartesiane o polari), ottenibile mediante la derivazione di un’unica funzione scalare, chiamata appunto lagrangiana.

Questo aspetto, attraverso la formulazione hamiltoniana che ne deriva e che vedremo successivamente, è essenziale in meccanica quantistica perché mette in luce il formalismo algebrico della cinematica e della dinamica, formalismo utilizzato più volte nella teoria. Quindi ci tocca sbatterci un po’ la testa, temo.

Ma prima di cominciare, ci serve qualche nozione iniziale.

Partiamo da Newton

Supponiamo di avere un sistema in cui un punto materiale si muove, rispetto ad esso, di moto rettilineo uniforme. In questo sistema, più specificatamente chiamato sistema di riferimento inerziale vale la legge di Netwon che ne regola il movimento:

ma = F

e, più in generale con N punti materiali vale per ognuno:

m_ka_k = F_k (k=1,\dots N)

Poiché l’accelerazione è la derivata seconda della posizione, ne consegue che la legge di Newton non è una equazione qualunque, ma è una equazione differenziale di secondo ordine dove l’incognita è x(t) e dove vi compare, nell’equazione anche attraverso le sue derivate:

\dot{x}(t) = \frac{dx}{dt}(t), \ddot{x}(t) = \frac{d^2x}{dt^2}(t)

che ci consentono di esprimere l’equazione di Newton in forma esplicitamente differenziale:

\ddot{x}(t) = \frac{1}{m}F(x, \dot{x}, t)

Il principio di determinismo che regola la meccanica classica ci consene di scrivere che, assegnata una forza F, ogni soluzione dell’equzione di Newton è univocamente individuata dalle condizioni iniziali del sistema.

x(0) = x_0, \dot{x} = v_0

ovvero la posizione e la velocità iniziale a $t_0$ .

Il motivo per cui Newton ritenne che il moto fosse determinato dalla posizione e dalla velocità iniziali è dovuto al fatto che l’equazione fosse descrivibile mediante sviluppo in serie e, pertanto, come soluzione di certe equazioni differenziali con particolari scelte dei dati iniziali (per i quali è anche possibile estrarre il relativo ritratto)). È il teorema di Cauchy-Kowalewska, ma avrò pietà e non lo approfondiremo in questa sede. Piuttosto,c ominciamo a parlare di energia.

Il teorema dell’energia

Supponiamo di avere un sistema composto da un unico punto materiale soggetto a una forza F(x, v, t), ovvero genericamente dipendente dalla velocità, dalla posizione nello spazio e dal tempo. Il teorema dell’energia cinetica afferma che l’energia cinetica posseduta da un corpo è pari all’energia cinetica iniziale più il lavoro compiuto da una forza che agisce sul corpo stesso lungo una determinata traiettoria.

In termini meccanici, l’energia cinetica T è espressa come:

T = \frac{1}{2}mv^2 = \frac{1}{2}mv v

che, derivato rispetto al tempo,

\frac{d}{dt}\frac{1}{2}m(v v) = 2v m\frac{dv}{dt} = ma \Rightarrow

\dot{T} = F v \tag{*}

La detivata $\dot{T}$ dell’energia rappresenta la potenza della forza mentre la forma integrale

T(t_1) - T(t_0) = \int_{t_0}^{t_1} Fv dt \tag{**}

è il lavoro della forza.

Quindi, come volevasi dimostrare, le due forme (*) e (**), ovvero le forme differenziale e integrale dell’espressione, ci consentono di affermare che:

Il tasso di variazione dell’energia cinetica è pari alla potenza della forza;
La variazione netta dell’energia cinetica è pari al lavoro della forza.

Ovviamente stiamo assumendo che (come avviene nella stragrande maggioranza dei casi) la massa m sia costante; per la legge di Newton, la forza impressa sul corpo ne farà variare solo la velocità.

Supponiamo che sul corpo agisca una forza posizionale; non, quindi, una generica forza $F(x, v, t)$ , ma una forza che dipende solo dalla posizione nello spazio in cui è applicata $F = F(x)$ . Poiché la foza permea, con la sua distribuzione, tutto lo spazio genera, appunto, un campo vettoriale di forze (ovvero una legge che assegna una forza meccanica ad ogni punto dello spazio).

In questa circostanza, l’integrale in (**) dipende solo dalla traiettoria seguita dal punto materiale nell’intervallo di tempo $t_0, t_1$ ; chiamiamo questa traiettoria $\gamma$ .

T(t_1) - T(t_0) = \int_{\gamma}{F(x) dx}

(perché data la funzione di movimento $x = x(t)$ , all’incremento infinitesimo si ha $dx = vdt$ ).

Se il campo di forze oltre a essere posizionale è conservativo, si dice che la funzione ammette potenziale, cioè che esiste una funzione $V(t)$ tale che

F = -gradV \Rightarrow F_x = -\frac{dV}{dx}, F_y = -\frac{dV}{dy}, F_z = -\frac{dV}{dz}

La funzione V è chiamata energia potenziale e il campo è definito conservativo perché in queste condizioni vale la legge di conservazione dell’energia (o Teorema dell’Energia) che dice che, chiamata energia la quntità

E = T + V

(cioè la somma di energia cinetica e potenziale)

per un qualunque movimento $x = x(t)$ soluzione dell’equazione di Newton $ma = F$ , si ha

\dot{E} = 0

Questo è vero nella misura in cui

Fv = -\frac{dV}{dt} \frac{dx}{dt} = -\frac{dV}{dt} = -\dot{V}

Sostituendo nel teorema dell’energia cinetica visto a inizio paragrafo

\dot{T} = Fv \Rightarrow \dot{T} = -\dot{V} \Rightarrow

\frac{d}{dt}(T + V) = 0

Per come è formulato, il Teorema dell’Energia vale per forze che variano nello spazio con legge x(t) ed è, inoltre, una legge invariante. Al variare del sistema di riferimento inerziale considerato, infatti, variano le espressioni per l’energia, ma il suo gradiente complessivo è sempre identicamente nullo, così come può variare l’espressione per il lavoro, ma esso rappresenta, sempre e in ogni sistema, l’energia trasferita da un corpo a un altro attraverso l’applicazione di una forza.

Le costanti di moto

L’energia, essendo una quantità dinamica, è una funzione definita nello spazio degli stati $E = E(x, v)$ e, poiché, in ogni punto dello spazio degli stati passa un unico vettore (originato dalle condizioni iniziali $$ x_0, v_0) che è soluzione dell’equazione di Newton, allora si può esplicitare la dipendenza

E(t) = E(x(t), v(t))

che, derivata rispetto al tempo ricordando che $E = T(v) + V(x)$

\dot{E} = \frac{dT}{dv}a + \frac{dV}{dx}v = mva - Fv = v(ma - F) = 0

(il valore della precedente è zero perché ci muoviamo nel luogo delle soluzioni dell’equazione di Newton)

Le variabili dinamiche che godo di questa proprietà di invarianza rispetto a un movimento (in un sistema inerziale) sono dette costanti di moto. L’energia E, che mantiene inalterato il proprio valore lungo qualsiasi movimento $x = x(t)$ che sono soluzioni dell’equazione di Newton è, evidentemente, una di esse.

Costanti di moto e ritratti in fase

Come abbiamo detto in un precedente articolo, il ritratto in fase “fotografa” la dinamica del sistema (x, v) a partire dalle diverse condizioni iniziali $(x_0, v_0)$ . Questi valori iniziali, a loro volta, determinano un valore iniziale invariante di energia $E_0$ , tant’è che il principio di conservazione dell’energia fa riferimento proprio a questo valore iniziale di energia, ovvero

E = T + V = E_0

Questo significa che i movimenti nel ritratto in fase sono distribuiti in “fogli” stratificati sui diversi livelli di energia iniziale, invariante, $E_0$ . Per questo motivo, queste superfici sul diagramma delle fasi sono chiamate superfici di livello dell’energia.

Ora, non voglio insistere nella trattazione di argomenti di meccanica, ma questo formalismo razionale ci sarà utile in ambito hamiltoniano. Che, a sua volta, ci consente di trovare una correlazione nel corrispettivo concetto quantistico, tutt’altro che intuitivo.

Prendete, quindi, questo articolo come un ostico, ma utile, approfondimento formale per meglio capire i concetti che verranno in seguito. E possiate perdonarmi!

Lo spazio degli stati

Thu, 31 Oct 2019 00:00:00 +0100

Supponiamo di voler studiare la dinamica di un sistema inerziale composto da un singolo punto materiale in moto nello spazio. In quanto tale, suddetto punto e soggetto alla legge del moto di Newton:

ma = F

La dinamica di questo sistema inerziale è rappresentata dal movimento del punto materiale, ovvero l’incognita è rappresentata dalla posizione del punto nel tempo:

x = x(t)

Il che ci porta a concludere che la legge di Newton non solo è una equazione funzionale, ma è anche una equazione differenziale ordinaria di secondo ordine, perché l’incognita (la posizione) vi compare con il termine di derivata seconda (l’accelerazione, ricordando che $a(t) = \ddot{x(t)})$ ). In quanto tale, risolverla analiticamente è quasi sempre molto complicato e in ogni caso dipende molto dalla complessità del sistema.

Poiché ogni soluzione dell’equazione di Newton è individuata da una coppia di vettori (e dalle rispettive condizioni iniziali di posizione $x_0$ e velocità $v_0$ ), l’intera dinamica del sistema è descrivibile come l’insieme di tutte le coppie ordinate {x, v}, che individuano uno spazio vettoriale in $\mathbb{R}^3 \times \mathbb{R}^3$ . Lo spazio generato da questo prodotto cartesiano descrive ogni possibile stato dinamico del sistema e prende il nome, per l’appunto, di spazio degli stati o spazio delle fasi.

Nel caso specifico, fissata una forza F come una ben definita funzione delle condizioni iniziali e, genericamente, dal tempo t, ovvero F(x, v, t), esiste una e una sola soluzione all’equazione di Newton che al tempo iniziale $t_0$ parte da un punto ${x_0, v_0}$ dello spazio delle fasi e che determina l’evoluzione futura del sistema lungo t secondo le leggi della meccanica (l’equazione differenziale del moto).

L’evoluzione del sistema altri non è che una successione di punti nello spazio delle fasi o, se il sistema è continuo, una curva avente come tangente in ogni punto il vettore le cui componenti sono i due vettori {x, v} al variare di t.

Questo consente di poter visualizzare lo spazio degli stati in un diagramma chiamato ritratto di fase in cui andare a disegnare tutte le possibili traiettorie del sistema (in che stato il sistema evolverà al variare di t) e definirne qualitativamente le peculiarità.

Ma forse è il caso di fare un esempio.

Il pendolo ideale

Innanzitutto una precisazione. Il concetto di ritratto di fase è del tutto generale e non è legato necessariamente a un sistema meccanico (descritto dalle equazioni del moto di Newton), ma può essere utilizzato su sistemi dinamici di qualsiasi natura e con un numero qualsiasi di dimensioni.

Nulla vieta, per capirci, di descrivere un sistema attraverso l’uso di N variabili, anche infinite, e relative condizioni iniziali in modo da individuare uno spazio di fase in $\mathbb{R}^N \times \mathbb{R}^N$ . Né siamo costretti a utilizzare vettori reali (in meccanica quantistica, ad esempio, quei vettori sono complessi).

Il problema, più che altro, sta nell’efficacia della rappresentazione di uno spazio degli stati quando la dimensionalità del sistema dinamico cresce.

Tuttavia, in meccanica classica la dinamica è espressa dalle variabili posizionali e dai loro gradienti (più spesso si usa il momento in luogo della velocità, ma la sostanza non cambia perché il momento $p = mv$ ). Per essere pratici, useremo perciò nel nostro esempio un sistema meccanico caratterizzato da un movimento in una dimensione, così da avere un diagramma di fase facilmente visualizzabile in un piano cartesiano con la posizione sull’asse delle ascisse e il relativo gradiente sull’asse delle ordinate.

Il pendolo ideale si adatta bene allo scopo.

Supponiamo di esprimerne la posizione come l’angolo che forma con il proprio asse verticale $\theta$ , quindi in uno spazio in $\mathbb{R}$ , e il gradiente attraverso la velocità angolare $\dot{\theta}$ .

L’equazione che ne regola il moto armonico è le seguente:

\ddot{\theta} = -\frac{g}{l}sin\theta

Nell’immagine in basso, possiamo vedere i vari stati che assume il pendolo, in termini di coppie di angolo $\theta$ e velocità angolare $\dot{\theta}$ , fissate delle condizioni iniziali per $\theta_0$ e $\dot{\theta_0}$ . L’oscillazione del pendolo da destra verso sinistra (per poi tornare indietro) descrive una traiettoria di transizioni di fase che nel ritratto di fase disegna una circonferenza.

Andamento nel tempo e rappresentazione di stato del pendolo ideale scelta una coppia di condizioni iniziali. Si dice ideale in quanto, nel sistema di riferimento inerziale preso in esame, si considerano nulle le forze di attrito. Il pendolo, insomma, continuerà a muoversi all’infinito di moto armonico sul piano xy.

Di fatto, note le condizioni iniziali ed i vettori che determinano le transizioni di stato al variare di t, possiamo prevedere l’evoluzione del sistema e quindi il suo futuro. È il concetto base del determinismo laplaciano, che però studieremo nel dettaglio in uno dei prossimi articoli.

Se, però, non fissiamo una coppia di condizioni iniziali, i vettori di tutte le possibili transizioni di stato vanno a costruire un campo vettoriale che descrive tutti gli stati possibili del sistema: il ritratto di fase vero e proprio. Non offre una soluzione analitica dell’equzione differenziale che regola il moto del sistema (cosa che pure sarebbe stata possibile calcolare nell’esempio specifico del pendolo, ma che in genere è estremamente complicata), ma offre una buona vista di sintesi ed enfatizza la presenza di regioni particolari. Vediamole:

Interpretazione del diagramma

Le traiettorie disegnate rappresentano sette possibili evoluzioni del sistema a partire da altrettante condizioni iniziali, che, ricordiamo, sono i “punti di partenza” e sul diagramma sono rappresentate dai cerchietti. Si notano subito tre regioni particolari:

Le traiettorie in arancione sono caratterizzate da un gradiente di velocità angolare che a un certo punto cambia segno. È il comportamento che subito associamo a un movimento pendolare: il peso che oscilla in avanti fino ad un angolo $\theta_{max}$ (la distanza percorsa nella direzione delle ascisse $\theta$ aumenta), riducendo progressivamente la sua velocità angolare (la traiettoria curva avvicinandosi all’asse delle ascisse) per poi, quando la velocità è zero, tornare indietro. Lo stesso movimento si ha nel verso opposto e così via, con oscillazioni infinite.
Le traiettorie in blu sono caratterizzate da velocità angolari iniziali sufficienti per far girare il pendolo su se stesso (attorno al proprio vincolo). Il pendolo oscilla, perde progressivamente velocità, ma la velocità non è nulla quando $\theta = 180°$ , quindi comincia a cadere nella direzione opposta, riprendendo velocità che ha il suo massimo quando $\theta = 0$ per poi ricominciare. La velocità, infatti, non è mai nulla (la traiettoria non interseca mai l’asse delle ascisse).
Le traiettorie in rosso sono gli unici due punti di equilibrio del sistema, che si hanno quando il pendolo ha velocità angolare iniziale nulla e giace sul suo asse in posizione di riposo (con $\theta = 0$ ma anche con $\theta = 180°$ ).

Il tutto si ripete con periodicità $2 \pi$ .

In definitiva dovrebbe essere chiaro il funzionamento di questa rappresentazione e come può essere utile per studiare l’evoluzione dinamica di un sistema, una volta che se ne è determinata la sua rappresentazione in termini di sistema di equazioni differenziali ordinarie.

Giacché non abbiamo risolto suddette equazioni, ne fornisce solo una vista approssimata, eppure la soluzione analitica non avrebbe evidenziato le differenti regioni dinamiche del sistema in modo tanto lampante.

Certo, al crescere dell’ordine del sistema, la visualizzazione diventa complessa e inefficace, per non dire impossibile. Resta, tuttavia, uno strumento prezioso anche per visualizzare mentalmente come un sistema evolve e per spiegare come la sua dinamica è descritta da vettori in un campo. Questo concetto, tra l’altro, risulta essenziale nello studio della Meccanica Quantistica, oltre che ovviamente in Meccanica Razionale.

Prossimamente faremo qualche esempio pratico di realizzazione di ritratti di fase tramite R, visto che esiste un package semplice e intuitivo adatto allo scopo. Alla prossima!

Stati di Spin

Mon, 28 Oct 2019 00:00:00 +0100

Negli articoli precedenti, abbiamo definito lo spazio degli stati di un sistema quantistico come un sistema vettoriale composto da vettori complessi e, come tale, caratterizzato da una direzione, un modulo e un verso (anche se intesi non in senso spaziale). Abbiamo anche visto che una certa impredicibilità è tipica di un sistema quantistico e che la misura stessa, per quanto infinitamente gentile, altera (anzi, come abbiamo detto, prepara) il sistema.

Appurato che i vettori di stato predicono in modo perfettamente deterministico ciò che si può conoscere di un sistema (che, però, non è tutta l’informazione contenuta in un sistema; questo, per via del principio di indeterminazione), abbiamo tutti gli elementi per studiare un sistema concreto.

Quello più facile: uno spin singolo

Introduzione allo spin

Innanzitutto è bene fare una precisazione: quando parliamo di sistema di spin singolo parliamo proprio di uno spin, ovvero una caratteristica intrinseca delle particelle che non ha un corrispettivo nel mondo classico.

Non è quindi lo spin di un elettrone. L’elettrone è la particella subatomica che porta uno spin a spasso per l’Universo. Quindi il sistema che individuano è diverso, e più complicato, di quello (per certi versi astratto) individuato dal solo spin.

E a maggior ragione non è la componente di rotazione dell’elettrone sul proprio asse, anche se spesso si ricorre a questa analogia per meglio rappresentarlo, visto che il vettore di spin può essere visto come un momento angolare magnetico caratterizzato da tre componenti sugli assi spaziali ${x, y, z}$ .

Lo spin fu introdotto da Pauli come un’astrazione puramente matematica per descrivere il modello delle particelle quantistiche; non fu mai pensato dallo scienziato come qualcosa di reale, sperimentalmente misurabile. Anzi, quando ne fu effettivamente misurato il valore, Pauli all’inizio non era del tutto certo che la grandezza misurata fosse proprio il suo spin.

Come dicevamo, però, in questa fase ci concentriamo sull’idea astratta di spin, e in particolare sugli stati assunti dal sistema da esso individuato, non dal motivo per cui assume certi valori e non altri, né tantomeno sulla sua natura fisica.

Gli stati di spin lungo z

Prendiamo un sistema fisico spin singolo: come già assodato, esso può assumere solo due valori in corrispondenza di una misura orientata lungo l’asse $z$ (non è sempre vero per qualunque direzione, ma per ora accontentatevi), i valori sono spin up e spin down.

Alternativamente, possiamo definire che lo spin si trova in uno stato generale, composto da una sovrapposizione dei due stati di base (up e down), quindi generalizziamo:

\vert A \rangle = \alpha_u \vert u \rangle + \alpha_d \vert d \rangle

Non spaventatevi! È una notazione compatta per esprimere un concetto semplice: lo stato di spin è formato da una componente up e una componente down, ognuna pesata per un coefficiente, detto coefficiente di combinazione lineare.

Il simbolo $\vert A \rangle$ è un vettore di stato generico che chiamiamo ket A. I simboli $\vert u \rangle$ e $\vert d \rangle$ sono i vettori di stato relativi allo spin up e allo spin down.

Non è questa la sede per spiegare la notazione bra-ket, ma sappiate che è uno strumento elegante e compatto per scrivere le equazioni della meccanica quantistica.

Tornando al nostro stato generale, i coefficienti $\alpha_u$ e $\alpha_d$ sono numeri complessi che esprimono il “peso” di ciascuna componente. Il modulo quadro di questi coefficienti esprime la probabilità di trovare lo spin, durante una misura, in uno piuttosto che nell’altro stato.

Esprimiamo questa probabilità scrivendo la matrice densità dei coefficienti. Riscriviamo lo stato generale in forma vettoriale:

\mathbf{A} = \begin{bmatrix} \alpha_u \\ \alpha_d \end{bmatrix}

Naturalmente, $\vert \alpha_u \vert^2$ è la probabilità di osservare il sistema nello stato up e $\vert \alpha_d \vert^2$ è la probabilità di osservarlo nello stato down.

Poiché la somma delle probabilità deve essere 1, abbiamo:

\vert \alpha_u \vert^2 + \vert \alpha_d \vert^2 = 1

La misura dello spin

Cosa succede quando misuriamo lo spin? La risposta è in linea con i postulati della meccanica quantistica: prima della misura, il sistema si trova in uno stato di sovrapposizione. L’atto della misura “prepara” il sistema, collassandolo in uno dei due autostati.

Per calcolare la probabilità che il sistema collassi su up o down in una direzione arbitraria, non basta conoscere i coefficienti lungo z ma bisogna proiettare lo stato sul vettore relativo alla direzione di misura.

Questo non significa saperlo a priori: anche se conosciamo lo stato iniziale, non possiamo prevedere esattamente il risultato della singola misura, ma possiamo prevedere la distribuzione statistica dei risultati di tante misure.

Se lo spin è preparato nello stato up e misuriamo lungo lo stesso asse z, otterremo sempre up. Se invece misuriamo lungo un asse diverso, la probabilità sarà data, in sintesi, dall’angolo fra la direzione dello stato e la direzione della misura — proprio come in un coseno direttore.

Preparare uno stato di spin

Finora abbiamo parlato di misurare spin. Ma come si prepara uno spin in uno stato specifico?

Uno dei metodi più comuni è usare un magnete di Stern-Gerlach, che, accoppiandosi magneticamente con lo spin, lo indirizza su un percorso selettivo in base al suo valore.

Nell’esperimento di Stern-Gerlach, un fascio di particelle con spin viene fatto passare attraverso un campo magnetico non uniforme. A seconda del valore dello spin, le particelle vengono deflesse verso l’alto o verso il basso, separando così i due stati di spin e preparando il sistema in uno di essi.

Bloccando uno dei due fasci, possiamo ottenere un fascio di particelle con spin preparato nello stato desiderato. Questo è un modo per “inizializzare” lo spin in uno stato noto.

Basi ortonormali in un sistema quantistico

Mon, 21 Oct 2019 00:00:00 +0200

Chi ha un minimo di dimestichezza con l’algebra lineare conosce certamente il concetto di base di uno spazio vettoriale come l’insieme massimo di vettori mutuamente ortogonali che generano lo spazio stesso e ne determinano la dimensionalità.

Ebbene, non c’è nulla in algebra che restringa tale concetto al fatto che i suoi vettori siano reali e individuino, di conseguenza, uno spazio reale (magari tridimensionale). È assolutamente sensato generalizzare il concetto di base al campo complesso, per individuare l’intero spazio degli stati di un sistema quantistico. Tutti gli stati interni che il sistema può assumere, per intenderci.

Basi ortonormali di un sistema complesso

In maniera del tutto analoga a quanto si fa in un sistema reale, si cominciano a prendere dei vettori con modulo unitario che siano tutti tra di loro mutuamente ortogonali (che, nel campo complesso, significa prendere due vettori il cui prodotto interno sia uguale a zero. Essendo tutti questi vettori di modulo unitario, l’informazione interessante che portano in dote è la direzione che individuano.

Ebbene, continuando a prendere vettori (direzioni) ortogonali, si arriverà ad un punto in cui non è più possibile prendere altri preservando la condizione di mutua ortogonalità e saremo costretti a fermarci: i vettori presi fino a questo momento individueranno una base ortonormale e il loro numero la dimensionalità dello spazio.

La cosa interessante (sempre in perfetta analogia con i vettori reali) è che tutti i vettori dello spazio sono esprimibili come combinazione lineare degli elementi della base.

Ora, tecnicamente parlando, l’algebra non prevede che i vettori di base siano ortonormali (modulo unitario, ortogonali tra di loro), tuttavia per una serie infinita di ragioni, in meccanica quantistica normalmente lo sono. Per semplificare i calcoli, più che altro.

Basi ortonormali e meccanica quantistica

Supponiamo di avere una base ortonormale complessa di dimensione N. Esprimiamola in notazione di Dirac utilizzando un ket: $\vert i \rangle$ .

Tale base, per quanto detto, avrà $i_1 ... i_N$ componenti ortogonali tra di loro.

Consideriamo ora un generico vettore di stato A ed esprimiamolo come combinazione lineare con i componenti del vettore di base:

\vert A \rangle = \sum_{i} \alpha_i \vert i \rangle

con gli $\alpha_i$ coefficienti complessi chiamati componenti della base.

Effettuiamo ora il prodotto interno della precedente uguaglianza per un particolare vettore della base j scelto arbitrariamente tra i vettori $i_N$ della base.

\langle j \vert A \rangle = \sum_{i} \alpha_i \langle j \vert i \rangle

Poiché i vettori sono ortogonali tra di loro e hanno modulo unitario, l’equazione precedente vale 0 per qualsiasi coppia $\vert j \rangle \ne \vert i \rangle$ e vale 1 se $\vert j \rangle = \vert i \rangle$ .

La sommatoria quindi collassa a un unico termine diverso da zero:

\langle j \vert A \rangle = \alpha_j

Quindi le componenti di un generico vettore A sulla base ortonormale i sono dati dal prodotto interno del vettore stesso con la base.

\vert A \rangle = \sum_i \vert i \rangle \langle i \vert A \rangle

Questa formulazione è essenziale per poter studiare la dinamica di un sistema, ovvero come lo stato di un sistema quantistico varia nel tempo e come è possibile studiarne l’evoluzione. Lo vedremo in uno dei prossimi articoli. Alla prossima!