VERSIONE: 1.0 | SISTEMA OPERATIVO: WINDOWS (32/64bit) 2000, XP, Vista e 7 | RILASCIO: OPEN SOURCE

I DISPOSITIVI MASSABUS SONO ORA IN VENDITA COMPLETI E AGGIORNATI QUI!

Il software MassaBus Controller da solo non è in grado di controllare le funzioni affidate al sistema domotico MassaBus, per questo motivo esso dispone di una modalità automatica che permette ad un software esterno di controllare le varie unità del bus domotico attraverso un porta TCP/IP. Tale software può essere adattato al massimo per soddisfare le esigenze dell’utente finale. In questa parte si analizza un software di esempio per comprendere alcuni aspetti della domotica: il monitoraggio e la mutazione immediata delle funzioni.

Il software di esempio progettato si occupa di visualizzare a video la temperatura di due sensori di temperatura (schede Temperature sensor) presenti nel bus e monitorare l’attivazione di un sensore di movimento piroelettrico PIR attraverso l’ingresso 1 di una scheda Multi I/O Device. Quando il sensore PIR rivelerà un movimento il software a seconda della modalità impostata via software può intraprendere due azioni: accendere una luce o attivare un allarme. Queste due funzioni vengono svolte in maniera immediata e senza alcuna modifica alla circuiteria del sistema, rappresentando quindi la praticità di utilizzo di un sistema domotico.

La circuitazione di esempio utilizzata con il software di controllo e il sistema MassaBus è visibile in figura sotto, dove è anche possibile vedere un esempio di assegnazione degli indirizzi delle schede nel bus. 

In tale circuito si nota la presenza di un campanello di allarme, di una luce e del sensore PIR per il rilevamento dei movimenti. Il campanello richiede una tensione di 12Vac, mentre la luce a led viene alimentata con 16Vdc eppure non vie è alcun problema di pilotaggio essendo il relè considerabile come un normale deviatore meccanico. Il sensore PIR invece provvede a fornire al primo ingresso una tensione di 16Vdc (che è supportabile dalla scheda nonostante l’ingresso sia progettato per una tensione di 12V) che si occupa di attivare il fotoaccoppiatore di ingresso e il led di segnalazione.

Questa applicazione ovviamente ha una dubbia utilità, permette però di capire come un sistema domotico possa “interagire” con l’ambiente circostante. Ad esempio se nel computer master viene installato un cellulare GSM con opportuno software di controllo comunicante via TCP/IP con il software MassaBus Controller, sarà possibile controllare a distanza l’ambiente in cui il sistema MassaBus è installato. Tutto questo tramite normali SMS o chiamate dati.

Il circuito descritto montato fisicamente è visibile in figura sotto dove si possono notare in centro la campana di allarme, il sensore PIR e introno le schede MassaBus utilizzate. 

ALTRE IMMAGINI

Sono disponibili i sorgenti per Visual Basic .NET (gratuito) o Visual Studio 2010 e l'eseguibile compilato per avviare direttamente l'applicazione.

share this

share with

Follow

Tweet

I DISPOSITIVI MASSABUS SONO ORA IN VENDITA COMPLETI E AGGIORNATI QUI!

Molte persone oggi conoscono Arduino, una piattaforma di sviluppo che in pochi anni è diventato un vero e proprio ecosistema composto da schede, librerie e moduli aggiuntivi detti "shields". I vantaggi dell'utilizzo di arduino sono derivanti da tanti fattori, primo fra tutti il fatto che sia compeltamente open source. Un altro vantaggio non indifferente è la possibilità di disporre di un microcontrollore programmabile al volo direttamente tramite usb attraverso un IDE di sviluppo multipiattaforma.

Non è quindi un mistero la volontà di far incontrare il sistema per domotica MassaBUS con Arduino. Partiamo da un presupposto, la caratteristica principale di MassaBUS è di essere un sistema flessibile: le schede sono dei semplici servi di un cervello centrale che può mutare indipendemente dalla struttura del sistema. Il cervello centrale fino ad ora (come mostrato nei miei articoli su MassaBUS) era un PC avente in esecuzione un programma di gestione. Per quelli a cui piace modificare ed evolvere i progetti di continuo il PC è un ottima soluzione in quanto unisce praticità e velocità di cambiamento (basta aggiornare il software), però spesso questa soluzione è esagerata per la maggior parte degli utilizzi dove magari si vuole aggiornare l'impianto di tanto in tanto (o anche mai!!). In questo caso Arduino può sostituire efficacemente il PC centrale, meantenedo la praticità di riprogrammazione con il vantaggio di rappresentare una soluzione meno onerosa garantendo bassisimi consumi senza utilizzare sistemi embedded avanzati.

Le schede del sistema MassaBUS si vanno quindi a collegare tramite bus RS485 a un nodo centrale costituito da una scheda Arduino avente in esecuzione il programma di gestione del sistema (con incluse eventuali shield ethernet o wifi...).

In questa pagina vi mostrero le funzioni necessarie per implementare in Arduino il protocollo MassaBUS, un programma di esempio e uno schema per realizzare la shield RS485 necessaria per interfacciare Arduino UNO (o Leonardo, PRO) con il bus RS485 utilizzato da MassaBUS. Puoi acquistare la scheda già montata e collaudata per Arduino direttamente qui.

INTERFACCIA ARDUINO RS485

Per utilizzare il bus RS485 con Arduino è necessario disporre di una shield di interfaccia RS485. Qui ne vedremo un tipo realizzato appositamente per utilizzare tutte le caratteristiche del MassaBUS. Infatti la scheda oltre ad avere i componenti indispensabili all'uso dell'RS485 dispone anche delle funzioni di terminazione linea e polarizzazione linea attivabili tramite dip-switch. Inoltre dispone di un led per segnalare la trasmissione di un pacchetto (o altre funzioni a piacimento) ed infine un pulsante che può essere utilizzato ad esempio per prove, ripristini o altre funzioni.

Ecco lo schema elettrico dell'interfaccia:

Come visibile nello schema sopra il componente principale della shield è l'integrato MAX485 che si occupa di trasformare il bus RS485 in segnali 0-5V adatti per l'utilizzo con microcontrollore a 5V come quello della scheda Arduino UNO. L'integrato utilizza il pin RX e TX dell'UART di Arduino nonchè un pin di output (2) che controlla l'abilitazione della trasmissione nel bus (essendo half-duplex). L'abilitazione della ricezione (cioè i dati sul bus vengono portati nel pin RX di Arduino) può essere eseguita con 2 modalità selezionabili tramite ponticello TX ECHO: la prima prevede l'attivazione della ricezione solo quando la trasmissione è disattivata, mentre la seconda mantiene la ricezione sempre attiva pertanto sul pin RX di arduino avremo anche l'ECO del pin TX. La modalità per l'uso con MassaBUS è quella in cui la ricezione è disattivata durante la trasmissione.

Le uscite del BUS RS485 sono collegate ad un dip switch che tramite il selettore 1 permette di attivare la terminazione della linea (solo se la scheda è all'inizio o alla fine del bus) e tramite il selettore 2 e 3 permette l'attivazione della polarizzazione della linea (attivazione di entrambi necessaria in una sola scheda del BUS).

In seguito possiamo trovare delle piccole aggiunte che fanno da contorno alla scheda: un led al pin 3 di Arduino e un pulsante al pin 5 di Arduino. Il led può essere utile per indicare la trasmissione di un pacchetto, mentre il pulsante (attivo con ingresso alto su Arduino) può essere utile per ripristinare in particolari condizioni i valori di default del sistema (ipotizzando l'uso della ethernet shield insieme a questa shield, esattamente come avviene nei dispositivi di rete). La resistenza da 470 all'ingresso di Arduino dove è collegato il pulsante serve come protezione per Arduino in caso che tale pin di ingresso venga erroneamente impostato come uscita. Ovviamente sia il led che il pulsante sono utilizzabili a vostra discrezione!

Puoi acquistare la scheda già montata e collaudata per Arduino direttamente qui.

IL CODICE PER ARDUINO

Essendo Arduino il nodo centrale, esso si occupa anche di far partire la comunicazione e una volta fatto si aspetta una risposta. Ecco quindi che il codice per arduino si divide in due parti: una si occupa della trasmissione del pacchetto (tramite una funzione chiamata "code_data_to_send") e di una funzione di ricezione chiamata dalla funzione di decodifica ("decode_ric_data") che a sua volta è chiamata da una routine di cattura dei dati seriali ("serialEvent") che si verifica ogni volta che il primo byte del pacchetto arriva nella seriale di Arduino. Di seguito trovate tutte le funzioni con le rispettive chiamate.

Le funzioni sono state inserite in un programma di esempio che si occupa di scrivere ogni 5 secondi due valori alternati in output. Per provare subito il programma ed effettuare i primi esperimenti di utilizzo è necessario collegare ad Arduino + RS485 una scheda Multi I/O Device o Mini I/O Device con indirizzo pre programmato 2. Nei relè di uscita, una volta caricato il programma, vedrete variare l'output ogni 5 secondi.

//-----------------------------------------------------------------
// Esempio applicativo del protocollo MassaBus con Arduino
// Il programma per la prova di funzionamento richiede una scheda
// di output (Multi I/O o Mini I/O con indirizzo pre impostato a 2)
// Durante la prova ogni circa 5 secondi l'output sulla scheda cambierà
// di stato
//------------------------------------------------------------------
//Definisco numero byte bus
#define SIZE_BUS_DATA 11
//Definisco il timeout massimo per la seriale
#define MAX_MILLIS_TIMEOUT 50
//Inizializzazioni
int led_act = 13;//Pin di arduino con il LED incluso
int bus_dir = 2;//Pin di selezione della direzione
int count;//Variabile conteggio generica
long mil_mem = 0;//Variabile memorizzazione millisecondi
byte my_adr = 1;//Mio indirizzo nel bus
byte send_compose[SIZE_BUS_DATA];//Array invio pacchetto
//Variabili procedure ricezione (riguardano l'ultimo pacchetto decodificato)
byte recived_data[SIZE_BUS_DATA];//Array del pacchetto ricevuto
boolean correct_data;//True se il pacchetto era corretto
byte adress_reciver_ric;//L'indirizzo destinatario
byte adress_sender_ric;//Indirizzo mittente
byte type_ric;//Tipologia pacchetto
byte data1_ric;//Campo dato 1
byte data2_ric;//Campo dato 2
//Procedura creazione trama da inviare su BUS
//Campi: indirizzo destinatario,tipologia pacchetto, dato 1, dato 2)
void code_data_to_send(byte adress_reciver,byte type_s,byte data1_s,byte data2_s)
{
 //Variabili utilizzate nella procedura
byte checksum_send;//checksum completo
byte checksum_send_low;//checksum diviso (parte bassa)
byte checksum_send_hi;//checksum diviso (parte alta)
byte type_to_send;//Tipologia pacchetto
byte data_send_1;//Primo campo dati da inviare
byte data_send_2;//Secondo campo dati da inviare
byte adress_sender;//Indirizzo mittente
//Inizio procedura
type_to_send = type_s << 2; //shift di due bit per spazio riservato zero flag
//se l'indirizzo è in modalità normale (destinatario diverso da 255)
if(adress_reciver != 255){
  adress_sender = my_adr; //Metto come mittente il mio indirizzo
 } else {
  adress_sender = 255; //Altrimenti anche il mittente a 255
 } 
if(data1_s == 0){//se data1 è pari a 0
  data_send_1 = 48; //lo sostituisco con il codice ASCII 48
  type_to_send = type_to_send | 1; //Imposto a 1 il rispettivo zero flag
 } else {
  data_send_1 = data1_s; //altrimenti mantengo il dato
 }
if(data2_s == 0){//se data2 è pari a 0
  data_send_2 = 48; //lo sostituisco con il codice ASCII 48
  type_to_send = type_to_send | 2; //Imposto a 1 il rispettivo zero flag
 } else {
  data_send_2 = data2_s; //altrimenti mantengo il dato
 }
//Calcolo e assegnazione bit checksum
//Effettuo XOR con tutti i campi necessari
checksum_send = adress_reciver ^ adress_sender ^ type_to_send ^ data_send_1 ^ data_send_2;
//Suddivido il checksum in due parti (alta e bassa) a 4 bit ciascuna
//Imposto di ogni parte il bit più significativo a 1 come previsto da protocollo
checksum_send_low = (checksum_send & 15) | 128;
checksum_send_hi = (checksum_send >> 4) | 128;
// Composizione array stringa seriale
//Ad ogni rispettivo byte del pacchetto assegno il rispettivo dato
send_compose[0] = 'S';
send_compose[1] = adress_reciver;
send_compose[2] = adress_sender;
send_compose[3] = type_to_send;
send_compose[4] = data_send_1;
send_compose[5] = data_send_2;
send_compose[6] = checksum_send_low;
send_compose[7] = checksum_send_hi;
send_compose[8] = 3; //Terminazione
send_compose[9] = 3;
send_compose[10] = 3;
//Invio il pacchetto
send_data();
}
//Procedura invio dati su bus tramite seriale
void send_data(){
 // setto il flag di trasmissione
 UCSR0A=UCSR0A |(1 << TXC0);
 Serial.flush();
 // abilito led
 digitalWrite(led_act,HIGH);
 //attivo il MAX485 in trasmissione
 digitalWrite(bus_dir,HIGH);
 //Mando l'array di byte
 Serial.write(send_compose, SIZE_BUS_DATA);
 //Attendo la fine della trasmissione
 Serial.flush();
 while (!(UCSR0A & (1 << TXC0)));
 //Disabilito led e max485
 digitalWrite(bus_dir,LOW);
 digitalWrite(led_act,LOW);
}
//Procedura decodifica dati
void decode_ric_data(){
//Variabili checksum separati
byte chk_low;
byte chk_hi;
//Composizione complessiva del checksum
byte checksum;
//Variabile checksum ricalcolato
byte calcolated_checksum;
//imposto a default la variaible pacchetto corretto
correct_data = false;
//Verifico che il primo pacchetto sia S e ci sia la terminazione (come da protocollo MassaBUS)
if((recived_data[0] =='S')&&(recived_data[8] == 3)){//Controllo start byte e terminazione
 //Ricostruzione byte checksum
 //Separo la parte bassa dal pacchetto
 chk_low = recived_data[6] & 15;
 //Separo la parte alta dal pacchetto
 chk_hi = recived_data[7] & 15;
 //Mette insieme i due byte per ricostrire checksum (con shift del più alto)
 checksum = (chk_hi << 4) | chk_low; 
 //controllo il dato ricevuto con il checksum (lo ricostruisco con i byte ricevuti)
 calcolated_checksum = recived_data[1] ^ recived_data[2] ^ recived_data[3] ^ recived_data[4] ^ recived_data[5];
 //Verifico che il checksum sia uguale (calcolato e ricevuto) e verifico che i due byte dei
 //pacchetti dei checksum abbiano il bit più significativo alto (come da protocollo)
 if((calcolated_checksum == checksum) && ((recived_data[6] & 128) == 128) && ((recived_data[7] & 128) == 128)){
   //se il checksum è corretto
   //Setto nella variabile condivisa l'indirizzo del destinatario (forse questa scheda!!!)
   adress_reciver_ric = recived_data[1];
   //Setto nella variabile condivisa l'indirizzo del mittente
   adress_sender_ric =recived_data[2];
   //preleva il pacchetto di tipologia (saltando gli zero flag)
   type_ric = recived_data[3] >> 2; 
   //Verifica degli zero flag (sia primo che secondo campo dati)
   //Se dato 48 e rispettivo zero flag a 1 setto data a 0
   //altrimenti setto il valore ricevuto
   if((recived_data[4]==48)&&((recived_data[3] & 1)==1)){
     //se data1 = 0 (controllo zero flag a 1)
     data1_ric=0;
   } else {
     data1_ric=recived_data[4];
   }
   //Verifica degli zero flag
   //Se dato 48 e rispettivo zero flag a 1 setto data a 0
   //altrimenti setto il valore ricevuto
   if((recived_data[5]==48)&&((recived_data[3] & 2)==2)){
     //se data2 = 0 (controllo zero flag a 1)
     data2_ric=0;
   } else {
     data2_ric=recived_data[5];
   }
   //Indico che il pacchetto è stato decodificato correttamente
   correct_data = true;
 }
}
 //Se il pacchetto è decodificato correttamente
 if(correct_data){
   //Chiamo la procedura che gestisce il pacchetto decodificato
   packet_data_elaboration();
 }
}
// the setup routine runs once when you press reset:
void setup() {
  // inizializzo led indicazione invio pacchetto e led selezione direzione
  pinMode(led_act,OUTPUT);
  pinMode(bus_dir,OUTPUT);
  Serial.begin(9600);
}
//evento lanciato durante la ricezione di dati seriali
void serialEvent() {
  byte index_buffer_rx = 0;
  boolean get_byte_continue =true;
  //Prendo i millisecondi attuali
  long last_millis =millis();
  long mem_millis;
  //Inizializzo conteggio millisecondi di timeout
  int count_millis = 0;
  //Inizializzo varibile indicante dati corretti
  boolean bus_data_avaible =false;
  //Verifico disponibilità dati
  if(Serial.available()){
    //Prelevo primo dato
    recived_data[index_buffer_rx++] = Serial.read();
    //Attivo loop di ricezione pacchetti
    while(get_byte_continue){
      //Parte gestione byte ricevuti
      if(Serial.available()){
        recived_data[index_buffer_rx++] = Serial.read();
        //Verifico se il buffer ha un pacchetto completo
        // (-2 per riconosere il pacchetto conteggiando da 0)
        if(index_buffer_rx > (SIZE_BUS_DATA - 2)){
          //Fermo la ricezione di byte (dopo uscirà dal ciclo)
          get_byte_continue = false;
          //Indico mettendo in true che il pacchetto è stato ricevuto correttamente
          bus_data_avaible = true;
        }
      }
      //Seconda parte (conteggia i milliscondi del ciclo while)
      //Se supera timeout esco (evitando stalli del software!)
      //Parte gestione timeout
      //Prelevo i millisecondi attuali dall'accensione di arduino
      mem_millis = millis();
      //Se diversi da quelli memorizzati precedentemente
      if(mem_millis != last_millis){
        //Salvo in memoria gli attuali
        last_millis = mem_millis;
        //Incremento il conteggio dei millisecondi
        count_millis++;
        //Se supera soglia di millisecondi impostati (costante)
        if(count_millis > (MAX_MILLIS_TIMEOUT - 1)){
          //Esco dal ciclo mettendo in flase la variabile
          get_byte_continue = false;
          //bus_data_avaible rimane in false (pacchetto non corretto!!)
        }
      }
     }
  }
  //Se all'uscita del while i dati sono corretti
  if(bus_data_avaible){
    //Chiamo la procedura di decodifica pacchetto
    //Nell'array recived_data ho tutti i byte del pacchetto
    //Pronti da analizzae...
    decode_ric_data();  
  }
}
void loop() {
  //Attendo 5 secondi (non uso delay per permettere ricezione seriale)
 if (millis() != mil_mem){
   mil_mem = millis();
 if(count++ > 5000){
   count = 0;
   //Invio in output 5 (tipologia 12 output, indirizzo 2)
 code_data_to_send(2, 12, 5, 0);
 }
}
}
 
void packet_data_elaboration() {
//Se il pacchetto è indirizzato qui e arriva dal dispositivo 2 con tipologia 12
if ((adress_reciver_ric == 1) && (adress_sender_ric == 2) && (type_ric == 12)){
  if(data1_ric = 5){
    delay(5000);//attendo 5 sec
    code_data_to_send(2, 12, 10, 0);
    //Invio in output 10 (tipologia 12 output, indirizzo 2)
  }   
 }
}

Di seguito trovate il sorgente per Arduino.

DOWNLOAD SORGENTE ARDUINO

Buon lavoro!

share this

share with

Follow

Tweet

I DISPOSITIVI MASSABUS SONO ORA IN VENDITA COMPLETI E AGGIORNATI QUI!

Questa scheda è la versione ridotta della scheda Multi I/O Device del sistema domotico MassaBus. Dispone di 4 uscite a relè e di 4 ingressi digitali optoisolati e condivide la maggior parte dei comandi della scheda gemella più grande.

SCHEMA ELETTRICO

Lo schema è semplificato rispetto alla scheda Multi I/O Device, si nota in particolare l'uso di un microcontrollore più piccolo 16F628A e la mancanza del convertitore analogico-digitale. L'integrato ULN2803A è stato sostituito da 4 transistor per ottimizzare spazio e costi.

FIRMWARE

Il firmware è stotanzialmente identico a quello della scheda Multi I/O tranne per la mancanza delle istruzioni che eseguivano le funzioni del convertitore analogico-digitale che in questa scheda non è presente.

REALIZZAZIONE PRATICA

Di seguito è possibile osservare il circuito su PCB, l'immagine è puramente indicativa. Per realizzare le schede fate riferimento ai file allegati.

Attenzione che alcuni componenti (diodi, resistenze) sono montati in verticale quindi un terminale va sulla scheda e l'altro terminale assume la forma di "u" rovesciata per poter arrivare anch'esso alla scheda.

Fate attenzione anche a montare i due ponticelli presenti sulla scheda, realizzabili con del filo nudo.

ALCUNE IMMAGINI

I file per la realizzazione della scheda sono in formato PDF con sorgente in formato per FidoCAD, il firmware è compilato in formato HEX con il sorgente per l'IDE MikroBasic (in versione free).

share this

share with

Follow

Tweet

I DISPOSITIVI MASSABUS SONO ORA IN VENDITA COMPLETI E AGGIORNATI QUI!

La scheda Temperature sensor è una scheda del sistema domotico MassaBus che provvede a misurare la temperatura in un ambiente o su una cosa. Per effettuare ciò utilizza un sensore di temperatura digitale della Dallas Semiconductor DS18S20 che permette di rilevare temperature da -55 a +125°C con una accuratezza di +/- 0,5°C. Essendo il sensore di tipo digitale esso può essere posto anche a distanza di qualche metro dalla scheda di gestione, permettendo l’attacco in maniera semplice su un oggetto di cui vi è necessario monitorare la temperatura.

SCHEMA A BLOCCHI

La scheda collegata al bus permette di fornire al sistema MassaBus la temperatura ambientale o di una cosa che potrà essere elaborata dal sistema domotico per eseguire azioni di vario genere. La scheda ha come cuore centrale in microcontrollore PIC 16F628 che si occupa di gestire sia il sensore, sia il bus domotico. La scheda può essere alimentata direttamente con l’alimentazione centralizzata del sistema MassaBus essendo dotata di stabilizzatore.

Il microcontrollore PIC 16F628

Il microcontrollore PIC 16F628 fa parte della stessa famiglia del microcontrollore PIC 16F876 utilizzato nella scheda “Multi I/O Device”, pertanto in questo capitolo verranno descritte solo le differenze che presenta rispetto al 16F876. Innanzitutto questo microcontrollore dispone di un package più piccolo a 18 pin , meno periferiche e meno memoria disponibile. Permette però di adattarsi meglio, rispetto al 16F876, ai sistemi più semplici garantendo compattezza e più economicità.

Le sue principali caratteristiche sono:

• CPU RISC ad alte prestazioni, cioè dispone di un ridotto set di istruzioni in assembly aventi tempi di esecuzione simile.
• La maggior parte delle istruzioni richiede un solo ciclo della CPU per essere eseguita, un ciclo corrispondono a 4 impulsi di clock.
• Supporta differenti tipi di generatori di clock e frequenze di clock fino a 20Mhz, dispone anche al suo interno di un oscillatore RC impostabile a 4 MHz o 37 KHz .
• Power on timer e watchdog timer e Brown-out Reset.
• Alto range di tensioni di funzionamento: da 3 a 5,5V.
• Uscite in grado di supportare fino a 20mA continuativamente.
• 2Kbyte di memoria FLASH interna.
• 10 tipi di interrupt supportati.
• 3 porte di I/O denominate PORTA, PORTB, PORTC.
• Dispone di molte periferiche interne, tra cui: 3 timer, USART interno implementato a livello hardware e una EEPROM interna di 128 byte.

In figura sotto è visibile lo schema a blocchi dell’architettura interna del microcontrollore.

Per la descrizione dei componenti si rimanda alla descrizione fatta nell'articolo di descrizione della scheda "Multi I/O Device" essendo il PIC 16F876 della stessa famiglia del microcontrollore 16F628.

Sensore di temperatura ad alta precisione DS18S20

Il sensore di temperatura DS18S20 della Dallas Semiconductor è un trasduttore di temperatura digitale che consente di misurare temperature da -55 a 125°C con una accuratezza di +/- 0,5°C e di fornire direttamente in digitale la temperatura appena misurata. Nella figura superiore è possibile osservare l’aspetto esteriore del sensore di temperatura. Come si può notare esso presenta tre terminali di cui 2 necessari all’alimentazione ed uno per la comunicazione dati. Per la comunicazione questo sensore di temperatura utilizza uno speciale protocollo chiamato OneWire che permette a sensore di comunicare in maniera bidirezionale con un unico filo conduttore.

Il sensore di temperatura dispone internamente di un convertitore analogico digitale con una risoluzione di 9 bit, di una memoria che mantiene memorizzati gli ultimi valori e alcune impostazioni e di una interfaccia per il controllo del bus OneWire.

Le sue caratteristiche principali, da datasheet, sono:

• Protocollo di comunicazione OneWire.
• Possibilità di connessione multipla avendo ogni sensore un proprio indirizzo.
• Range di alimentazione da 3 a 5,5V.
• Range di temperatura misurata da -55 a +125°C.
• Accuratezza della misura di +/- 0,5°C
• Risoluzione conversione analogico digitale di 9 bit.
• Tempo di conversione massimo pari a 750ms.
• Permette il settaggio di temperature di allarme.
• Possibilità di alimentare l’unità tramite l’apposito terminale o direttamente dal bus OneWire.

Per interfacciare il sensore all’unità di controllo (es. microcontrollore) è necessario collegare il pin del protocollo OneWire a un terminale del microcontrollore di tipo Open-Collector (vedere la figura sotto) e collegare una resistenza di pull-up da 4,7K, inoltre è necessario alimentare il sensore tramite l’apposito pin o tramite una speciale modalità che non essendo usata non viene descritta. Per effettuare una misurazione è necessario fornire nel terminale del protocollo OneWire delle parole di comando che fanno capo sempre ad un reset del sensore.

La misurazione di una temperatura si articola in due fasi: inizio della conversione e lettura della misura nella memoria (la cui struttura è visibile in figura sotto) dopo almeno i 750ms necessari alla conversione. Come si può notare nella struttura della memoria la temperatura viene salvata nei primi due byte della memoria, mentre gli altri byte vengono utilizzati per alcune funzioni non utilizzate nella scheda.

I primi due byte assumono i valori visibili in figura sotto associati alla temperatura misurata. Si può notare come il primo byte meno significativo rappresenta il valore binario di temperatura convertito (che moltiplicato per 0,5°C fornisce il valore diretto della temperatura in gradi celsius), mentre il secondo byte più significativo rappresenta il segno.

Nella scheda si è scelto di consentire l’uso di un solo sensore, pertanto in questo caso andranno forniti al sensore una successione di comandi ben definiti senza utilizzare l’indirizzamento opzionale del sensore (per maggiori dettagli fare riferimento al datasheet).

1. Comando di reset
2. Comando di salto senza indirizzamento (detto skip rom)
3. Comando della funzione (es. inizio conversione, lettura etc)

Per i dettagli sui comandi si faccia riferimento al datasheet e al firmware della scheda descritto di seguito e nei file allegati.

FIRMWARE DI GESTIONE

Il firmware di gestione è stato progettato, come per le altre schede aventi microcontrollore PIC, attraverso il compilatore mikroBasic pertanto valgono le stesse considerazioni fatte precedentemente. Il compilatore contiene al suo interno una libreria chiamata OneWire che permette la gestione diretta dei sensori di temperatura DS18S20 e del pin del microcontrollore adibito alla comunicazione con il sensore, attraverso delle subroutine apposite:

• Ow_Reset(Porta, pin) che effettua il reset del sensore di temperatura e restituisce 1 se il sensore non viene rilevato;
• Ow_Read(Porta, pin) che permette di leggere un dato nel bus OneWire;
• Ow_Write(Porta, pin, dato) che permette di scrivere un dato nel bus OneWire.

Vengono utilizzate inoltre anche le librerie EEPROM per la gestione della omonima memoria e la libreria UART per il controllo della seriale. Essendo il tempo di conversione di 750ms per non rallentare il funzionamento del bus si è scelto di articolare il funzionamento della scheda con due tipi di funzioni normali: una per la partenza della conversone e una per il prelievo del valore convertito.

Le funzioni svolte dal firmware sono le seguenti:

• Provvede ad implementare le caratteristiche del protocollo MassaBus nella comunicazione con il bus.
• La funzione di partenza della conversione della temperatura può essere effettuata singolarmente e in broadcast consentendo di inviare un unico comando di conversione a tutte le schede e permettendo successivamente di prelevare in maniera veloce il valore a tutte le schede senza attendere più volte il tempo di 750ms necessario alla conversione.
• Il firmware utilizza il timer1 a 16 bit configurato per fornire un interrupt ogni 524ms (come nella scheda Multi I/O Device) che permette di scandire il tempo necessario alla conversione senza impegnare l’esecuzione del programma. Essendo l’unità temporale dell’interrupt di 524ms per effettuare un conversione coprendo i 750ms del sensore sono necessari due interrupt per poter poi prelevare il valore di temperatura.
• In accordo con le funzioni del sensore la scheda può rilevare la presenza del sensore.
• Essendo la conversione in broadcast senza conferma, il firmware della scheda può permettere tramite una funzione una sola lettura a conversione, permettendo di capire se il comando era stato ricevuto correttamente.
• Gestione del transceiver MAX485 per permettere la comunicazione nel bus condiviso.
• Programmazione degli indirizzi diretta via software.

Di seguito è possibile osservare il diagramma di flusso del programma inserito nel pic. In esso si fa riferimento a delle procedure esterne (decodifica dati, controllo input e codifica dati) che possono essere ritrovate in dettaglio nel firmware in linguaggio BASIC fornito.

Nel diagramma di flusso progettato, analogamente a quello della Multi I/O Device, vi è presente un ciclo continuo (LOOP) che si occupa in questo caso principalmente di verificare la fine di un eventuale conversione del sensore iniziata precedentemente e la presenza di dati in transito nel bus. Se la scheda è richiamata (direttamente o tramite indirizzo di Broadcast) il firmware si occupa di effettuare l’operazione richiesta. Come in tutte le schede slave del sistema MassaBus è presente un speciale modalità (selezionabile sulla scheda tramite deviatore) che permette la programmazione degli indirizzi direttamente via software.

Il firmware è disponibile nei download della scheda (a fondo pagina), è comprensivo di sorgenti e file HEX per programmare il microcontrollore.

SCHEMA ELETTRICO

In figura sopra è visibile lo schema elettrico progettato della scheda sensore di temperatura del sistema MassaBus. Si nota la presenza dello stabilizzatore 7805 (IC4) che provvede a fornire i 5V stabilizzati necessari al corretto funzionamento dei circuiti integrati della scheda. Il microcontrollore PIC (IC1) ha collegato il bus OneWire del sensore attraverso una sua particolare porta con uscita di tipo open-collector chiamata RA4 (presente nel package sul pin 3) e il cui schema interno è visibile in figura sotto dove è evidenziato il particolare circuito di output.

In questa maniera è possibile utilizzare attraverso tale porta il protocollo OneWire utilizzato dal sensore, anche attraverso l’uso della resistenza di pull-up R3 da 4,7K prevista dal protocollo.

A sinistra del microcontrollore si può notare il pulsate di reset P1 collegato al pin di reset generale del microcontrollore e i pin che collegano l’interfaccia UART interna al PIC con il transceiver MAX485 ed il relativo dip switch a 3, entrambi descritti nello schema elettrico della scheda Multi I/O Device. Sono presenti inoltre i componenti presenti in tutte le schede slave del sistema MassaBus, ovvero il led di segnalazione attività con l’opportuna resistenza di limitazione della corrente e il deviatore che consente di selezionare la modalità normale o la modalità programmazione. A destra del microcontrollore è presente il quarzo a 4 MHz con i relativi condensatori che garantisce una maggiore stabilità e precisione rispetto all’oscillatore a 4 MHz interno al microcontrollore.

REALIZZAZIONE PRATICA

Di seguito è possibile osservare il circuito su PCB, l'immagine è puramente indicativa. Per realizzare le schede fate riferimento ai file allegati. 

Alcune immagini 

Sono allegati al progetto i file programma del microcontrollore (diagramma per il programma Diagram Designer, programma in basic per mikroBasic Pro, file HEX precompilato da inserire direttamente nel PIC) e i file di realizzazione della scheda (in formato PDF e FidoCAD).

Nota: Il programma mikroBasic permette nella sua versione gratuita di compilare con funzionalità complete programmi grandi fino a 2Kbyte, il programma di questa scheda è inferiore a questa soglia e pertanto potrete ricompilare a piacimento il programma utilizzando la versione FREE di mikroBasic.

share this

share with

Follow

Tweet

Benvenuto in Massari Electronics

Questo sito di Marco Massari tratta di argomenti riguardanti elettronica, informatica, automazione e molto altro. Clicca nel menù superiore per accedere alle varie sezioni del sito, ove tra le tante realizzazioni che ho intenzione di condividere troverete alcuni dei miei progetti come Remotecontrol e MassaBus.

NEWS:

• Se vuoi seguire tutti gli aggiornamenti del sito e molto altro puoi iscriverti attraverso l'apposito box alla pagina di Facebook di Massari Electronics!
• Orologio a display nixie con microcontrollore PICOrologio a display nixie con microcontrollore PIC

ALCUNI ARTICOLI:

	Realizzazione di un fucile elettromagnetico a scopo didattico in grado di sparare piccoli oggetti ferrosi come chiodi o di magnetizzare i cacciaviti.
	Realizzazione di un lampeggiatore musicale avente la possibilità di comandare molti dispositivi come barre di led o lampade ad incandescenza. Collegandolo ad una fonte audio si potrà avere un piacevole effetto stroboscopico a ritmo di musica.
	OffTime è un programma che permette di spegnere, riavviare, sospendere o disconnettere un PC ad un orario prefissato o dopo un certo periodo di tempo impostabile. Risulta utilissimo per chi vuole spegnere il PC durante la notte. Dispone di molte funzionalità aggiuntive ed è compatibile anche con windows 7 e 8.
	Remotecontrol è un mio primo progetto riguardante i telecontrolli. Tale sistema permette di controllare a distanza, anche via internet, 8 uscite e 5 ingressi della porta parallela. Particolarmente interessanti sono le modalità di interfacciamento tra circuiti esterni e la porta parallela del PC.

Buona navigazione!

share this

share with

Follow

Tweet

I DISPOSITIVI MASSABUS SONO ORA IN VENDITA COMPLETI E AGGIORNATI QUI!

Domotica fai da te. Il sistema MassaBusèun sistema domotico adatto per controllare ed automatizzare ambienti domestici ed aziendali. Esso si basa sullo standard di comunicazione RS485, molto usato a livello industriale per la sua elevata resistenza ai disturbi induttivi e capacitivi. L’interfacciamento del sistema al computer centrale avviene tramite una porta seriale standard RS232 mentre la comunicazione nel bus viene gestita in modalità MASTER – SLAVE con una rete RS485 di tipo half-duplex che permette di estendere il sistema fino ad una distanza di 1200 metri.

Il sistema può essere usato per automatizzare i vari dispositivi presenti in una abitazione o in una azienda e per monitorare degli ambienti interni o esterni. Attualmente il sistema permette di collegare fino a 32 dispositivi (limite dettato dalla rete RS485 ma espandibile fino  a 254 attraverso opportune schede di rigenerazione del segnale) comprendenti un dispositivo MASTER composto da un PC e dei dispositivi SLAVE che permettono di gestire uscite digitali e monitorare ingressi digitali, tensioni,  temperature e altro.

Caratteristiche principali:

• Interfacciamento al computer tramite seriale RS232;
• bus di comunicazione RS485 avente alta resistenza ai disturbi;
• interfaccia RS232 isolata elettricamente dal bus di comunicazione RS485;
• sistema estendibile senza rigeneratori fino a 1200m e 31 dispositivi slave, oppure oltre 1200m e fino a  253 dispositivi slave attraverso l’uso di rigeneratori di segnale;
• Alimentazione centralizzata;
• Flessibilità, possibilità di ampliamento ed adattamento agli ambienti in cui è predisposto;
• Controllo centralizzato tramite PC predisposto con software di gestione;
• I/O isolati dal sistema;
• Utilizzo componenti di facile reperibilità;
• Massima libertà nella programmazione degli indirizzi: ogni unità indirizzabile può avere da 1 a 254 come indirizzo e l’indirizzo può essere programmato direttamente via software;
• Le schede slave dispongono di alcune caratteristiche comuni quali: un led di segnalazione attività, un interruttore che consente di attivare la programmazione degli indirizzi e un pulsante di reset per applicare i nuovi indirizzi o per effettuare il reset della scheda;
• Tutte le schede interfacciate al bus RS485 dispongono di dip switch per adattare la scheda alle caratteristiche del bus.

Il sistema MassaBus prevede come mezzo fisico trasmissivo un doppino twistato non schermato (UTP) per il trasporto dei segnali differenziali A e B ed un terzo conduttore che si occupa di interconnettere la massa in comune ai vari dispositivi. Il doppino twistato può anche essere di tipo schermato (FTP o SFTP) che permette di avere una maggiore resistenza ai rumori esterni, utile soprattutto in ambienti particolarmente rumorosi dal punto di vista elettromagnetico. Oltre ai segnali è necessario prevedere anche 2 fili conduttori che collegheranno l’alimentatore del sistema con i singoli dispositivi del bus. Questi fili andranno scelti di opportuna sezione in accordo con la dimensione e la struttura del sistema adottata.

Il sistema MassaBus strutturalmente è composto dagli elementi visibili in figura.

Comunicazione logica del sistema

Il sistema MassaBus per poter gestire la propria architettura a bus non ha bisogno solo degli accorgimenti illustrati nel capitolo precedente, ma deve anche prevedere un ben preciso protocollo di comunicazione che permetta, oltre al trasferimento dati, anche l’indirizzamento dei dispositivi presenti nel bus. Questo tipo di protocollo viene detto “protocollo di linea”. Esso è stato ideato da me e si rifà ai protocolli di linea adottati a livello 2 ISO OSI nelle reti, adattati all’utilizzo specifico nel sistema MassaBus.

Tale protocollo ha le seguenti caratteristiche:

• E’ un protocollo di linea a pacchetti organizzati in trama.
• Indirizza fino a 254 dispositivi (da1 a 254).
• Permette 63 tipi di comando ai dispositivi (da1 a 63).
• Consente l’invio di 2 campi dati ad 8 bit per pacchetto.
• Utilizza una rivelazione (ma non di correzione) degli errori attraverso operazioni di XOR, detta “Checksum”.
• Ha una trama avente 11 byte.

Il protocollo di linea applicato nel sistema prevede per la comunicazione una forma a pacchetto avente una trama (figura 2.12) composta da 11 byte, aventi ognuno una funzione specifica.

I byte hanno le seguenti funzioni nella trama:

• Start byte (0): questo byte indica l’inizio della trama.
• Indirizzo destinatario(1): è un indirizzo ad 8 bit che indica il destinatario del pacchetto.
• Indirizzo mittente (2): è un indirizzo ad 8 bit che indica il mittente del pacchetto.
• Type e zero flag (3): questo byte è composto da 2 parti: i primi due bit meno significativi rappresentano gli “zero flag”, mentre gli altri bit indicano il tipo di comando a cui si riferisce il pacchetto. Gli zero flag sono bit posti a 1 quando il campo data 1 o data2 ha valore zero (il meno significativo indica uno zero, in data 1, quando ha valore 1, il secondo bit indica uno zero, in data 2, quando ha valore 1). Questo accorgimento è necessario poiché il master utilizza linguaggi di alto livello aventi spesso problemi nel trattare dati aventi in mezzo alla trama valori nulli (pari a 0).
• Data 1 e data 2 (4 e 5): rappresentano i 2 byte inviati dal pacchetto
• Checksum low (6): contiene come bit più significativo un 1 fisso e come 4 bit meno significativi i 4 bit meno significativi del Checksum calcolato prima della trasmissione.
• Checksum high (7): contiene come bit più significativo un 1 fisso e come 4 bit meno significativi i 4 bit più significativi del Checksum calcolato prima della trasmissione. I bit posti ad 1 fisso dei due byte di Checksum low e high consentono di evitare il formarsi di byte aventi valore 0 e di sequenze simili agli end byte.
• End byte (8,9 e 10): sono una sequenza di 3 byte aventi valore 3, che non può presentarsi in altri campi altri della trama, indicanti la fine del pacchetto.

Indirizzamento dispositivi

L’indirizzamento dei dispositivi MassaBus avviene tramite un codice binario ad 8 bit, permettendo di indirizzare fino a 254 dispositivi. Tale numero massimo è dovuto alle limitazioni sull’utilizzo degli indirizzi, in particolare:

• L’indirizzo 0 non può essere utilizzato
• L’indirizzo 255 è riservato al master per comunicazioni di broadcast ( a tutti i dispositivi slave, in contemporanea) e per la programmazione iniziale degli indirizzi.

Il master deve essere unico nella rete e deve disporre di un unico indirizzo tra 1 e 254, assegnatogli prima dell’ assegnazione degli indirizzi agli slave. I dispositivi slave possono essere al massimo 253 con indirizzi da1 a 254. Questo protocollo non si interessa del mezzo fisico utilizzato, pertanto per poter usare 254 dispositivi è necessario prevedere unità di rigenerazione del segnale essendo la rete RS485 limitata, nei transceiver utilizzati, a 32 dispositivi interconnessi senza rigenerazione.

Di seguito trovate una tabella che indica le vari funzioni dei campi presenti nel pacchetto. Solitamente la comunicazione di base avviene con una chiamata del master al slave e lo slave subito risponde al master. L'unica eccezione è appunto in caso di broadcast in cui gli slave comandati non rispondono. Nelle comunicazioni normali la tipologia pacchetto tra domanda master e risposta slave, salvo errori, non cambia. A cambiare è solo il campo dati che cambia significato di volta in volta. Di seguito la tabella permette di capire l'associazione tipologia pacchetto e significato campo dati in domanda e risposta al master.

Hardware & Software attuale del sistema MassaBus, cliccare sui link per i dettagli (tutte le parti sono in fase di pubblicazione)

La parte hardware del sistema MassaBus si articola attualmente su queste tipologie di dispositivi:

• Scheda alimentazione provvede ad alimentare l’intero sistema
• Scheda di interfaccia bus provvede a convertire i segnali dell’interfaccia PC RS232 in segnali adatti al bus RS485 del sistema
• Scheda Multi I/O device permette di controllare 8 uscite a relè, 8 ingressi optoisolati e dispone di un ingresso analogico 0-5V per collegare sensori o dispositivi aventi in uscita un segnale analogico
• Scheda Mini I/O device permette di controllare 4 uscite a relè e 4 ingressi optoisolati
• Scheda Temperature sensor permette il controllo della temperatura presente in un ambiente o in un oggetto
• Scheda PAN camera control permette di controllare la rotazione di una telecamera a 360°

Inoltre è possibile arricchire la dotazione sensoriale e di interazione del sistema con appositi dispositivi accessori da collegare agli input/output del sistema:

• Termostato elettronico permette di attivare un ingresso del sistema MassaBus quando la temperatura misurata tramite un sensore NTC supera la soglia impostata tramite trimmer
• Sensore di pioggia e allagamenti permette di attivare un ingresso del sistema MassaBus quando un sensore apposito rileva la presenza di liquidi come in caso di pioggia o allagamenti

Mentre la parte software del PC si articola su questi programmi:

• MassaBus Controller Il programma di gestione della comunicazione e di tutte le schede del bus, supporta una modalità manuale dove i comandi al bus vengono dati tramite l'intefaccia del software e una modalità automatica in cui un programma esterno (es. MassaBus Application Example) tramite una connessione TCP può invocare i comandi sul bus ed automatizzare tutto il sistema.

• MassaBus Application Example è un software dimostrativo che lavora in simbiosi con il programma MassaBus Controller e permette di dare "intelligenza" al sistema domotico. Questo programma può essere sostituito con uno creato appositamente per soddisfare le proprie esigenze.

Questo progetto è stato presentato per la mia tesina di maturità, nel link qui sotto è possibile visualizzare il pdf con la tesina completa di spiegazioni dettagliate sul funzionamento di ogni scheda. Infatti troverete tutto quello che è pubblicato sul sito (e che deve essere ancora pubblicato) con alcune spiegazioni in più ed una dettagliata analisi dei software coinvolti.

TESINA MASSABUS (PDF)

share this

share with

Follow

Tweet

La tecnologia NFC (acronimo di "Near Field Communication", ovvero "Comunicazione di prossimità") risulta essere una tecnologia sempre più presente nei moderni cellulari e smartphone. Per i pochi che non la conoscessero, la tecnologia NFC permette ad un comune cellulare dotato di apposita unità, di poter comunicare attraverso un protocollo software e hardware con altri dispositivi siano essi altri cellulari, dispositivi di pagamento elettronici o TAG; la caratteristica comune è che la comunicazione avviene a corto raggio (tipicamente massimo 2cm) e secondo protocolli definiti dallo standard NFC (e da quelli da cui si basa l'NFC stesso). In pratica per utilizzare l'NFC è sufficiente appoggiare il cellulare o smartphone al dispositivo NFC ready con cui comunicare (sia essi un POS per il pagamento elettronico, un TAG o un cellulare). Attualmente l'NFC per smartphone è supportato solo da alcuni cellulari Android, Windows Phone e Blackberry.

In questo articolo non voglio descrivere l'uso di NFC con altri cellulari o con POS per il pagamento, ma l'utilizzo di NFC con i TAG, ovvero dei dispositivi di varia forma molto simili ad adesivi plastificati che permettono di memorizzare dati fruibili da tutti i dispositivi NFC e che si possono applicare sui vari oggetti.

QUI PUOI ACQUISTARE TAG NFC COMPATIBILI COME QUELLI DESCRITTI

PARLIAMO DI TAG NFC

Tag è una parola che spesso associamo a social network, ma spesso viene usato per definire dispositivi che permettono di identificare oggetti. Questi possono essere i famosi codici a barre o i più moderni QR code o anche ai moderni sistemi RFID usati moltissimo in ambito industriale e commerciale. In questo campo il TAG è un dispositivo adesivo di spessore ridotto come la carta adesiva dotato essenzialmente di un'antenna e di un chip di memoria in grado di memorizzare dati utili all'identificazione dell'oggetto. In ambito RFID esistono due grandi tipi di TAG: quelli ATTIVI dotati di batteria e in grado di comunicare a distanza e quelli PASSIVI non dotati di batteria e che vengono alimentati direttamente dal lettore stesso durante la lettura. Questi tag PASSIVI possono utilizzare una trasmissione di potenza tramite induzione magnetica (simile ad un trasformatore senza nucleo) o tramite induzione elettrica (funzionante a maggiori distanze).

Questa parentesi cosa centra con NFC? Semplice! L'NFC deriva come tecnologia da RFID, o meglio prende in uso la caratteristica comune, ovvero la comunicazione a corto raggio. Quindi l'NFC usa TAG molto simili a RFID, ma essendo solo a corto raggio i TAG sono quasi sempre passivi e a induzione magnetica con una frequenza di lavoro fissata a 13,56 MHz. Questo fa si che un TAG NFC non richieda alcun tipo di batteria e che funzioni ininterrottamente nel tempo, in quanto è il lettore stesso che appoggiandosi sul TAG lo alimenta con induzione magnetica e il TAG a sua volta mette a disposizione le sue funzionalità al lettore (che può anche scrivere dati al suo interno). I TAG NFC in commercio possono essere quasi tutti riscritti anche più volte e possono anche essere resi di sola lettura attraverso accorgimenti descritti in seguito. 
Ricapitolando un TAG NFC non è altro che una piccola unità di memoria che può comunicare con un lettore (es. smartphone) per leggere/scrivere il suo contenuto. Semplificando possiamo paragonare un TAG NFC al classico QR code che permette di memorizzare dati in un dispositivo da applicare ad un oggetto.
I vantaggi, però, rispetto al QR code sono molto evidenti:

• Possibilità di riscrivere i dati più volte
• Non richiede lettori ottici o fotocamere ma solo un dispositivo lettore NFC
• Non richiede elaborazione dell'immagine (utile nei sistemi embedded a bassa potenza)
• Non richiede particolari condizioni di luminosità
• Non richiede il puntamento perfetto di una figura
• Negli smartphone non è necessario attivare nessun software per leggere il TAG in quanto il lettore NFC viene abilitato direttamente a schermo attivo
• Possibilità di occultare il TAG in posti non visibili

TAG NFC, QUESTIONE DI MEMORIA

 La quantità di memoria è un punto fondamentale del TAG, cioè la quantità di dati che è possibile memorizzare al suo interno, tale dato dipende dal chip NFC che il TAG utilizza. Le famiglie di chip più famose e utilizzate sono:

• Chip "Ultralight" con 46 Byte di memoria
• Chip "NTAG203" con 137 Byte di memoria
• Chip ad 1 KByte di memoria

Ma di quanta memoria si ha necessità? Ovviamente dipende dal caso di utilizzo. I TAG NFC possono memorizzare informazioni varie quali testo, URL internet, numeri telefonici, coordinate geografiche e addirittura vcard (simili ad un biglietto da visita elettronico). Per quanto riguarda URL e numeri di telefono sono spesso sufficienti i primi due chip elencati sopra. Mentre per testi e vcard (molto esose di memoria) è quasi obbligatorio usare i chip NFC a 1KByte.

GESTIRE I TAG NFC

Con i moderni smartphone gestire i TAG NFC è una attività molto semplice. Sia gli OS Blackberry, Windows Phone e Andoid supportano nativamente, dietro esplicito consenso dell'utente e solo a schermo attivo, tutte le principali funzioni dei TAG NFC quali per esempio il puntamento ad una pagina web, l'invio di un SMS, l'effettuazione di una chiamata ad un numero specificato etc. Per scrivere i TAG NFC invece è necessario dotarsi di apposite App in grado di svolgere questa funzione. Di seguito ne elenco alcune per Android e Windows Phone.

Android: 

• NFC Task Launcher
• NFC TagWriter by NXP

Windows Phone:

• NFC Interactor
• Nokia NFC Writer

Tutte queste App, chi più chi meno, vi permettono di gestire la scrittura di contenuti su NFC. Alcune App addirittura vi permettono di bloccare la riscrittura sul TAG, utile in luoghi pubblici per tutelarne il contenuto da riscritture successive.

IDEE DI UTILIZZO DEI TAG NFC

Di seguito descriverò alcune idee di utilizzo della tecnologia NFC. Spesso in internet si associano i TAG NFC ad utilizzi pubblicitari o per modificare le funzioni del telefono in automatico, qui invece voglio descrivere come l'NFC può fare da ponte tra oggetti fisici e virtuali in uno scenario di domotica, ovvero l'elettronica applicata per la casa e l'ufficio. In questo contesto il TAG diventa un oggetto fisico che ci permette di fare qualcosa, lo smartphone diventa il mezzo e un sistema elettronico dedicato si occuperà di attuare i comandi.

Ovviamente tra il TAG e lo smartphone (mezzo) c'è l'NFC, mentre tra lo smartphone e il sistema di attuazione ci deve essere un canale che permetta di segnalare le operazioni, in particolare ad oggi possiamo usare chiamate, sms, siti internet, email. In questo contesto analizzerò in particolare un canale creabile tramite chiamata e un canale creabile tramite sito web locale, nulla vieta di fare le stesse cose tramite SMS o email. 

• IL TAG APRICANCELLO

Oggi in molti luoghi sono presenti cancelli automatici e per l'apertura fino a poco tempo fa era necessario dotarsi o di una chiave o di un telecomando. Entrambe le soluzioni con l'avvento dei cellulari e degli smartphone sono diventate scomode in quanto sia la chiave che il telecomando debbono necessariamente essere presenti in tasca o nel portaoggetti della macchina per poter essere usati. Invece da alcuni anni esistono sia sistemi embedded che sistemi software che permettono di aprire il cancello tramite una comune chiamata. Questo fa si che il cellulare o lo smartphone diventi un vero e proprio telecomando che ovviamente già oggi portiamo sempre con noi. Ma come funziona ciò? E LA SICUREZZA? Il funzionamento è tanto semplice quanto geniale in quanto tutti i dispositivi del genere reagiscono ad una chiamata senza rispondere ma analizzando il numero (ovvero il Caller ID), se questo corrisponde ad un numero preimpostato nella rubrica dei numeri abilitati ad aprire il cancello (i numeri associano la sim usata) allora il sistema provvede a chiudere un relè che a sua volta è collegato al contatto di apertura cancello. Il fatto che il dispositivo non risponda alla chiamata e riattacchi immediatamente permette di tenere impegnata la linea al minimo e permette di evitare i costi della chiamata in quanto la comunicazione non avviene mai. L'unica accortezza è ricaricare anno per anno la sim di un importo minimo per permettere di posticiparne la scadenza. Tale soluzioni è molto più sicura di qualsiasi telecomando in quanto il numero è nostro e non può essere clonato senza eseguire procedure che risultano più dispendiose che scavalcare il cancello (o abbatterlo direttamente).

Per aprire il cancello, in conclusione, è sufficiente chiamare tramite il proprio cellulare autenticato il dispositivo. Questo implica di dover memorizzare un numero in rubrica da tenere sempre a portata di uso. Con il TAG NFC è possibile inserire il numero nel TAG e apporre il tag nel cruscotto della macchina o nel portachiavi. Quando vogliamo aprire il cancello in ogni parte del mondo (non solo a 50m massimi come con i classici telecomandi) sarà sufficiente appoggiare lo smartphone sul TAG e immediatamente effettuare la chiamata. Semplice e veloce.

Sotto potete vedere lo scenario indicato e la strumentazione. Per quanto riguarda io applico già questo tipo di utilizzo tramite il sistema domotico MassaBUS presente in questo sito. E' sufficiente dotare il server domotico di un modem GSM anche di seconda mano (I modem TC35 Siemens usati si trovano facilmente e costano pochissimo, sono molto affidabili, vengono dismessi dagli utilizzatori perché non supportano la tecnologia GPRS che però in questo scenario di utilizzo non serve a nulla) e attuare l'attivazione del relè tramite una scheda di output. La lista dei numeri di cellulare può essere gestita per abilitare o disabilitare utenze (pensate ad un'azienda o ad un condominio con cancello automatico condiviso).

• COMANDI TRAMITE SITO INTERNET 

Prendiamo in considerazione sempre il server domotico o il sistema embedded che gestisce la casa (riscaldamento, antifurto, illuminazione), con NFC e smartphone possiamo cambiare o far cambiare lo stato delle impostazioni della casa in maniera semplice e veloce senza digitare alcun URL! Come? Innanzitutto è necessario implementare un server web nel sistema domotico e creare un applicazione "server-side" che si occupi di ricevere i comandi da URL tramite i metodi GET o POST ampiamente conosciuti da chi sviluppa per il WEB. L'applicazione server può essere realizzata con il linguaggio o metodo preferito (PHP, Perl, CGI...) e non fa altro che attuare i cambiamenti al cuore dell'applicazione domotica. Per la sicurezza consiglio di prevedere l'accesso solo tramite rete locale sotto rete wifi protetta. Nel TAG NFC è necessario salvare l'URL dell'applicazione web sul vostro server a cui potrete mettere i parametri tramite il metodo GET, in particolare il comando da eseguire. Poi se il TAG controlla qualcosa di critico o è esposto all'esterno è assolutamente consigliabile richiedere una password dopo la lettura del TAG. Esempio tipico è l'attivazione/disattivazione dell'antifurto a casa. Niente più codici da inserire nella tastiera dell'allarme o telecomandi da portarsi dietro ma un TAG NFC con memorizzato il comando. Quando l'utente leggerà tramite il proprio smartphone il TAG automaticamente il cellulare andrà nella pagina di ricezione comando dove chiederà di inserire la password di autenticazione. Ovviamente se il comando è solo previsto in locale tramite wifi per sicurezza è necessario che lo smartphone si colleghi in automatico alla rete wifi, cosa che però i moderni smartphone fanno tranquillamente autonomamente. La sicurezza è garantita dall'accesso nella rete wifi e dalla password per abilitare il comando nell'applicazione WEB.
Sotto una foto mostra lo scenario di utilizzo.

Qui potete trovare un esempio di applicazione PHP che viene eseguita lato server. Per semplicità la password è statica e memorizzata in sorgente, la pagina è un classico form con nome utente e password e il nome utente (con il comando) possono essere passati direttamente con il metodo GET dall'URL salvato nel TAG NFC. L'attuazione del comando può essere fatta via PHP con l'uso di socket TCP o il richiamo di applicazioni tramite shell.

CLICCA QUI PER VISUALIZZARE IL CODICE PHP (FORMATO PDF)

Di seguito è possibile scaricare il sorgente in PHP

DOWNLOAD SORGENTE PHP

BUON LAVORO!{jcomments on}

share this

share with

Follow

Tweet