Gateway

Generalità

Un gateway è un estensione software di BIGStudio2 (costituita da un servizio Windows) che si occupa della gestione di un particolare apparato hardware o bus. Abbiamo quindi la configurazione dei gateway relativi a:

• bus KNX / Konnex

• ADS

• BACNET

• Blue Wave

• Dorma kaba saflok system

• GSM

• IntesisWMP

• Lora

• M-Bus

• Modbus

• Riconoscimento targhe

• SaltoIS

• Telegram

• Wiegand

Configurazione gateway

Per attivare e configurare un nuovo gateway si può accedere alla sezione Gateways:

Figura 17

In questa sezione sono elencati i gateway attivabili sul software: per ogni gateway è possibile attivare una o più istanze.

Questa sezione del software è utilizzabile con successo solo se BIGStudio2 è avviato come amminstratore.

Ogni gateway è colorato in base alla possibilità o meno di attivarla:

• Verde: il gateway è abilitabile con licenza attuale

• Grigio: il gateway non è abilitabile con la licenza attuale

Per ciascuna istanza di gateway è possibile definire:

• InstanceGUID: identificativo univoco dell’istanza

• Nome

• PC installazione: nome e workstation GUID che identifica il pc su cui sarà avviato il gateway; la lista è caricata dalla tabella WORKSTATIONS

• Attivo: indica se il gateway è attivo o meno

• Stato: si veda la colorazione dei gateway

• Pc installazione: sempre LOCALHOST

Tramite i pulsanti presenti nel pannello strumenti è possibile:

Figura 18

1. Aggiungere una nuova istanza di un gateway: selezionando il gateway di interesse e premendo Nuovo viene creato un nuovo gateway

2. Eliminare una istanza preesistente: selezionando l’istanza desiderata si può eliminare il gateway e tutti gli indirizzi ad esso associati.

3. Inviare modifiche al server: nel momento in cui è stata effettuata una modifica sui gateway è necessario informare il server delle variazioni

4. Riavviare il servizio associato al gateway in caso di anomalia

5. Stoppare il servizio associato al gateway

Per configurare un nuovo gateway è necessario:

• Avviare BIGStudio2 come amministratore

• Recarsi nella sezione dei gateway

• Selezionare la tipologia di gateway di cui si vuole creare una nuova istanza

• Premere Nuovo

• Definire Nome, ip e porta del gateway

• Premere Invia modifiche.

Il software si occupa in automatico di avviare il servizio di windows associato e caricare la prima configurazione di default (SOLO SE BIGSTUDIO E’ AVVIATO COME AMMINISTRATORE).

Nel momento in cui si elimina l’istanza di un certo gateway vengono eliminati anche tutti gli indirizzi, i dispositivi e qualsiasi informazione ad esso associata.

KNX

Nella sezione KNX è possibile configurare il gateway con il bus KNX.

Per ogni gateway esiste una sezione comune di configurazione, che si trova, una volta selezionato il gateway, in alto nella colonna di destra della finestra di BIGMS.

Figura 19 - Impostazioni generiche che gateway

Dato che il software può gestire per ogni tipologia di gateway più gateway, è presente una combobox dalla quale selezionare il gateway che si desidera configurare. Viene visualizzato il nome e, tra parentesi, la prima parte del suo GUID, cioè l’identificativo alfanumerico univoco che lo identifica.

E’possibile attivare o disattivare il gateway. Inoltre viene mostrato lo stato di connessione TCP tra il Master Gateway e il gateway.

Le altre informazioni, non modificabili, sono il nome, l’IP e la porta di ascolto del gateway.

Figura 20 - Opzioni gateway

Esiste quindi una sezione sempre presente, ma diversa da gateway a gateway, nella quale configurare alcune caratteristiche specifiche del gateway in esame.

Nel caso di un gateway KNX queste caratteristiche sono:

• Notifica indirizzi di gruppo non definiti dalla configurazione: se abilitata fa si che anche indirizzi di gruppo non presenti nel progetto ETS importato vengano comunque rilevati e trasmessi al software per un eventuale monitoraggio nella barra di stato inferiore

• Aggiorna indirizzi di gruppo correlati: se abilitato vengono considerate le correlazioni tra indirizzi determinate dalla configurazione del progetto ETS per cui, la modifica del valore di un indirizzo a seguito di un telegramma su bus, fa sì che a livello software lo stesso valore venga anche applicato a tutti gli indirizzi correlati.

Importazione progetto ETS

La configurazione della sezione KNX consiste essenzialmente nell’importazione di un progetto ETS, che può essere realizzato con ETS3, 4, 5 o 6. Nel caso di ETS3 l’esportazione dei file necessari da importare in BIGMS è piuttosto complessa, ed è illustrata in appendice a questo manuale. Nel caso di esportazione da ETS4, 5 o 6 è invece molto semplice: basta esportare il file knxproj. Visto che sia ETS4, 5 e 6 esportano un knxproj è lasciato all’utente il compito di saperlo in anticipo e selezionare l’opzione corretta.

Figura 21 - Strumenti configurazione KNX

Premendo i tasti Importa (da ETS4 o 5 o 6) viene richiesto di selezionare un file kxnproj.

Inoltre viene richiesta l’eventuale password del progetto ETS e il numero di caratteri finali da estrarre dal nome ambiente definito in ETS per definire il nome breve dell’ambiente in BIGStudio.

Figura 22 - Selezione file knxproj

Una volta terminata la procedura di importazione del file vengono popolate le 3 sezioni che rappresentano la configurazione KNX:

• Aree

• Ambienti

• Indirizzi di gruppo

La quarta area (Dispositivi) rappresenta il database di dispositivi riconosciuti da BIGStudio. Si tratta in particolare di dispositivi di controllo accessi KNX. Riconoscendo questi dispositivi vengono determinati gli indirizzi di gruppo specifici da usare per la gestione del sistema di controllo accessi (aggiunta e rimozione dei permessi di accesso, registrazione dello storico accessi, configurazione delle fasce orarie, ecc.)

Figura 23 - Configurazione KNX

Aree

La finestra Aree (in alto a sinistra) contiene le informazioni che in ETS si ritrovano nella vista Building. L’elemento radice è l’edificio, che si divide in piani, camere, ecc.

Figura 24 - Proprietà aree

Le proprietà di un’area sono:

• Descrizione da importazione ETS, non modificabile

• Descrizione area, personalizzabile dall’utente

Figura 25 - Strumenti configurazione aree

Lavorando nella sezione aree è possibile decidere di eliminare un’area o l’ambiente selezionato, ma anche di creare una nuova area o un nuovo ambiente. Anche se tecnicamente possibile, questa non è mai un’operazione consigliata. La cosa migliore è sempre modificare il progetto ETS in modo che questo rifletta sempre la reale configurazione dell’impianto e quindi reimportare il progetto ETS in BIGMS.

E’possibile reimportare il progetto ETS infinite volte. Occorre tenere presente che una reimportazione non cancella mai alcun dato, ma aggiunge solo elementi mancanti (siano essi aree, ambienti, dispositivi o indirizzi di gruppo).

Nel caso delle aree e degli ambienti l’unica informazione univoca che permette di correlare quanto già importato in BIGMS e quanto presente nel nuovo progetto ETS è il nome. Quindi la modifica a nomi di ambienti nel progetto ETS e la successiva importazione comporta la creazione di un nuovo ambiente nella configurazione BIGMS. Questo nuovo ambiente sarà ovviamente relazionato ai dispositivi come definito nel progetto ETS. Ne consegue che il vecchio ambiente sarà privo di dispositivi; esiste il rischio che siano già state create tessere con permessi di accesso per l’ambiente ora «vuoto». Queste tessere continuano a funzionare, in quanto la memorizzazione dei codici tessera avviene sui dispositivi stessi. Eliminando il permesso di accesso al vecchio ambiente non accade però nulla (cioè le tessere continuano ad avere accesso) in quanto il software cerca per quell’ambiente i dispositivi da cui rimuovere i codici tessera, ma non trova nulla, in quanto questi dispositivi sono ora associati ad un ambiente con un nuovo nome.

Il consiglio è quindi quello di fare particolare attenzione ai nomi degli ambienti, in particolare evitare di modificare questi nomi in ETS (e poi reimportare il progetto in BIGMS) dopo aver creato tessere per l’accesso alle camere!

Se con BIGMS si modifica il nome di un ambiente, questo viene salvato e visualizzato come descrizione «custom» per quell’ambiente. Il software mantiene in memoria il nome originale ricavato dall’importazione ETS per poter, in caso di reimportazione, trovare la corretta corrispondenza tra ambienti ETS e ambienti BIGMS.

Ambienti

La finestra Ambienti (in alto a destra) contiene l’elenco di tutti gli ambienti definiti con ETS tramite la vista Building, siano essi camere, aree comuni o locali tecnici.

Figura 26 - Proprietà ambiente

Le proprietà di un ambiente sono:

• Nome ambiente da importazione ETS, non modificabile

• Tipologia ambiente, personalizzabile in:

  • Area comune

  • Camera

  • Invisibile

  • Area tecnica

  • Custom

• Descrizione ambiente, personalizzabile dall’utente

• Descrizione breve ambiente (numero di camera)

Le proprietà di un ambiente sono disponibili allo stesso modo sia selezionando l’ambiente nella vista aree, che selezionandolo nella vista ambienti.

Per ogni ambiente sono elencati i dispositivi in esso contenuti, sia che si tratti di dispositivi riconosciuti tramite il database interno di BIGMS, sia che si tratti di dispositivi non presenti in questo database.

I dispositivi riconosciuti hanno una loro specifica icona:

Figura 27

Figura 28

Figura 29

Figura 30

che rappresenta la tipologia di dispositivo (lettori di tessere, tasche porta tessere, termostati, tastierini numerici, ecc.)

I dispositivi non presenti nel database, ma comunque riconosciuti e per i quali vengono caricati tutti gli indirizzi di gruppo associati, hanno questa icona:

Figura 31 - Icona usata per dispositivi KNX non presenti nel database BIGMS

Figura 32 - Elimina ambiente o dispositivo

Selezionato un dispositivo o un ambiente è possibile eliminarlo.

Figura 33 - Nuovo ambiente

Senza alcuna selezione è possibile creare un nuovo ambiente. Il nuovo ambiente può essere inserito in un’area trascinandolo nell’area opportuna della vista aree.

Dispositivi

Rappresenta il database dei dispositivi riconosciuti. Il primo livello dell’albero è costituito dai produttori dei dispositivi. Per ogni produttore sono elencati i prodotti inseriti nel database. Dopo l’importazione, per ogni codice prodotto, sono elencati i dispositivi con quel codice inseriti nel progetto ETS.

Figura 34 - Proprietà dispositivo

Per i dispositivi sono visualizzate le proprietà caratteristiche anagrafiche (descrizione e indirizzo fisico) e gli indirizzi di gruppo che permettono il corretto funzionamento della comunicazione con il dispositivo per la gestione del controllo accessi.

In Figura 23 si fa particolare riferimento ad un lettore del sistema di controllo accessi ABB. In questo particolare caso, essendo il databank ETS identico per lettore e tasca (è il dispositivo stesso che in base al firmware caricato esegue una o l’altra funzione) il software non è in grado di distinguere in fase di importazione di quale dispositivo si tratti. Questo è l’unico caso in cui la corretta assegnazione lettore o tasca deve essere confermata o modificata dall’utente.

Indirizzi di gruppo

Rappresenta la vista Indirizzi di gruppo presente in ETS.

Figura 35 - Proprietà indirizzo

Le proprietà di un indirizzo di gruppo KNX sono:

• Nome

• Formato dati

• Tipo di oggetto

Il formato dati è riconosciuto correttamente se quell’indirizzo è associato ad un dispositivo registrato nel database di BIGMS. Nel caso in cui l’indirizzo sia associato ad un dispositivo non presente nel database viene riconosciuta in modo corretto la dimensione del dato. Nell’esempio di Figura 24 si tratta di un dato costituito da 3 byte. E’possibile per l’utente modificare questa definizione, ad esempio andando a selezionare un altro tipo di dato a 3 byte, come il «11.001 3-byte date». La modifica del formato è lasciata assolutamente libera, ma è ovviamente consigliato non fare alcuna modifica senza la competenza necessaria.

Il tipo di oggetto rappresenta un’informazione di «alto livello» utile al supervisore, ma non utilizzata per l’elaborazione del dato KNX. Ad esempio un indirizzo di gruppo ad 1 bit (indirizzi che costituiscono la maggioranza degli indirizzi di un impianto) sarà a livello fisico sempre, ovviamente, valorizzato con un bit di valore «1» oppure «0». A livello logico possiamo attribuire molteplici significati diversi ai valori «1» e «0» come ad esempio:

• Acceso/accendi = 1, spento/spegni = 0

• Aperto/apri = 1, chiuso/chiudi= 0

• Abbassato/abbassa = 1, alzato/alza = 0

• Inverno = 1, estate = 0

• On = 1, off = 0

• Avanti = 1, indietro = 0

I tipi di oggetto sono definiti all’interno del database di BIGStudio.

La corretta assegnazione di questo significato ad un indirizzo non comporta alcuna modifica o malfunzionamento a livello di impianto KNX, ma facilita la lettura dello stato del sistema e il suo comando attraverso il supervisore.

Connsessione al bus KNX

Per ogni gateway deve essere solitamente definita la modalità di connessione al bus o dispositivo controllato. Le possibilità di connessione sono quelle utilizzabili anche tramite ETS, rese disponibili attraverso i driver Falcon.

• USB

• IP

• Seriale

Figura 36 - Connessione al bus

KNX Secure

Figura 37 - Strumenti configurazione Modbus

Per l’abilitazione del KNX Secure è necessario:

• Abilitare la spunta Abilitazione KNX Secure

• Indicare gli indirizzi fisici che possono essere usati dall’interfaccia IP; l’interfaccia non gestisce automaticamente l’indirizzo IP ma lo richiede in fase di configurazione della connessione; BIGStudio itera su quelli indicati

• Indicare la password usata in fase di esportazione del keyring

• Caricare il keyring: selezionando il file questo viene caricato nella memoria di BIGStudio

Modbus

Il gateway Modbus permette la lettura/scrittura di dati Modbus collegandosi a dispositivi seriali o IP. Partendo dalla tipologia di collegamento, si può definire una nuova interfaccia seriale, sulla quale saranno collegati uno o più slave Modbus identificati da uno UnitID.

Figura 38 - Proprietà slave Modbus RTU

Oppure si può definire uno slave Modbus ethernet.

Figura 39 - Proprietà slave Modbus ethernet

Una volta definiti i dispositivi Modbus, siano essi seriali o IP, deve essere definita la mappa della memoria Modbus dove andare a leggere / scrivere valori. Siccome in alcuni casi i dati sono molti, è possibile organizzarli in cartelle.

Con la definizione di un indirizzo di memoria Modbus si va a indicare un’area di memoria nella quale è possibile leggere e/o scrivere. Quest’area di memoria avrà un indirizzo iniziale e sarà costituita da n word (16 bit), specificati nella colonna Quantità. La funzione Modbus da utilizzare è definita nella colonna Funzione. Sono disponibile le seguenti funzioni:

• 0x01 Read Coils

• 0x02 Read Discrete Inputs

• 0x03 Read Holding Register

• 0x04 Read Input Register

Figura 40 - Configurazione Modbus

Definito un indirizzo, cioè un’area di memoria, questa conterrà n variabili o range di indirizzi. All’interno dell’area di memoria ogni variabile si trova in una posizione specificata dal suo bit iniziale (colonna «Dal bit») e occupa n bit (colonna «Lunghezza»).

Le proprietà da definire per una variabile sono:

• Dal bit: bit iniziale della variabile all’interno dell’area di memoria che inizia all’indirizzo definito nella griglia superiore

• Lunghezza: numero di bit che compongono la variabile

• Formato dati alto livello: definisce come interpretare i bit della variabile. La possibilità di definire una tipologia oppure no dipende dalla lunghezza in bit della variabile. Le possibili opzioni sono:

  • BOOLEAN

  • INTEGER

  • STRING

  • TIME

  • FLOAT

• Segno: determina se il dato INTEGER deve essere considerato con segno oppure no

• Reverse block: determina se i byte di dato ricevuti da questo indirizzo devono essere scambiati a seguito della ricezione

• Fattore: indica un fattore per cui moltiplicare il dato letto

• Offset: indica un offset da sommare al dato letto

• ID: è un numero univoco che identifica la variabile. Concorre alla composizione dell’identificativo vero e proprio

• Identificativo: ottenuto dal nome del dispositivo Modbus definito precedentemente + «/» + ID

• Tipologia: come nel caso degli indirizzi di gruppo KNX, la tipologia assegna un significato logico ad una variabile Modbus per rendere più intuitivo l’uso del supervisore.

M-Bus

Il gateway M-bus permette la lettura dei valori contenuti nella memoria dei contatori M-bus.

Figura 41 - Strumenti M-bus

Gli strumenti relativi alla configurazione M-bus permetto la definizione di un nuovo contatore M-bus, la sua duplicazione o cancellazione.

Tipi di dispositivi

E’anche possibile importare una nuova tipologia di contatore M-bus non disponibile nel database di BIGStudio. Il file di configurazione che definisce una nuova tipologia è un file XML. Per la sua definizione rivolgersi al servizio di assistenza clienti BIG.

I tipi di dispositivi importati sono visibili nella tab tipi di dispositivi: per ciascun dispositivo è possibile modificare:

• Nome del dispositivo, per aggiustare eventuali errori di importazione

• Nome di ogni proprietà: da sfruttare nel momento in cui si identificano le proprietà per indicare un nome user friendly (ad esempio Volume acqua calda invece di Volume1)

• Contatore: per far sì che l’indirizzo generato per ogni dispositivo di questa tipologia associato a questa proprietà sia utilizzato come contatore dell’ambiente associato al dispositivo nelle note spese

• Fattore: per applicare un eventuale fattore a tutti gli indirizzi che saranno generati a partire da questa proprietà

• Unità di misura: per applicare un’unità di misura di default a tutti gli indirizzi che saranno generati a partire da questa proprietà

• Profilo di pagamento: per applicare un profilo di pagamento di default a tutti gli indirizzi che saranno generati a partire da questa proprietà

Ogni volta che vengono modificati i campi Contatore, Unità di misura, Profilo di pagamento è necessario utilizzare il pulsante Genera contatori per aggiornare la configurazione delle note spese in base a quanto è stato configurato nei tipi di dispositivi.

Sostituzione di un contatore

Il pulsante sostituisci deve essere utilizzata quando viene sostituito un contatore MBUS: il popup che viene presentato permette di indicare l’indirizzo secondario del nuovo dispositivo montato in sostituzione di quello selezionato e si occupa di:

• Modificare l’indirizzo fisico del dispositivo

• Modificare gli indirizzi associati al dispositivo (mantenendo la precedente configurazione di letture, log, …)

• Correggere i riferimenti dei vecchi indirizzi con i nuovi (mantenendo le precedenti configurazioni) in:

  • Valori loggati

  • Scenari (comandi)

  • Note spese (indirizzi principale dei contatori e quelli usati come numeratore/denominatore)

  • Grafici (serie del grafico)

  • Supervisioni (indirizzi di stato e comando dei componenti)

  • DataProcess

In caso di sostituzione di un contatore sarà premura di chi effettua la procedura di sostituzione sul software verificare l’offset da applicare ai nuovi indirizzi visto che solitamente la contabilizzazione dei nuovi dispositivi riparte da zero. Per farlo autocalcolare si può attivare la funzione di Ripristino a seguito di reset sugli indirizzi in log; in questo modo quando viene ricevuto il primo valore dal dispositivo, inferiore al valore precedente, l’offset viene automaticamente calcolato.

Figura 42

Definito un nuovo dispositivo M-bus le informazioni richieste per la sua configurazione sono solo 3:

• Nome

• Tipo: da scegliere tra le tipologie note inserite nel software

• Indirizzo secondario: identificativo univoco stampato su ogni dispositivo M-bus

• Ambiente: se si associa un ambiente ad un contatore tutti i suoi indirizzi che hanno il flag ‘Contatore’ (dalla configurazione Tipi di dispositivi MBUS) verranno aggiunti come contatori nella configurazione pagamenti dell’ambiente associato

Configurazione generale

Figura 43 - Proprietà gateway M-bus

Oltre alle classiche proprietà dei gateway, il gateway M-bus presenta di default alcune opzioni particolari che è possibile modificare:

• Salva log di tutti i telegrammi: salva automaticamente il valore di tutti i dati letti da un dispositivo M-bus senza che venga impostata singolarmente, per ogni valore, la richiesta di salvataggio.

• Gestisci letture periodiche: è il gateway stesso che si occupa delle letture periodiche impostate (relativamente alle variabili M-bus), mentre solitamente questo compito è assolto da BIGOmnia.

• Salva comandi di lettura periodica nello storico comandi: se è impostato il punto precedente, il gateway di gestione M-bus, oltre ad inviare i comandi di lettura periodica, salva nel database di BIGStudio, nello storico comandi, i comandi richiesti.

Figura 44 - Proprietà connessione linea M-bus

Il gateway M-bus legge i dati dei dispositivi M-bus attraverso un master M-bus collegato via seriale. Per avere l’elenco dei master M-bus compatibili rivolgersi al servizio di assistenza tecnica BIG.

Saflok System 6000

La sezione di configurazione del BIG Saflok permette di settare seguenti parametri di configurazione:

• Stazione Saflok mittente [StationFromNumber]: parametro richiesto dalle specifiche di protocollo, default 0;
• Stazione Saflok destinatario [StationToNumber]: parametro richiesto dalle specifiche di protocollo, default 0;
• IP del server Saflok [SaflokServerIP]: IP della macchina dove gira il software Saflok;
• Porta del server Saflok [SaflokServerPort]: porta PMS definite dal software Saflok, default 8264;
• Password del software Saflok [SaflokServerPassword]: password del software Saflok, default user “PMS” default password “SAFLOK”;
• SaflokRoomKeyNumberLenght (numero di caratteri usati nella codifica del numero camera; se il numero camera è inferiore viene paddato con spazi sulla destra; default 5);

La configurazione permette inoltre di definire un elenco di ambienti abilitati Saflok per i quali è possibile definire la descrizione breve (numero), la descrizione, il tipo di ambiente e il pass number. Quest’ultimo viene utilizzato nelle richieste inviate al server Saflok. Per ciascun ambiente nasce un dispositivo lettore parallelo che eredita il nome dall’ambiente.

I comandi che è possibile inviare al gateway BIG Saflok passano attraverso i seguenti indirizzi:

• Command/new
  • Valore = RoomNumber|KeyLevel|EncoderStationNumber|NKeys|Checkout|Expiration|
    |PassNumberOption|PassNumbers|MagneticCardData
• Command/Duplicate
  • Valore = RoomNumber|KeyLevel|EncoderStationNumber|NKeys|Checkout|Expiration|
    |PassNumberOption|PassNumbers|MagneticCardData
• Command/Change
  • Valore = RoomNumber|KeyLevel|NewCheckout|OriginalCheckout
• Command/CheckOut
  • Valore = RoomNumber|KeyLevel
• Command/CheckIn
  • Valore = RoomNumber|KeyLevel|NewCheckOut

SALTO XS4 ProAccess Hams Industry Standard

Per il corretto funzionamento del gateway BIG Salto è necessario avviare sulla macchina server Salto l’applicazione HAMS100, alla quale il gateway si connette per procedere a scrittura/lettura di tessere.

Il software HAMS100 deve essere così configurato (da Strumenti/Configurazione/Opzioni generali):

• nella sezione PMS

Figura 45

• • Assicurarsi di selezione INDUSTRY STANDARD come protocollo
  • Specificare come protocollo di comunicazione TCP/IP
  • specificare IP e porta di ascolto, tramite il pulsate MODIFICARE (dovranno
    poi essere usati nella configurazione del gateway BIG Salto)

• nella sezione ON-LINE

Figura 46

• • Assicurarsi di selezione INDUSTRY STANDARD come protocollo

Il gateway BIG Salto necessita dei seguenti parametri di configurazione, ovvero (in tabella GATEWAYS_SETTINGS):

• SaltoISServerIP: IP o nome macchina su cui è eseguito HAMS100 (nella configurazione precedente sarebbe 127.0.0.1)

• SaltoISServerPort: porta di ascolto del protocollo IS (nella configurazione precedente sarebbe 2324)

• SaltoISRetentionMode: modalità di gestione delle scritture tessere, ovvero

  • E → Ejection. Il software HAMS100 attende la rimozione della tessera dall’encoder prima di dare l’esito dell’azione di scrittura

  • R [default e consigliato] → Retention. Il software HAMS100 invia l’esito dell’azione di scrittura senza attendere la rimozione della tessera dall’encoder

  • T → Ejection by the rear side. Come E.

• SaltoEncodedNumber: numero identificativo di chi si connette (di solito 1).

La configurazione permette inoltre di definire un elenco di ambienti abilitati Salto per i quali è possibile definire la descrizione breve (numero), la descrizione, il tipo di ambiente e il salto authorization number. Per ciascun ambiente nasce un dispositivo lettore parallelo che eredita il nome dall’ambiente.

I comandi che è possibile inviare al gateway BIG Salto sono verso i seguenti indirizzi:

• Read/Card
• Read/Track1
  • Valore = ENCODER_NUMBER
    ad esempio “1”
• Read/Track2
  • Valore = ENCODER_NUMBER
    ad esempio “1”
• Read/Track3
  • Valore = ENCODER_NUMBER
    ad esempio “1”
• Command/New
  • Valore = ENCODER_NUMBER|NUMBER OF KEY|ROOM1|ROOM2|ROOM3|ROOM4|
    AUTHORISATION_GRANTED|AUTHORISATION_DENIED|START_DATETIME|EXPIRATION_DATETIME
    |OPERATOR_DATA|TRACK1|TRACK2|TRACK3|RETURN_CARD_SERIAL_NUMBER
    ad esempio “1|1|101|102|||||1030150917|23300917|Operator||||0”
    [scrive 1 tessera per camera 101, con accesso alla 102, valida dalle 10:30 del 15/09/2017 alle 23:00 del 30/09/2017]
• Command/Duplicate
  • Valore = ENCODER_NUMBER|NUMBER OF KEY|ROOM1|ROOM2|ROOM3|ROOM4|
    AUTHORISATION_GRANTED|AUTHORISATION_DENIED|START_DATETIME|EXPIRATION_DATETIME
    |OPERATOR_DATA|TRACK1|TRACK2|TRACK3|RETURN_CARD_SERIAL_NUMBER
    ad esempio “1|1|101|102|||||1030150917|23300917|Operator||||0”
• Command/CheckOut
  • Valore = ENCODER_NUMBER|ROOM
    ad esempio “1|101”

Programmatore Salto

Per poter scrivere le tessere con il programmatore di tessere direttamente da BIGStudio è necessario configurare nei programmatori di tessere un programmatore di tipo Salto Industry Standard, che si basa su gateway, scegliendo come gateway di riferimento quello Salto.

Dalla sezione di controllo accessi è possibile scrivere una tessera con il programmatore Salto sia nel caso in cui la tessera sia abilitata su ambienti di tipo Salto, sia di tipo ABB.

Salto KS (Cloud)

Il gateway Salto KS permette di integrare le API di Salto per la configurazione in cloud dei diritti di accesso.

Il tecnico Salto si dovrà occupare di effettuare la configurazione in cloud delle serrature e dei tag presenti sull’impianto. I tag sono Mifare Desfire e non vengono scritti da BIGStudio ma solo associati agli utenti sulla base dei loro diritti di accesso.

Configurazione connessione al server Salto

• Client ID: fornito dal tecnico Salto

• Client secret: fornito dal tecnico Salto

• Username: username delle credenziali di accesso con cui si accede al portale Salto

• Password: password proveniente dalle credenziali di accesso con cui si accede al portale Salto

• Site ID: ID dell’impianto (da leggere la prima volta tramite chiamata API)

Figura 47

Se tutti i dati inseriti sono validi il pallino del gateway diventa verde.

Importazione configurazione iniziale

L’elenco di tutte le serrature, dei tag e degli utenti configurati sull’impianto sono importabili tramite i relativi pulsanti nella sezione di configurazione dell’impianto.

Se gli utenti importati hanno associato un tag viene creata e attivata una tessera corrispondente al tag dell’utente. Gli accessi e le date di attivazione e scadenza sono quelli del gruppo in cui si trova l’utente.

L’import può essere forzato manualmente nel momento in cui viene effettuata una modifica successiva sull’impianto (o vengono aggiunti dei tag).

Figura 48

Figura 49

Indirizzi

• Salto/Site/ReadLocks: scritto ad 1 per avviare l’import delle serrature, la risposta inviata dal gateway sullo stesso indirizzo è 1=Importazione iniziata, 2=Importazione terminata con successo, 3=Importazione fallita

• Salto/Site/ReadTags: scritto ad 1 per avviare l’import dei tag, la risposta inviata dal gateway sullo stesso indirizzo è 1=Importazione iniziata, 2=Importazione terminata con successo, 3=Importazione fallita

• Salto/Site/ReadUser: scritto ad 1 per avviare l’import degli utenti, la risposta inviata dal gateway sullo stesso indirizzo è 1=importazione iniziata, 2=importazione terminata con successo, 3=importazione fallita

• Salto/Site/ReadHistory: scritto ad 1 per avviare l’import degli storici, la risposta inviata dal gateway sullo stesso indirizzo è 1=importazione iniziata, 2=importazione terminata con successo, 3=importazione fallita

• Salto/Site/ReadLockInfo: ON per riempire gli indirizzi Salto/{customIdDevice}/2, Salto/{customIdDevice}/3, Salto/{customIdDevice}/4 con le informazioni riguardanti i dispositivi dell’impianto

• Salto/Site/LastDayTimeInfo: contiene la data in cui è avvenuta l’ultima richiesta sull’indirizzo ReadLockInfo

• Salto/{customIdDevice}/1: valore = tagCode_dd-MM-yyyy|HH:mm (esempio: 123456_25-08-2021|14:00) per avviare la creazione di un permesso di accesso, la modifica della data di scadenza di una tessera, l’aggiunta di una camera, lo sblocco di una tessera

• Salto/{customIdDevice}/2: contiene l’informazione riguardante lo stato (online/offline) del dispositivo con id pari a customIdDevice; online=On, offline=Off

• Salto/{customIdDevice}/3: contiene l’informazione riguardante il livello di batteria del dispositivo con id pari a customIdDevice; Scarica=0, Quasi Scarica=1, Carica Bassa=2, Carica Normale=3, Carica=4

• Salto/{customIdDevice}/4: contiene l’informazione riguardante lo stato (attivo o meno) della modalità privacy; attiva=On, non attiva=Off

• Salto/{customIdDevice}/5: valore = tagCode (esempio: 123456) per avviare la rimozione di un permesso di accesso, per bloccare una tessera, per eliminare una camera da una tessera

Controllo accessi

1. Creare il cliente

2. Creare una nuova tessera

3. Abilitare i varchi Salto: sull’abilitazione del primo varco verrà richiesto quale tag associare alla tessera logica di BIGStudio; la scelta ricade fra i tag non ancora associati ad altre tessere

4. Definire la data di scadenza

5. Attivare la tessera: l’attivazione crea sul portale di Salto l’utente, gli associa il tag, crea il gruppo di accesso su cui sono configurate le corrette serrature e definisce il periodo di accesso. Se l’utente creato non ha nome su Salto al posto del nome sarà inserito il cognome. Il nome del gruppo è dato da NomeCognome_GUID. Se un utente ha nel cognome o nel nome un apostrofo sul portale di Salto questo verrà rimosso.

In ogni gruppo creato su Salto viene inserito un solo utente e ogni utente ha associato un solo tag. Per assegnare un altro tag a un utente bisogna creare un’altra tessera, e la sua attivazione andrà a creare sul portale di Salto un nuovo utente, con associato il tag scelto, il gruppo di accesso con le corrette serrature e il periodo di accesso della tessera appena creata.

Le modifiche fatte alle informazioni dell’utente (la scadenza di una tessera, l’accesso a una camera) vengono poi propagate anche sul portale di Salto senza dover premere altri pulsanti.

Bloccare una tessera fa sì che sul portale di Salto venga bloccato l’utente a cui è associato il tag che corrisponde alla tessera appena bloccata.

Se da una tessera vengono eliminate tutti gli accessi sul portale di Salto l’utente ai cui è associato il tag che corrisponde alla tessera viene eliminato insieme al suo gruppo; invece, su BIGStudio tessera e utente rimarranno finché non verranno eliminati premendo il pulsante ‘Elimina’.

Per disassociare un tag da un utente da BIGStudio è necessario:

1. Selezionare la tessera che corrisponde al tag

2. Eliminare la tessera. Quest’azione comporterà l’eliminazione sul portale di Salto del solo utente associato al tag e del suo gruppo.

Disassociare tutti i tag da un utente consiste nell’eliminare tutte le sue carte da BIGStudio, in questo modo l’utente sul portale di Salto non sarà più presente; invece, su BIGStudio l’utente rimarrà finché non verrà eliminato premendo il pulsante ‘Elimina’.

N.B.. Le card di Salto KS non hanno tipologia.

Storici

Dopo un timer di 120 secondi dalla connessione del gateway avviene il primo download degli storici raccolti sul cloud da Salto. Finita questa importazione il timer diventa un timer in loop di un’ora e al suo scadere avviene il download degli storici. Il download comunque può anche essere forzato premendo il relativo pulsante nella sezione di configurazione dell’impianto.

Ping

È possibile effettuare il ping dei dispositivi effettuando i seguenti passi:

• Spostarsi nella sezione Configurazione

Figura 50

Figura 51

• In alto selezionare Dispositivi

• Passare nel tab Filtri

• Selezionare in gateway SaltoIS e premere il pulsante Filtra

Figura 52

• Impostare la tabella con i dispositivi nella modalità di configurazione

• Passare da filtri a strumenti

• Selezionare le righe della tabella interessate

• Premere il pulsante ‘Ping selezionati’

Figura 53

EElectron

Per utilizzare il programmatore eElectron TE00C01 è necessario effettuare una richiesta di certificato attraverso l’apposito programma (fornito direttamente dal produttore).

Generazione del certificato

Copiare il contenuto della cartella “Y:InstallEElectronLicenceRequestGenerator“ e inserirlo nella cartella del pc del cliente (es consigliato. “C:eElectron“).

Si consiglia la generazione di una cartella dedicata in quanto l’eseguibile crea dei file nella stessa posizione in cui si trova.

Il certificato generato dall’applicazione è molto importante e non va disperso in quanto è legato ai dati di fabbrica del PC su cui verrà installato il programmatore, quali MAC Address della scheda di rete assegnata e CPU ID.

In caso di sostituzione del PC, il certificato va rigenerato e deve essere eseguita una nuova richiesta ad eELectron. In tal caso, bisognerà fornire ad eElectron il vecchio file di richiesta (.req).

Per iniziare la procedura avviare il file eLicEncoderDLL.exe.

Nell’immagine sottostante viene illustrato un esempio di compilazione della form:

Figura 54

N.B. Utilizzare come cartella di output del certificato (Output folder) l’attuale cartella dove viene eseguito il programma

Premere successivamente il pulsante “Create Cert“ che verrà abilitato alla compilazione di tutti i campi obbligatori.

Nella cartella selezionata verranno generati due file, uno con estensione “.key“ e uno con estensione “.req“.

Il nome dei file generati dovrà essere usato come valore del campo “Identità” all’interno della griglia dei programmatori .

Questi file dovranno essere trasmessi a EElectron (inviarli a paolo.segu@eelectron.com) per la creazione del certificato per la macchina di installazione.

In risposta verrà restituiti due file con estensione .pem. Tra questi due file quello necessario per il programmatore è nominato come [identità del programmatore]-cert.pem (es. file in fig.2 “E1602B08-A234-48D0-9AF2-9B1949192379-cert.pem”). Il secondo file può essere cancellato.

Installazione del certificato

Per installare il certificato all’interno di BIGStudio dovranno essere eseguiti i seguenti passaggi:

1. Dopo aver abilitato il programmatore all’interno dell’apposita configurazione, copiare l’identità del programmatore da uno dei file ottenuti (es. file in fig.2 “E1602B08-A234-48D0-9AF2-9B1949192379”)

2. Spostarsi all’interno della “Configurazione/Program.tessere” e impostare il campo Identità della riga desiderata con il valore precedente

3. Copiare il campo “GUID” del programmatore interessato e spostarsi successivamente all’interno della cartella di installazione di BIGStudio → Certificates → “valore campo GUID” e al suo interno copiare il file .key (generato in precedenza atttraverso eLicEncoderDLL.exe) e il file .pem (rilasciato da eElectron)

4. Rinominare i file .key e .pem in “eelectron-cardprogrammer-cert.key” e “eelectron-cardprogrammer-cert.pem”.

N.B. Se la cartella non esiste verificare che il programmatore sia stato registrato correttamente dal software; Verificare, inoltre, che il file (creato dalle librerie di eElectron) C:ProgramDataeEncodereEncoder.ini sia valorizzato correttamente (percorsi file assoluti) dopo aver riavviato il servizio

Significato dei pallini di connessione al Gateway

• Verde: Programmatore collegato correttamente via USB e la licenza inserita è valida
• Giallo: Programmatore non collegato o licenza non valida
• Rosso: Gateway programmatore bloccato

BlueWave

Il gateway BIG BlueWave necessita dei seguenti parametri di configurazione, ovvero (in tabella GATEWAYS_SETTINGS):

• CheckGuestEscape: Controllo di fuga dell’ospite; nel caso in cui il gettone bluewave rimanga vicino passi entro una certa distanza dal sensore viene considerato come in fuga.

• GuestEscapeWindow: Finestra temporale di attesa di un assistente prima di fare scattare l’allarme per una eventuale fuga; l’avvicinamento del gettone dell’ospite viene considerato come fuga solo se nei precedenti o successivi X secondi nessun gettone associato ad assistenti si è avvicinato al sensore

• ListeningTCPPort: porta su cui è configurato il software FlyStart (si suppone che sia in esecuzione sulla stessa macchina del gateway).

Per il corretto funzionamento del gateway BlueWave è necessario che sulla macchina su cui è in esecuzione il gateway BlueWave sia in esecuzione il software FlyStart, configurato come segue:

La configurazione del gateway BlueWave prevede la configurazione dei suoi dispositivi e dei gettoni:

Configurazione dispositivi

I dispositivi derivano dall’importazione ETS, ma è possibile configurare:

• ID: usato nella definizione degli indirizzi (Access code, Valid access e Alarm);

• Indirizzo: identificativo del dispositivo;

• Distanza attivazione: distanza massima a cui il gettone è considerato come abbastanza vicino per far scattare l’allarme;

• Tempo di mascheramento[s]: se un gettone viene rilevato N volte in un intervallo di tempo minore del tempo di mascheramento viene segnalato solo il primo.

Per ogni dispositivo nasce un nodo identificato dall’ID del dispositivo contenente i tre indirizzi associati (Access code, Valid access e Alarm); l’aggiornamento degli indirizzi è demandato al gateway, pertanto solo con il gateway in funzione è possibile avere gli indirizzi allineati con la configurazione.

Configurazione gettoni

Una volta definiti i dispositivi è possibile definire i gettoni:

• Identificativo gettone: numero della tessera nata in associazione al gettone, calcolato a partire dall’identificativo del gettone fornito da BlueWave.

• Tipo gettone: ospite o personale;

• Ospite/Personale: figura associata al gettone.

Ogni volta che nasce un gettone nasce in associazione una tessera con gli stessi dati.

PBX

Il Gateway PBX permette di interfacciare BIGStudio con un centralino in modo da poter effettuare e ricevere chiamate.

Configurazione elenco degli interni

La configurazione del gateway permette di definire l’elenco degli interni che il centralino PBX dovrà gestire; è possibile aggiungere, duplicare e rimuovere interni tramite gli appositi bottoni nel menù strumenti e per ciascun interno è possibile definire:

• Descrizione: descrizione testuale dell’interno;

• Interno SIP: interno;

• Password: usata con il numero per l’accesso al centralino SIP

• Mantieni registrato: check che permette di definire gli interni che il centralino SIP mantiene registrati.

• Usa come mittente: alcuni centralini non necessitano di un singolo mittente per eseguire la chiamata ma possono scegliere il primo libero fra un insieme di mittenti. Per inserire l’interno nell’elenco dei numeri da usare come mittente si può usare questo check.

Per inserire l’interno nell’elenco dei numeri da usare come mittente si può usare questo check.

Figura 55

Per ogni interno definito nasce un nodo nell’albero degli indirizzi, nella sezione riservata al gateway, al di sotto del quale nascono i seguenti indirizzi:

• SIP/InternoSIP/1: Call: Indica l’utilizzo nell’InternoSIP come mittente di una chiamata che ha come destinatario il valore dell’indirizzo.

Figura 56

Configurazione gateway SIP

Il gateway SIP richiede inoltre la configurazione delle seguenti opzioni:

• numero di chiamate contemporanee gestite;

• IP del centralino (se web)

• Porta del centralino (se web)

• Timeout interruzione chiamata in corso in caso di mancata risposta (in secondi)

• http/HTTPS (se centralino web)

Figura 57

Nel database gli interni SIP sono salvati nella tabella MEDIA con kind SIP e con la seguente corrispondenza colonna/campo:

• DESCRIPTION: Descrizione

• PROPERTY_1: Interno SIP

• PROPERTY_2: Password

• PROPERTY_3: Mantieni registrato

• PROPERTY_4: Usa come mittente (se non è definito il mittente della chiamata nella notifica il gateway dovrà sceglierne uno fra quelli associati a lui (tramite la property_5) con property_4 = true

• PROPERTY_5: InstanceGUID del gateway di riferimento

Le operazioni possibili da effettuare in questa sezione sono:

Figura 58

• Nuovo: per l’inserimento di un nuovo numero

• Duplica: per la duplicazione dei numeri selezionati

• Elimina: per la cancellazione dei numeri selezionati

• Importa da CSV: genera nuovi numeri PBX in base al csv scelto; il csv deve avere solo 2 colonne:

  • Interno SIP

  • Descrizione del numero

• Genera notifiche da CSV: genera nuove notifiche in base al csv scelto; il csv deve avere 3 colonne:

  • Interno SIP mittente (vuoto se nessun mittente specificato)

  • Interno SIP destinatario

  • ID della fascia oraria di BIGStudio associata (vuoto se nessuna fascia oraria) (da vedere nel db di BIGStudio prima dell’importazione

La notifica generata si chiama DescrizioneInternoSIP (InternoSIP) NomeFasciaOraria

Inoltre nella TestApplication è presente una voce “genera allarmi da csv” che, preso un csv con colonne: 1. Nome logica 2. InstanceGUID del gateway dell’indirizzo 3. Indirizzo Definisce delle logiche/allarmi con condizione [indirizzo = valore di allarme], dove il tipo logica/allarme è definibile nel form, come il valore di allarme (di default 1).

GSM

SiemensMC35i e DigicomPocketGSM

Il gateway GSM permette di interfacciare BIGStudio con un modem GSM, in modo da poter inviare e ricevere messaggi e chiamate attraverso il modem.

Per il corretto funzionamento del gateway è necessario configurare nelle opzioni il tipo di modem GSM usato e le caratteristiche della sua connessione seriale, in particolare nella tabella GATEWAY_SETTING dovranno essere presenti:

• GSM_Kind

• GSM_DeviceManufacturer

• GSM_DeviceModel

• GSM_BaudeRate

• GSM_DataBits

• GSM_StopBits

• GSM_Parity

• GSM_HandShake

• GSM_CommandWrite

• GSM_CommandRead

• GSM_TransactTimeout

• GSM_TimeoutMultiplier

• GSM_TxFlowRTS

• GSM_TxFlowDTR

• GSM_RxTerminator

• GSM_SendOnReceive

• GSM_TxTerminator

• GSM_TerminatorRegEx

Figura 59

VirtualGMS

Il VirtualGSM permette di interfacciare BIGStudio con un servizio terzo, Vonage, in modo da poter inviare messaggi.

Figura 60

Figura 61

Quindi per poter utilizzare il VIrtualGSM è necessario fare un account sul Vonage (Crea Account). L’account così creato avrà un credito iniziale di 2 €. È possibile eseguire l’upgrade dell’account cliccando in alto a sinistra sul credito (rettangolo verdenella figura in alto a destra).

Per il corretto funzionamento del GSM Virtuale è necessario inserire nel pannello ‘Connessione al GSM’ i dati del servizio. Tali dati sono:

• API Key: utilizzata insieme all’API Secret per autenticare le richieste API; ottenibile andando nella sezione API Settings (riquadro verde nella figura sottostante);

• API Secret: utilizzata insieme all’API Key per autenticare le richieste API; ottenibile andando nella sezione API Settings (riquadro verde nella figura sottostante);

Figura 62

• [Opzionale] Nome mittente: nome del mittente dei messaggi che verranno inviati; come valore di default è impostato BIGStudio; deve contenere lettere e/o numeri, no spazi, e non deve essere più lungo di undici caratteri.

Figura 63

Indirizzi

Per ogni modem (e di conseguenza ogni gateway) nascono i seguenti indirizzi:

• GSM/1 [Registrato]: se il modem è registrato alla rete;

• GSM/2 [Qualità del segnale]: da 0 a 100;

• GSM/3 [Gestore rete]: gestore della rete a cui il modem è agganciato;

• GSM/4 [In uso/libero]: se il modem è in uso da qualcuno o è libero;

• GSM/11 [Numero mittente]: numero del mittente del messaggio o della chiamata;

• GSM/12 [Testo SMS in arrivo]: testo dell’SMS in ingresso;

• GSM/13 [Chiamata in arrivo]: a 1 se c’è una chiamata in corso in arrivo;

• GSM/14 [SMS in arrivo]: a 1 se c’è un SMS in arrivo;

• GSM/15 [Stato]: stato attuale del GSM;

• GSM/16 [Numero e messaggio in arrivo]: numero del mittente e messaggio in arrivo;

• GSM/17 [Numero e messaggio in uscita]: numero del ricevente e messaggio in uscita;

• GSM/18 [Chiamata in uscita]: numero del ricevente della chiamata;

• GSM/ErrorVonage [Errore Vonage] (solo per GSM virtuale): errore restituito da Vonage in caso di mancato invio del messaggio.

Ricezione chiamata (solo con GSM fisico)

Nel caso in cui si ricevi una chiamata, il modem GSM scrive gli indirizzi GSM/13 e GSM/11.

In caso di ricezione di una chiamata il modulo del controllo accessi verifica se al numero contenuto nell’indirizzo GSM/11 è associata l’apertura di un certo varco (vedi configurazione apposita nel controllo accessi) e, nel caso, gli accessi associati vengono aperti.

Ricezione SMS (solo con GSM fisico)

Nel caso in cui si ricevi un SMS, il modem GSM scrive gli indirizzi GSM/14, GSM/11 e GSM/12.

Invio chiamata

Nel caso in cui si invii una chiamata, il modem GSM lavora sull’indirizzo GSM/18.

Invio SMS

Nel caso in cui si invii un SMS, il modem GSM lavora sull’indirizzo GSM/17.

L’invio dell’SMS è usato nelle notifiche.

Storico delle comunicazioni

Tutte le chiamate e i messaggi in ingresso e in uscita vengono storicizzati nella tabella LOG_COMMUNICATIONS e sono visibili dal relativo report.

Comandi possibili

L’utente, inviando sms al gateway, ha la possibilità di interagire con il sistema, in particolare per:

• Può chiedere al sistema istruzioni sull’utilizzo del sistema stesso (HELP/AIUTO/ASSISTANCE)

• Può chiedere al sistema la configurazione di default per quanto riguarda gli scenari che l’utente può eseguire via sms (SCENARIOLIST) o squillo (SCENARIOONCALL)

• Può chiedere informazioni su un singolo scenario, inviando il nome dello scenario (NomeScenario#? oppure CodiceScenario#?) e ricevendone la descrizione.

• Può chiedere al sistema l’elenco dei varchi che l’utente può aprire tramite sms (ACCESSESLIST) o squillo (ACCESSESONCALL)

• Può eseguire uno scenario inviando il nome dello scenario o il codice dello scenario

• Può aprire un varco inviando il nome breve dell’ambiente da aprire

Quando il Gateway GSM riceve un SMS verifica se ricade in una parola chiave, in caso contrario verifica se esista uno scenario corrispondente (per nome o codice), infine verifica se esista un varco da aprire (per nome breve).

L’esecuzione degli scenari è vincolata al fatto che esista un utente di BIGStudio2 avente permessi sugli scenari il cui numero di telefono corrisponde a quello da cui è stato ricevuto l’sms (o la chiamata); l’apertura di un varco è vincolata al fatto che esista un cliente di BIGStudio2 avente permesso di aprire quel varco su un numero di telefono corrispondente a quello da cui è stato ricevuto l’sms (o la chiamata).

Figura 64

ESPA

Il gateway ESPA permette di interfacciare BIGStudio con una serie di dispositivi che usano il protocollo ESPA. La definizione di questi dispositivi avviene nella sezione dedicata, dove è possibile configurare una struttura di aree e ambienti nei quali risiedono i dispositivi.

Per il corretto funzionamento del gateway è necessario configurare nelle opzioni il tipo di sistema usato (dalla sezione opzioni) e i tipi di chiamata abilitati.

Figura 65

Fatto ciò è possibile configurare le aree e gli ambienti di tipo ESPA attraverso gli appositi pulsanti nel menù strumenti.

Figura 66

Nella sezione di sinistra vengono configurate aree e ambienti (gli ambienti non possono avere sottoaree o sottoambienit). Nella sezione di destra si vedono gli ambienti creati ed è possibile definire i dispositivi.

Per le aree è possibile definire solo la descrizione.

Figura 67

Per gli ambienti è possibile definire la descrizione, l’identificativo dell’ambiente e un eventuale account SIP associato.

Figura 68

Per i dispositivi è possibile definire la descrizione, l’identificato, il tipo dispositivo (a scelta fra letto e bagno) e l’eventuale account SIP associato.

Figura 69

Per ogni camera e dispositivo ESPA creato nascono i seguenti indirizzi:

• ESPA/IDENTIFICATIVO/001 → Chiamata infermiere IDENTIFICATIVO [Boolean]: chiamata in arrivo dall’ambiente/dispositivo IDENTIFICATIVO destinata agli OSS

• ESPA/ IDENTIFICATIVO /002 → Chiamata medico IDENTIFICATIVO [Boolean]: chiamata in arrivo dall’ambiente/dispositivo IDENTIFICATIVO destinata agli INFERMIERI

• ESPA/ IDENTIFICATIVO /003 → Chiamata OSS IDENTIFICATIVO [Boolean]: chiamata in arrivo dall’ambiente/dispositivo IDENTIFICATIVO destinata ai MEDICI

Figura 70

Al termine della creazione degli indirizzi è possibile usare il bottone di generazione automatica degli allarmi nella pagina Allarmi per generare gli allarmi associati ai dispositivi e alle camere ESPA creati.

Riconoscimento targhe

Il gateway PlateRecognition permette di interfacciare BIGStudio con una le telecamere IP per il riconosciemnto targhe. La definizione di queste telecamere avviene nella sezione dedicata, dove è possibile configurare una struttura di aree e ambienti nei quali risiedono le telecamere.

Per ogni telecamera è possibile anche prendere le immagini da una cartella di lavoro, invece di pollare una telecamera, facendo fare il poll nella cartella ad un software terzo.

Prerequisiti

Per il corretto funzionamento del gateway è necessario installare SimpleLP3 versione 3.3.0.0 dal sito WareLogic.com.

Il file SimpleLPR3.dll e il contenuto della cartella native devono essere copiati nella cartella di installazione di BIGStudio.

Configurazione

Nelle opzioni del gateway è necessario indicare:

• Directory di lavoro: cartella in cui vengono salvate le immagini scaricate dalla telecamera, utile per il debug.

• Tempo di ritenzione: tempo per cui l’immagine non viene considerata perché vale ancora la precedente

Per configurare le aree e gli ambienti di tipo PlateRecognition si utilizzano gli appositi pulsanti nel menù strumenti.

Figura 71

Nella sezione di sinistra vengono configurate aree e ambienti (gli ambienti non possono avere sottoaree o sottoambienit). Nella sezione di destra si vedono gli ambienti creati ed è possibile definire i dispositivi.

Per le aree è possibile definire solo la descrizione.

Figura 72

Per gli ambienti è possibile definire la descrizione e l’identificativo dell’ambiente.

Figura 73

Per i dispositivi è possibile definire:

• Descrizione

• Identificativo della telecamera (utilizzato per la creazione dei sui indirizzi

• IP della telecamera: nel caso in cui l’immagine debba essere pollata da BIGStudio è possibile indicare l’URL attraverso cui scaricare l’immagine corrente vista dalla telecamera; nel caso in cui le immagini siano pollate tramite altri sistemi e inseriti in una cartella questa informazione deve essere lasciata vuota

• Utente, Password: credenziali di accesso alla telecamera per scaricare le immagini

• Interrogazione ciclica, Intervallo di interrogazione: indica se abilitare o meno l’interrogazione ciclica dell’immagine dalla telecamera e il suo intervallo.

• Area di ritaglio: utilizzata per ritagliare l’immagine prima della verifica della presenza di una targa; viene fatto a partire dalle immagini che si trovano nella cartella di lavoro della telecamera, pertanto sia su quelle scaricate dalla telecamera da BIGStudio che su quelle trovate nella cartella (scaricate da altri); X è la distanza dal margine sinistro, Y dal margine in altro, Larghezza e Altezza sono le dimensioni della nuova immagine; tutte le dimensioni sono espresse in pixel.

• Cartella di salvataggio per le immagini: se configurata, indica la cartella in cui vengono pescate le immagini per la loro elaborazione. Questa configurazione si usa al posto dell’URL della telecamera stessa nel caso in cui sia un software esterno che si occupa di pollare la telecamera e scaricare i file pollati in questa cartella; in questo caso l’elaborazione avviene ogni volta che una nuova immagine compare nella cartella.

Figura 74

Per ogni telecamera creata nascono i seguenti indirizzi:

• CAMERA/CUSTOMID/1 DETECTEDPLATE: contiene il numero di targa riconosciuto;

• CAMERA/CUSTOMID/2 DETECTIONDATETIME: contiene la data in cui è stata riconosciuta la targa;

Wiegand

Il gateway Wiegand permette di interfacciare BIGStudio con i tastierini e i lettori che supportano il protocollo Wiegand.

Configurazione fisica dei dispositivi

Per utilizzare i dispositivi Wiegand è necessario

1. Abilitare l’invio dei dati dal lettore verso una “centrale”

2. Convertire i dati ricevuti da Wiegand a Seriale

3. Trasmissione del codice sulla seriale a BIGStudio2

Abilitazione invio dati verso la “centrale”

I lettori Wiegand hanno solitamente le modalità operative “Stand-alone” o “Con centrale”: nel primo caso il lettore apre direttamente il varco tramite un relè a bordo se il codice tessera è memorizzato sul lettore, nel secondo invia il codice tessera ad una centrale che abilita o meno l’apertura del varco. La modalità operativa da configurare è “Con centrale”, in modo che sia BIGStudio2 a discriminare l’abilitazione del varco.

Ad esempio, in caso di lettore GIGIEFFE la configurazione deve essere fatta tramite l’apposito programmatore.

Conversione dei dati da Wiegand a seriale

Per la conversione dei dati dal protocollo Wiegand a seriale è consigliato l’uso del WIE232 (marca Papouch).

Il convertitore viene collegato al tastierino/lettore e converte i codici tessera ricevuti in una stringa che invia sulla seriale.

Il convertitore va configurato nel seguente modo:

1. Pin 6 = On; per abilitare l’invio automatico del codice letto su seriale.

2. Pin 1-5: a On in base al tipo di dispositivo Wiegand a disposizione. Per i Wiegand 26 è necessario abilitare i pin 1 e 5.

Trasmissione codice tessera da seriale a BIGSTUDIO2

Il codice tessera emesso dal convertitore WIE232 può essere inviato

1. direttamente sulla seriale del PC

2. ad un convertitore seriale-IP per l’invio in rete del codice tessera

In fase di configurazione da BIGStudio2 del dispositivo è possibile indicare il metodo di comunicazione del dispositivo (seriale o IP) e i relativi parametri di comunicazione.

Configurazione dei dispositivi tramite BIGStudio2

La definizione di questi dispositivi avviene nella sezione dedicata, dove è possibile configurare una struttura di aree e ambienti nei quali risiedono i dispositivi.

Figura 75

Per configurare le aree e gli ambienti di tipo Wiegand si utilizzano gli appositi pulsanti nel menù strumenti.

Nella sezione di sinistra vengono configurate aree e ambienti (gli ambienti non possono avere sottoaree o sottoambienit). Nella sezione di destra si vedono gli ambienti creati ed è possibile definire i dispositivi.

Per le aree è possibile definire solo la descrizione.

Figura 76

Per gli ambienti è possibile definire la descrizione e l’identificativo dell’ambiente.

Figura 77

Per i dispositivi è possibile definire la descrizione, l’identificativo e la modalità di connessione del tastierino/lettore:

• Seriale: è necessario indicare i parametri di comunicazione della seriale

• IP: è necessario indicare l’IP da cui comunica il dispositivo e la porta di ascolto del server TCP del servizio (nella sezione “Opzioni”)

Figura 78

Figura 79

Per ogni dispositivo nasce un indirizzo Reachable, che rappresenta la raggiungibilità della dispositivo (ping su IP, handshake su seriale): la raggiungibilità di tutti i dispositivi del gateway viene testata all’avvio del gateway. Se si vuole testare la raggiungibilità del dispositivo periodicamente è necessario abilitare il ping periodico sul dispositivo (Configurazione → Dispositivi → Configurazione → Abilita ping)

Per ogni dispositivo creato nascono i seguenti indirizzi:

• WIEGAND/CUSTOMID/1 PlantCode: contiene il codice impianto (non ancora gestito);

• WIEGAND /CUSTOMID/2 KeyCode: contiene il codice chiave inviato dal lettore;

In caso di tastierino ad ogni pressione di un tasto viene inviato il numero premuto. Il codice tessera si considera completo alla pressione del tasto #.

Lora

Tramite il gateway LoRa è possibile comunicare con i gateway LoRa e conseguentemente con i dispositivi a loro associati.

Al fine di realizzare correttamente l’integrazione, sono necessari i seguenti componenti:

• ChirpStack: server open-source LoraWan che consente di ricevere I dati dai dispositivi LoraWan installati. È disponibilie in versione web server (da installare su macchina Linux) o immagine Docker ( https://www.chirpstack.io/docs/chirpstack/downloads.html)

• Gateway LoraWan-Ethernet: consente di collegare In rete i vari dispositivi dislocati in aree geografiche differenti.

Il server Chirpstack comunicherà con il gateway software tramite protocollo MQTT (https://www.chirpstack.io/application-server/integrations/mqtt/ )

Architettura

Ricezione di un dato da un dispositivo LoRa

• I dispositivi LoRa in campo mandano in broadcast le loro informazioni

• Le antenne LoRa/gateway LoRa IP in campo intercettano i dati e tramite la configurazione effettuata sul Mikrotik dell’antenna inviano i dati via IP sul server Chirpstack

• Il Mikrotik crea anche una VPN con cui è possibile monitorare lo stato del gateway

• Il server Chirpstack riceve il dato in IP e verifica che il mittente sia presente fra i dispositivi configurati fra le Application di Chirpstack

• Se il dispositivo è riconosciuto il Server Chirpstack tramite il suo broker MQTT Mosquitto invia i topic contenenti il dato ricevuto dai dispositivi LoRa

• Il gateway LoRa di BIGStudio riceve sul suo client MQTT interno il dato e lo spacchetta per trasformarlo in indirizzi di BIGStudio

Invio di un dato ad un dispositivo LoRa:

• Il gateway LoRa di BIGStudio trasforma l’indirizzo BIG in un payload MQTT che invia al broker Mosquitto di Chirpstack

• Il broker Mosquitto riceve il payload e accoda la richiesta di scrittura nella coda di Chirpstack

• Quando la comunicazione con il dispositivo è aperta Chirpstack manda il dato al gateway più vicino al dispositivo (in base al SNR)

• Il gateway inoltra il dato al dispositivo interessato

Tipi di dispositivi

Il primo passo nella configurazione è la definizione dei tipi di dispositivi presenti sull’impianto tramite l’apposita tab. Attenzione! È necessario completare tutta la configurazione dei tipi di dispositivi, perché una volta aggiunti i dispositivi di una certa tipologia, tale tipologia non è più modificabile.

Figura 80

1. Nella sezione in alto è possibile inserire i tipi di dispositivi: per ciascuno è possibile definire una descrizione e un costruttore (il campo costruttore è testuale, perciò si può usare il campo costruttore anche per inserire altri dati ritenuti utili);

   

   Figura 81

   1. Assicurarsi di selezione INDUSTRY STANDARD come protocollo

2. Ciascun tipo di dispositivo LoRa può inviare e ricevere diversi blocchi di informazione (qui chiamati Blocchi di dati associati (payload) al dispositivo): per ciascuno di questi è possibile indicare:

   1. Descrizione: usato dall’utente per riconoscere il dato inviato.

   2. Indirizzi identificativi del payload in arrivo: ciascun payload inviato dal dispositivo è identificabile tramite una sua porzione che indica quali sono le informazioni contenute nel blocco e, di conseguenza, come può essere decodificato; è quindi necessario indicare per ogni blocco qual è la porzione da cercare per riconoscere il blocco e quale valore deve assumere questa porzione. Per ciascun dato ricevuto è possibile identificare più porzioni per l’identificazione dell’informazione inviata. Tutti i payload in arrivo dal dispositivo devono avere almeno una porzione valorizzata in questa sezione.

   

Figura 82

c. **Payload fisso da scrivere**: per inviare comandi a un dispositivo è possibile creare un payload in cui viene definita una parte fissa (costante per quello specifico comando) e una parte variabile. La parte variabile è identificata con la stringa ``#id=X#``, in cui **X** rappresenta l’ID della porzione (definita al punto **3**). Da includere in quel payload; è consigliabile configurarla per ogni comando che si vuole mandare al dispositivo. .. figure:: Payload.png :width: 200px :align: center .. raw:: html

Figura 83

.. figure:: New-DeletePayolad.png :width: 200px :align: center .. raw:: html

Figura 84

d. Attraverso i bottoni nel menù strumenti è possibile aggiungere o rimuovere un tipo di dispositivo.

3. Ciascun blocco di dati ricevuto/inviato contiene diverse informazioni e deve essere decodificato per poter estrarre tali informazioni; nella sezione Decodifica indirizzi è possibile indicare per ciascuna porzione di blocco rappresentante un’informazione:

   

   Figura 85

1. ID: id univoco dell’informazione;

2. Descrizione: nome dell’indirizzo di BIGStudio2 derivante

3. Carattere iniziale: dato che il blocco inviato è sempre sotto forma di stringa esadecimale, è conveniente utilizzare come unità di misura il carattere; l’inizio del blocco è indicato dalla posizione del suo primo carattere (in base 0) nella stringa.

4. Numero caratteri: lunghezza del blocco in caratteri nella stringa esadecimale.

5. Formato dati: formato dell’indirizzo BIGStudio2 derivante (i formati di dati possono essere configurati dalla sezione Indirizzi).

6. Offset: valore da sommare al dato ricevuto (se intero o float) prima di memorizzarlo in database o inviarlo ai client.

7. Fattore: valore da moltiplicare al dato ricevuto (se intero o float) prima di memorizzarlo in database o inviarlo ai client (ad esempio le temperature arrivano solitamente in decimale e devono essere moltiplicate per 0,1 per ottenere la temperatura reale)

8. Reverse Block: se il byte array ricevuto associato alla porzione è scritto in LSB si può attivare il Reverse Block per far sì che la codifica/decodifica ne tenga conto

Per ciascun indirizzo di ciascun dispositivo definito nasce un indirizzo della forma

• LORA/ID_DEVICE/sendPayload: dove ID_DEVICE è l’ID del dispositivo LORA; valore da scrivere con stringa esadecimale per inviare un comando diretto al dispositivo; viene valorizzato ogni volta che viene inviato un payload al dispositivo.

• LORA/ID_DEVICE/lastReceivedPayload: dove ID_DEVICE è l’ID del dispositivo LORA; rappresenta la stringa esadecimale ricevuta dal dispositivo

• LORA/ID_DEVICE/PROPERTYID: dove ID_DEVICE è l’ID del dispositivo LORA, mentre PROPERTYID è l’id nella tabella LORA_ADDRESS_DECODING (ciascuna riga di questa tabella identifica una porzione del dato ricevuto da considerare come informazione a granularità minima).

Esempio: Il dispositivo presente negli screenshot sovrastanti è attuatore 4 canali che è stato decodificato sulla base delle informazioni sottostanti indicate dal produttore.

Figura 86

Dispositivi

Nella sezione Dispositivi è possibile inserire i dispositivi presenti sull’impianto dei tipi precedentemente definiti.

Figura 87

Per ciascuno è necessario definire:

• Nome

• Tipo: da scegliere fra i tipi di dispositivi presenti nell’anagrafica

• DevEui: dato passato dal costruttore e presente su un’etichetta sul dispositivo stesso

• ApplicationID: identificativo applicazione presente su Chirpstack

Per ogni dispositivo configurato nascono i seguenti indirizzi che definiscono la bontà della comunicazione fra il dispositivo e il gateway di riferimento.

• LORA/ID_DEVICE/rssi: potenza del segnale fra il dispositivo e il gateway;

• LORA/ID_DEVICE/snr: rapporto segnale/rumore;

Nodi derivanti

Data la configurazione precedente i nodi e gli indirizzi derivanti sono i seguenti.

Figura 88

Dati intercettati tramite l’mqtt

Il sistema di Chirpstack invia diversi tipi di pacchetti che vengono intercettati dal gateway:

• UP: messaggi inviati dal dispositivo al gateway; contengono gli aggiornamenti periodici inviati dal dispositivo; usato per spacchettare i dati in indirizzi di BIGStudio2

Alfa by Sinapsi

Tramite il gateway Alfa è possibile comunicare con i contatori energetici prodotti da Sinapsi.

Connessione al cloud di Sinapsi

Per la comunicazione con gli Alfa BIGStudio si collega in MQTT al cloud di Sinapsi tramite i dati forniti da Sinapsi stesso:

• IP del broker mqtt

• Porta del broker mqtt

• Username per l’autenticazione mqtt

• Password per l’autenticazione mqtt

• Client ID per il riconoscimento dell’utente autenticato

Queste informazioni devono essere configurate nella sezione Opzioni del gateway Alfa.

Configurazione dispositivi

Per la configurazione dei dispositivi è necessario organizzare i dispositivi stessi in un edificio, andando a definire aree e ambienti che la costituiscono. In ciascun ambiente è possibile inserire uno o più dispositivi.

Ciascun dispositivo è identificato da una descrizione e da un Activation Key, il quale, fornito da Sinapsi, identifica univocamente il dispositivo fra i due sistemi.

Per ciascun dispositivo vengono creati n indirizzi della forma SINAPSI/ID_DEVICE/PROPERTYID.

Le property ID sono tante quanti i dati inviabili dal singolo contatore, identificati tramite un obis name che può esere ricavato seguendo il link : http://dev1.sgh.snpds.com:8023/apps/iomtsgdata/v1/obisdescriptor

Al momento non tutte le property sembrano utilizzate.

Ricezione dei dati La ricezione dei dati da mqtt avviene per ogni contatore (identificato da un Activation Key), sottoscrivendosi al singolo topic: /Username/ iomtsgdata/ActivationKey/# Dove:

• Username è lo username con cui si è fatta l’autenticazione mqtt

• ActivationKey è l’identificativo del contatore come configurato in BIGStudio

I payload ricevuti sono sempre della forma:

{
    "du": "DU21060501",
    "pod": "IT001E414380506",
    "data": {
        "1-0:1.7.0.255_3,0_2": "136",
        "ts": "1630326230"
    }
}

Dove

• “du”: IoMeter2g fabrication number

• “pod”: POD del misuratore intelligente 2G

• “<obis_name>”: valore della grandezza specificata da obis_name. Vedi elenco al seguente Link: http://dev1.sgh.snpds.com:8023/apps/iomtsgdata/v1/obisdescriptor

• “ts”: Unix timestamp del valore obis_name – il dato proviene dal misuratore intelligente 2G

Quando si riceve un payload sul topic di un contatore il servizio spacchetta il payload ricavando l’obis_name e il suo valore: per ogni obis_name è stato generato un indirizzo di BIGStudio in fase di creazione del dispositivo; perciò il dato ricevuto sullo specifico obis_name viene rimappato sul relativo indirizzo di BIGStudio.

Telegram – Notifiche e accessi tramite App Telegram

Il gateway Telegram permette di interfacciare BIGStudio con l’app di messaggistica Telegram e tramite di essa inviare notifiche di allarmi o gestire accessi ai varchi.

Innanzitutto è necessario creare un BOT Telegram; Vedere l’apposita sezione “Creazione BOT Telegram” con le istruzioni passo-passo

Nella sezione dedicata, è necessario indicare l’ API token ottenuto seguendo la creazione del BOT

Figura 89

.. figure:: serverOptions.png :width: 400px :align: center

Figura 90

Creazione BOT Telegram

Questa configurazione viene eseguita da uno smartphone sul quale deve essere installata l’app di Telegram

Figura 91

Aprire Telegram e ricercare tra gli utenti BotFather, quindi premere Start per iniziare la configurazione.

Figura 92

Per iniziare con la creazione digitare /newbot e inviare.

Figura 93

Inserire il nome del BOT che comparirà quando l’utente ricerca tra gli utenti Telegram

Figura 94

Indicare il nome dell’utente. Il nome deve terminare con bot. Questo utente è interno al BOT e non sarà visualizzabile dagli utenti. Immettere un valore senza spazi e quindi inviare.

Figura 95

Viene mostrato il token HTTP API che sarà necessario per la configurazione di BigStudio. Salvarsi tale valore.
A questo punto il BOT è creato, ma è necessaria una ulteriore configurazione per un corretto utilizzo.
Digitare /mybots e inviare.

Figura 96

Dall’elenco che verrà visualizzato selezionare il BOT appena creato. Compariranno dei pulsanti che consentono di navigare tra le impostazioni del BOT (Vedi Figura 37)

Figura 97

Per iniziare con la creazione digitare /newbot e inviare.

Figura 98

Menu Edit BOT

Questo menù consente di modificare alcune impostazioni di come il BOT verrà visualizzato.

Figura 99

Selezionare la voce Edit Bot. Comparirà un nuovo menù che permetterà di modificare i parametri del BOT

Figura 100

Figura 101

Tramite questi pulsanti si potranno configurare alcune opzioni di come il BOT comparirà:

• Edit Description: (opzionale) Inserire un testo che gli utenti vedranno quando aprono una chat con il BOT
• Edit About : (opzionale) Inserire un testo che gli utenti vedranno come profilo del BOT
• Edit Botpic : (opzionale) Inserire un’immagine che gli utenti vedranno associata al BOT. Per aggiungere un’immagine premere il pulsante clips e selezionare l’immagine desiderata. Usare il vostro logo migliorerà la visibilità e la fiducia degli utenti
• Edit Commands: (opzionale). IL BOT riconosce alcuni comandi base che consentono di vedere lo stato dell’utente e ottenere la lista dei sui permessi. Per migliorare l’esperienza utente si consiglia di inserire i comandi. I comandi vanno indicati esattamente come indicato in questo manuale:(vedi figura 10)
• help-Lista Comandi < ctrl+invio >
• status-Stato utente

Per inserire i comandi in sequenza è necessario premere dopo il primo comando < ctrl+invio > in modo da andare a capo invece che inviare subito il testo

IMPORTANTE:

dopo ogni azione premere Back to bot e quindi nuovamente Edit bot

A questo punto le voci del menu Edit bot sono correttamente configurate e si passa al menu Bot Settings

Menu bot Settings

Questo menù consente di modificare alcune impostazioni di come il BOT potrà essere usato

Figura 102

Selezionare la voce Bot Settings. Comparirà un nuovo menù che permetterà di modificare i parametri del BOT.

Figura 103

Premere Allow Groups?

Figura 104

Selezionare la voce Bot Settings. Comparirà un nuovo menù che permetterà di modificare i parametri del BOT.

API Token

Siamo giunti alla fine della configurazione del BOT. Ora è necessario prendere il token API salvato in precedenza cosi da inserirlo nei parametri di Bigstudio e consentire cosi al software di interagire con il Bot.

Qualora non sia stato salvato o sia stato smarrito il token API è possibile reperirlo nuovamente.

Figura 105

Dal menù principale del Bot selezionare API Token

Figura 106

Copiare il valore presentato e inserirlo nell’apposita configurazione di BigStudio

Crestron

Il gateway Crestron permette di interfacciare BIGStudio2 con il processore Crestron: l’obiettivo è quello di far comparire un messaggio di benvenuto all’accesso in camera.

File di configurazione

Il file di configurazione da cui legge il gateway è nella forma:

<?xml version="1.0" encoding="UTF-8"?>
<Settings>

  <Gateway InstanceGUID="8A85A9A2-A409-472D-87C1-9FF3ED97A1F0" Description="Crestron Gateway" Pc_Name="LOCALHOST" Active="True" TCPPort="1411">

    <Parameters>
      <UseCryptography>False</UseCryptography>
      <CryptoKey>NoKey</CryptoKey>
      <ProcessorIP>192.168.77.201</ProcessorIP>
      <ProcessorIPID>09</ProcessorIPID>
      <ProcessorPassword></ProcessorPassword>
      <ProcessorPort>41794</ProcessorPort>
      <ProcessorUsername></ProcessorUsername>
      <ProcessorUseSSL>False</ProcessorUseSSL>
    </Parameters>

    <Functions>
        <Function Slot="0" Type="1" Join="1" Value="1" Command = "SHUTDOWN" Options="/s /f /t 5" />
        <Function Slot="0" Type="1" Join="2" Value="1" Command = "NOTEPAD" Options="" />7
    </Functions>

  </Gateway>

</Settings>

L’instanceGUID e la porta su cui gira deve corrispondere alle informazioni presenti nelle tabelle Gateway e GatewayRelations.

AccessManager_ToCrestron_SendDetailsOnAccess	TRUE
AccessManager_ToCrestron_GatewayGUID	8A85A9A2-A409-472D-87C1-9FF3ED97A1F0
AccessManager_ToCrestron_GuestNameOnAccessSerialAddress	1/2/1
AccessManager_ToCrestron_RoomNumberOnAccessSerialAddress	1/2/2
AccessManager_ToCrestron_DetailsOnAccessDigitalAddress	1/1/1
AccessManager_ToCrestron_SendOnlyFirstAccess	FALSE

Dove l’instanceGUID è la stessa presente nella tabella gateway.

All’accesso di un utente su un lettore BIGOmnia scrive gli indirizzi indicati i quali vengono trasmessi dal CrestronGateway al processore.

Gli indirizzi sono della forma: slot/type/join, dove slot e join sono parametri richiesti da Crestron, mentre type è a scelta fra:

0. Analogico

1. Digitale

2. Seriale

Se il parametro SendOnlyFirstAccess è TRUE l’inoltro di informazioni a Crestron avviene solo la prima volta che si rileva un accesso da parte di una tessera in un determinato ambiente.

Il RoomNumber inviato a Crestron è - Quello dell’ambiente in cui è stato effettuato l’accesso se l’ambiente è una camera - Quello della prima camera trovata associata a quella tessera se l’ambiente è un accesso comune.

Dahua

Il gateway Dahua permette di integrare i tastierini, i lettori di card e i totem per il riconoscimento facciale Dahua.

I lettori di card leggono solo tessere Mifare di cui leggono l’UID.

Dalla configurazione è possibile organizzarli logicamente in base al luogo in cui sono posizionati; in particolare è possibile:

• Creare/modificare/eliminare un’area: ciascuna area è un contenitore di ambiente che ha come unica caratteristica il nome che la identifica.

• Creare/modificare/eliminare un ambiente: ciascun ambiente può contenere più tastierini ed è caratterizzato da un nome esteso e un nome breve.

• Creare/modificare/eliminare un tastierino/totem: per ogni tastierino è necessario indicare:

  • Descrizione: a discrezione dell’utente per identificare il dispositivo

  • IP: ip del dispositivo Dahua; l’ip si può leggere direttamente sul dispositivo, nella sua configurazione.

  • Porta: Porta del lettore Dahua: di default 37777

  • Username: utilizzato per la login sul dispositivo; di default admin

  • Password: utilizzato per la login sul dispositivo; di default 123456 oppure 88888888 sui tastierini.

  • Tipologia: tastierino, lettore di tessere o totem per il riconoscimento facciale

  • Tempo chiusura relè (millisecondi): tempo di chiusura del primo relè nel momento in cui viene inviato il relativo indirizzo ad 1

Figura 107

Figura 108

Figura 109

• Nella sezione Codici a bordo è possibile interrogare i tastierini per sapere i codici caricati a bordo

Per ogni dispositivo nascono i seguenti indirizzi:

• Dahua/IdDevice/1 - UpdateDateTime: usato per aggiornare l’ora sul tastierino

• Dahua/IdDevice/2 – AddNumericKey: usato per aggiungere un codice numerico (per tastierino o UID della card) sul dispositivo; viene scritto con il codice da aggiungere ‘_’ data di scadenza

• Dahua/IdDevice/3 – RemoveNumericKey: usato per rimuovere un codice numerico dal dispositivo; viene scritto con il codice da rimuovere

• Dahua/IdDevice/4 – ReadKeyOnKeypad: scritto a 1 per chiedere al gateway di leggere tutti i codici a bordo del tastierino

• Dahua/IdDevice/5 – ReadKeyOnKeypadResult: contiene l’elenco dei codici numerici associati al dispositivo

• Dahua/IdDevice/6 – Transit: contiene il codice digitato sul tastierino e l’esito della digitazione; il valore termina con 00 se l’accesso è negato, con 40 se l’accesso è consentito.

• Dahua/idDevice/7 – AddFAce: contiene idImmagineInDB_CardNumber_ExpirationDate ed è usato per aggiungere un volto su uno specifico dispositivo

• Dahua/idDevice/8 – RemoveFace: contiene idImmagineInDB_CardNumber ed è usato per rimuovere un volto su uno specifico dispositivo

• Dahua/idDevice/10 – OpenDoor: da scrivere ad 1 per inviare il comando di apertura porta

• Dahua/idDevice/11 – ClearAllCode: cancella a bordo dispositivo tutit i codici presenti

• Dahua/idDevice/13 – RebootDevice: da scrivere ad 1 per riavviare il dispositivo

Figura 110

Creazione dal controllo accessi di una tessera

Visto che i dispositivi Dahua si basano sull’UID della tessera Mifare BIGStudio traccia gli UID delle card in fase di scrittura, senza scrivere nessun dato sulla card.

Figura 111

Su BIGStudio si ha l’informazione del codice card (presente solo in BIGStudio, non scritto sulla card) e dell’UID della card (inviato al dispositivo Dahua per il riconoscimento).

In fase di scrittura della card viene solamente letto l’UID della tessera e salvato nel database di BIGStudio; se erano presenti tessere precedenti associate a quell’UID viene rimossa l’associazione in modo che ogni UID sia univocamente associato ad una sola tessera nel database di BIGStudio.

Risoluzione problemi con tessere Mifare su lettori Dahua

Quando si fa la messa in servizio di un lettore di card Dahua è necessario caricare sul lettore il codice card fittizzio 00000001 abilitato a lunga scadenza.

Senza questo codice a bordo del lettore le librerie di Dahua non forniscono informazioni in merito ai codici già a bordo e di conseguenza non permettono la modifica e la cancellazione delle card a bordo.

La procedura è:

• Se il lettore non è nuovo eseguire il Factory Reset dal tool ConfigTool presente dentro ToolBox (ToolBox lo trovate al link https://dahuawiki.com/Software/Dahua_Toolbox)

• Scrivere l’indirizzo DAHUA/ID_DEVICE/2 (AddKey) con il valore 1_31-12-2030|11:00:00 per aggiungere la chiave con ID 1 e scadenza nel 2030

• Verificare che sia stato correttamente caricato eseguendo una lettura dei codici a bordo (dalla configurazione del gateway Dahua in BIGStudio)

A questo punto è possibile procedere con la normale creazione/attivazione delle card.

Accessi virtuali

Premessa

L’obiettivo è integrare in supervisione un componente che permetta l’accesso al cliente tramite QRCodeScanner (che scansiona un QRCode), FaceRecognition o tastierino virtuale e permetta o neghi l’accesso al cliente associato a quel metodo di accesso.

Per ogni accesso che si può effettuare con uno di questi metodi verrà creata una pagina di supervisione (personalizzabile a piacere) con il componente scelto che sarà l’unica pagina visibile su un touch collocato in prossimità dell’accesso: il cliente si avvicina e con il QRCode o il codice che gli è stato consegnato effettua l’accesso.

Configurazione dispositivi controllo accessi

Per ogni accesso che dovrà essere effettuato deve essere creato un dispositivo virtuale nella sezione Accessi virtuali. Per ciascun dispositivo dovrà essere indicato l’ambiente in cui si trova; gli ambienti a disposizione sono tutti gli altri ambienti già presenti nel sistema, di qualsiasi tipologia.

Figura 112

I dispositivi possono essere di tre tipologie diverse: QRCodeScanner, FaceRecognition, Keypad.

I dispositivi nascono con strategia di accesso centralizzata che non può essere cambiata.

I dispositivi appartengono ad un gateway AccessControl che è virtuale ma non è associato ad un servizio ed è gestito internamente dal MasterGateway.

Ad ogni porta che sappiamo dovrà essere aperta con uno di questi metodi associamo un dispositivo.

Per ogni dispositivo nascono gli indirizzi:

• ACCESSCONTROL/IDCustomDevice/1: Access: contiene la stringa letta dal componente (QRCode o Keypad) con un 40 finale.

• ACCESSCONTROL /IDCustomDevice/2: Result: 3 stati: In attesa di Accesso, Accesso Valido, Accesso Negato, codici di errore.

• ACCESSCONTROL /IDCustomDevice/3: CustomerName: nome e cognome del cliente

• ACCESSCONTROL/IDCustomDevice/4: Language: codice della lingua da utilizzare (utile per far vedere delle bandierine in supervisione e cambiare al volo la lingua del componente)

• ACCESSCONTROL/IDCustomDevice/5: State: testo da visualizzare nella label associata per il cliente

Configurazione QRCode scanner

Figura 113

Per lo scanner QRCode è necessario indicare:

• URL della telecamera da cui pollare (o cartella, nel caso in cui la telecamera sia configurata per scaricare immagini periodicamente in una cartella)

• Utente per accesso alla telecamera

• Password per accesso alla telecamera

• Intervallo di interrogazione: tempo di poll della telecamera in millisecondi (si consiglia di non scendere sotto il secondo)

• Percentuale di ritaglio: dall’immagine prelevata dalla cartella viene rimossa una percentuale da ogni lato dell’immagine. Nell’esempio sopra viene rimosso il 25% da ogni lato.

Nel caso in cui si vogliano salvare in una cartella le immagini scansionate dalla telecamera, con applicato il fattore di ritaglio (in pratica l’immagine su cui lavora il decoder del QRCode) si possono inserire nella tabella SETTINGS le seguenti configurazioni

• QRCodeScanner_UseFolderDebug: booleano, indica se salvare o meno le immagini in una cartella;

• QRCodeScanner_FolderDebug: stringa, indica la cartella in cui salvare le immagini; terminare con il backslash e verificare i permessi sulla cartella.

Questa configurazione può essere utile in fase di messa in servizio e test di funzionamento preliminare della telecamera, ma NON deve essere lasciata, visto che salva molte immagini (una per telecamera, per tempo di poll) nella cartella indicata.

Configurazione sezione controllo accessi

L’utente crea il cliente e in automatico nasce la tessera di tipologia QRCode (nella sezione anagrafica), la associa agli ambienti, assegna periodo di validità, calendari, fasce orarie e la attiva (al momento opportuno).

Ogni tessera così creata ha un codice di 6 cifre casuali.

Se la tessera selezionata è di tipo QRCode nel momento in cui si invia la notifica al cliente si può inserire la keyword #cardnumber per far stampare in mail il QRCode, il quale contiene il codice della tessera virtuale generata.

In questo momento nel QRCode è contenuto solo il codice della tessera virtuale.

Passaggio QRCode/Digitazione codice sul tastierino

Al passaggio del QRCode il componente scanner scrive l’indirizzo /1 con il codice della tessera associata al QRCode e BIGOmnia riceve l’indirizzo, verifica la validità della tessera, decide il da farsi e scrive gli indirizzi di risposta al valore corretto.

Configurazione componente AccessControl Il componente è parametrizzabile con: 1. IDDispositivo che rappresenta quello scanner 2. ResetTime: tempo di reset al termine del passaggio (rimette a “In attesa di codice” l’/1) 3. OpenOnLoad: si avvia all’apertura della pagina, altrimenti si avvia cliccando sul componente 4. Stringhe di stato: come per le immagini di stato è possibile aggiungere sul componente le stringhe di stato, cioè un insieme di stringhe che possono essere visualizzate in base al risultato dell’accesso;

1. Per ogni lingua sono parametrizzabili le stringhe di:

   1. ValidAccessText

   2. InvalidAccessText

   3. InvalidAccessExpiredText

   4. InvalidAccessNotValidText

   5. InvalidAccessWrongTimeslotText

   6. InvalidAccessWrongCalendarText

   7. InvalidAccessLockedCardText

In queste stringhe è possibile inserire la keyword #name per mostrare il nome e cognome del cliente che ha effettuato l’accesso

2. Nel momento in cui il componente riceve l’indirizzo di Result compone la stringa in base a quanto parametrizzato e scrive l’indirizzo State (sulla base della lingua presente nell’indirizzo Language).

Configurazione app

L’app dovrà fare accesso con un utente specifico e avere la possibilità di indicare (su ogni touch) la pagina preferenziale da far partire. Partirà così con l’autologin e farà vedere solo la pagina interessata.

Integrazione dispostivi IPDoor

I dispositivi IPDoor by InfinityPlay sono una vasta gamma di dispositivi di videocitofonia.

Essi offrono alcune funzionalità comuni in quest’anno quali (la gestione delle chiamate SIP, la visualizzazione della telecamere) e alcune funzionalità speciali quali la gestione nativa dei tastierini numerici e la lettura/interpetazione dei codici QR. Tali funzionalità non sono comprese nel core di base dei dispositivi e possono essere ottenute acquistando delle opportune licenze che sono legate AL SINGOLO DISPOSITIVO.

La configurazione si compone genericamente di due step:

• Attivazione e configurzione del dispositivo all’interno del cloud IPDoor

• Collegamento dell’integrazione attvitata sul cloud all’interno del sistema di BIGStudio.

Configurazione account IPDoor su cloud proprietario

Prima di effettuare la configurazione sul cloud, è necessario registrarsi al portale https://console.ipdoor.com/. Dopo aver completato l’attivazione del proprio account è necessario attivare il dispositivo attraverso il QRCode allegato alla chiave “Master Key” presente all’interno della confezione del prodotto e successivamente associare il dispositivo precedentemente attivato al buidling creato in fase di registrazione. La procedura di attivazione del primo dispositivo e creazione del building è molto semplice e guidata e verrà presentata solo al primo login.

Terminati questi passaggi verremo reindirizzati alla homepage dell’impianto precedentemente creato.

Figura 114

In questa sezione si potranno visualizzare:

• Gli utenti visualizzati e attualmente creati (utili soprattutto in fase di gestione delle chiamate SIP)

• I gruppi di utenti

• I dispositivi reali o virtuali registrati

• Registrare nuove licenze

• Gestire il controllo accessi nativamente sul dispositivo

Registrazione di una nuova licenza IPDoor

Ogni dispositivo IPDoor dispone di funzionalità speciali che possono essere abilitate con l’acquisto di opportune licenze. L’inserimento delle licenze acquistate può avvenire in due modi:

• Inserimento manuale del codice licenza

• Scansione del QRCode fornito con la licenza

NB: Le licenze sono legate ai singoli dispositivi e non possono essere ripetete.

Per poter abilitare la registrazione e la lettura dei codici QR è necessario avere una licenza di tipo Controllo Accessi per ogni dispositivo abilitato

Inserimento di un dispositivo fisico

Per poter inserire un nuovo dispositivo, è necessario disporre del codice QR stampato sulla Master Key fornita assieme al dispositivo. Una volta registrata correttamente saremmo in grado di poterlo visualizzare all’interno dell’elenco del nostro building

Inserimento di un’integrazione

Per poter abilitare la lettura e l’interpretazione di un codice QR sui dispostivi IPDoor è necessario creare un dispositivo di tipo “Integrazione” che permette di specificare gli url personalizzati di callback per inviare il contenuto del codice QR letto dal singolo dispositivo.

Per creare una nuova integrazione è necessario premere il tasto “+” accanto alla voce “Dispostivi” e successivamente premere “Altri dispositivi” e “Integration”

Figura 115

La compilazione dell’integrazione si compone di due parti:

• Inserimento del server a cui collegare gli endpoint di integrazione (e compilazione del relativo nome)

• Inserimento degli endpoint finale a cui inviare il contenuto del codice QR letto

Compilato il nome e il campo dell’indirizzo IP (che dovrà corrispondere a quello del server di BIGStudio) si potranno collegare uno o più endpoint di callback per l’invio del codice QR.

Per aggiungere un novo endpoint basterà premere il tasto “+” nella sezione integrazione che abiliterà la visualizzazione della form sottostante

Figura 116

Compilare l’interfaccia con i seguenti parametri:

• Tipo: Duemmegi credential

• Nome: Integrazione BIGStudio (il nome è solo l’indentificativo dell’endpoint=

• Path: api/environment/requestaccess/{idDispositivo}. Il campo dell’ID dispositivo dovrà essere recuperato da BIGStudio e farà riferimento al dispositivo di tipo codice QR legato agli accessi virtuali

• Porta: porta API BIGStudio3

Una volta completata la configurazione premere il tasto “Fatto”

Collegare l’integrazione al dispostivo

Registrato sia il dispositivo all’interno del portale e creata l’integrazione sarà necessario collegarli al fine di completare l’integrazione.

Per effettuare il collegamento selezionare il dispositivo fisico in homepage sotto la voce “Dispositivi”, premere successivamente “Configurazione” → “Integrazioni” che abiliterà la visualizzazione delle integrazioni collegate al singolo dispositivo

Figura 117

Per collegare l’integrazione creata precedentemente, premere il tasto “+” accanto al nodo “Integrazioni” e selezionare successivamente l’integrazione creata precedentemente. Prima di completare la conferma (premendo il tasto conferma è necessario impostare la fascia oraria di validità dell’integrazione). Se l’integrazione deve essere sempre valida, premere l’opzione “7 gg.” all’interno del popup di impostazione della fascia oraria.

Completati questi ultimi passaggi, il dispositivo IPDoor sarà in grado di inviare il contenuto dei codici QR al software per l’opportuna elaborazione

Configurazione dispositivi BIG

I dispositivi BIG sono dei touch 7 o 10 pollici che possono essere usati per l’interfacciamento con BIGStudio. Su questi touch possono essere configurate diverse periferiche esterne (led, relais, sensori di temperatura), che possono essere interfacciati e gestiti con BIGStudio.

Come si configurano i dispositivi in BIGStudio

La configurazione parte dal dispositivo stesso, che comunica tramite l’app di BIGStudio installata a bordo: all’avvio l’app riconosce il tipo di dispositivo su cui è installata e, in caso di dispositivo BIG, rileva le sue informazioni:

• Nome del dispositivo: letto dalla configurazione di Android, modificabile dalla sezione “Informazioni dispositivo” dell’app BIGStudio

• Produttore

• Codice/Modello

• Seriale: identificativo univoco del dispositivo

Figura 118

Le informazioni rilevate vengono inviate al server BIGStudio tramite una chiamata API; il server crea, se necessario (se il serial number non è già presente), il nuovo dispositivo nell’anagrafica dei dispositivi MQTT di BIGStudio.

Indirizzi per la comunicazione

Per controllare le periferiche del dispositivo nascono i seguenti indirizzi:

• BIG/ID/1 LedColor: red, green, blue, empty: regola il colore del led a bordo del touch; il valore dell’indirizzo è il colore RGB in esadecimale.

• BIG /ID/2 R1PermanentOnOff: boolean, On = chiude il relè 1; Off = apre il relè 1

• BIG /ID/3 R2PermanentOnOff: boolean, On = chiude il relè 2; Off = apre il relè 2

• BIG /ID/4 R1StairCaseOn: integer, chiude il relè 1 per il numero di millisecondi indicati dal valore

• BIG /ID/5 R2StairCaseOn integer, chiude il relè 2 per il numero di millisecondi indicati dal valore

• BIG /ID/6 R1OnDelay: integer, Ritarda i comandi di permanent on sul relay 1 per il numero di secondi indicati dal valore

• BIG /ID/7 R1OffDelay: integer, Ritarda i comandi di permanent off sul relay 1 per il numero di secondi indicati dal valore

• BIG /ID/8 R2OnDelay: integer, Ritarda i comandi di permanent on sul relay 2 per il numero di secondi indicati dal valore

• BIG /ID/9 R2OffDelay: integer, Ritarda i comandi di permanent off sul relay 2 per il numero di secondi indicati dal valore

Per quanto riguarda i relais si ricordi che i comandi sono considerati senza priorità, quindi ciascun comando è indipendente e non viene influenzato dagli altri: ad esempio se si invia un R1StairCaseOn a 10000 millisecondi e dopo qualche secondo si invia un R1PermanentOnOff a On, allo scadere dei 10 secondi il relay verrà aperto.

In questo momento non è possibile avere a disposizione lo stato dei relais.

Automatismi sui dispositivi BIG

Quando viene avviata l’app di BIGStudio, se il dispositivo è riconosciuto come BIG, viene spento il led e aperti i relais.

Quando un componente del controllo accessi virtuale riceve l’esito di un transito il componente accende in automatico il led verde (se accesso consentito) o rosso (se negato) per tre secondi.

BIG Intesis WMP Gateway

Permette la comunicazione tra BIGStudio e i dispositivi Intesis che implementano il protocollo ASCII WMP tramite una connessione IP (wireless principalmente).

Unità di informazione ricavate tramite il comando “ID”

• Model STRING Read Only

• MAC STRING Read Only

• IP STRING Read Only

• Protocol STRING Read Only

• Version STRING Read Only

• RSSI INTEGER Read Only

• RSSIMeaning STRING Read Only

Unità di informazione ricavate tramite il comando “INFO”

• RunVersion STRING Read Only

• ConfigVersion STRING Read Only

• Hash STRING Read Only

Unità di informazione ricavate tramite i comandi “GET”

• OnOff BOOL Read Write

• Mode INTEGER Read Write

• SetpointTemperature FLOAT Read Write

• FanSpeed INTEGER Read Write

• VaneUpDown INTEGER Read Write

• VaneLeftRight INTEGER Read Write

• AmbientTemperature FLOAT Read Write

Unità di informazione ricavate tramite i comandi “LIMITS”

• LimitsOnOff_OnLimit BOOL Read Write

• LimitsOnOff_OffLimit BOOL Read Write

• LimitsMode_AutoLimit BOOL Read Write

• LimitsMode_HeatLimit BOOL Read Write

• LimitsMode_DryLimit BOOL Read Write

• LimitsMode_FanLimit BOOL Read Write

• LimitsMode_CoolLimit BOOL Read Write

• LimitsFanSpeed_AutoLimit BOOL Read Write

• LimitsFanSpeed_Speed1Limit BOOL Read Write

• LimitsFanSpeed_Speed2Limit BOOL Read Write

• LimitsFanSpeed_Speed3Limit BOOL Read Write

• LimitsFanSpeed_Speed4Limit BOOL Read Write

• LimitsFanSpeed_Speed5Limit BOOL Read Write

• LimitsFanSpeed_Speed6Limit BOOL Read Write

• LimitsFanSpeed_Speed7Limit BOOL Read Write

• LimitsFanSpeed_Speed8Limit BOOL Read Write

• LimitsFanSpeed_Speed9Limit BOOL Read Write

• LimitsVaneUpDown_AutoLimit BOOL Read Write

• LimitsVaneUpDown_Pos1Limit BOOL Read Write

• LimitsVaneUpDown_Pos2Limit BOOL Read Write

• LimitsVaneUpDown_Pos3Limit BOOL Read Write

• LimitsVaneUpDown_Pos4Limit BOOL Read Write

• LimitsVaneUpDown_Pos5Limit BOOL Read Write

• LimitsVaneUpDown_Pos6Limit BOOL Read Write

• LimitsVaneUpDown_Pos7Limit BOOL Read Write

• LimitsVaneUpDown_Pos8Limit BOOL Read Write

• LimitsVaneUpDown_Pos9Limit BOOL Read Write

• LimitsVaneUpDown_SwingLimit BOOL Read Write

• LimitsVaneLeftRight_AutoLimit BOOL Read Write

• LimitsVaneLeftRight_Pos1Limit BOOL Read Write

• LimitsVaneLeftRight_Pos2Limit BOOL Read Write

• LimitsVaneLeftRight_Pos3Limit BOOL Read Write

• LimitsVaneLeftRight_Pos4Limit BOOL Read Write

• LimitsVaneLeftRight_Pos6Limit BOOL Read Write

• LimitsVaneLeftRight_Pos7Limit BOOL Read Write

• LimitsVaneLeftRight_Pos8Limit BOOL Read Write

• LimitsVaneLeftRight_Pos9Limit BOOL Read Write

• LimitsVaneLeftRight_Pos0Limit BOOL Read Write

• LimitsVaneLeftRight_SwingLimit BOOL Read Write

• LimitsSetPointTemperature_UpperLimit FLOAT Read Write

• LimitsSetPointTemperature_LowerLimit FLOAT Read Write

• LimitsAmbientTemperature_UpperLimit FLOAT Read Only

• LimitsAmbientTemperature_LowerLimit FLOAT Read Only

Altre unità di informazione

• LimitsOnOff_Set BOOL Write Only

• LimitsMode_Set BOOL Write Only

• LimitsFanSpeed_Set BOOL Write Only

• LimitsVaneUpDown_Set BOOL Write Only

• LimitsVaneLeftRight_Set BOOL Write Only

• LimitsSetPointTemperature_Set BOOL Write Only

API

Il gateway API permette di interfacciarsi con delle API web attraverso BIGStudio2.

Tipi di chiamate API supportate

Al momento le chiamate API supportate devono rispondere ai seguenti requisiti:

• Metodo di chiamata GET (non sono supportati altri metodi)

• L’API da chiamare deve essere una stringa fissa in cui l’unica parte variabile è l’IP che si sta interrogando

  • Es. Corretto: http://192.168.1.15/api/test

  • Es. Non gestito: http://192.168.1.15/api/device/15/prova/1

• L’API non può avere un contenuto JSON (o di altro tipo) da passare al momento della chiamata

• L’autenticazione può essere

  • Non presente

  • Basic

  • L’autenticazione Digest NON è gestita!

• La chiamata API può ritornare solo lo stato, oppure anche un pacchetto JSON, che viene scompattato in indirizzi di BIGStudio.

Nelle prossime versioni di BIGStudio la gestione delle API verrà ampliata, riducendo i requisiti di cui sopra.

Configurazione tipi dispositivi API

La configurazione dei tipi di dispositivi API permette di definire un insieme di tipologie di dispositivi, ciascuno dei quali è interrogabile tramite diverse API.

Tutti i dispositivi appartenenti alla stessa tipologia saranno interrogabili con le stesse API; le uniche informazioni univoche per dispositivo saranno il suo indirizzo IP e la sua autenticazione (username, password).

La prima fase della configurazione è quindi relativa all’importazione delle tipologie di dispositivi: per ogni tipologia è necessario definire un json come il seguente:

{
    'DeviceDescription': 'Door Bird',
    'Manufacturer': 'Door bird',
    'API': [
        {
            'Name': 'Door bird apertura porta',
            'URL': 'http://#physicalAddressDevice/bha-api/open-door.cgi?r=1',
            'Method': 'GET',
            'ReturnContentType': '',
            'ReturnContentFormat': [],
            'InputContentType': '',
            'InputContentFormat': []
        },
        {
            'Name': 'Door bird accensione luce',
            'URL': 'http://#physicalAddressDevice/bha-api/light-on.cgi',
            'Method': 'GET',
            'ReturnContentType': '',
            'ReturnContentFormat': [],
            'InputContentType': '',
            'InputContentFormat': []
        },
        {
            'Name': 'Door bird stato',
            'URL': 'http://#physicalAddressDevice/bha-api/info.cgi',
            'Method': 'GET',
            'ReturnContentType': 'json',
            'ReturnContentFormat': [
                'BHA.RETURNCODE',
                'BHA.VERSION[0].FIRMWARE',
                'BHA.VERSION[0].BUILD_NUMBER',
                'BHA.VERSION[0].WIFI_MAC_ADDR',
                'BHA.VERSION[0].RELAYS',
                'BHA.VERSION[0].DEVICE-TYPE'
            ],
            'InputContentType': '',
            'InputContentFormat': []
        }
    ]
}

Dove:

• La prima parte è relativa al dispositivo (descrizione e manufacturer), seguita dall’elenco delle API
• Se l’API prevede solo una chiamata senza valori di ritorno (a parte lo stato) può essere configurata come segue:
  • Name: nome dell’API, sarà anche il nome dell’indirizzo BIG usato per effettuare la chiamata API
  • URL: URL fisso da chiamare; l’IP del dispositivo viene indicato con la keyword #physicalAddressDevice
  • Method: GET, POST (per ora solo la GET è supportata)
  • ReturnContentType: tipo dell’oggetto ritornato dall’API; da lasciare vuoto se non ritorna valore, JSON se ritorna un JSON
  • ReturnContentFormat: se la chiamata ritorna un JSON allora è necessario compilare l’array del ReturnContentFormat con l’elenco dei token JSON di interesse. Verranno tutti trattati gestiti come Stringhe a meno di ulteriori modifiche da BIGStudio2
  • InputContentType: tipo dell’oggetto da passare nel corpo della chiamata API; da lasciare vuoto se non richiede un valore, JSON se richiede un JSON. PER ORA NON è SUPPORTATO!
  • InputContentFormat: come il returnContentFormat. PER ORA NON è SUPPORTATO!

Una volta costruito il JSON questo può essere importato in BIGStudio tramite il pulsante di importazione della sezione API.

Creazione dispositivi API

Una volta importate le tipologie di dispositivi API è possibile creare i dispositivi.

Figura 119

Per ciascun dispositivo va indicato un nome, la tipologia (fra quelle importate precedentemente), l’indirizzo fisico, eventuale username e password.

Nodi ed indirizzi

Fatto ciò, sotto il nodo BIGOmnia nascono i seguenti nodi/indirizzi:

Figura 120

• Per ogni dispositivo nasce una cartella

• Per ogni API definita nel tipo di dispositivo nascono:

  • Un indirizzo (API/IDDevice/X) con il nome dell’API indicato nel JSON che viene usato per effettuare la chiamata API. Può essere scritto con un qualsiasi valore ed effettua sempre la chiamata.

  • Per ogni informazione Y presente nell’InputContentFormat viene creato un indirizzo (API/IDDevice/Y) con nome “nome dell’API + Y” da scrivere prima di effettuare la chiamata API; al momento della chiamata verranno usati i valori attuali di questi indirizzi per comporre il JSON da inviare. NON ANCORA SUPPORTATO

  • Per ogni informazione Z presente nel ReturnContantFormat viene creato un indirizzo (API/IDDevice/Z) con nome “nome dell’API + Z” che viene scritto da BIGOmnia nel momento in cui la chiamata API ritorna un valore nel JSON.

Informazioni aggiuntive chiamate API

Ogni volta che viene effettuata una chiamata API nello storico comandi viene inserita una riga che ha risultato positivo se la chiamata API è andata a buon fine, negativo altrimenti.

MQTT

L’obiettivo è integrare qualsiasi dispositivo che possa inviare informazioni in MQTT comportandosi come client.

Il dispositivo si collega al broker MQTT presente all’interno del MasterGateway e invia dati che sono tradotti in indirizzi nel sistema BIGStudio.

Parole cardine

• Tipo di dispositivo: è la configurazione di una tipologia di dispositivo, indipendentemente dal singolo specifico dispositivo

• Dispositivo: è lo specifico dispositivo, è riconosciuto tramite un identificativo univoco che viene considerato come il suo indirizzo fisico e appartiene ad una certa tipologia di dispositivo.

• Topic: è l’informazione che viene scambiata fra il dispositivo e il broker MQTT presente nel Master Gateway; il suo valore può essere semplice (un intero, un float, un boolean) oppure complesso (un json)

Creazione gateway MQTT

Il gateway MQTT viene creato dal Master Gateway quando carica le informazioni relative a MQTT, pertanto è da verificare nelle impostazioni di BIGStudio2 che MQTT sia abilitato.

Figura 121

Configurazione gateway MQTTS

Il gateway MQTT Master Gateway può essere impostato a MQTTSecure dalle impostazioni (a partire dalla versione 3.800). Se è abilitato, nelle impostazioni è possibile inserire il protocollo SSL (di default impostato a TLSv1_2) e la password del certificato .pfx. Il certificato deve essere salvato con nome certificate.pfx al percorso Certificates.

Configurazione connessione MQTT del dispositivo

Il dispositivo deve essere configurato in modo che mandi dati al broker MQTT presente nel MasterGateway (indirizzo IP del server e porta configurata, di default 1883).

Visto che il broker richiede un’autenticazione è necessario creare un utente di BIGStudio2 per la sua autenticazione (se ne può usare uno per tutti i client MQTT); nella configurazione dell’autenticazione del dispositivo vanno inseriti Username e Password in chiaro di BIGStudio2.

Importazione in BIGStudio delle tipologie di dispositivi

Nella pagina del gateway di BIGStudio, così come viene fatto per M-Bus, è possibile importare i tipi di dispositivi MQTT e creare dei dispositivi assegnandogli la tipologia.

Figura 122

La configurazione del nuovo tipo di dispositivo viene fatta attraverso la creazione di un file JSON che segue la seguente struttura:

{
    "Name": "temperatura",
    "Topic": "shelly/#physicalAddressDevice/temperature",
    "PayloadKind": 0,
    "PayloadSection": "",
    "DeviceKind": "temperatura",
    "ReadOnly": 1
}

• Name: nome dell’informazione (sarà il nome dell’indirizzo)

• Topic: stringa del topic ricevibile da quel dispositivo

  • Se deve contenere un identificativo del Dispositivo si usa la keyword #physicalAddressDevice

• PayloadKind: intero, tipo del payload

  • 0=il valore del payload è già il valore definitivo dell’informazione indicata dal topic

  • 1=il valore del payload è un json che può contenere più informazioni

• PayloadSection: vuoto se il PayloadKind = 0, altrimenti indica i componenti del JSON che rappresentano l’informazione nella forma X.Y.Z dato un json della forma {x: {y: {z:1}}}

• DeviceKind: nome della tipologia dell’indirizzo in BIGStudio fra le tipologie MQTT: VERIFICARE SEMPRE PRIMA DELL’IMPORTAZIONE CHE ESISTA UN DEVICE_KIND MQTT CON QUEL NOME

• ReadOnly: boolean, indica se l’indirizzo che ne deriva è in sola lettura o può essere scritto

Esempio json

Dato un dispositivo che invia i seguenti topic:

shellies/shellyht-<deviceid>/sensor/temperature: in °C or °F depending on configuration

shellies/shellyht-<deviceid>/sensor/humidity: RH in %

shellies/shellyht-<deviceid>/sensor/battery: battery level in %

Il JSON derivante è:

{
    {'DeviceDescription': 'ShellyH&T',
    'Manufacturer': 'Shelly',
    'Topics':[{'Name': 'Temperatura',
    'Topic': 'shellies/shellyht-#physicalAddressDevice/sensor/temperature',
    'PayloadKind':0,
    'PayloadSection':'',
    'DeviceKind':'Integer',
    ‘ReadOnly’:1
    },
    {'Name': 'Umidita',
    'Topic': 'shellies/shellyht-#physicalAddressDevice/sensor/humidity',
    'PayloadKind':0,
    'PayloadSection':'',
    'DeviceKind':'Integer',
    ‘ReadOnly’:1
    },
    {'Name': 'Batteria',
    'Topic': 'shellies/shellyht-#physicalAddressDevice/sensor/battery',
    'PayloadKind':0,
    'PayloadSection':'',
    'DeviceKind':'Integer',
    ‘ReadOnly’:1
    }]}
}

Quando viene importato il json associato ad una certa tipologia di dispositivo questo ha al suo interno l’indicazione del nome della tipologia di indirizzo da associare ad ogni informazione.

Il nome è esattamente quello visibile nella sezione Tipologia indirizzi in BIGStudio2. Pertanto si consiglia, prima di importare il json di verificare che le tipologie di indirizzi siano configurate e in caso contrario configurarle.

Creazione del dispositivo

Per creare il dispositivo, dopo aver importato la relativa tipologia, è sufficiente premere sul pulsante Nuovo e definire il nome del dispositivo, la sua tipologia e il suo identificativo

Figura 123

.. figure:: table2.png :width: 600px :align: center

Figura 124

Indirizzi

Ogni volta che viene creato un dispositivo nascono:

• Un dispositivo e la sua cartella sotto il nodo del gateway MQTT

  • Handle = idDevice

  • NameFolder = Name device

• Un indirizzo per ogni riga nella tabella MQTT_DEVICE_DEVICE_KIND correlata

  • Address = MQTT/CustomIDDevice/IDRigaMQTTDeviceKind

  • Name = name nella tabella MQTT_DEVICE_DEVICE_KIND

  • Tipologia = DeviceKind nella tabella MQTT_DEVICE_DEVICE_KIND

  • Handle treenode = idAddress

  • Name treenode = Name dell’indirizzo

  • Readonly = ReadOnly nella tabella MQTT_DEVICE_DEVICE_KIND

Figura 125

Gestione ricezione topic nel MasterGateway

Ogni volta che arriva un topic nel MasterGateway questo:

Figura 126

I due dizionari citati contengono rispettivamente tutti i topic che sono definiti con PayloadKind=0 (cioè un valore semplice nel payload del messaggio MQTT) e tutti quelli definiti con PayloadKind = 1

(cioè un valore json complesso nelpayload del messaggio MQTT che verrà spacchettato in n indirizzi BIGStudio)

Network

Il gateway Network permette l’integrazione di BIGStudio con i dispositivi di rete Mikrotik tramite protocollo SSH.

Al momento sono integrati solo i router Mikrotik e le operazioni possibili sono:

• Creazione di un nuovo utente con accesso alla rete

• Abilitazione dell’utente per l’accesso alla rete

• Disabilitazione dell’utente per l’accesso alla rete

Configurazione Dispositivo di rete

Figura 127

Attraverso la barra degli strumenti è possibile:

• Inserire un nuovo dispositivo

• Duplicare i dispositivi selezionati

• Eliminare i dispositivi selezionati

Figura 128

Per ogni dispositivo è necessario indicare (dati salvati nella tabella DEVICES):

• Il nome del dispositivo (DEVICES.DESCRIPTION)

• Il tipo del dispositivo (per ora solo Mikrotik) (DEVICES.ID_VIMAR_DEVICE)

• L’indirizzo fisico (DEVICES.PHYSICAL_ADDRESS)

• Username di accesso al dispositivo (DEVICES.DAHUA_USERNAME)

• Password di accesso al dispositivo (DEVICES.PASSWORD)

Dispositivi Mikrotik

Per ogni dispositivo Mikrotik nascono le seguenti informazioni:

Figura 129

• Cartella Nome dispositivo [handle = devices.ID]

  • MIKROTIK/CUSTOM_ID_DEVICE/1 HotSpotUserAdd: Stringa, utilizzata per aggiungere un utente al router; il formato della stringa deve essere name=x|password=y|sharedUsers=z, dove name è il nome utente, password la sua password e sharedUsers il numero di connessioni simultanee che può avere quell’utente

  • MIKROTIK/CUSTOM_ID_DEVICE/2 HotSpotUserRemove: Stringa, utilizzata per rimuovere un utente dal router; la stringa deve contenere il nome dell’utente.

  • MIKROTIK/CUSTOM_ID_DEVICE/3 HotSpotUserEnable: Stringa, utilizzata per abilitare un utente già esistente sul router; la stringa deve contenere il nome dell’utente.

  • MIKROTIK/CUSTOM_ID_DEVICE/4 HotSpotUserDisable: Stringa, utilizzata per disabilitare un utente già esistente sul router; la stringa deve contenere il nome dell’utente.

  • MIKROTIK/CUSTOM_ID_DEVICE/5 EnableAll: Boolean, da scrivere ad 1 per abilitare tutti gli utenti presenti sul router.

  • MIKROTIK/CUSTOM_ID_DEVICE/6 DisableAll: Boolean, da scrivere ad 1 per disabilitare tutti gli utenti presenti sul router.

La creazione degli indirizzi è automatica in base ai dati inseriti nella tabella VIMAR_DEVICE_DEVICE_KIND: ogni volta che viene creato un dispositivo di tipologia X (X è l’ID della tipologia nella tabella KNOWN_DEVICE) viene generato un indirizzo per ogni corrispondenza trovata nella tabella VIMAR_DEVICE_DEVICE_KIND dove l’ID_VIMAR_DEVICE è X. Gli indirizzi generati sono sempre della forma NETWORK/CUSTOM_ID_DEVICE/PROPERTY_IDENTIFICATION con nome pari a PROPERTY_DESCRIPTION.

La compilazione della tabella VIMAR_DEVICE_DEVICE_KIND è lasciata al gateway.

BACNET

Il gateway BACNET permette di configurare BIGStudio2 come un client BACNET, il quale data una lista di dispositivi BACNET può interagirci, scrivendo e leggendo gli oggetti esposti e le loro proprietà.

Tipi di oggetti riconosciuti

Di seguito sono elencati gli oggetti BACNET gestiti, con l’elenco delle proprietà supportate, il loro tipo e la possibilità di scrittura (R=solo lettura, W=lettura e scrittura).

DEVICE

Property	Data type	Writable
OBJECT_IDENTIFIER	BACNetObjectIdentifier	R
OBJECT_NAME	String	R
OBJECT_TYPE	BACNetObjectType	R
SYSTEM_STATUS	BACNetDeviceStatus	R
VENDOR_NAME	String	R
VENDOR_IDENTIFIER	Int	R
MODEL_NAME	String	R
FIRMWARE_REVISION	String	R
APPLICATION_SOFTWARE_VERSION	String	R
PROTOCOL_VERSION	Int	R
PROTOCOL_REVISION	Int	R
PROTOCOL_SERVICES_SUPPORTED	BACNetServicesSupported	R
PROTOCOL_OBJECT_TYPE_SUPPORTED	BACNetObjectTypesSupported	R
OBJECT_LIST	String	R
MAX_ADPU_LENGTH_ACCEPTED	Int	R
SEGMENTATION_SUPPORTED	BACNetSegmentation	R
APDU_TIMEOUT	Int	R
NUMBER_OF_APDU_RETRIES	Int	R
DATABASE_REVISION	Int	R

ANALOG (INPUT, OUTPUT E VALUE)

Property	Data type	W1	W	W
OBJECT_IDENTIFIER	BACNetObjectIdentifier	R	R	R
OBJECT_NAME	String	R	R	R
OBJECT_TYPE	BACNetObjectType	R	R	R
PRESENT_VALUE	Real	W1	W	W
STATUS_FLAG	BACNetStatusFlags	R	R	R
EVENT_STATE	BACNetEventState	R	R	R
OUT_OF_SERVICE	Boolean	R	R	R
UNITS	BACNetEngineeringUnits	R	R	R
CURRENT_COMMAND_PRIORITY	BACNetOptionalUnsigned	R
RELINQUISH_DEFAULT	Real		R

MULTI STATE (INPUT, OUPUT E VALUE)

Visto che il PRESENT_VALUE del MultiState si presenta come un intero, per poterlo utilizzare facilmente all’interno del software si consiglia di creare una tipologia di indirizzo avente stati e metodi corrispondenti agli stati del MultiState, in modo da renderlo più fruibile all’interno del sistema. La tipologia di indirizzo può essere creata e associata nella sezione indirizzi.

Property	Data type	Input	Output	Value
OBJECT_IDENTIFIER	BACNetObjectIdentifier	R	R	R
OBJECT_NAME	String	R	R	R
OBJECT_TYPE	BACNetObjectType	R	R	R
PRESENT_VALUE	Unsigned	W	W	W
STATUS_FLAG	BACNetStatusFlags	R	R	R
EVENT_STATE	BACNetEventState	R	R	R
OUT_OF_SERVICE	Boolean	R	R	R
NUMBER_OF_STATE	Unsigned	R	R	R
PRIORITY_ARRAY	BACNetProprityArray		R
CURRENT_COMMAND_PRIORITY	BACNetOptionalUnsigned		R
RELIQNQUISH_DEFAULT	Real		R

Configurazione di un dispositivo BACNET

Figura 130

Dal menù strumenti è possibile:

• Creare un nuovo dispositivo

• Duplicare uno o più dispositivi selezionati

• Eliminare il dispositivo selezionato

• Aggiungere un oggetto al dispositivo selezionato

• Eliminare uno o più oggetti selezionati

• Cercare nella rete locale i dispositivi BACNET presenti

Per ciascun dispositivo BACNET è necessario indicare:

Figura 131

• Il nome del dispositivo: testo libero

• L’indirizzo IP fisico del dispositivo; i formati possibili sono:

  • IP:Porta nel caso in cui l’indirizzo IP identifichi un solo dispositivo BACNET

  • Type|Net|IP:Porta|TypeRouted|NetRouted|IPRouted:PortaRouted nel caso in cui ci sia un primo dispositivo che fa da ponte (MSTP) con altri dispositivi;

    -Type: tipo di rete (None = 0, IP = 1, MSTP = 2, Ethernet = 3, ArcNet = 4, LonTalk = 5, PTP = 6) -Net: numero della rete -IP:Porta: IP e porta del primo dispositivo (quello che fa da ponte) -TypeRouted: tipo di rete del dispositivo finale -NetRouted: numero della rete -IPRouted:PortaRouted: IP e porta del dispositivo finale

• Il BACNET ID del dispositivo: l’identificativo unico del dispositivo nella rete BACNET

• Il flag di inserito manualmente indica se è stato configurato a mano dall’utente o se è stato importato a seguito di una ricerca dei dispositivi in rete.

Ciascun dispositivo espone degli oggetti che possono essere configurati a mano e richiedono:

Figura 132

• ID: identificativo dell’oggetto, deve essere unico all’interno del sistema; ogni volta che viene creato un nuovo dispositivo i suoi oggetti partono con ID incrementato di 100 rispetto all’ultimo dispositivo creato. L’ID proposto dal software è sempre univoco.

• Nome: il nome dell’oggetto; se l’oggetto è creato dall’utente viene inserito a piacere, se derivante da importazione viene proposta la property OBJECT_NAME dell’oggetto.

• Tipo oggetto: tipologia BACNET dell’oggetto. La scelta è limitata alle tipologie gestite dal software; le altre tipologie vengono identificate come NON GESTITE. Una volta definita la tipologia nasce un indirizzo per ogni property gestita da quella tipologia, sulla base di quanto definito nei paragrafi precedenti.

• Istanza: istanza BACNET dell’oggetto in riferimento alla sua tipologia.

• Ricevi dati su variazione: in caso di attivazione viene abilitata la sottoscrizione sull’oggetto BACNET per il COV (Change Of Value); nel caso in cui il dispositivo e l’oggetto in questione gestiscano il COV viene inviata una segnalazione a tutti i BACNET client sottoscritti a tale evento nel momento in cui il PRESENT_VALUE dell’oggetto cambia valore. Tramite questa sottoscrizione il gateway rileva le variazioni del PRESENT_VALUE e ne mantiene aggiornato il valore.

• Ricevi dati per [m]: la sottoscrizione al COV è temporanea, infatti in fase di sottoscrizione è necessario indicare il tempo (in minuti) per cui il client rimane iscritto; allo scadere del tempo il dispositivo BACNET disiscrive automaticamente il client. Per evitare disallineamenti fra lo stato reale del dispositivo e l’informazione rilevata dal software viene gestita l’automatica reiscrizione nel momento della scadenza. È necessario comunque indicare il tempo per cui viene mantenuta la sottoscrizione. Il default da standard BACNET è di 60 ora: NB. Da documentazione il default dei dispositivi Schneider è 8 ore.

• Eliminato: nel caso in cui venga reimportato un dispositivo che non esponga più determinati oggetti, tali oggetti vengono mantenuti nel software ma indicati come eliminati.

• Tipo: tipologia in BIGStudio2 dell’indirizzo PROP_PRESENT_VALUE dell’oggetto corrente.

Ricerca automatica dei dispositivi

Alcuni dispositivi BACNET si presentano automaticamente (IAm) sulla rete quando viene inviato un apposito segnale di ricerca (WhoIs). Tramite questo automatismo è possibile cercare i dispositivi e importarli automaticamente nel software, senza doverli configurare manualmente. La ricerca dei dispositivi avviene solo nella rete locale del pc.

La ricerca dei dispositivi mostra per ogni dispositivo il suo nome, il suo indirizzo IP, il suo BACNET ID e il numero di oggetti associati; per ciascun dispositivo è possibile vedere se il dispositivo è già presente (con lo stesso BACNET ID) e decidere di importarlo o meno.

In caso di importazione di un nuovo dispositivo viene creato il dispositivo, a cui vengono aggiunti tutti gli oggetti esposti (con le relative proprietà). Gli oggetti riconosciuti vengono correttamente tipizzati, quelli non ancora gestiti vengono indicati con tipologia NON_GESTITA.

In caso di importazione di un dispositivo già presente (con lo stesso BACNET ID) gli oggetti presenti nel sistema ed esposti dal dispositivo vengono mantenuti, quelli presenti nel sistema e non esposti dal dispositivo vengono segnati come Eliminati, quelli non presenti nel sistema ma esposti dal dispositivo vengono aggiunti. Un oggetto è considerato presente se appartiene allo stesso dispositivo e ha lo stesso OBJECT_TYPE e la stessa istanza; se l’oggetto è già presente viene aggiornato il suo nome.

Attenzione! Non tutti i dispositivi si presentano su richiesta, pertanto anche se sono presenti nella rete sarà necessario configurarli manualmente. Inoltre, alcuni dispositivi si presentano automaticamente al loro avvio: le presentazioni di questi dispositivi vengono ignorate, dato che non sono conseguenti ad una richiesta.

I dispositivi che supportano la funzione WhoIs rispondono molto velocemente alla richiesta con il loro IAm; è possibile configurare il tempo di attesa delle risposte, oltre il quale le risposte ricevute non vengono considerate. Il tempo di default è di 10 secondi.

Figura 133

Indirizzi BACNET generati

Figura 134

Per ciascun dispositivo BACNET è definito un nodo nell’albero degli indirizzi; ogni suo oggetto è identificato da un nodo figlio; ciascuna proprietà di un oggetto rappresenta un indirizzo BIG della forma: BACNET/ID OGGETTO/ENUMERATORE PROPERTY Dove:

• BACNET è una stringa fissa;

• ID OGGETTO è l’ID dell’oggetto visibile nella sua configurazione

• ENUMERATORE PROPERTY è un numero che identifica la proprietà

Per BACNET sono state aggiunte nativamente alcune tipologie di indirizzi per gestire le omonime proprietà:

• SystemStatus: Operational=0|Operational (read only)=1|Download in progress=3|Non operational=4|Backup in progress=5;
• Segmentation: Both (transmit/receive)=0|Transmit only=1|Receive only=2|None=3
• StatusFlags: Normal=0|Alarm=8|Fault=4|Value overridden=2|Out of service=1|
  Alarm, Fault=12|Alarm, Value overridden=10|Alarm, Out of service=9|Fault, Value overridden=6|
  Fault, Out of service=5|Value overridden, Out of service=3|Alarm, Fault, Value overridden = 14|
  Alarm, Value overridden, Out of service=11|Alarm, Fault, Out of service=13|Fault, Value overridden,
  Out of service=7|Alarm, Fault, Value overridden, Out of service=15
• Valore = ENCODER_NUMBER|NUMBER OF KEY|ROOM1|ROOM2|ROOM3|ROOM4|
  AUTHORISATION_GRANTED|AUTHORISATION_DENIED|START_DATETIME|EXPIRATION_DATETIME
  |OPERATOR_DATA|TRACK1|TRACK2|TRACK3|RETURN_CARD_SERIAL_NUMBER
  ad esempio “1|1|101|102|||||1030150917|23300917|Operator||||0”
  [scrive 1 tessera per camera 101, con accesso alla 102, valida dalle 10:30 del 15/09/2017 alle 23:00 del 30/09/2017]
• EventState: Normal=0|Fault=1|Off-normal=2|High limit=3|Low limit=4|Life safety=5
• ObjectType:OBJECT_ANALOG_INPUT=0|OBJECT_ANALOG_OUTPUT=1|OBJECT_ANALOG_VALUE=2|
  OBJECT_BINARY_INPUT=3|OBJECT_BINARY_OUTPUT=4|OBJECT_BINARY_VALUE=5|OBJECT_DEVICE=8|
  OBJECT_MULTI_STATE_INPUT=13|OBJECT_MULTI_STATE_OUTPUT=14

Come detto precedentemente per gli oggetti di tipo Multi State si consiglia di creare una tipologia di indirizzo ad hoc per il PRESENT_VALUE in modo da decodificarne il valore e renderlo significativo per l’utente finale.

Gestione priorità BACNET

Per ogni oggetto BACNET è definito un indirizzo PRIORITY_ARRAY in sola lettura che rappresenta l’array attuale di priorità BACNET per l’oggetto in questione.

In aggiunta è presente un indirizzo BIG_PRIORITY che rappresenta la priorità su cui verrà scritto il PROP_PRESENT_VALUE alla successiva scrittura. Se l’indirizzo non è valorizzato la priorità di default è 16.

Per scrivere un valore ad una priorità maggiore, quindi è necessario scrivere la BIG_PRIORITY alla priorità su cui si vuole scrivere, scrivere il PRESENT_VALUE e infine abbassare nuovamente la priorità al suo valore di default.

Per cancellare il valore scritto su una certa priorità scrivere il PRESENT_VALUE (dopo aver impostato la priorità) al valore ‘NULL’ (stringa testuale).

ADS

Il gateway ADS permette di configurare BIGStudio2 come un client ADS, il quale data una lista di dispositivi ADS può interagirci, scrivendo e leggendo gli indirizzi del progetto plc Beckhoff.

Configurazione di un dispositivo ADS

Dal menù strumenti è possibile:

• Creare un nuovo dispositivo manualmente (identificato dal suo NETID)

• Eliminare il dispositivo selezionato

• Aggiungere un oggetto (cartella/indirizzo) al dispositivo selezionato

• Eliminare uno o più oggetti selezionati

• Importare automaticamente tutti gli oggetti da un dispositivo, inserendo come parametro la cartella presente nel progetto PLC nella quale ricercare gli oggetti da importare automaticamente

Ogni volta che si crea un dispositivo è necessario indicare:

• NETID: identificativo riconosciuto da Beckhoff (obbligatorio)

• Indirizzo IP: (obbligatorio)

• NETID secondario: identificativo riconosciuto da Beckhoff di un secondo plc Beckhoff usato come ridondanza rispetto al primo (facoltativo)

• Indirizzo IP secondario: indirizzo ip di un secondo plc Beckhoff usato come ridondanza rispetto al primo (facoltativo)

• Versione di TwinCAT: 2 o 3

• Strategia di rientro dallo swap del secondario: spiegata nel dettaglio nella sezione dedicata

Figura 135

Per ciascun dispositivo nascono i seguenti indirizzi:

• ADS_IDDevice/Import [bool]: utilizzato per sollecitare l’importazione automatica di un insieme di indirizzi

• ADS_IDDevice/ImportResult [int]: 0 se l’importazione è fallita, 1 se è in corso, 2 se è stata terminata con successo

• ADS_IDDevice/Connected [bool]: 0 se il dispositivo non è connesso, 1 se il dispositivo è connesso; se ad un dispositivo logico su BIGStudio corrispondono più plc (c’è ridondanza) questo indirizzo si riferisce al plc corrente

• ADS_IDDevice/State [bool]: 1 se il dispositivo è running, 0 se non è running; se ad un dispositivo logico su BIGStudio corrispondono più plc (c’è ridondanza) questo indirizzo si riferisce al plc corrente

• ADS_IDDevice/DeviceConnected [integer]: se ad un dispositivo logico su BIGStudio corrispondono più plc (c’è ridondanza) questo indirizzo indica quale dei dispositivi fisici è correntemente usato; 0 indica il primario, 1 il secondario

• ADS_IDDevice/DeviceSwap [bool]: scrivibile da parte dell’utente per forzare lo swap del dispositivo in ritorno verso il plc primario; il pulsante di swap nella sezione ADS scrive ad 1 questo dispositivo per forzare il ritorno verso il plc primario

Figura 136

Multi master e swap fra i diversi dispositivi fisici

Ad ogni plc logico su BIGStudio possono essere associati più plc fisici che permettono la ridondanza dei dati: il primo di questo è quello considerato come principale, il secondo (definito come secondario) è utilizzato solo quando il primario non è raggiungibile in rete e viene selezionato automaticamente dal gateway ADS.

Se si ha a disposizione il plc secondario ogni volta che il primario non è più raggiungibile per un tempo predefinito si effettua lo swap sul secondario.

Lo swap di ritorno dal dispositivo secondario al primario può essere effettuato secondo tre strategie:

1. Effettua lo swap sul primario non appena è di nuovo a disposizione (secondario e primario): nel momento in cui viene effettuato lo swap sul secondario viene avviato un controllo periodico (una volta al minuto) di raggiungibilità sul primario; il controllo prevede un iniziale ping al dispositivo primario, seguito, in caso di successo, da un reale tentativo di connessione tramite ADS al dispositivo primario; se il controllo termina con successo il gateway ADS disconnette il secondario e si riconnette al primario.

2. Effettua lo swap solo quando il dispositivo corrente muore (due primari): nel momento in cui viene effettuato lo swap sul secondario questo plc viene considerato come primario, perciò fino a che il secondario (ora nuovo primario) rimane online ed è possibile collegarsi con ADS il dispositivo corrente viene considerato come primario. Quando il dispositivo corrente non è più utilizzabile il software automaticamente tenta la connessione al primario originale. Nel caso in cui il primario originale non sia più utilizzabile ma non lo è neanche il secondario il software tenta periodicamente lo switch fra i due plc in attesa che uno dei due ritorni online.

3. Effettua lo swap solo con il comando manuale dell’utente: nel momento in cui viene effettuato lo swap sul secondario il software non tenta mai nessuna procedura di ritorno sul plc primario, fino a che non riceve il comando manuale di un utente tramite il software di BIGStudio. Anche se il secondario diventasse inutilizzabile il software ritenta sempre la connessione con il secondario, senza considerare mai il primario.

Ogni volta che viene effettuato uno swap dal primario al secondario (o viceversa) il software registra sul nuovo dispositivo le notifiche CoV in modo da riottenere i dati aggiornati; è compito dei due plc mantenere sincronizzati i dati.

Figura 137

Configurazione indirizzi ADS

Per ciascun indirizzo ADS è necessario indicare:

Figura 138

• Dimensione: la dimensione dell’oggetto è la stessa del progetto PLC e dipende dal tipo di dato

• Formato di alto livello: rappresenta il tipo dell’oggetto

• Fattore:

• Offset:

• Nome: il nome dell’oggetto

• ID: valore univoco di identificazione dell’indirizzo

• Identificativo: stringa univoca che si riferisce all’oggetto creato

• Tipologia:

• Ricevi dati su variazione: check per attivare la sincronizzazione automatica, se lato plc il valore cambia, si aggiorna automaticamente il valore lato BIGStudio; la sincronizzazione automatica tramite le librerie di TwinCAT permette la registrazione alle notifiche per un massimo di 1000 indirizzi. Se si attivano più di 1000 indirizzi quelli in esubero non verranno considerati.

Tipologie di oggetti

Vengono gestiti i seguenti tipi di oggetti:

• INT: lettura e scrittura

• REAL: lettura e scrittura

• DOUBLE: lettura e scrittura

• STRING: lettura e scrittura

• BOOLEAN: lettura e scrittura

• DATE,DATETIME: lettura e scrittura

• TIME: lettura

Importazione automatica indirizzi

Attenzione: in TwinCAT2 non è possibile filtrare gli indirizzi, perciò quando viene lanciata l’importazione vengono importate tutte le variabili configurate sul plc! Questa operazione richiede tantissimo tempo, quindi in caso di TwinCAT2 sarà necessario configurare a mano gli indirizzi ADS sotto una cartella genitore il cui nome è ‘’ (stringa vuota, da usare al posto di GVL usato in TwinCAT3).

BIGStudio richiede una cartella di partenza dentro la quale ricercare tutti gli oggetti da importare per poi procedure all’importazione. E’ possible reimportare tutti gli oggetti nel caso ne venissero aggiunti alcuni selezionando la stessa cartella padre (BIGStudio gestisce i doppioni) ma non è possible gestire la modifica di oggetti ( se viene modificato il nome di un oggetto, il sistema non agisce in modifica ma in aggiunta).

Una volta importati gli oggetti, verranno visualizzati nella corrispondente finestra nel seguente modo:

Figura 139

Cliccando con il tasto dx sui singoli oggetti è possibile effettuare una lettura e/o scrittura:

Figura 140

ADS over MQTT

È possibile utilizzare ADS sfruttando il protocollo MQTT, seguendo le istruzioni al link:

https://infosys.beckhoff.com/english.php?content=../content/1033/tc3_adssamples_net/185256971.html&id=

La gestione di ADS over MQTT è trasparente al gateway ADS di BIGStudio, ma richiede l’installazione e la configurazione di Mosquitto con i plugin di TwinCAT e la configurazione dei file di route tramite MQTT nella cartella di installazione di TwinCAT come definito nel manuale linkato sopra.

Security

Il gateway Security permette di integrare i principali sistemi di antifurto, in modo da poter gestire l’attivazione e disattivazione dell’antifurto nelle sue diverse parti e rilevare eventuali intromissioni.

Configurazione comunicazione con la centralina

La configurazione con la centralina passa attraverso i seguenti parametri:

Figura 141

• IP: IP della centralina

• Porta: porta su cui comunica la centralina

• Tipo centralina: TecnoAlarm

  • Passphrase:

  • Access code:

• Zone utilizzate: numero di zone realmente utilizzate

• Programmi utilizzati: numero di programmi realmente utilizzati

Creazione indirizzi

Nel momento in cui vengono definiti i parametri di comunicazione con la centralina e la prima connessione va a buon fine, il Security Gateway crea automaticamente tutti gli indirizzi necessari sulla base del tipo di centralina riconosciuta e del numero di zone e programmi utilizzati (indicati nella configurazione).

La creazione degli indirizzi si basa sulla tabella [VIMAR_DEVICE_DEVICE_KIND]: per ogni informazione della centralina da gestire viene creata una riga nella forma:

• ID_VIMAR_DEVICE = 4 (fisso, unknown)

• PROPERTY_IDENTIFICATION: incrementale, usato come subgroup dell’indirizzo associato

• DESCRITPION: nella forma NomeCentralina|GENERIC_AREA_ZONE|AddressName;

  • NomeCentralina è il nome della centralina usata (es. TecnoAlarm)

  • GENERIC_AREA_ZONE contiene la stringa GENERIC, AREA o ZONE per indicare il fatto che l’indirizzo ricade nei generici della centralina o in quelli area o in quelli zona; gli indirizzi identificati per area o zona vengono replicati per ogni zona/area usata

In particolare, il consiglio è di organizzare i dati nella [VIMAR_DEVICE_DEVICE_KIND] per arrivare a creare tre blocchi distinti di indirizzi:

• Generic: contiene gli indirizzi associati alla centralina nel suo complesso; sono della forma SECURITY/0/X

• Area: contiene gli indirizzi associate alle aree; per ogni area nasce una cartella nell’albero degli indirizzi (con handle pari al numero dell’area) dove sono raccolti tutti i dati della singola area; gli indirizzi sono nella forma: SECURITY/AREA_N/X dove N è il numero dell’area;

• Zone: contiene gli indirizzi associati alle zone; per ogni zona nasce una cartella nell’albero degli indirizzi (con handle pari al numero della zona) dove sono raccolti tutti i dati della singola zona; gli indirizzi sono nella forma SECURITY/ZONE_N/X dove X è il numero della zona;

Rinomina zone/aree

Nella configurazione del gateway è possibile vedere l’elenco delle zone e dei programmi configurati: ciascuno di essi nasce avendo come nome il numero stesso della zona o del programma ma può essere modificato direttamente dalla griglia.

Figura 142

Lettura periodica stato centralina

Visto che la centralina non invia automaticamente le variazioni di stato dei sensori è necessario impostare delle letture periodiche. Tramite la sezione Lettura periodica stati è possibile configurare un ciclo di lettura che viene ripetuto per tutto il periodo di vita del gateway: il ciclo è formato da un insieme di comandi distanziati fra di loro da un numero di secondi definito; nel ciclo è possibile ripetere la lettura di un certo comando, in modo da leggere le informazioni più significative con maggiore frequenza.

I comandi possibili sono:

• READ_STATUS: lettura completa dello stato della centralina

• READ_ZONE: lettura completa dello stato di tutte le zone

• READ_PROGRAMS: lettura completa dello stato di tutti i programmi

Un esempio di configurazione è il seguente, in cui si aspettano 2 secondi, si legge lo stato completo della centralina, si legge per 4 volte lo stato completo delle zone a distanza di 1 secondo e infine si legge lo stato dei programmi con 1 secondo di ritardo. Al termine le letture riprendono dall’inizio.

Figura 143

Sincronizzazione con la rubrica LDAP

È possibile esportare in LDAP i nominativi dei clienti/staff, le loro mail e gli UID delle loro tesser Mifare per integrazione con softwrare terzi. Il server LDAP è gestito tramite OpenLDAP (struttura di base: cn=Manager,dc=big,dc=com) usando come base di dati file .ldif; l’installazione del server OpenLDAP è fatta a mano, così come la configurazione iniziale della sua struttura.

La configurazione iniziale per BIG viene fatta installando OpenLDAP e indicando i percorsi come nello screen sottostante (si veda nella documentazione LDAP di BIG la configurazione ldiff di default).

L’abilitazione della sincronizzazione con LDAP è fatta da settaggi di BIGStudio, dove vengono anche indicati i dati di connessione al server.

Figura 144

La base DN in cui vengono creati gli utenti è indicata nei settings; la password di default è secret.

La struttura delle entry è la seguente:

• ObjectClass: inetOrgPerson

• Uid: mail del cliente/staff

• Sn: cognome del cliente/staff

• Cn: nome del cliente/staff

• Mail: mail del cliente

• RegisteredAddress: UID della card

La rimozione degli utenti dalla rubrica è fatta al momento della cancellazione della card o alla sua scadenza nel caso in cui sia attiva la funzione di eliminazione automatica delle card.

Integrazione Xerox (non più supportata)

L’integrazione con le stampanti Xerox permette di sincronizzare i clienti di BIGStudio con la rubrica di Xerox, attraverso la mail e l’identificativo univoco (UID) delle tessere Mifare.

La sincronizzazione dei dati fra Xerox e BIG avviene in un server LDAP: ad ogni modifica significativa sulle tessere Mifare BIGStudio (il suo componente BIGDatabase) inserisce automaticamente i dati della card sul server LDAP (si veda la configurazione LDAP).

Xerox una volta all’ora sincronizza la sua rubrica con quella LDAP; se un utente appena attivato su BIGStudio tenta una stampa/scansione ma la rubrica locale di Xerox (che legge da quella LDAP) non contiene ancora il nominativo, Xerox forza una risincronizzazione da LDAP, aggiungendo di fatto il nuovo nominativo.

Stampa

Per effettuare la stampa l’utente dovrà installare la stampante sul suo pc puntando al server indicato dalla struttura.

Dopo aver lanciato la stampa dal suo pc l’utente si presenta alla stampante e passa il badge: la stampante verifica l’UID della card appena passata e la sua presenza nella rubrica di Xerox (con l’eventuale sincronizzazione forzata); se l’utente è presente nella rubrica la sua stampa è abilitata e viene effettuata.

Se l’utente non è riconosciuto la stampa non viene effettuata.

Scansione

L’utente si presenta dalla stampante ed effettua scansione solo su chiavetta presentando il proprio badge alla stampante; il passaggio del badge verifica la presenza dell’UID della tessera nella rubrica di Xerox e abilita la scansione.

Report attività fatte per utente

Attraverso il software di Xerox è possibile configurare l’invio periodico con file .csv del riepilogo delle stampe: da configurazione Xerox è possibile inviare questi dati solo per mail (ad una mail creata ad hoc per BIG) con cadenza settimanale o mensile.

Nel caso in cui sia necessaria una cadenza più stretta (giornaliera/oraria) l’esportazione del dato (inviando la mail a BIG e innescando il processo di reportistica) può essere fatta in ogni instante in modo manuale dal software di Xerox.

Il servizio PMStoISO di BIG scarica le nuove mail ricevute da Xerox sulla casella di posta ad hoc, salva nel database di BIG il numero di stampe (colori e bianco/nero), copie e scansioni ricevute da Xerox per ogni utente e tessera. Le mail scaricate vengono eliminate dal server di posta per evitarne il sovraccarico; i file, una volta valutati, vengono spostati in una cartella ad hoc.

Figura 145

Impostazioni da configurare:

• Percorso ricezione report di Xerox: cartella in cui vengono salvati i file csv inviati via mail da Xerox

• Percorso salvataggio report di Xerox: cartella in cui vengono spostati i file csv inviati via mail da Xerox al termine della valutazione

• Server: server pop3 da cui scaricare la posta

• Porta: porta del server pop3

• Username/mail: utente mail a cui vengono inviati i report di Xerox

• Password: password dell’utente di cui sopra

• Indirizzo mail Xerox: indirizzo mail del mittente di Xerox, in modo da considerare solo le mail ricevute da Xerox.

I dati ricevuti (stampe a colori e in bianco/nero, copie e scansioni) vengono memorizzati in BIGStudio nello storico delle comunicazioni.

Lutron

Il gateway Lutron permette di gestire I dispositivi connessi ad un processore Lutron HomeWorks tramite connessione TCP con protocollo TLS 1.2.

Prima connessione al processore tramite certificati Per effettuare la prima connessione con un dispositivo Lutron è necessario eseguire la seguente procedura.

1. Accedere al sito https://developer.iot.lutron.io/login nella sezione MYLUTRON LOGIN con le proprie credenziali (o registrarsi se necessario)

2. Nella sezione ‘Certificates’ scaricare ‘Integrator Intermediate Certificate’

3. Nella sezione ‘Certificate requests’ scaricare Il file visualizzato con estensione .pem; questo certificato è il ‘Global certificate’ e il file CERTIFICATE_SIGNING_REQUEST.csr

N.B. Nel caso in cui il ‘Global Integrator Certificate’ non sia disponibile bisogna eseguire una serie di passaggi utilizzando openssl da terminal Linux o da console Git Bash.

1. Eseguire: openssl req -new -newkey rsa:4096 -nodes -keyout CHIAVE_PRIVATA.key -out CERTIFICATE_SIGNING_REQUEST.csr compilando i parametri quando richiesto come segue:

   1. Common Name (CN): Nome del richiedente

   2. Organization (O): Azienda del richiedente

   3. Organizational Unit (OU): Engineering

   4. Locality (L): Città del richiedente

   5. State (ST): Regione del richiedente

   6. Country (C): IT

2. Eseguire: openssl rsa -in CHIAVE_PRIVATA.key -pubout -out CHIAVE_PUBBLICA.key’

   1. Accedere nuovamente al sito https://developer.iot.lutron.io/login/ per avanzare la richiesta del Global certificate: Accedere alla sezione ‘Certificate request’

   2. Cliccare su Add

   3. Compilare i campi necessari come segue:

      1. Purpose: Development

      2. Csr: Selezionare il file CERTIFICATE_SIGNING_REQUEST.csr precedentemente creato

      3. Selezionare HomeWorks QSX

3. Attendere che il certificate venga rilasciato.

Configurazione di un dispositivo Lutron

Per connettersi al processore compilare le seguenti impostazioni e premere il tasto Conferma / Aggiorna

Figura 146

• IP Processore: ip del processore a cui ci si vuole connettere

• Porta di comunicazione processore: porta su cui stabilire la connessione (di default la 8081)

• Tipo di autenticazione:

  • Se username e password è necessario inserire le credenziali che sono state configurate sul processore Lutron

  • Se Certificato è necessario fare l’upload di

    • global certificate: fornito da Lutron (generato come spiegato al punto precedente)

    • intermediate certificate: fornito da Lutron (generato come spiegato al punto precedente)

    • private key: chiave privata dei certificati (generata come spiegato al punto precedente).

  • In caso di utilizzo dei certificati, dopo aver premuto il pulsante Conferma/Aggiorna è necessario:

    • Accedere alla cartella di installazione di BIGStudio, nella sottocartella Temp/Lutron e installare in Windows i certificati integrator-intermediate-certificate.cer e ChainCertificateToInstallInWindows.pfx. Per l’installazione la procedura è di:

      • Aprire il certificato

      • Selezionare il percorso di archivio Computer locale

      • Inserire la password (se richiesta) BIGLutr0n!

      • Nelle opzioni di importazione abilitare ‘Contrassegna la chiave come esportabile’

      • Usare l’opzione ‘Seleziona automaticamente l’archivio certificati’

    • Premere il bottone giallo presente nella parte alta del processore Lutron, per far sì che la procedura iniziale di connessione termini correttamente.

  • In caso di connessione ai certificati andata a buon fine potete trovare tutti i certificati Lutron e le chiavi utilizzate per la loro generazione nella cartella di installazione di BIGStudio, nella sottocartella TempFiles/Lutron; questi certificati e le relative chiavi sono generate da BIGStudio e dal processore Lutron in fase di prima connessione.

Importazione dei dispositivi

Permette di scansionare i dispositivi attualmente connessi al processore e li aggiunge alla lista dei dispositivi.

Figura 147

Dispositivi supportati

Il gateway al momento supporta I dispositivi con i seguenti tipi di controllo:

• Switched: Dispositivi che possono essere accesi o spenti.

• Dimmed: Dispositivi dimmerabili.

• Shade: Tapparelle con veneziane non regolabili.

• ShadeWithTilt: Tapparelle con veneziane regolabili.

• ShadeWithTiltWhenClosed: Tapparelle con veneziane regolabili solo quando totalmente chiuse.

• CCO: Contact Closure Output.

• OpenCloseStop: Dispositivi dotati di motore che possono ricevere comandi di aperture e chiusura.

• Button: Pulsanti.

Per ogni dispositivo viene generata una cartella [handle = customID] contenente gli indirizzi compatibili con esso.

Indirizzi

Di seguito sono elencati gli indirizzi relativi a questo gateway e i dispositivi ad essi associati:

• Lutron/CUSTOM_ID/1: ON – OFF (Booleano)
  ON (1) = Acceso, OFF (0) = Spento
  Compatibile con dispositivi : Switched, Dimmed, CCO
• Lutron/CUSTOM_ID/2: Fade Time (Intero tra 0 e 144000
  In quanto tempo viene modificato completamente il Dimming Value espresso in decimi di secondo.
  Compatibile con dispositivi: Dimmed
• Lutron/CUSTOM_ID/3: Dimming Value (Intero tra 0 e 100)
  Regolazione del livello del dispositivo
  Compatibile con dispositivi: Dimmed
• Lutron/CUSTOM_ID/4: Raise/Lower (Booleano)
  Raise (1)= Alza, Lower (0)= Abbassa
  Dopo aver ricevuto questo segnale il livello del dispositivo continua ad alzarsi o abbassarsi fino a quando non raggiunge il valore massimo o minimo o non viene fermato dal segnale di Stop.
  Compatibile con dispositivi: Dimmed, Shade, ShadeWithTilt, ShadeWithTiltWhenClosed, OpenCloseStop
• Lutron/CUSTOM_ID/5: Stop (Booleano)
  Stop (2): Ferma il Raise/Lower
  Compatibile con dispositivi: Dimmed, Shade, ShadeWithTilt, ShadeWithTiltWhenClosed
• Lutron/CUSTOM_ID/6: Lift Level (Float da 0 a 100) 0= Aperta, 100= Chiusa Determina lo stato di apertura della tapparella con precisione fino alla seconda cifra decimale. Compatibile con dispositivi: Shade, ShadeWithTilt, ShadeWithTiltWhenClosed, OpenCloseStop
• Lutron/CUSTOM_ID/7: Tilt Level (Float da 0 a 100) 0= Aperte, 100= Chiuse Determina l’inclinazione delle veneziane con precisione fino alla seconda cifra decimale. Compatibile con dispositivi: ShadeWithTilt, ShadeWithTiltWhenClosed
• Lutron/CUSTOM_ID/8: Raise/Lower Tilt (Booleano) Raise Tilt (1)= Aumenta inclinazione, Lower Tilt (0)= Diminuisce inclinazione Dopo aver ricevuto questo segnale il livello di inclinazione delle veneziane continua ad alzarsi o abbassarsi fino a quando non raggiunge il valore massimo o minimo o non viene fermato dal segnale di Stop Tilt. Compatibile con dispositivi: ShadeWithTilt, ShadeWithTiltWhenClosed
• Lutron/CUSTOM_ID/9: Stop Tilt (Booleano) Stop Tilt (1): Ferma il Raise/Lower Tilt Compatibile con dispositivi: ShadeWithTilt, ShadeWithTiltWhenClosed
• Lutron/CUSTOM_ID/10: Press and hold (Booleano) Press and hold (1): Attiva la funzione associata a Press and hold del pulsante Compatibile con dispositivi: Button
• Lutron/CUSTOM_ID/11: Press and release (Booleano) Press and release (1): Attiva la funzione associata a Press and release del pulsante Compatibile con dispositivi: Button
• Lutron/CUSTOM_ID/12: Release (Booleano) Release (1): Attiva la funzione associata a Release del pulsante Compatibile con dispositivi: Button
• Lutron/CUSTOM_ID/13: Multitap (Booleano) Multitap (1): Attiva la funzione associata a Multitap del pulsante Compatibile con dispositivi: Button

bTicino

Il gateway bTicino permette di gestire dispositivi e ambienti presenti in un progetto “MyHotelSuite” tramite connessione MQTT con protocollo TLS 1.2.

Configurazione progetto

Tramite il programma MyHotelSuite aprire un progetto esistente o un nuovo progetto.

Figura 148

Dalla tab ‘Edit’ si possono aggiungere o rimuovere edifici, piani e camere.

Figura 149

Una volta finito di creare il progetto dalla tab ‘File’ si può salvare il progetto come ‘.plant’ per modificarlo in seguito e salvarlo come ‘.hsproj’ tramite il tasto ‘Create hotel file’.

Figura 150

Il file ‘.hsproj’ va poi caricato nel “Supervision server”, nella tab ‘Project selection’. Se non attivi assicurarsi di attivare ‘Enable PMS Integration’ e ‘Enable badge programming’.

Figura 151

Tenere sempre aperto il “Supervision server” e “HotelSupervision MQTT connector”.

Indirizzi di camera

Ogni camera ha i seguenti indirizzi associati:

• BTICINO_ENV/CUSTOM_ID/1: Available (Booleano [Yes – No]) READ ONLY: Camera disponibile.

• BTICINO_ENV/CUSTOM_ID/2: Presence (Booleano [Yes – No]) READ ONLY: Ospite in camera.

• BTICINO_ENV/CUSTOM_ID/3: Maintenance (Booleano [Yes – No]) READ ONLY: Camera in manutenzione.

• BTICINO_ENV/CUSTOM_ID/4: DoNotDisturb (Booleano [On – Off]): Non disturbare.

• BTICINO_ENV/CUSTOM_ID/5: MakeUpRoom (Booleano [On – Off]): Pulizia camera.

• BTICINO_ENV/CUSTOM_ID/6: SOS (Booleano [Yes – No]) READ ONLY

• BTICINO_ENV/CUSTOM_ID/7: RequestRoomService (Booleano [On – Off]): Servizio in camera

• BTICINO_ENV/CUSTOM_ID/8: RefreshRoomData (Intero) WRITE ONLY: Aggiorna lo stato della camera.

Indirizzi termostato

Ogni termostato ha i seguenti indirizzi associati:

• BTICINO_DEV/CUSTOM_ID/1: Unit (Booleano [C – F]): Unità di misura dei gradi (Celsius o Fahrenheit)

• BTICINO_DEV/CUSTOM_ID/2: SummerWinter (Intero [Estate=0|Inverno=1|Auto=2]): Stagione del termostato.

• BTICINO_DEV/CUSTOM_ID/3: Mode (Intero [Eco=0|Comfort=1|Manual=2|Production=3|Off=4]: Modalità operativa termostato.

• BTICINO_DEV/CUSTOM_ID/4: ActualTemperature (Float) READ ONLY: Temperatura corrente.

• BTICINO_DEV/CUSTOM_ID/5: ActualSetPoint (Float): Set point corrente in base alla Stagione e alla Modalità operativa.

• BTICINO_DEV/CUSTOM_ID/6: FanSpeed (Intero [Low=0|Mid=1|High=2|Auto=3|N/A=4]): Velocità delle ventole.

Dispositivo virtuale controllo accessi

Per ogni camera viene associato un dispositivo virtuale di controllo accessi con un solo indirizzo:

• BTICINO_DEV/(ROOM_ID * 100)/7