grand Mahdi,
you are so kind answering such questions that maybe for you are
obvious, but not for me!
Thank you again and keep in touch!
M
On 17/02/2015 18:10, Mahdi Ben Alaya
wrote:
The MQTT protocol was not defined in the SmartM2M standard, that's
why we did not integrated it officially in OM2M.
However the OneM2M standard (published recently in 31 January
2015) defined a specific binding to MQTT, so we will try to
integrate MQTT natively in our next OneM2M compliant release
planned in September 2015.
Actually, we worked more with "mosquito" as an external broker and
"paho" to interwork with MQTT-enabled devices.
But, we will look closely to "moquette" since it is written in
java and compliant with OSGi.
Meanwhile, you can try to build the "moquette" OSGi bundle
separately.
Then you can add it to OM2M OSGi container like this:
Start OM2M OSGi console then enter:
> install file:{path-to-bundle}/moquette-bundle-0.5.jar
After installation enter:
> start {moquette-bundle-id}
Mahdi
Le 17/02/2015 17:15, Massimo Vecchio
a écrit :
thanks again,
You can check the step 1.5.2 of the
following tutorial to learn how to add simple jar dependencies
to OM2M: https://wiki.eclipse.org/OM2M/Developer
actually I'm on it, trying to add the sample.ipu plugin, and
sadly touching with my hands all my limits in advanced java
development...:(
Anyway, I will give it a try.
Just another question (ooops I told the last one was the last!):
why didn't you release a (even untested) branch with the
moquette bundle already integrated? In the end, it would be nice
to have a mqtt protocol available off-the-shelf...it is mere
curiosity...
Best,
M
On 17/02/2015 16:59, Mahdi Ben
Alaya wrote:
No it is pretty easy since moquette is already OSGi compliant.
I want to point out that you can even add plain java library
to an OSGi based project.
You can check the step 1.5.2 of the following tutorial to
learn how to add simple jar dependencies to OM2M: https://wiki.eclipse.org/OM2M/Developer
You are welcome,
Mahdi
Le 17/02/2015 16:50, Massimo
Vecchio a écrit :
Thank you Mahdi for the support.
last question (I hope): how about MQTT? Do you think it is
too hard to integrate moquette in om2m, for example? I read
that it should be compatible with the osgi framework, but
cannot evaluate how difficult the integration could be
(sorry, but I'm not a software expert and heard about osgi
only last week....).
Thanks again,
M
On 17/02/2015 12:51, Mahdi Ben
Alaya wrote:
Hello Massimo,
Thank you for your comment. I really appreciate the things
that your are trying to do and put together in your
project.
There are two mechanisms to integrate legacy devices into
OM2M.
Case 1) HTTP or CoAP enabled devices.
Let's suppose that you have a HTTP-enabled plug device
with IP address 192.168.0.4 and listening port 9090.
You can monitor and control this plug using this two
specific HTTP requests:
Since, by default OM2M offers the HTTP binding, then you
can create an application resource called MY_DEVICE
containing "http://192.168.0.4:9090"
as specific Application Point of Contact (APoC).
HTTP request example:
POST 127.0.0.1:8080/om2m/gscl/applications
<om2m:application xmlns:om2m="http://uri.etsi.org/m2m"
appId="MY_DEVICE">
<om2m:aPoCPaths>
<om2m:aPoCPath>
<om2m:path>http://192.168.0.4:9090</om2m:path>
</om2m:aPoCPath>
</om2m:aPoCPaths>
</om2m:application>
That's all. Now when you send a HTTP GET request to the
GSCL with this URI
"127.0.0.1:8080/om2m/gscl/applications/MY_DEVICE/state",
the GSCL will automatically translate it to http://192.168.0.4:9090/state
based on the information stored on the APoC.
Then, the HTTP request is re-targeted to your plug
device, and the HTTP response is returned to you.
If you send a HTTP POST request with empty body to the
GSCL with this URI
"127.0.0.1:8080/om2m/gscl/applications/MY_DEVICE/toggle",
it will be automatically translated to http://192.168.0.4:9090/toggle
and re-targeted to your device to toggle it.
In addition, you can create an oBIX XML description for
the MY_DEVICE application within a specific container to
advertise your device operations and simplify their
discovery.
Let's suppose that the "DESCRIPTOR" container is already
created in this URL:
/gscl/applications/MY_DEVICE/containers/DESCRIPTIOR
HTTP request example:
POST
127.0.0.1:8080/om2m/gscl/applications/MY_DEVICE/containers/DESCRIPTOR/contentInstances
<obj>
<str name="type" val="xxxx"/>
<str name="location" val="yyyy"/>
<op name="get"
href=""
is="retrieve"/>
<op name="toggle"
href=""
is="execute"/>
</obj>
If you check the created contentInstance on the OM2M web
interface, you will find the device attributes and nice
buttons that you can use to monitor and control your
device.
You can use also use "create" (is="create") and delete
(is="delete") operations if needed.
Since OM2M implements the CoAP communication binding,
CoAP-enabled devices can be integrated using the same
approach explained for HTTP.
Case 2) Other legacy devices
To integrate IP-enabled devices speaking other protocols
like MQTT or non IP-enabled devices like Zigbee, you need
to create a specific Interworking Proxy Unit (IPU) plugin
to make the required mapping.
You can check the following developer guide https://wiki.eclipse.org/OM2M/Developer
to learn how to add a new plugin to OM2M and implement you
own IPU.
Hope this can help,
Mahdi
Le 09/02/2015 22:41, Massimo
Vecchio a écrit :
Hi all,
first let me take this opportunity to thank the
developers team for this really amazing project!!!
I could build the project from maven flawlessly (and
this is already a personal success for me, not being so
smart at pure s/w side). The merit goes to the crystal
clear wiki documentation! congrats again.
Then the big question mark that is floating in my
head...
Imagine that I decide to migrate all my little vertical
apps developed in the last couple of years. Such apps
involve sensors and microcontrollers (mostly
arduino-like): in the end little bits and things which
normally are not IP-based but can communicate via short
range communication techs (like bluetooth, nrf, xrf,
srf, etc etc). Normally data reach my gateway (let's be
short...a raspberry pi) which through a dev. framework
like node-red can end up on the internet...
Now, my question is: how can I "port" my current
h/w&s/w mix into om2m? what are the (ideal)
sequential steps to follow? is it worth (apparently yes
to me....that's why I started getting involved in this
challenge...)? any advice from anyone that already tried
this out?
Thanks!
M
_______________________________________________
om2m-dev mailing list
om2m-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password,
or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/om2m-dev
_______________________________________________
om2m-dev mailing list
om2m-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/om2m-dev
_______________________________________________
om2m-dev mailing list
om2m-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/om2m-dev
_______________________________________________
om2m-dev mailing list
om2m-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/om2m-dev
_______________________________________________
om2m-dev mailing list
om2m-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/om2m-dev
_______________________________________________
om2m-dev mailing list
om2m-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/om2m-dev
|
