L'analisi di questo protocollo è iniziata con un primo semplice test effettuato con la versione hardware e software utilizzata per EIB/KNX.

Visto che qualcosa si riusciva ad ottenere sono andato avanti su questa strada fino ad ottenere un successo pieno nella comprensione e replicazione dei comandi.

Nel percorso sono passato attraverso modifiche del software, dell'hardware passando anche per la realizzazione di progettini minori utili per analizzare e capire.

Se qualcuno vuole divertirsi a percorrere la mia stessa strada potete trovare una breve cronistoria qui.

 

ATTENZIONE: quanto descritto è il risultato della mia analisi, NON è una descrizione ufficiale del sistema scs che è di proprietà della bTicino. Declino ogni responsabilità derivante da eventuali mie conclusioni errate od incomplete.

Il protocollo SCS ha qualche somiglianza e molte differenze con EIB/KNX.

Ambedue utilizzano come mezzo trasmissivo un doppino (TP= twisted pair) che porta sia l'alimentazione che i segnali; per EIB l'alimentazione è di 29 Volt, per SCS di 27 Volt.

I segnali per EIB sono più "marcati" (la tensione scende da 29 a 23 Volts, per scs Ticino scende da 27 a 24 Volts: la differenza, apparentemente banale, viene però tenuta in considerazione dalle apparecchiature sul bus SCS che ignorano segnali troppo forti o troppo ripidi. Questo è il motivo per cui sull'hardware SCS la resistenza di carico di 68 ohm va sostituita con una resistenza da 100 ohm in serie ad una induttanza di 10uH (i fronti devono essere meno ripidi).

I timing sono simili: ogni byte è rappresentato da 1 bit di start più 8 bits di dati a 9600 bauds; la modulazione è con ritorno allo zero: i bits a zero hanno un impulso di circa 35uS ed una pausa di circa 70uS, i bits a uno sono rappresentati da una pausa di 105uS.

Nella cronistoria citata al paragrafo precedente potete vedere i dettagli.

I telegrammi SCS sono composti da 7 bytes e sono di diversi tipi - ne faccio un esempio con la relativa descrizione:

telegramma di comando:

A8 33 00 12 00 21 A3

viene inviato dai pulsanti agni attuatori ogni volta che il pulsante stesso viene premuto.

0xA8 iniziatore di comando
0x33 destinazione: codice dispositivo (corrisponde alla targhetta inserita sull'attuatore)
0x00 fisso (provenienza?)
0x12 richiesta di comando
0x00 comando accendi (0x01: comando spegni)
0x21 check byte (è sempre il risultato dell'operazione Xor dei 4 bytes precedenti)
0xA3 terminatore di comando

Gli indirizzi della serie Bx pare abbiano dei significati speciali nel protocollo SCS:

Il comando indirizzato al gruppo B1 viene eseguito da tutti i dispositivi di un determinato tipo (luci, tapparelle, ...), sono quindi comandi di "scenario". Il gruppo B8 forse significa "tutti i led" perchè lo si trova come indirizzo di destinazione dei messaggi di stato. Gli altri indirizzi della serie "Bx" potrebbero avere significati analoghi.

acknowledge:

A5

è la risposta standard dell'attuatore che accetta il comando - se l'attuatore non risponde con "ack" il comando viene ripetuto (al massimo per 3 volte),

telegramma di stato

A8 B8 33 12 01 98 A3

viene inviato a tutti dall'attuatore che cambia di stato: lo scopo è quello di far accendere o spegnere i led dei pulsanti.

0xA8 iniziatore di comando/stato
0xB8 sempre uguale - identifica gli stream di stato
0x33 provenienza - codice dispositivo (corrisponde alla targhetta inserita sull'attuatore)
0x12  richiesta di comando
0x00 stato di acceso (0x01: stato di spento)
0x99 check byte (è sempre il risultato dell'operazione Xor dei 4 bytes precedenti)
0xA3 terminatore di comando/stato

questo telegramma viene ripetuto sempre 3 volte: probabilmente perchè nessuno risponde con ack (0xA5)

Telegramma di richiesta di stato

A8 33 00 15 00 26 A3

può essere inviato agli attuatori per richiedere lo stato corrente.

0xA8 iniziatore di comando
0x33 destinazione: codice dispositivo (corrisponde alla targhetta inserita sull'attuatore)
0x00 fisso (provenienza?)
0x15 richiesta di stato
0x00 fisso
0x26 check byte (è sempre il risultato dell'operazione Xor dei 4 bytes precedenti)
0xA3 terminatore di comando

Il dispositivo interrogato risponde con un telegramma di stato.

 

TARGHETTA DEI DISPOSITIVI

Ogni attuatore ha una targhetta numerica formata da cavallotti che possono essere cambiati. Gli attuatori semplici hanno una targhetta di 2 numeri che ne costituiscono l'indirizzo (in esadecimale). Gli attuatori multipli hanno una targhetta multipla, la prima cifra è comune a tutte le uscite: per esempio un attuatore a 4 uscite marcato "31234" risponde agni ndirizzi "31", "32", "33" e "34".

- Schema

- Firmware dell'analizzatore
 

E' nata la prima versione di ScsGate - caratteristiche:

- Versione semplificata: NON usa TPUART

- Collegabile al PC (con interfaccia MCP2200) o ad altro microprocessore (tipo arduino)

Consente di ricevere e trasmettere messaggi SCS attraverso una line seriale UART a livelli TTL.

Qui trovate lo schema elettrico. Per il transistor (senza sigla) ho utilizzato un residuato che avevo nei cassettini: va bene qualunque transistor "switch" che arrivi almeno a 50V (Vce) e a 500mA (Ic) per sicurezza.

L'accoppiamento con il bus SCS è diretto (attenzione) protetto da 2 fusibili da 500mA e dal diodo D1 - usate un diodo sckottky da almeno 50V, 0.5A.   La scrittura avviene attraverso il  transistor Q1 che chiude la linea su di una resistenza da 110 ohm 1W - la lettura avviene dal comparatore interno al PIC protetto da 2 zener da 5V e che utilizza uno zener da 16V che fa da "scalino" sul bus.

Qui i disegni lato vetronite del PCB, dei componenti sotto, dei componenti sopra.

Qui il firmware  versione 18.04, da iniettare nel PIC.

Qui un documento che fa da manuale d'uso.

Limitazioni note di questa versione: la scrittura sul bus SCS avviene senza "controllo di collisione". Significa che se scrivete un telegramma proprio mentre qualche altro dispositivo sta trasmettendo probabilmente il vostro messaggio verrà perso. Questa limitazione scompare a partire dalla versione 18.10

Inoltre data la particolare struttura del dispositivo non posso garantire che il funzionamento sia corretto e stabile su tutti gli impianti - sul mio funziona bene: aspetto vostri riscontri !!!

Purtroppo non sono in grado di pubblicare routines o esempi d'uso da arduino - se qualcuno mi manda del materiale sarò lieto di pubblicarlo.

Un grazie pubblico a chi mi ha aiutato / supportato come poteva via email.

E' disponibile una versione aggiornata del firmware (V 18.30).

- è stato eliminato un difetto presente in modalità HEX ( il carattere 0h00 veniva ignorato in ricezione)

- il comando @q risponde ora con k seguito dal numero di versione anche in modalità HEX

- il settaggio effettuato con i comandi @M @F @D viene memorizzato in eeprom e quindi è ora permanente

- il comando @l (log) è stato implementato anche per il modo HEX

Il manuale d'uso è stato aggiornato con quanto sopra e con le spiegazioni su come aggiornare il firmware.

La nuova versione è disponibile gratuitamente, contattatemi via email.

Per problemi nell'installazione del driver MCP2200 visitate questa pagina.

Per esempi d'uso con Arduino:  http://guidopic.altervista.org/alter/arduino-xxxgate.html

ATTENZIONE: E' FATTO DIVIETO A CHIUNQUE DI UTILIZZARE IL PRESENTE MATERIALE A SCOPO DIVERSO DALL'USO PERSONALE E AMATORIALE SALVO MIO ESPLICITO CONSENSO SCRITTO.

Se avete bisogno di altre informazioni o di supporto contattatemi pure.

Nelle pagine "Arduino" e "Raspberry" alcuni interessanti esempi di integrazione...

 

 

 27 nov 2016 - nuova evoluzione di SCSGATE, integrazione diretta con WiFi:   ESP_SCSGATE