Home » Eclipse Projects » OM2M » Device to GSCL (dIa)(Info on dIa reference point.)
| | | |
| Re: Device to GSCL (dIa) [message #1431991 is a reply to message #1431436] |
Fri, 26 September 2014 12:51   |
 Mahdi Ben Alaya
Messages: 229
Registered: November 2013 |
Senior Member |
|
|
Here, we are speaking of the communication between small sensors/actuators and the gateway. So, Let me explain a little bit the possible scenarios:
You can have:
1) A sensor/actuator speaking zigbee (Leagcy device, and non IP-enabled) -> a specific interworking proxy plugin should deployed on the gateway to make the mapping and so create required resources on the GSCL resource tree (applications, containers, and contentInstances, groups, subscriptions, access roghts, etc.).
2) A sensor/actuator speaking http or coap (Legacy device, IP-enabled) -> the gateway can convert received ETSI HTTP/CoAP request to HTTP/CoAP specific requests (Using a simple URL translation) and retarget it to the HTTP/CoAP sensor/actuator. Here because the sensor/actuator is a legacy device (preconfigured so we don't have access to the code), then someone should create required resources for him on the gateways (applications, containers, and contentInstances), it can be created simply by any REST client.
3) A sensor/actuator (ETSI-compliant, IP-enabled) -> this is similar to the example (2), but in this case the sensor/actuator can create by himself required resources on the GSCL when started directly using HTTP/CoAP requests.
Once one of these scenario is performed, a simple REST client can send a simple HTTP or CoAP request to the NSCL, then the NSCL will retarget it corresponding GSCL. The GSCL will update the URL of the request and send it to the specific sensor/actuator device. The response will be returned back from the sensor/actuator to the GSCL to the NSCL to the REST client. Every will be done in a seamless way. In the point of view of the REST client, it is like browsing a simple website, he will not event know that his request traversed several machines.
GET nscl-ip:port/om2m/nscl -> the NSCL is answering.
GET nscl-ip:port/om2m/gscl -> the GSCL is answering (even that we are still using the NSCL IP address)
If this is enough clear for you, then we can move to help you handling in more details your specific scenario.
Hope this help,
Mahdi
[Updated on: Fri, 26 September 2014 12:52] Report message to a moderator |
|
| |
| Re: Device to GSCL (dIa) [message #1432915 is a reply to message #1432492] |
Sat, 27 September 2014 23:36 |
Mahdi Ben Alaya
Messages: 229
Registered: November 2013 |
Senior Member |
|
|
Let's consider the following example:
Imagine we have a specific lamp speaking HTTP and listening locally on the port 1400.
Let's suppose that it works like this:
- GET to http://127.0.0.1:1400/state to retrieve the lamp state
- POST (with empty body) to http://127.0.0.1:1400/state/true to switch on the lamp.
- POST (with empty body) to http://127.0.0.1:1400/state/false to switch off the lamp.
Let's suppose also that we have the possibility to add some code to the lamp device. In this case, we can update the lamp logic to make it create a LAMP application on the GSCL. (If not possible, no problem a REST client, another application, or even the gateway can create it).
The only thing that you have to do is to precise the Appliaction Point of Contact Path (aPoCPath) tag in the LAMP application resource. In fact, the aPoCPath enables to the gateway to send specific requests to outside (e.g. re-targeting to the lamp) so, in our example, it should contain the address of the lamp (http://127.0.0.1:1400) . Here is an example:
POST 127.0.0.1:8181/om2m/gscl/applications
<om2m:application appId="LAMP" xmlns:om2m="http://uri.etsi.org/m2m">
<om2m:aPoCPaths>
<om2m:aPoCPath>
<om2m:path>http://127.0.0.1:1400</om2m:path>
</om2m:aPoCPath>
</om2m:aPoCPaths>
</om2m:application>
That's all. Now you can send request to the NSCL to reach your specific lamp device. Examples:
GET http://127.0.0.1:8080/om2m/gscl/LAMP/state (Get the lamp state using ETSI request)
POST http://127.0.0.1:8080/om2m/gscl/LAMP/state/true (Switch on the lamp using ETSI request)
POST http://127.0.0.1:8080/om2m/gscl/LAMP/state/false (Switch off the lamp using ETSI request)
Here the NSCL will retarget the request to the GSCL, then the GSCL will replace the first part of the URI with the one provided in the LAMP application aPoCPath, and finally will send it to the lamp device. The response is returned back from the lamp device to the GSCL to the NSCL, till your client.
Remarque: The same mechanism works for CoAP devices. The GSCL is able to select the appropriate client (http or coap) based on the APoCPath.
Some improvements:
1) Discovery: It is important to store metadata somewhere about your devices (attributes, possible operations, etc.) to simplify discovery. E.g. a container DESCRIPTOR can be created for the LAMP application to include a machine-readable description of the lamp features (oBIX format can be used). Example:
POST 127.0.0.1:8181/om2m/gscl/applications/LAMP/containers
<om2m:container xmlns:om2m="http://uri.etsi.org/m2m" om2m:id="DESCRIPTOR"/>
POST 127.0.0.1:8181/om2m/gscl/applications/LAMP/containers/DESCRIPTOR/contentInstances
<obj>
<str name="type" val="Lamp"/>
<str name="location" val="Home"/>
<op name="getStatus" href="gscl/applications/LAMP/status" is="retrieve"/>
<op name="switchOn" href="gscl/applications/LAMP/status/true" is="execute"/>
<op name="switchOff" href="gscl/applications/LAMP/status/false" is="execute"/>
</obj>
The current OM2M web interface is able to understand this oBIX format and create automatically buttons to trigger your device.
2) Persistence: It is possible to persist the generated data on the gateway data base to get the history, avoid triggering the device for each requests, etc. E.g. a container DATA can be created for the LAMP applications, then the lamp state can be pushed in the gateway as contentInstance resource each time the lamp state is updated. Example:
POST 127.0.0.1:8181/om2m/gscl/applications/LAMP/containers
<om2m:container xmlns:om2m="http://uri.etsi.org/m2m" om2m:id="DATA"/>
POST 127.0.0.1:8181/om2m/gscl/applications/LAMP/containers/DATA/contentInstances
<obj>
<str name="state" val="true"/>
</obj>
You can find more details on this tutorial: http://wiki.eclipse.org/OM2M/REST_API
Hope this help,
Mahdi
[Updated on: Sun, 28 September 2014 01:14] Report message to a moderator |
|
| | |
| Re: Device to GSCL (dIa) [message #1434762 is a reply to message #1434012] |
Tue, 30 September 2014 14:58 |
Mahdi Ben Alaya
Messages: 229
Registered: November 2013 |
Senior Member |
|
|
Hello Ramakrishna,
If you are looking for a http interaction with the gateway, then I think it is better to run your http client in a separate device. You will be free to code your client in a basic program using e.g. java, python, c++,or even curl commands, independently of the OM2M gateway. You can use the Apache http client, or copy some code from the http rest client code available on the "org.eclipse.om2m.comm.http" plugin.
Theoretically, we develop a new OM2M plugin only if we want to interact locally with the gateway interface using direct library call, or to initializes some resources that may be used after by remote clients.
Can you give me more details about your scenario: domain, use case, devices (sensors/actuators types), protocols, context, etc. This will help me to better understand your need.
Thanks
[Updated on: Tue, 30 September 2014 15:01] Report message to a moderator |
|
|
Goto Forum:
Current Time: Wed Apr 24 19:40:10 GMT 2024
Powered by FUDForum. Page generated in 0.04096 seconds |
] 
Search
Help
Register
Login
Home
