Connecting machines with Koneki

Introduction to M2M at Eclipse - welcome Koneki - Part 2

    

Debugging a Lua application

Besides its very powerful content-assist mechanism, Lua Development Tools 0.8 comes with a debugger that can be used with virtually any Lua runtime. It comes in the form of a DBGp (DeBuG protocol) client written in Lua, which can instrument a Lua script to make it talk to the debugging server running in the IDE.

In order to use the debugger, you just need to include two files (debugger.lua and debugintrospection.lua) in your Lua path, and add the following statement before the code you actually want to debug: “require('debugger')()”. It is also possible to automatically inject the debugger into any existing script by using the following command-line syntax: “lua -e "require('debugger')();" MyApp.lua”.

Since debugging works by opening a server in the IDE, you have to launch your debug configuration prior to running the instrumented Lua script. Creating a debug configuration is done via the usual Run | Debug Configurations… menu (Figure 4).

As long as your Lua virtual machine is not too funky (e. g. it is better to have loadstring support), basically every debugging feature you would get when developing for Java will be available to you: breakpoints (including conditional breakpoints), variables exploration and modification, interactive expressions, console, multi-threading (coroutines) debugging, etc.  

Figure 4: Lua debugger in action

Other tools available in Koneki

OMA-DM simulator 

Earlier this year, we made available an Eclipse plug-in that allows configuring and running OMA-DM simulations. OMA-DM is a standard communication protocol widely used in the telecommunications industry to monitor and synchronize the state of communicating devices such as mobile phones, or the kind of modules you might find in an M2M solution.

The user interface of the simulator is a forms editor that offers a visual representation of the simulated device’s data tree, and an interactive dashboard allowing monitoring of the OMA-DM packets going back and forth between the client and the server (Figure 5).

Figure 5: Visualisations of the simulated data tree

M2M model 

While it is still at a very early stage, we are working on the definition of a model of M2M applications whose goal will be to express important information such as: data manipulated by an application as well as the protocols used to exchange this data with other actors of an M2M solution, dependencies towards specific hardware capabilities or software libraries, etc.

We believe that such a model will facilitate the creation of extensible tools, by allowing third parties to develop their own extensions, for example, a bandwidth estimator for a specific communication protocol. We also think that this model can be leveraged at runtime, for example by letting an M2M developer have data access APIs that hide the complexity inherent to the serialization/deserialization of data on the wire.

The first version of this M2M model is already available in the Git repository of the project, and focuses on the description of the data manipulated by an application. It addresses the specifics of M2M, for example by allowing a distinction to be made between data that is to be only sent to another machine vs. data that can also be updated remotely, or to describe operations that can be executed remotely.

Figure 6: Koneki’s data model applied to an M2MIWG use case

 The requirements for this M2M model are discussed within the M2M Industry Working Group, where real-life use cases are used to nail down the core notions that the model should cover.

Coming next

You may wonder what is to be expected for the next releases of Koneki, especially what we will do to add more M2M content to Koneki. Our next hot topic is to work on the contribution of a Lua application framework that could run on virtually any kind of Linux platform, and would simplify the remote management of the system, the IOs manipulations, the access to the network, etc. We are also looking at addressing the huge community of makers and hobbyists who demand a platform that would simplify access to communication APIs (SMS, 3G connectivity, etc.), remote management of embedded systems (over-the-air firmware upgrade, monitoring of network status), and so forth.

Also, the Koneki team is really looking forward to working on providing a complete M2M-oriented modeling environment, together with the Damos team. Damos is a recently proposed Eclipse Tools project whose scope is to provide an integrated development environment for developing data flow-oriented systems using block diagrams.

We are working on the plan for our 0.9 release that we expect to deliver at the end of the year, and are very much looking for community inputs, so feel free to stop by our forum or our mailing-list to raise your voice! We want to release a 1.0 version together with the Kepler train next year, fun times ahead! — www.eclipse.org/koneki

Author Bio:


Benjamin is Open Source Evangelist at Sierra Wireless. He has a longtime passion for Eclipse and its ecosystem, and is a committer to several Eclipse projects (e4, PDE, …) and contributor to numerous other open-source projects. He leads the Koneki project and actively participates in the M2MIWG. In his day-to-day job, he supports the community and advocates the use of innovative technologies (Lua, modeling, …) for the Internet of Things. When not wandering on the Koneki forum, he is building crazy communicating devices using Arduino kits! You can find him online on Twitter (@kartben) or on his blog: http://blog.benjamin-cabe.com.

This article appeared in Java Tech Journal: Eclipse Juno - find more of that and other issues of JTJ/JAX Magazine here.

Pages

Benjamin Cabé
Benjamin Cabé

What do you think?

JAX Magazine - 2014 - 03 Exclucively for iPad users JAX Magazine on Android

Comments

Latest opinions