Una volta stabilito che KNX merita un approfondimento per il contesto considerato, la domanda non è più «perché KNX?», ma «quale comportamento deve avere questo sistema e come sarà possibile verificarlo?». La scelta preliminare della tecnologia, trattata nella guida Quando scegliere KNX, non sostituisce il progetto. Qui il metodo generale dei requisiti viene applicato alle decisioni specifiche di un sistema KNX: funzioni, comunicazioni, dispositivi, dati, interfacce e condizioni di verifica. La configurazione e le prove sul sistema realizzato appartengono invece al commissioning.
Livello tecnico · Avanzato
Dalla scelta KNX al problema progettuale
Il punto di partenza è una funzione osservabile, non un catalogo di prodotti né una schermata ETS. Per ogni funzione rilevante occorre descrivere chi la usa, quale evento la avvia, quale risultato è atteso e quali condizioni ne delimitano il funzionamento. Un comando, uno stato e un riscontro non sono intercambiabili: se l’esito deve essere conosciuto da un altro sottosistema, anche quella informazione diventa parte del requisito di comunicazione.
Questa sequenza è un metodo editoriale di progetto, non una procedura obbligatoria imposta dalle specifiche KNX. Il livello di dettaglio dipende dal rischio, dalla complessità e dagli accordi del progetto. Una decisione ancora aperta deve restare riconoscibile come tale, anziché essere nascosta in una configurazione provvisoria.
Funzioni, utenti e requisiti di comunicazione
Descrivere uno scenario significa separare comportamento atteso e mezzi per ottenerlo. Chi genera l’informazione? Quali dispositivi o sistemi devono riceverla? Serve un comando, un valore misurato, uno stato di ritorno o più di questi elementi? Quale comportamento è richiesto se un’interfaccia, una rete o una sorgente di dati non è disponibile? Queste domande delimitano il flusso informativo prima di scegliere indirizzi e parametri.
Un esempio illustrativo è il comando di una funzione di illuminazione con riscontro di stato: il progetto deve distinguere la richiesta dell’utente dal dato che conferma lo stato effettivo. L’esempio non definisce una soluzione universale né prova che ogni prodotto esponga gli oggetti necessari. Il requisito va confrontato con l’applicazione e i parametri dei prodotti considerati.
Architettura e infrastruttura
Le funzioni e i loro flussi vanno poi collocati in una struttura. Secondo la documentazione KNX della topologia in ETS, area, linea e — dove applicabile — segmento sono concetti utili a rappresentare l’organizzazione del progetto. Media, accoppiatori, alimentazioni e interfacce KNX/IP introducono confini e dipendenze che devono essere valutati nel caso concreto. Le regole e le capacità applicabili vanno verificate sulle specifiche e sui prodotti nella versione pertinente; qui non si assumono limiti numerici validi per ogni impianto.
Una topologia rappresentata correttamente non dimostra da sola prestazioni fisiche, disponibilità o comportamento in guasto. Se la continuità di una funzione conta, il progetto deve individuare le dipendenze — per esempio alimentazione, collegamenti e componenti di interfaccia — e definire il comportamento atteso in caso di indisponibilità. Interoperabilità non equivale a resilienza; un’architettura distribuita non elimina per definizione ogni punto critico.
Dal dispositivo al dato condiviso
La funzione progettata incontra prodotti e applicazioni concreti. In ETS i group object sono i punti di comunicazione esposti dall’applicazione; i parametri del dispositivo possono influire sugli oggetti disponibili e sul loro comportamento. Perciò la selezione deve considerare prodotto, versione dei dati applicativi e impostazioni pertinenti: la certificazione del prodotto non verifica la funzione richiesta nel progetto.
L’indirizzo individuale serve a identificare il dispositivo nella struttura; l’indirizzo di gruppo organizza invece la comunicazione funzionale. Il progetto deve stabilire come oggetti e indirizzi di gruppo rappresentano comandi, valori e riscontri, senza confondere identificazione del dispositivo e significato della funzione. Anche il datapoint type (DPT) è rilevante per interpretare i dati: una stessa lunghezza non dimostra lo stesso significato. La mappatura effettiva va verificata rispetto alle applicazioni e alle versioni selezionate, non dedotta dal solo nome dell’oggetto.
Confini d’integrazione e sicurezza
Quando una funzione attraversa il confine KNX, il progetto deve rendere espliciti interfaccia, dati scambiati, direzione, comportamento atteso e responsabilità. La presenza di un gateway o di KNX/IP non dimostra un’integrazione end-to-end. Questa pagina definisce il confine progettuale; la realizzazione di una piattaforma specifica, inclusa Home Assistant, richiede un approfondimento distinto. Il caso è trattato in Integrare KNX e Home Assistant: architettura e responsabilità.
Per la sicurezza la sequenza è: requisito, capacità pertinente, supporto dei prodotti scelti, configurazione prevista e futura verifica. La documentazione KNX Security distingue capacità come KNX IP Secure e KNX Data Secure; la loro disponibilità nell’ecosistema non significa che il sistema progettato sia già protetto. Vanno identificati i confini di fiducia e le responsabilità per configurazione, custodia delle informazioni necessarie e manutenzione successiva, senza inserire chiavi o segreti nella documentazione editoriale.
Progettare per verificare e mantenere
Un requisito utile al progetto deve poter essere ricondotto a un risultato atteso e a un criterio di verifica. Il criterio può riguardare una funzione, uno scambio dati, un’interfaccia o il comportamento in una condizione di guasto rilevante. Verificare che una configurazione sia coerente non coincide con verificare il comportamento dell’impianto: il Project Check offline di ETS, per esempio, non esegue una prova fisica sul bus. Allo stesso modo, un download riuscito non dimostra l’accettazione del risultato nell’edificio.
La struttura del progetto ETS, i nomi, la tracciabilità delle funzioni e la documentazione facilitano consegna e modifiche future, ma nessun formato o convenzione qui proposto viene presentato come obbligo KNX universale. Dove applicabile, il progetto chiarisce anche chi avrà accesso ai dati e quali dipendenze di versione o prodotto potrebbero condizionare manutenzione e sostituzioni. Verifica, validazione rispetto all’uso e accettazione sono momenti distinti; le relative attività operative saranno trattate nella pagina dedicata al commissioning.
Il pacchetto di handoff al commissioning
Il confine fra progetto e commissioning è una baseline di progetto verificabile. A seconda del caso può comprendere funzioni e requisiti, topologia e media, prodotti e versioni applicative selezionati, strategia degli indirizzi individuali e di gruppo, mappatura oggetti/DPT, interfacce, requisiti di sicurezza, criteri di verifica e criteri di accettazione concordati. Convenzioni ETS, documentazione, decisioni aperte e responsabilità completano il quadro quando pertinenti. Non si tratta di un pacchetto documentale identico e obbligatorio per ogni progetto KNX.
La baseline indica cosa si intende configurare e quale evidenza servirà per giudicare il risultato; non è lo stato as-commissioned. Durante il commissioning si identificano e configurano i dispositivi, si verificano comunicazioni e funzioni, si registrano risultati e scostamenti e si preparano gli elementi di consegna. Se emerge una modifica progettuale materiale, occorre ricondurla al controllo delle decisioni di progetto prima che diventi parte della nuova baseline. L’esecuzione delle prove e l’handover, a partire da questa baseline, sono trattati in Commissioning e handover KNX.
Questo articolo ha finalità informative e non definisce un progetto o un intervento per un edificio specifico. Prima di applicarne i contenuti, verifica requisiti e condizioni del caso, nonché le versioni pertinenti di norme, software, prodotti e documentazione ufficiale. Quando la decisione comporta competenze o responsabilità professionali, richiedi una valutazione qualificata.