Un gateway KNX collega due mondi di protocolli. Da ciò deriva facilmente l’ipotesi che i prodotti con la stessa combinazione di protocolli siano in gran parte intercambiabili. Proprio nel caso di DALI e Modbus, invece, è vero il contrario.

Le differenze decisive spesso non risiedono nel collegamento fisico, ma nel modello applicativo, nei tipi di dispositivi supportati, nelle strutture dei dati e nel modo in cui questi vengono mappati su KNX.

DALI-2 amplia l’universo standardizzato oltre i classici dispositivi di controllo (Control Gear) includendo i dispositivi applicativi (Control Devices). Tra questi rientrano i controller applicativi (Application Controller) e i dispositivi di input (Input Devices). I dispositivi di input possono, ad esempio, rilevare la presenza, la luminosità o la pressione dei pulsanti e comunicano solitamente in base agli eventi come partecipanti multi-master. 

Pertanto, la semplice indicazione «gateway DALI-2» non è sufficiente. Il gateway deve limitarsi a controllare apparecchi DALI-2 o deve funzionare esso stesso come controller applicativo e integrare anche dispositivi di input? Questa distinzione è fondamentale per i progetti che prevedono l’utilizzo di sensori DALI-2.

Il controller applicativo multi-master disponibile nel portafoglio Inyx, ad esempio, supporta, oltre ai reattori, anche rilevatori di movimento DALI-2 conformi alle norme, sensori di luce e interfacce a pulsante.

Lo stesso vale per Colour Control e Tunable White. Il supporto del DT8 garantisce innanzitutto che sia possibile attivare le relative funzioni DALI. Per l’integrazione KNX, tuttavia, è rilevante il modo in cui il gateway mappa queste funzioni tramite oggetti di comunicazione e parametri.

Un gateway DALI a due canali della gamma Inyx, ad esempio, supporta la temperatura di colore DT8 tramite oggetti a 2 byte e fornisce inoltre informazioni sullo stato, le ore di funzionamento, gli errori relativi a lampade e alimentatori elettronici, nonché i valori diagnostici del bus DALI.

In questo modo, un progetto che richiede solo la funzione «Tunable White» può avere requisiti diversi rispetto a un impianto in cui gli stati operativi e di errore dettagliati devono confluire in un sistema di monitoraggio di livello superiore.

Nel caso di Modbus, l’attenzione non è rivolta ai tipi di dispositivi, bensì al modello di dati del dispositivo esterno. La specifica Modbus definisce i codici funzione e gli accessi ai registri, ma non il significato concreto che i produttori attribuiscono ai propri registri.

Per l’integrazione è quindi necessario conoscere:

• Quali registri contengono i valori richiesti?
• Quali registri sono leggibili o scrivibili?
• Quale tipo di dati viene utilizzato?
• Quanti registri occupa il valore?
• Quale scala è prevista?
• Quale notazione di indirizzamento utilizza la documentazione del produttore?

Proprio l’indirizzamento è una classica fonte di errore. I telegrammi Modbus funzionano con indirizzi relativi a base zero, mentre la documentazione dei produttori utilizza spesso numeri di registro assoluti come 40001.

Un apparente «errore di offset» può quindi derivare semplicemente da rappresentazioni diverse dello stesso indirizzo.

Ogni registro Modbus è composto da 16 bit. I tipi di dati più grandi devono essere distribuiti su più registri. Un numero in virgola mobile a 32 bit richiede quindi due registri contigui.

Per un gateway KNX è quindi importante sapere quali tipi di dati la sua applicazione supporta direttamente e come questi possano essere mappati sui tipi di punti dati KNX. Un gateway con 250 canali non è automaticamente più adatto di uno con 32 punti dati, se il dispositivo più piccolo riproduce in modo corretto proprio le strutture di dati necessarie.

Inyx, ad esempio, offre sia un gateway RS485 parametrizzabile tramite ETS con 32 punti dati liberamente scalabili, sia un gateway KNX/Modbus-RTU con 250 canali configurabili, funzione master/slave e logiche aggiuntive.

La domanda rilevante non è quindi «Quanti punti dati?», ma quali punti dati, in quale struttura e con quale funzione?

Ciò assume ancora maggiore importanza quando si tratta di funzioni di scrittura. Il fatto che, ad esempio, nella documentazione Modbus sia presente un valore di setpoint non significa automaticamente che esso possa essere modificato tramite Modbus.

I codici funzione supportati e il modello di registro specifico del dispositivo esterno determinano quali valori possono essere scritti. Un gateway KNX non può generare una possibilità di regolazione che il dispositivo collegato non offra di per sé.

Pertanto, in caso di integrazione, occorre sempre considerare l’intera catena: Funzione KNX desiderata → valore del sistema esterno richiesto → possibilità di accesso → tipo di dati → mappatura del gateway.

Sia per DALI che per Modbus si presenta quindi lo stesso problema: l’indicazione del protocollo è troppo generica per la scelta. Ciò che conta sono i ruoli, i tipi di dispositivo, le strutture dei dati, gli oggetti di comunicazione e le funzioni diagnostiche supportati dal gateway specifico.

Proprio per questo vale la pena confrontare le applicazioni già prima della specifica, non solo al momento della messa in servizio.