0.9 MeetingNotes

Data Model

##SEP:

- Restful + HTTP 
- ad-hoc data model -> functionsets e capabilities legate al dominio energy
	-> non c'è supporto a dispositivi devices HA (DIMMER?)

##OSGi: DAL

- Generico, semplice
- forse troppe cose da implementare (devices status change flow)
- completamente basato su osgi (fa uso del service tracker)
- non dipende da come si espongono le risorse
	- va valutato come si adatta al protocollo scelto per esporre le api

##Xively/EEML

- environment->feed->datastream->datapoint
	- non c'è il concetto di device esplicito, un device corrisponde ad un feed in un environment
	- un feeed contiene uno o più datastream per rappresentare device che contengono più sensori

##SensorML

- modelling of sensors and processes
- campi più espliciti
- Ontology support

##BUTLER:

- un device, espone servizi. Un servizio può richiedere servizi
- un servizio espone una o più risorse
	-una risorsa è
		-proprietà
		-sensorData
		-stateVariable
		-Action (che può modificare la statevariable)
	-ogni risorsa ha uno o più metodi
	-i metodi possono avere parametri in input e possono essere get/set/act/subscribe
- REST

##ETSI:

- tante cose
- complesso
- pagina 16 ETSI pdf

##LightWeightM2M:

- si basa su CoAP come protocollo, gli oggetti vengono scambiati
- Oggetti ID -> istanze ID -> risorse ID. Azioni su risorse (READ/WRITE/EXECUTE)
- device non modellati esplicitamente (non esiste un vero modello dei dati)
- in corso definizione azioni/info esplicite specifiche di dispositivi (temperatura, consumo)

##CoRE LInk format:

- rest, spiega come si espongono le risorse
- non specifica i tipi accettati -> estensibile

API

Requisiti:

1. Deve essere facile usare le API con molteplici linguaggi di programmazione
2. Tramite le API deve essere possibile ricevere eventi asincroni dai dispositivi
3. Il sistema deve supportare device eterogenei nascondendo i dettagli implementativi o le tecnologie che si usano, in maniera omogenea
4. Il sistema deve supportare più di un modo (standard) per esporre le API

3: dipende dal data model 4: dipende dal sistema

OPENHAB:

- REST API + server push https://github.com/openhab/openhab/wiki/REST-API
- xml, json, jsonp
- Data Model ad-hoc, event-oriented


1: V
2: V -> server push
il data model non fornisce particolari vantaggi-> generico

##Butler:

Mapping con il DAL -> 
	servizio -> Funzioni
	risorsa -> o property della funzione o operazione
	
1. V (http-rest/jsonrpc/mqtt/coap/soap)
2. V -> url di callback con publish/subscribe (il client non può essere dietro nat con http+rest)

##Xively:

REST, Sockets, WebSockets, MQTT	
xml, json, cvs	
ha la parte di dati ma non quella di invocazione funzioni
supporta la notifica di eventi con callback HTTP, attraverso Websockets o MQTT
data model mappabile esclusa parte di environment che non è per forza inclusa nelle device api
1. V (rest/socket/mqtt)
2. V -> url di callback, websockets

##XMPP extensions:

i dispositivi client xmpp come client xmpp	

	- http://xmpp.org/extensions/xep-0323.html - lettura dati da dispositivi
	- http://xmpp.org/extensions/xep-0325.html - fa set di parametri e controllo di dispositivi

http://xmpp.org/extensions/xep-0326.html - Come esporre devices da un concentratore
	- mapping dal: 			
		- device-> nodi
		- funzioni -> comandi
			-> si specifica nel 323 come prendere le prpoperty 
- specifiche publish/subscribe previste, ma non ancora rilasciate

1: V
2: (V) previsto dal protocollo, ma non ancora standardizzato

##SEP: - client/server rest http - eventi asincroni modellati con interazioni client/server

1: V
2: X -> implementato client/server con azioni esplicite

##ETSI: - non è definito il protocollo scambio messaggi - definite le capability dei dispositivi - publish/subscribe definito

1: mappabile su protocollo a piacere, molto esteso/complesso V/X
2: c'è publish/subscribe V

mapping con DAL possibile con GRA (Gateway Resource Abstraction) capability (pagina 26)

##LightWeight M2M

Mappato su CoAP
	facile da usare
scope: da gw <-> WSN

1: V ci sono tante librerie che implementano il supporto
2: V in draft (Observer lo stesso usato in CoAP) - Work in progress: https://datatracker.ietf.org/doc/draft-ietf-core-observe/

Wrap-Up

For internal devices APIs the OSGi Device Abstraction Layer will be initially tested. Relevant rfcs:

• rfc0196 - Device Abstraction Layer
• [rfc0210 - Device Abstraction Layer Functions] (https://github.com/osgi/design/blob/master/rfcs/rfc0210/rfc-0210-DeviceAbstractionLayerFunctions.pdf?raw=true)

Device APIs protocols mapping for external services

• XMPP extensions mapping - DAL
• HTTP Rest Mapping