KNXgate è un modulo di interfaccia tra il bus Konnex e una porta seriale UART a 115200 baud; è un dispositivo amatoriale autocostruito e come tale privo di qualsiasi garanzia in merito al corretto funzionamento ed interfacciamento – KONNEX è un bus “proprietario” che non è lecito replicare con dispositivi commerciali senza le dovute autorizzazioni.

Scopo del modulo è di consentire a dispositivi esterni (computers, Arduino, …) tramite porta seriale o USB di ricevere e inviare messaggi sulla rete KONNEX (accendere e spegnere luci, tapparelle, ecc...) - l'interfaccia si riferisce SOLO ai moduli di automazione, non alla trasmissione dati (citofonia, video, ecc...).

Il modulo è stato testato su di un bus Vimar BY-ME, tale sistema pur non essendo marcato “konnex” utilizza di fatto il medesimo sistema trasmissivo ed il medesimo protocollo di base.

Il firmware è aggiornabile sia tramite i programmatori standard “Microchip” con uscita ICSP (es. pickit3) sia attraverso l’interfaccia seriale/usb MCP2200 con un software apposito (windows) da me realizzato.

Al momento non sono previsti futuri rilasci, potranno esserci nuove versioni sia per miglioramenti delle funzionalità sia per richieste o segnalazioni pervenutemi.

Interfaccia KNXgate: Connessioni

                                      

 

La scheda ha 3 connettori:

-        Il connettore di destra va collegato al bus KNX rispettando le polarità indicate - in alto e + in basso (!).  Prima di collegarlo al bus controllate con un voltmetro. Il collegamento serve solo per i segnali di ingresso e uscita, non alimenta la scheda.

 

-        Il connettore centrale (TP) serve a tarare i livelli di input – se avete acquistato questo dispositivo è già tarato.  In caso contrario: con il connettore KNX collegato al bus domotico il trimmer va tarato per avere su questi pin 0,5 Volts (positivo a sinistra, negativo a destra)

 

-        Il connettore di sinistra a 6 pin serve sia a programmare il PIC che a fornire ingresso e uscita verso arduino o verso il PC:

o   Programmazione: connettore ICSP Microchip standard collegabile, ad esempio, a pickit3: 1=/reset    2=positivo 5V    3=negativo   4=PGD    5=PGC    6=

o   Arduino:  1=/reset o non collegato     2=positivo 5V (alimentare da arduino)     3=negativo    4= ingresso seriale (RX) da collegare all’uscita seriale di arduino    5= uscita seriale (TX) da collegare all’ingresso seriale di arduino    6= non usato

o   PC: la schedina di interfaccia con MCP2200 va connessa qui e provvede un’interfaccia USB verso il PC contemporaneamente all’alimentazione

Sui pin 2 e 3 del connettore di sinistra va fornita una alimentazione stabilizzata da 5V a 3,3V in caso di connessione ad arduino o ad un programmatore Microchip – invece in caso di connessione con la schedina MCP2200 l’alimentazione proviene direttamente dalla USB.

Il dispositivo va programmato almeno la prima volta con un programmatore Microchip che possa programmare PIC18F26K80 (io uso pickit3), successivamente il PIC può essere riprogrammato attraverso la connessione MCP2200 – USB con un mio programmino VB6.

 

Modello 141113 (firmware 18.4x)

Questo nuovo modello si differenzia dal precedente per non avere il trimmer di taratura ed il diodo zener.  La taratura è interna al firmware e può essere effettuata tramite appositi comandi.  Il vantaggio consiste in una migliore tolleranza di escursione termica a cui il diodo zener è soggetto.

La taratura tramite firmware è già effettuata e predisposta per l’alimentazione a 5 volt; nel caso dobbiate alimentare il dispositivo a 3,3 volt va inviato l’apposito comando di ri-taratura @3; per tornare alla taratura originale si usa il comando @5.

ATTENZIONE ! Non tutti i dispositivi sono adatti al funzionamento a 3,3 Volt – chiedete prima di acquistare.

Il test-point (TP) è stato mantenuto e può essere collegato ad un oscilloscopio per verifica. Il pin di destra deve avere un livello di circa 3 volt con bus collegato e mostrare i segnali del bus con impulsi bassi ampi circa 1 volt; il pin di sinistra emette uno spike di sincronismo per ogni impulso rilevato.

Connessione con MCP2200

Se avete comprato da me l’interfaccia MCP2200, potreste avere la versione con presa USB grande o mini. La versione con USB grande ha il connettore a 5 pin, quella con USB piccolo ha il commettore a 4 pin:

La versione con USB grande (a 5 pin) va collegata facendo combaciare il pin 1 (vedi freccia), il pin 6 di KNXGATE rimane libero.

La versione con USB piccolo (a 4 pin) va collegata facendo combaciare il proprio pin 1 con il pin 2 di KNXGATE, il pin 1 e il pin 6 di KNXGATE rimangono liberi.

 

 

Test con il PC

Può essere effettuato collegando la scheda MCP2200 come sopra descritto, al pc porta USB dall’altro.

Preliminarmente il PIC deve essere programmato (se lo avete acquistato da me è già programmato), vanno installati i driver per MCP2200 scaricabili dal sito Microchip.

Se avete autocostruito l’interfaccia MCP2200 va utilizzata l’utility di configurazione per MCP2200 per impostare la velocità di 115200 baud (non necessario se l’avete acquistata da me).

Attraverso la schedina MCP2200 collegate il dispositivo SOLO al PC: il led deve lampeggiare.

Il led lampeggia ogni secondo oppure ogni volta che sul bus KNX transitano degli impulsi.

Utilizzate un programma di comunicazione seriale (tipo Putty) a 115200 baud: aprite una sessione e digitate “@MA” (modalità ascii). Il dispositivo deve rispondere “k” (ok). Digitare “h” (minuscolo). Il dispositivo deve rispondere con una sorta di menu/help con le opzioni principali. La conversazione completa a video sarà circa così:

@MAkh

KNXgate V 18.04

@M[A|X] : modo ascii | hex

@F[0|1|2|3|4] : filtro

@D[value]: dest line/sector

@q : query version

@b : buffer clear

@r : read immed.

@R : read defer.

@c : cancel def.

@W[0-F][data] write

@w[value][destin] write

A questo punto attivate il log a video con il comando @l – il dispositivo risponde “k”. Provate ad accendere e spegnere qualche luce, a video dovreste vedere così:

 

KNX[4]: B4 10 0C 0B 15 E1 00 80 28

KNX[5]: CC

 

Le spiegazioni di quello che vedete le trovate sui documenti ufficiali konnex, riassumo brevissimamente:

B4: control byte (iniziatore del telegramma)

10: indirizzo del dispositivo che invia il telegramma (linea e settore)

0E: indirizzo del dispositivo che invia il telegramma (device)

0B: indirizzo del dispositivo di destinazione (linea e settore)

15: indirizzo del dispositivo di destinazione (device)

E1: network protocol data unit – il semibyte di destra (1) è la lunghezza dei “dati”

00: transport protocol data unit

80: dati (lunghezza sopra specificata) . 81=accendi  80=spegni

28: check byte

 

CC: è la risposta (acknowledge) del dispositivo che si è acceso o spento

 

Prendete nota del quarto byte (0B nell’esempio sopra) – è l’indirizzo di linea e settore dei vostri attuatori – se è diverso da 0B (impostato in knxgate) dovrete utilizzare il comando @D per re-impostarlo in knxgate (vedi sotto).

Prendete nota del quinto byte (15 nell’esempio sopra) – sarà diverso per ogni dispositivo che accendete o spegnete. Sui bus konnex generalmente i dispositivi non sono marcati con etichette e per leggerli dovrete loggare i comandi.

Provate ad accendere e spegnere il dispositivo con i comando “@w11D” e “@w01D” – se il dispositivo risponde siete a posto!

 

Altri brand

Un utilizzatore del mio dispositivo mi ha gentilmente fornito il log rilevato su di un impianto knx “Tebis ts”  di Hager technologies.

 

BC 01 03 08 14 E2 00 80 12 2D

CC

BC 01 03 08 14 E2 00 80 10 2F

CC

BC 01 03 08 13 E2 00 80 02 3A

CC

BC 01 03 08 13 E2 00 80 00 38

CC

 

BC: control byte (normal priority telegram)

01: address of sender device (sector)

03: address of sender device

08: address of destination device (sector)

14:  address of destination device

E2: network protocol data unit – data length is 2

00: transport protocol data unit

80: data byte 1

12: data byte 2

2D: check byte

 

CC: acknowledge from receiving device

Rispetto al log Vimar esistono alcune differenze:

-        Il control byte è 0xBC invece che 0xB4 (cambiano i bit che indicano la priorità del messaggio).

-        Network protocol data unit vale 0xE2 invece che 0xE1 (la lunghezza dati è dichiarata 2 bytes)

-        Data byte invece di 0x81 (accendi) o 0x80 (spegni) vale 0x8012 (accendi) o 0x8010 (spegni) o 0x8002 (accendi) o 0x8000 (spegni)

Da notare che fino ad oggi (versione firmware 18.31) la lunghezza dati di 2 bytes non è implementata nel comando breve di scrittura @w. Lo sarà in futuro.

Aggiornamento del firmware

L’ultima versione del firmware la potete ottenere contattandomi via email e consiste in un file .hex

Può essere aggiornato in 2 modi:

1)     Utilizzando uno dei programmatori Microchip (o clone) tipo Pickit3

2)     Collegando la scheda MCP2200 o analoga interfaccia verso una porta COM1-2-3-4 di un PC con Windows (XP/7/8) ed utilizzando l’apposito programmino VB che potete scaricare da qui.

 

 

 

Utilizzo con Arduino o con Raspberry

Il colloquio avviene tramite porta seriale con livelli TTL (0-5V oppure 0-3V) alla velocità di 115200 baud.

Nel paragrafo successivo sono elencati i comandi leciti, esistono altri comandi non ancora documentati, utili soprattutto per i test del dispositivo.

Sul mio sito sono pubblicati alcuni esempi di software utilizzabili per la connessione e l’utilizzo tramite Arduino.

 

Il firmware

Lo scambio di dati viene sempre sollecitato da un comando inviato al dispositivo – ogni comando ha il seguente formato (i simboli < e > vengono utilizzati come separatori):

<@><comando><valore><dati opzionali>

Il modulo risponde sempre ma in vario modo a seconda del comando.

@I<valore> [non implementato]

Imposta il tipo di interfaccia hardware utilizzata; i valori possono essere i seguenti:

0 : TP-UART infineon (default)

1 : FZE1066G infineon

2 : comparatore interno al PIC

3 : comparatore esterno

Risposte possibili: <k> : tutto ok <E> : errore

 

@M<valore>

Imposta la modalità di comunicazione sulla porta seriale; i valori possono essere i seguenti:

X : esadecimale (default): i dati vengono scambiati in esadecimale puro (bytes da 0x00 a 0xFF)

A : ascii: i dati vengono scambiati con caratteri ascii, per esempio l'esadecimale 0x2A va inviato con 2 caratteri, il carattere '2' seguito dal carattere 'A'. In modalità ascii la lunghezza effettiva dei dati inviati risulta quindi doppia rispetto alle lunghezze specificate che sono quindi lunghezze logiche. La modalità ascii è utile per fare test diretti con programmi standard di interfaccia seriale (tipo “putty”).

Il valore impostato viene memorizzato nella eeprom del PIC e rimane valido anche spegnendo e riaccendendo il dispositivo.

Risposte possibili: <k> : tutto ok <E> : errore

 

@F<valore>

Permette di applicare un filtro sui messaggi SCS per ignorare quelli che non interessano; i valori espressi sempre in ascii possono essere i seguenti:

0 : nessun filtro

1 : i messaggi doppi o tripli vengono trasmessi in seriale una volta sola.

2 : i messaggi di ACK (0xCC) vengono ignorati.

3 : comprende sia il filtro “1” che il filtro “2”.

4 : i messaggi di ACK e i messaggi di stato vengono ignorati.

Il valore impostato viene memorizzato nella eeprom del PIC e rimane valido anche spegnendo e riaccendendo il dispositivo.

Risposte possibili: <k> : tutto ok <E> : errore

 

@D<valore>

Permette di impostare il valore del byte di “linea e settore” del dispositivo di destinazione nei messaggi –  inizialmente questo valore è impostato a 0B.

Il valore impostato viene memorizzato nella eeprom del PIC e rimane valido anche spegnendo e riaccendendo il dispositivo.

Risposte possibili: <k> : tutto ok <E> : errore

 

@r

Permette di leggere dal dispositivo il successivo telegramma ricevuto e bufferizzato; la lettura lo rimuove dal buffer. Il dispositivo ha un buffer in grado di contenere fino a 10 telegrammi; la mancata lettura dei messaggi provoca un overflow del buffer con conseguente perdita dei telegrammi più vecchi.

Risposta:

<lunghezza> : sempre e solo un carattere (ascii o esadecimale puro) da '0' a 'F' che indica la lunghezza logica dei dati rimanenti (se vale '0' significa che non ci sono telegrammi in attesa di scodamento)

<dati> : i dati del telegramma in esadecimale puro oppure in ascii a seconda del modo operativo

 

@R

Permette di leggere dal dispositivo il successivo telegramma ricevuto e bufferizzato; la lettura lo rimuove dal buffer. Il dispositivo ha un buffer in grado di contenere fino a 10 telegrammi; la mancata lettura dei messaggi provoca un overflow del buffer con conseguente perdita dei telegrammi più vecchi. Se il buffer non contiene messaggi la risposta viene differita: la risposta avrà luogo solo quando il buffer conterrà un telegramma.

Risposta:

<lunghezza> : sempre e solo un carattere (ascii o esadecimale puro)  da '0' a 'F' che indica la lunghezza logica dei dati rimanenti (non può essere 0)

<dati> : i dati del telegramma in esadecimale puro oppure in ascii a seconda del modo operativo

 

@c

Permette di uscire dallo stato di attesa innescato dal comando @R.

Risposta: <k>

 

@W<valore><dati>

Permette di trasmettere al dispositivo un telegramma da inviare in rete

<valore> : sempre e solo un carattere (ascii o esadecimale puro) da '0' a 'F' che indica la lunghezza logica dei dati rimanenti

<dati> : i dati del telegramma in esadecimale puro oppure in ascii a seconda del modo operativo

 

Risposte possibili: <k> : tutto ok <E> : errore

 

@w<valore><dati>

Modalità rapida per mandare un telegramma da inviare in rete. Attenzione: questa modalità si basa su di una serie di valori di default che vanno sicuramente bene per reti Vimar by-me ma che potrebbero non funzionare su altre reti KONNEX. Si consiglia quindi di usare per tali scopi il comando @W.

<valore> : sempre e solo un carattere (ascii o esadecimale puro) da '0' a 'F' che rappresenta il comando da inviare al dispositivo ('1' accendi, '0' spegni)

<dati> : indirizzo dell'attuatore in esadecimale puro (1 byte) oppure in ascii (2 bytes) a seconda del modo operativo

Per poter utilizzare correttamente questa modalità è indispensabile che il valore di linea e settore del dispositivo ricevente sia stato precedentemente memorizzato nella eeprom del pic (vedi comando @D).

Risposte possibili: <k> : tutto ok <E> : errore

 

 

@3

Imposta il comparatore interno al PIC a valori adeguati ad una alimentazione di 3,3Volts.

Comando disponibile sono con firmware 18.4x ed hardware 141113,

ATTENZIONE ! Non tutti i dispositivi sono adatti al funzionamento a 3,3 Volt – chiedete prima di acquistare.

Risposte possibili: <k> : tutto ok <E> : errore

 

@5

Imposta il comparatore interno al PIC a valori adeguati ad una alimentazione di 5Volts.

Comando disponibile sono con firmware 18.4x ed hardware 141113,

Risposte possibili: <k> : tutto ok <E> : errore

 

 

Comandi di test e debug

@b

Pulisce tutti i buffers di ricezione.

Risposta : <k> : tutto ok

 

@h

Espone un menu di help – solo in modalità ASCII.

 

@q

Query version – solo in modalità ASCII.

Risposta : <k>  seguito dalla VERSIONE : tutto ok

 

@l

Attiva un log a video dei messaggi ricevuti e trasmessi – solo in modalita ASCII.

Risposte possibili: <k> : tutto ok <E> : errore

 

@c

Pulisce lo stato di attesa - solo in modalita ASCII.

Risposte possibili: <k> : tutto ok <E> : errore

 

@d

Dump di tutti i buffers di ricezione – solo in modalita ASCII.

Risposte possibili: <k> : tutto ok <E> : errore

 

@s

Sbilancia l’indice dei buffers di ricezione simulando una ricezione di messaggio – solo in modalita ASCII-

Risposte possibili: <k> : tutto ok <E> : errore