Il concetto di Channel

Il concetto di channel (canale) é alla base di tutte le operazioni del sistema di messaggistica in quanto é su ciascuno di essi che vengono pubblicati eventi e comandi. Gli eventi sono notificati da un plugin sensore. Dal punto di vista di Freedomotic un sensore é costituito da un dispositivo fisico dotato di una componente software in grado di interagire con il middleware (framework).

Gli eventi possono essere scambiati utilizzando i formati più comuni (es. POJO, JSON, XML) e sono distribuiti ai trigger utilizzando una modalità di tipo publish-subscribe, ovvero ciascun trigger deve sottoscrivere uno specifico canale per ricevere tutti gli eventi che transitano attraverso di esso.

Sottoscrizione con wildcard

E’ possibile utilizzare nella sottoscrizione delle wildcards in modo da includere automaticamente un ampio insieme di eventi. Per esempio se un sensore genera eventi sul canale

app.events.sensors.moving.person.P003

un trigger può “ascoltare” questo specifico evento in modo da ricevere ulteriori dettagli sui movimenti della persona P003. Tuttavia se il trigger si pone in ascolto degli eventi

app.events.sensors.moving.person.∗

riceverà le informazioni relative a tutti i movimenti delle persone individuate nell’ambiente.

La semantica delle wildcard é la seguente:

  • punto (.) per separare i nomi in un percorso (path)
  • asterisco (*) per confrontare qualsiasi nome in un percorso (path)
  • simbolo maggiore di (>) per confrontare ricorsivamente ogni destinazione a partire dal nome corrente

Un trigger é un filtro utilizzato per decidere se un evento notificato deve essere processato o meno. Nel primo caso la reaction (automazione) ad esso associata é eseguita. Quest’ultima rappresenta un collegamento tra un trigger ed uno o più comandi eseguiti da un attuatore.

Una reaction consente un controllo del flusso di elaborazione dei comandi, acquisendo i valori di ritorno della loro esecuzione. Ciascuna lista di comandi é eseguita in parallelo all’interno di uno specifico thread, utilizzando un pattern request/reply. Si osservi che trigger e comandi sono componenti riusabili in quanto non definiti all’interno di una reaction (che si limita a specificare il flusso di esecuzione).

Un comando rappresenta un messaggio in uscita dal middleware e contente l’indicazione di un destinatario, un canale per l’appunto (es. app.plugins.protocols.modbus.in). Inoltre sono presenti tutti i parametri eventualmente necessari per la sua esecuzione. I comandi sono inoltrati utilizzando il pattern request/reply mentre gli eventi adottano il cosiddetto send-and-forget. L’attuatore é il terminale di tutto il processo di comunicazione e può eseguire fisicamente il comando nell’ambiente (es. accendere la luce o aprire una finestra). Inoltre può essere interrogato alla stregua di un sensore per conoscere il suo stato.

Trigger, reaction e comandi sono definiti all’interno di file XML automaticamente caricati e salvati dal middleware in modo da garantire la consistenza dei dati.

Esempi di Canali

Canale da sottoscrivere (riservato al trigger) Descrizione
app.events.sensors.moving.person.3 il trigger può “ascoltare” tutti gli eventi relativi ai movimenti della persona con ID=3
app.events.sensors.moving.person.* il trigger può “ascoltare” tutti gli eventi relativi ai movimenti di ciascuna persona nell’ambiente
app.events.sensors.*.person.3 il trigger può “ascoltare” qualsiasi evento relativo alla persona con ID=3
app.events.sensors.> un trigger può “ascoltare” tutti gli eventi notificati dai sensori

Utilizzando il sito, accetti l'utilizzo dei cookie da parte nostra. maggiori informazioni

Questo sito utilizza i cookie per fonire la migliore esperienza di navigazione possibile. Continuando a utilizzare questo sito senza modificare le impostazioni dei cookie o clicchi su "Accetta" permetti al loro utilizzo.

Chiudi