Wednesday, September 30, 2015

Meet me at the ApacheCon Core EU 2015

This Friday I will be speaking at the ApacheCon EU 2015, in Budapest. The even takes place at the same venue as a year before i.e. at lovely Corinthia Hotel Budapest. I will be giving two IoT related talks:

I will be in Budapest for Thursday and Friday. If you are at the Budapest at this time, feel free to drop me a line!

About ApacheCon Core:
Core will bring together the open source community to learn about and collaborate on the technologies and projects driving the future of open source, web technologies and cloud computing. Apache projects have and continue to be hugely influential in the innovation and development of software development across a plethora of categories from content, databases and servers, to big data, cloud, mobile and virtual machine. The developers, programmers, committers and users driving this innovation and utilizing these tools will meet in Budapest, October 1 & 2, for collaboration, education and community building.

Monday, September 28, 2015

Rhiot quickstarts - getting into the IoT really fast!

The goal of the Rhiot project is to allow the developers to create the Internet Of Things projects as easily as possible. We want to make the complex IoT projects simpler and bring the fun to the IoT world, while preserving all the benefits the developers can gain from the rich Red Hat JBoss Middleware portfolio
Keeping Rhiot philosophy in mind, we decided to start releasing the quickstarts - the set of the base projects that can be used as a building blocks for the IoT solution. Rhiot quickstarts can be copied and used as the template for your IoT solution.
The programming model we have chosen for Rhiot quickstarts revolves around Camel and Vert.x. Camel routes are our primary choice for the expression of the endpoint connectivity and message routing. So starting embedded MQTT ActiveMQ broker and connecting to it might be as simple as using the following Groovy snippet:
class MyMqttApp extends CamelBootstrap {

    void configure() {
        from(mqtt('topic')).log('Received ${body}')

Vert.x verticles and event bus are also the first class citizen in all the Rhiot applications. So Rhiot can help you with detecting Vert.x verticles or make it as easy to connect to the event bus as:
class MyMqttApp extends CamelGroovyVerticle {

    void configure() {

Looks interesting? More details about Rhiot API and quickstarts soon to come!

Tuesday, September 22, 2015

IoT server platform emerging at Eclipse

Recently at the Eclipse IoT Working group mailing lists one of our members raised the proposal to collaborate on the server-side platform specification.

Why this proposal is so important? Because it may result in the creation of the core engine for the IoT backend services that might become a kind of standard, as there are several companies interested in participating in the project.

I'm definitely interested in getting involved into that initiative. Tomorrow I will be presenting the Rhiot project to the Eclipse IoT Working Group, so the other members can see how Rhiot and that emerging platform could overlap.

I highly recommend to track the minutes published on the Eclipse IoT Working Group mailing lists. The emerging Eclipse platform can be a big thing!

BTW Wondering who is the part of the Eclipse IoT Working Group? EuroTech, IBM, Red Hat, Cisco, Bosch, Sierra Wireless, Canonical, Huawei, Verisign, to mention some of them.

Monday, September 14, 2015

Rhiot 0.1.1 is out

On the behalf of Rhiot team, I'm happy to announce that Rhiot 0.1.1 has been released. It's been a while since efforts related to rebranding the project from Camel Labs to Rhiot have been holding our release train.

What has changed in the latest Rhiot?

Thursday, July 30, 2015

Let's start the rhiot!

As many of you probably already know, in the recent months I've been hooked on the Internet Of Thing in general, and creating the rocking Internet Of Things messaging platform in particular. My R&D activities have been revolving around the adoption of the awesome Red Hat JBoss middleware portfolio to the IoT needs. Me, and the other folks interested in the adoption of the projects like Apache Camel or ActiveMQ to the IoT challanges, joined our forces to create the Camel IoT Labs project.

As the Camel IoT Labs project scope is really wider than the scope of the Camel itself, we decided to give up the old project name. Instead we would like to come up with something that would reflect the fact that we are working on the project with the bigger IoT messaging platform picture in mind.

We decided to go with renaming the project to rhiot (pronounced like riot). Our new name hides the Red Hat and IoT in it - which is fine, because we want to stress that our IoT project relies on the rock solid Red Hat software portfolio as its foundation. Starting from today we will be gradually migrating our Camel Labs to new Rhiot name. That will include moving our GitHub project to the new rhiot organization and changing our Maven coordinates from com.github.camellabs to io.rhiot.

I'm also thrilled to say that Red Hat decided to sponsor some R&D activities around the new Rhiot project. So stay tuned and expect amazing IoT stuff coming from the Rhiot team. Also keep in mind that we have really open policy regarding accepting new contributors for our project - if you want to help us to create the IoT messaging platform, you know where to find me :) .

Wednesday, July 29, 2015

Where am I? Collecting GPS data with Apache Camel

This is the re-post of my article Where Am I? Collecting GPS Data With Apache Camel originally posted at the DZone.

One of the most popular requirement for the field devices used in the IoT systems is to provide the current GPS location of that device and send this information to the data center. In hereby article I will tell you how Apache Camel can turn full-stack Linux microcomputer (like Raspberry Pi) into the device collecting the GPS coordinates.

Which GPS unit should I choose?

There is a myriad of the GPS receivers available in the market. BU353 is one of the most popular and the cheapest GPS units. It can be connected to the computer device via the USB port. If you are looking for good and cheap GPS receiver for your IoT solution, you should definitely consider purchasing this unit.

The picture below presents the BU353 connected to the Raspberry Pi device via the USB port.
You can optionally equip your Pi into the external mobile battery, like GOODRAM Power Bank P661. Equipped with the external power supply you can take your mobile GPS system to the car or into the outdoors. Battery significantly simplifies testing "in the field" part of your solution.

How can Camel help me?

Camel GPS BU353 component can be used to read the current GPS information from that device. With Camel GPS BU353 you can just connect the receiver to your computer's USB port and read the GPS data - the component will make sure that GPS daemon is up, running and switched to the NMEA mode. The component also takes care of parsing the NMEA data read from the serial port, so you can enjoy the GPS data wrapped into the com.github.camellabs.iot.component.gps.bu353.ClientGpsCoordinates POJO objects (which in turn are forwarded to your Camel routes).

Show me the code

In order to take advantage of the Camel GPS BU353 you have to add the following dependency to your Maven project:
BU353 component supports only consumer endpoints - it makes sense as GPS component is used to read, not write, GPS data. The BU353 consumer is the polling one, i.e. it periodically asks the GPS device for the current coordinates. The Camel endpoint URI format for the BU353 consumer is as follows:
Where label can be replaced with any text label:
The Camel route presented above reads the current GPS coordinates every 5 seconds and saves these into the /var/gps-coordinates directory. Each GPS coordinates pair is saved into the dedicated file. The complete runnable example of the route above is presented in the code snippet below. I use Camel Spring Boot support to start the Camel context and load the route definition:
public class GpsReader extends FatJarRouter {

  public void configure() throws Exception {

BU353 consumer receives the com.github.camellabs.iot.component.gps.bu353.ClientGpsCoordinates instances. ClientGpsCoordinates class is a convenient POJO wrapper around the GPS data:
  ConsumerTemplate consumerTemplate = camelContext.createConsumerTemplate();
  ClientGpsCoordinates currentPosition = 
    consumerTemplate.receiveBody("gps-bu353:current-position", ClientGpsCoordinates.class);

  String deviceId = currentPosition.clientId();
  Date taken = currentPosition.timestamp();
  double latitude =;
  double longitude = currentPosition.lng();
ClientGpsCoordinates class name is prefixed with the Client keyword to indicate that these coordinates have been created on the device, not on the server side of the IoT solution.

Process manager

Process manager is used by the BU353 component to execute Linux commands responsible for starting GPSD daemon and configuring the GPS receiver to provide GPS coordinates in the NMEA mode. If for some reason you would like to change the default implementation of the process manager used by Camel (i.e. com.github.camellabs.iot.utils.process.DefaultProcessManager), you can set it on the component level:
    GpsBu353Component bu353 = new GpsBu353Component();
    bu353.setProcessManager(new CustomProcessManager());
    camelContext.addComponent("gps-bu353", bu353);
If the custom process manager is not set on the component, Camel will try to find the manager instance in the registry. So for example for the Spring application, you can just configure the manager as the bean:
    ProcessManager myProcessManager() {
        new CustomProcessManager();
The custom process manager may be useful if for some reasons your Linux distribution requires executing some unusual commands in order to make the GPSD up and running.

What's next?

Do geographical capabilities of the Camel seem compelling to you? Then you should also Camel Geocoder component which can be used to easily convert GPS coordinates collected via Camel into the human readable street address. Also stay tuned for the geofencing features coming soon to the Camel IoT Labs project.

Thursday, July 23, 2015

Measuring the throughput of the IoT gateways

The key part of the process of tailoring the perfect IoT solution is choosing the proper hardware for the gateway device. In general the more expensive gateway hardware is, the more messages per second you can process. However the more expensive the gateway device is, the less affordable your IoT solution becomes for the end client. That is the main reason why would you like to have a proper tool for measuring the given IoT messages flow scenario in the unified way, on multiple devices.

Camel Labs Performance Testing Framework

Camel IoT Labs comes with the Performance Testing Framework that can be used to define the hardware profiles and test scenarios. Performance framework takes care of detecting the devices connected to your local network, deploying the test application into these, executing the actual tests and generating the results as the human-readable chart. For example the sample output for the MQTT QOS testing could generate the following diagram:

When to use Performance Testing Framework

Performance Testing Framework excels when you would like to answer the following question - how the different field hardware setups perform against the given task. And to answer that question just connect your devices to the local network, execute the performance testing application and compare the generated diagrams.

Here is the 30 seconds video guide demonstrating how easy it is to perform the test:

Hardware profiles

This section covers the hardware profiles for the performance tests. Profiles are used to describe the particular hardware configuration that can be used as a target device for the performance benchmark. Every performance test definition can be executed on the particular hardware profiles.

The example of the hardware profile can be Raspberry PI 2 B+ (aka RPI2).  The RPI2 hardware profile is just the Raspberry Pi 2 B+ model equipped with the network connector (WiFi adapter or the ethernet cable). Currently we assume that the device is running Raspbian operating system (version 2015-05-05).

The other profile we defined for the Camel Labs is the Raspberry is the PI 2 B+ with BU353 (aka RPI2_BU353) The RPI2_BU353 hardware profile is the same as RPI2 profile, but additionally equipped with the BU353 GPS receiver plugged into the USB port.

Running the performance tester 

The easiest way to run the performance benchmark is to connect the target device (for example Rapsberry Pi) into your local network (for example via the WiFi or the Ethernet cable) and start the tester as a Docker container, using the following command:

docker run -v=/tmp/gateway-performance:/tmp/gateway-performance --net=host camellabs/performance-of RPI2

 Keep in mind that RPI2 can be replaced with the other supported hardware profile (like RPI2_BU353). The performance tester detects the tests that can be executed for the given hardware profile, deploys the gateway software to the target device, executes the tests and collects the results. When the execution of the benchmark ends, the result diagrams will be located in the /tmp/gateway-performance directory (or any other directory you specified when executing the command above). The sample diagram may look as follows:

Keep in mind that currently we assume that your Raspberry Pi has default Raspbian SSH account available (username: pi / password: raspberry).

Future of the framework

I plan to develop the gateway Performance Testing Framework to make it the tool for the sizing of the IoT gateways. In particular I plan do add more benchmarks and supported hardware profiles. The performance framework is also a great tool to perform the fully automated end-to-end integration tests on the real hardware - I would definitely like to see the PTF as the tool for running Jenkins-based integration tests executed on the real devices.