Introduzione a OS.node e TWIDUNODE2 lo smart PoE injector
Le possibilità offerte dalla twidunode in fatto di gestione sono infinite. Infatti già sappiamo come sia possibile collegare tra loro un cluster di molti smart PoE injector twidunode e farli comunicare attraverso il CANBUS. Abbiamo visto inoltre come sia possibile accedervi alla propria console attraverso al porta USB.
Ora vedremo come sia possibile non solo remotizzare queste funzioni, ma come integrare il controllo delle twidunode PoE in una scheda di controllo attraverso un indirizzo IP ed una interfaccia WEB.
Componenti:
Per abilitare la comunicazione IP delle TWIDUNODE smart PoE, occorre solo una board embedded su cui far girare il sistema operativo Linux Based OS.node.
OS.node, per il momento è compilato per le board Raspberry2 e Raspberry3. La board con OS.node, comunica con il cluster di PoE attraverso la porta USB di una sola TWIDUNODE.
Architettura:
OS.node comprende tutto il software necessario per abilitare il bridge tra il cluster CANBUS delle TWIDUNODE e il sistema di gestione del logging e delle azioni.
Il PoE injector twidunode che ha entrambe collegati sia USB che CANBUS si comporta da bridge tra le porte.
Un demone si occupa di gestire la coda dei messaggi in entrata e uscita. Una volta collegata la porta USB tra twidunode e OS.node, un comando di start abilita lo stream binario di dati sul bus.
Interfaccia monitoraggio:
L’interfaccia di OS.node è divisa in menù. Il menu di gestione dei devices collegati, elenca gli ID dei dispositivi trovati nel BUS, da qui è anche possibile entrare in modalità diretta sull’interfaccia di gestione singola. Qui per esempio è possibile accendere/spegnere il carico, controllare il voltaggio impostato, vedere il grafico delle tensioni e delle correnti, lo stato della batteria ecc ecc.
Qui un estratto della singola interfaccia del singolo dispositivo:
Programmazione visuale degli eventi:
Un altro menù riguarda l’accesso all’interfaccia di gestione node.red.
Si tratta di un potentissimo editor visuale di configurazione eventi. Node-RED è uno tra i più noti tool di flow-based programming per l’Internet of Things. Nasce con l’obiettivo di dare a tutti, anche a chi non è esperto di programmazione, la possibilità di collegare tra loro diversi dispositivi (con eventuali relativi sensori ed attuatori), oltre a API e servizi online per poter realizzare sistemi altamente integrati e complessi in modo del tutto semplice ed intuitivo.
Townet ha definito alcuni nodi proprietari necessari ad integrare il flusso dati delle twidunode sul flow di Node.red. Si tratta di una delle più avanzate piattaforme di editing di eventi che potete trovare. Non ci sono limiti alle possibilità offerte.
Si spazia dal nodo SNMP (proprietario Townet) ai nodi “social” che permettono di gestire allarmi e comandi attraverso i social-network, come Twitter. Esistono nodi di codifica e transcodifica dei messaggi XML, oppure nodi per l gestione degli eventi basati su HTTP.
Insomma, le possibilità sono infinite.
MQTT
Per chi non lo conoscesse, MQTT è uno dei principali protocolli utilizzati attualmente in ambito Internet of Things. Permette di pubblicare messaggi su specifici “topic” ai quali chi vuole può registrarsi per poter ricevere aggiornamenti.
L’interconnessione publisher (chi pubblica) e subscriber (chi riceve/sottoscrive) è gestita attraverso un server centrale (broker) che ha il compito di “smistare” i messaggi applicando appunto il pattern publish/subscribe.
Ebbene l’architettura dei messaggi di red.node è basata su MQTT anche internamente. Quindi, OS.node è già abilitato di default a colloquiare con le più diffuse piattaforme IoT attraverso MQTT.
Per esempio, è possibile incapsulare lo streaming dei messaggi del cluster di twidunode, direttamente su una socket MQTT, semplicemente utilizzando i nodi offerti dall’interfaccia visuale.
Implementazione SNMP flessibile:
Come abbiamo già detto, Townet ha sviluppato il nodo server SNMP per poter gestire anche questo protocollo in maniera condizionale e dinamica.
Una volta abilitato nel flusso, il nodo si occupa di traslare in OID SNMP i messaggi JSON provenienti dai filtri precedentemente impostati.
