iotivity - modrpc/info GitHub Wiki
- OIC: http://openinterconnect.org/
- iotivity website: https://www.iotivity.org/
- iotivity-dev mailing list: http://lists.iotivity.org/pipermail/iotivity-dev/
- Programmer's guide: https://www.iotivity.org/documentation/linux/programmers-guide
- SmartHome demo: https://01.org/smarthome
- Based on REST API (GET/PUT/POST/DELETE)
-
RESOURCE: A resource is a component of a device which supports GET, PUT, POST, DELETE operations (cf. HTTP)
- A device consists of resources.
- e.g. A garage door opener is a resource, which consists of two sub-resources -- light and lock.
- e.g. One get apply GET operation over a resource to obtain its current state.
-
RESOURCE: A resource is a component of a device which supports GET, PUT, POST, DELETE operations (cf. HTTP)
- OPERATIONS: GET, SET, OBSERVE
-
Features: https://www.iotivity.org/documentation/features
- Resource registration: add a resource to IoTivity space
- Resource discovery: search for a resource OR be notified of availability resource
- Device discovery with filtering
- Property attributes (GET/SET/OBSERVE)
- Resource tree
- Presence notification service defined as a virtual resource
- Currently, IoTivity only supports CoAP (Constrained Application Protocol) over UDP/IP
- CoAP is quite similar to HTTP
- They plan to support HTTP over TCP/IP later.
-
CoAP message format:
- address: 192.168.8.102:56383
- type: CON (confirmable), NON (non-confirmable), ACK, RST (reset)
- token: length of token (0 ~ 8)
- code: Request (GET:0.01, SET:002, ...), Success (CREATED:2.01, CHANGED(2.04), CONTENT(2.05), ...), Client Error* (4.xx), Server Error (5.xx)
- message ID: 0xXXXX (16-bit), generated by sender and allows receiver to de-duplicate requests
- token: generated by client to match REQ to RESP
- options: URI-paths + URI-queries (e.g.
/oc/core?rt=core.sensor&if=core.mi.il)
- Registrating a resource
- To register (introduce) a resource, say R, to the IoTivity space, the following are required:
- request handler for R: the code which will be executed on GET/SET/OBSERVER request over **R**
- URI path for R: i.e. the _name_ under which others will refer to this resource
- What happens in device registration
- obtain OCPlatform C++ object (maybe Singleton), `platform`
-
platform.registerResource(&handle, "/light/1", "light", "oc.mi.def", handler, OC_DISCOVERABLE)-
/light/1: URI-path -
light: resource type (predefined set of well-known resource types) -
oc.mi.def: interface -- i.e. which operations are allowed over this resource -
handler: function which implements operations -
OC_DISCOVERABLE: resource should be reported to the client, when a client performs a resource discovery
-
- This call will eventually be changed to C function call:
OCCreateResource(&handle, "light", "oc.mi.def", "/light/1", handler, OC_DISCOVERABLE)
- Finding a resource
- What happens in device registration
- obtain OCPlatform C++ object (maybe Singleton), `platform`
-
platform.findResources("", "coap://224.0.1.187/oc/core?rt=alpha.light", findHandler)-
"": URI authority (target host), when empty, it's for all nodes -
"coap://224.0.1.187/oc/core?rt=alpha.light": URI path and URI query-
"/oc/core": URI path indicates resource -
"rt=alpha.light": URI query is the filter
-
-