About a month ago, Sierra Wireless proposed a new project under the umbrella of the M2M Industry Working Group that aims at delivering a crucial missing piece to the global architecture of the open source M2M stack this Group is trying to establish.
Mihini is a runtime technology that hides the complexity of the underlying hardware platform to a developer whose primary goal usually is pretty simple: connecting objects (power-meters, cars, digital photoframes, …) from the physical world to the Internet, therefore making their data available for consumption by web, mobile, or enterprise applications. Of course, sending data is not the only aspect of an M2M solution, and things such as being able to react to commands send from a server to the device, being able to remotely update an application, … are also important to the developer.
Mihini will allow to develop M2M applications by using the Lua programming language. We want the initial contribution to be something useful for the hackers and hobbyists community right from the beginning, by enabling M2M application development on prototyping platforms such as the BeagleBone and the RaspberryPi.
But in parallel of seeding Mihini with an initial set of features (interactions with physical ports of the system, communication using a GPRS/3G connection, …) that we think will increase the number of crazy DIY M2M solutions with Open Hardware platforms, we want to work on cleaning and establishing a solid API that addresses the recurrent pain points of M2M development. In particular, besides just enabling easy interaction with the physical inputs and outputs of a system, it is important to provide functionalities such as:
- data management API, that allows to process data in a way that is independent from how it is being acquired from the physical devices, and from how it will eventually be transmitted on the wire. In an ideal world, reacting to the changes of a given input, consolidating its different states/values over a period of time, etc. should be more of a configuration process than writing what will very likely be boilerplate code.
- application management API, that allows to remotely install, update and manage (stop, start, get the overall “health” by dumping some internal variables, …) applications on the field.
- application settings management API, that allows a developer to code an application for which some parameters can be managed remotely.
- etc.
Another kind of API that is very important when it comes to embedded/M2M frameworks is the one that third-party software can use to communicate with a running instance of the framework.
For that purpose, Mihini will expose a REST API for external applications such as (but not limited to) the Eclipse IDE to allow them to get some control on the framework in a simple manner (vs. using lower-level techniques such as e.g. RPC): what are the applications installed? how many of them are running? etc.
Besides allowing better IDE support, such an API enables the creation of administration GUIs (e.g. embedded web application run directly on the embedded device), batch provisioning tools, etc.
This diagram illustrates the high-level architecture of Mihini, and how it fits with Paho and Koneki.
.
If you are familiar with these two projects already, you’ll know that they both have a strong interest in Lua. Koneki is delivering an IDE for Lua, and Paho will soon provide an MQTT client written in Lua (currently available on Github) contributed by Andy Gelme.
Therefore it should be no surprise to you that Mihini applications will be developed using a Lua API: not only will it allow to leverage Koneki tooling and Paho communication libraries, but first and foremost we think that Lua is the best choice for developing M2M applications. It is easy to learn, easy to embed on constrained targets, and can interoperate with legacy C software very well (you might be interested in reading this excellent article from my Lua guru co-worker and future committer on Mihini, Fabien Fleutot). And there is also a pretty large community of Lua developers, with tons of available open source libraries ready to be reused! 🙂
More and more M2M at Eclipse!
You definitely should stay tuned, there is a lot to come regarding M2M in the next few weeks!
In particular, we will hold 4 webinars in September and October, we will deploy an M2M web portal on m2m.eclipse.org, … and of course we will create the Mihini project very soon, and start working on the initial contribution.
About a month ago, Sierra Wireless proposed a new project under the umbrella of the M2M Industry Working Group that aims at delivering a crucial missing piece to the global architecture of the open source M2M stack this Group is trying to establish.
Mihini is a runtime technology that hides the complexity of the underlying hardware platform to a developer whose primary goal usually is pretty simple: connecting objects (power-meters, cars, digital photoframes, …) from the physical world to the Internet, therefore making their data available for consumption by web, mobile, or enterprise applications. Of course, sending data is not the only aspect of an M2M solution, and things such as being able to react to commands send from a server to the device, being able to remotely update an application, … are also important to the developer.
Mihini will allow to develop M2M applications by using the Lua programming language. We want the initial contribution to be something useful for the hackers and hobbyists community right from the beginning, by enabling M2M application development on prototyping platforms such as the BeagleBone and the RaspberryPi.
But in parallel of seeding Mihini with an initial set of features (interactions with physical ports of the system, communication using a GPRS/3G connection, …) that we think will increase the number of crazy DIY M2M solutions with Open Hardware platforms, we want to work on cleaning and establishing a solid API that addresses the recurrent pain points of M2M development. In particular, besides just enabling easy interaction with the physical inputs and outputs of a system, it is important to provide functionalities such as:
- data management API, that allows to process data in a way that is independent from how it is being acquired from the physical devices, and from how it will eventually be transmitted on the wire. In an ideal world, reacting to the changes of a given input, consolidating its different states/values over a period of time, etc. should be more of a configuration process than writing what will very likely be boilerplate code.
- application management API, that allows to remotely install, update and manage (stop, start, get the overall “health” by dumping some internal variables, …) applications on the field.
- application settings management API, that allows a developer to code an application for which some parameters can be managed remotely.
- etc.
Another kind of API that is very important when it comes to embedded/M2M frameworks is the one that third-party software can use to communicate with a running instance of the framework.
For that purpose, Mihini will expose a REST API for external applications such as (but not limited to) the Eclipse IDE to allow them to get some control on the framework in a simple manner (vs. using lower-level techniques such as e.g. RPC): what are the applications installed? how many of them are running? etc.
Besides allowing better IDE support, such an API enables the creation of administration GUIs (e.g. embedded web application run directly on the embedded device), batch provisioning tools, etc.
This diagram illustrates the high-level architecture of Mihini, and how it fits with Paho and Koneki.
.
If you are familiar with these two projects already, you’ll know that they both have a strong interest in Lua. Koneki is delivering an IDE for Lua, and Paho will soon provide an MQTT client written in Lua (currently available on Github) contributed by Andy Gelme.
Therefore it should be no surprise to you that Mihini applications will be developed using a Lua API: not only will it allow to leverage Koneki tooling and Paho communication libraries, but first and foremost we think that Lua is the best choice for developing M2M applications. It is easy to learn, easy to embed on constrained targets, and can interoperate with legacy C software very well (you might be interested in reading this excellent article from my Lua guru co-worker and future committer on Mihini, Fabien Fleutot). And there is also a pretty large community of Lua developers, with tons of available open source libraries ready to be reused! 🙂
More and more M2M at Eclipse!
You definitely should stay tuned, there is a lot to come regarding M2M in the next few weeks!
In particular, we will hold 4 webinars in September and October, we will deploy an M2M web portal on m2m.eclipse.org, … and of course we will create the Mihini project very soon, and start working on the initial contribution.
In the next few weeks there will be four webinars to give you not only a general introduction to what Machine-to-Machine is, but also highlight how actors of the Eclipse community are working on addressing the challenges associated with M2M technologies.
