Apricancello da chiamata telefonica con database

Quello che possiamo proporre è una personalizzazione della ns Modem machine, il programma (Realizzato con LogicLab) di cui forniamo i sorgenti, tramite la libreria di gestione modem, gestisce un modem connesso alla porta seriale. Il FB ModemCore controlla continuamente la funzionalità del modem e se è connesso alla rete GSM, provvedendo in caso di problemi a reinizializzarlo.Una pagina web di test permette da un browser di testare il funzionamento eseguendo/ricevendo chiamate telefoniche ed inviando/ricevendo messaggi SMS. Agendo sul programma si può aggiungere la parte di interfaccia con il database.Premesso che il prodotto non può accedere direttamente alle query sul database, si può ipotizzare uno scambio dati TCP/IP o UDP con il server, delegando alla applicazione sul server l’esecuzione delle queries sul database. In pratica il server può interrogare ciclicamente il prodotto e/o attendere che il prodotto invii al server un pacchetto UDP con il numero CLIP ricevuto. Il server fatte le verifiche del caso potrà inviare al prodotto l’ordine di apertura cancello che verrà gestito da una delle uscite logiche presenti.Tra i modi per interfacciarsi posso citare Modbus TCP (Vedi topic, topic), esistono anche librerie in PHP per gestire il modbus TCP la più nota è la PhpModbus. E’ anche possibile sviluppare un proprio protocollo ad hoc in alternativa al modbus (Topic).

Noi progettiamo, costruiamo e supportiamo tecnicamente dei prodotti programmabili, quindi non forniamo un prodotto finito, ma prodotti che tramite un tool di sviluppo e con un linguaggio (non sconosciuto) ma molto ben conosciuto, e standardizzato dalla norma IEC-61131, permette di realizzare l’automazione richiesta. Come descritto precedentemente appositi FB gestiscono le operazioni complesse permettendo di ottenere velocemente il risultato.

Il protocollo Modbus è uno standard de-facto di comunicazione ed esiste una valanga di letteratura al riguardo, la specifica è scaricabile anche dal ns sito (Reference Guide). Comunque il programmatore può sviluppare anche un’altro tipo di protocollo di comunicazione (Il forum ha esempi in merito da cui partire).

Noi non realizziamo programmi completi, ci limitiamo al supporto del cliente nella programmazione (Anche tramite supporto remoto), desideriamo che sia il cliente “padrone” del programma e non debba dipendere da noi per le modifiche. In questo caso la soluzione che ho prospettato è quella di modificare un prodotto già esistente nel modo più generico possibile. Gestire le queries SQL vorrebbe dire stravolgere il prodotto e realizzare una applicazione “sartoriale” sulle Vs necessità.

Visto che c’è un server dove risiede l’interfaccia di gestione delle tabelle database mi sembra naturale gestire tutto da questo server. Così sarà solo il programma del server che “conosce” l’organizzazione del database facilitando l’eventuale riorganizzazione dello stesso.

Utilizzando Toolly possiamo testare il funzionamento del protocollo di comunicazione sia Voi lato server (Nel proseguo Sv) che io lato Modem Machine (Nel proseguo Mm), questo è molto comodo per sviluppare l’applicazione.

Considerando che i pacchetti UDP sono intrinsecamente sicuri grazie al controllo di checksum del datagramma (Come indicato dalla RFC 768), possiamo ipotizzare uno scambio di informazioni in ASCII. Questo facilita anche il debug via Toolly trattandosi di pure stringhe di testo.

a) Condivido la scelta di uno scambio dati ciclico (Heartbeat) tra Mm e Sv nell’ottica di garantire il controllo della funzionalità. Mm invia ogni 10 Sec Ready se tutto ok oppure Error:xx in caso di anomalia. Attende la risposta Ok da Sv.

b) Fissato il numero di telefono su 12 cifre massimo, su ricezione chiamata telefonica, Mm acquisisce il numero ed invia Call:xxxxxx, se numero nascosto invia Call:0000000.

c) Mm attende la risposta Allowed se accesso consentito, o Denied se non consentito, da Sv. se non riceve risposta dopo un tempo reinvia il numero.

Su ricezione Allowed viene gestita l’apertura della porta attivando una uscita logica per qualche secondo.

Se si vuole mantenere esattamente uguale la gestione l’unico modo è di creare una VPN tra la Modem Machine ed il tuo server, per fare questo puoi utilizzare un router Conel (Topic). In questo modo la VPN si comporta come un cavo di rete tra i due punti e puoi utilizzare la tecnica dello scambio di messaggi UDP.

Il router Conel alla accensione crea la VPN, naturalmente devi disporre sul tuo sito server di un indirizzo IP pubblico, la VPN può essere creata tra il router Conel ed il tuo router ADSL di acceso Internet, oppure puoi utilizzare un client VPN su PC (Esistono client gratuiti sia OpenVPN che IPSec).

Questa soluzione però prevede come ovvio l’aggiunta di un router oltre al modem, e devi utilizzare due SIM, una sul modem per la gestione delle chiamate ed una sul router per la VPN.

In alternativa è possibile modificare la gestione utilizzando il solo modem, in questo caso avresti anche una sola SIM, ma occorre fare modifiche sia lato Modem Machine che lato server. Il modem effetua una connessione HTTP verso il server chiedendo la pagina e passando in GET il comando (Heartbeat o numero telefono). Il server deve agire come server web ritornando una pagina web con con il comando verso il modem (Heartbeat , Denied o Allowed). In questo topic trattiamo una soluzione simile.

Occorre tenere presente che la connessione HTTP via modem richiede un certo tempo (da 20 a 60 Sec) ed in questo tempo il modem risulta cieco alle chiamate telefoniche. Questo non sarebbe un problema sulla attivazione dell’apertura perchè la chiamata sarebbe già ricevuta, ma potrebbe fare perdere chiamate sulla gestione dell’Heartbeat.