My Connected Car project

If you want to follow my progress on the project here some information.

I have started the development of the code that will run on the RPI 3.

Here is the link to the github repository:

Python code for RPI

If you have any suggestion, comments or want to contribute to the code, let me know.

Home Automation (2): A Nice and Responsive User Interface

I have decided to start from the end, the Front End.

 

But, before talking about how I have designed and built my UI, I need to give you a quick overview about the Messaging Infrastructure.

The communication between all the devices (equipped with sensors) and the Hub/Gateway is all based on MQTT protocol, over WI-FI.

In the near future I plan to add some Z-Wave devices (lights and plugs), but for now the underlying network is Wi-FI.

I don’t need to spend much time about MQTT, I Have written many blog’s posts on why it is the best and most widely used messaging protocol in IoT (Have a look at my previous posts).

The MQTT broker used is Eclipse Mosquitto 1.4, installed on a Raspberry PI 3 (RPI 3).

Every 30 seconds from each one of the rooms in my House an MQTT msg is sent to a dedicated topic. The serialization format chosen is JSON and a message carries several readings (Temperature, Humidity, Pressure, Light).

In addition, the same messaging approach is used to send commands and configuration changes from the Hub to a device (but I’ll address this side of the communication in another post).

Having said that, every information comes to the MQTT broker. You need only to subscribe to a Topic or a set of Topics and you will receive the information, every 30 sec., in JSON format.

I have setup OpenHAB 2, and OpenHAB has a nice Mobile UI and can directly bind items on the UI to MQTT topics.

But, I wanted also to develop a Nice and Responsive custom UI, without, if possible, writing too much code.

After many investigation, I discovered that there is a set of Node for Node-RED making really easy to develop a Web Front End.

These nodes are part of the module: node-red-dashboard, that I have installed in the Node-RED directory

(see: https://www.npmjs.com/package/node-red-dashboard)

 

After having installed it, you see a nice new set of nodes in the Node-RED palette:

Therefore, these are the main points behind Message Elaboration and UI:

• I have developed a set of Node-RED flows. Almost every flow starts from an MQTT input node: a message on a topic or set of topics (with wildcard) triggers the start of the flow;
• A flow typically transforms the message, extracts the relevant information and sends the message to a Node associated to a Widgets in the UI
• I have used several kind of Widgets: Text, Chart, Gauge, arranged in Groups and Two Tabs

 

All the Widgets are arranged in two Tabs: 

• The first one contains the widgets showing all the data coming from Sensors, arranged by Room;
• The second one contains a set of widgets to enable to keep under control the infrastructure; information displayed are: RTT for sensors, Number of Active Sensors, PI CPU Temperature Free Memory.

 

Here you see a snapshot of the First Tab:  

 

One of the important feature that I have added is a measure of the Air Quality and Gas concentration in the Kitchen (Group in the middle, above), useful, for example, to verify if there is a Gas Leak or if, during cooking for example, the Quality of the Air becomes too bad (can be, if windows are closed).

In the near future I plan to add also Alerts. One possible choice is to implement rules in Node-RED flows. I’m investigating the best way (if you have suggestions, please leave a comment!)

 To have an insight in the Infrastructure, I gather and display several information:

• Ping response time for all the sensors, as measured from the Hub/Gateway;
• Number of Connected Devices (devices with last message sent not older than 5 minutes);
• Timestamp for messages;
• Information relevant to the HUB: CPU temperature (RPI 3 tends to become hot), free memory and number of clients connected to MQTT broker (for now X devices + Node-RED) 

 

All the message elaboration (+ UI generation ) is organized in three flows:

• HomeAuto Main Flow
• Networking
• Hub/Gateway

 

To give you an idea, here you see the flows dedicated to elaborate and display messages coming from the Rooms.

 

To add more details, here you see the flow dedicated to elaborate and display messages coming from the device located in the bathroom

  The flow starts with a MQTT Input Node. This node subscribes to the topic bagno/+/msg.

(bagno, is the Italian word for BathRoom).

The + wildcard is there to enable, in the future, to have more devices in the same room, each one with a dedicated topic.

 

The upper part transforms the MQTT message (a string) in a JSON object. Then the two information (Temperature and Air Pressure) are extracted with a dedicated Change Node. The most important nodes from UI are the last (right). These nodes (coming from node-red-dashboard) implement the UI. Temperature is displayed in a Gauge and Pressure with a Chart (from the point of view of Weather Forecast what is more relevant is the Pressure trend).

The lower part registers the timestamp of the message arrival and display it in a Text Widget. In this way I can easily detect if, for some reason, one device has stopped sending messages.

The nice thing is that the UI is really responsive: every time a new message arrives it is updated and. Information are pushed from Node-RED server to your browser, and you don’t need to refresh the browser.  Really Cool. (I think it is based on WebSocket, but not sure till now).

Well, if you want some more details and code (JSON representation of flows) post a comment and I’ll see.

Stay tuned. This is only the beginning. 

Home Automation (1): the beauty of Visual Programming.

I have written several posts on Node-RED in my blog.
Node-RED is a Visual Programming Environment, based on NodeJS, that can be used to develop flows, to integrate for example an MQTT broker, and to easily manage, transform messages coming from devices. Perfect for IoT.
The nice thing about NodeRED is that it has a small memory footprint (it is based on NodeJS) and therefore it runs perfectly on a RPI 3 with only 1 GB of memory. The kind of device that you can adopt for a local gateway.
On this subject, for example, OpenHAB, that is Java based, takes much more memory.
Recently I have discovered that there are some modules for NodeRED that you can easily add and they give you the ability to develop flows with a resulting User Interface (UI).
The widgets that you can employ are the one that you see in one of my previous blog’s post: Gauge, Charts.
Is it difficult to develop some flows, starting from MQTT messages, displaying readings from sensors on a responsive and nice UI? No, a matter of hours.
Here you see a snapshot of the flows I have developed:

And here you see one tab of the resulting UI:


Readings (temperature, humidity, luminosity, air quality, gas) are coming from: Arduino MKR1000, Intel Edison, Fishino, connected through a WIFI network.

Home Automation

I have decided to build my Home Automation System.
A nice IoT exercise (small and not-so-complicated).
It will be completely built through OpenSource SW (and also Open HW).
This is a snapshot from the UI I have set-up today

A little note: UI and integration logic has been developed using Node-RED running on RPI3 and using Node-RED UI components. I plan to write a series of blog's posts to detail how I have designed and built my Home Automation solution, that, for now, monitor ambinet conditions in 3 rooms.

Constrained devices, MQTT, TLS

Yesterday evening I was doing some tests with an Arduino MKR1000 board.
It is a new board released some months ago. It is part of the Arduino family, but has some features specifically targeted to the IoT world.
It has WIFI on-board, has an encryption chip, and you can use MQTT.
Arduino has made available a Cloud Service (cloud.arduino.cc) where you can freely register your devices and test communication.

For example you can register several properties for each device (temperature, ...) and with an-easy-to-use API send updates.
The communication is based on MQTT over TLS.

Just a minute, I thought: but with TLS you need to encrypt the channel.
The usual handshake will happen: the broker has to send its certificate to the device and the certificate must be verified.
How is the board doing this?

The documentation is not complete, but walking around Internet and forums you find the answer
(thanks Google !).

The board contains a set of CA certificates, and for sure it is set up to recognize the site  

mqtt.arduino.cc

The problem arises when you try to use MQTT + TLS to connect to your gateway (RPI 3, in my case).
Here you not only need to set-up keys and certificates on the gateway, but also you need to upload the root CA on the MKR1000 board.

How can you do that?

Well, not easy. MKR1000 doesn't have a traditional file system and you cannot FTP files.
There is an utility. But it take some time to understand how to use it.
I'll try (probably) in the week-end.

Conclusion: a constrained device is less simple to set-up than a Linux based device.
Basically, this is one reason why they use Gateways. Your "things" communicate with a gateway locally and the gateway, on behalf, send messages to the IoT Cloud Service.

Stay tuned.

Raspberry 2 versus Intel Edison

I’m preparing, for my work, a presentation on IoT and researching.

I was searching some more detailed information regarding Edison power consumption.

By chance I came across several benchmarks comparing Edison with RPI 2.

It was my surprise to discover that Edison is as powerful as (if not more powerful) than RPI 2.

Worth to have a look:

http://www.davidhunt.ie/raspberry-pi-2-benchmarked/

IBM Bluemix, IoT and Coursera

Mooc from companies like Coursera are a great way for improving your knowledge and acquire new skills and competencies.

I have recently completed this course on IBM IoT Cloud platform

https://www.coursera.org/learn/developer-iot

I have found really interesting:

• The rising importance of JavaScript and NodeJS for IoT development
• How is easy to develop Gateways and Cloud based applications for real-time handling of telemetry data, using Visual Language NodeRED (based on NodeJS)
• How IBM Bluemix works
• The central role played by MQTT (well, it was invented by IBM)

If you need more insight into IBM Bluemix IoT and in general IoT Cloud platforms, I would recommend this course. Worth spending some euro to get a Verified Certificate.

 

Node-Red and IBM Bluemix

I’m progressing, in the free time, my evaluation of Cloud IoT platforms.

As I wrote in a previous blog post, IBM IoT platform is really interesting. One of her strong point is NodeRED, a Visual Programming Language for IoT and Integration, built on top of NodeJS.

I have upgraded my Raspbian Jessie image on my RPI. With the upgrade I have found a new version of NodeRED.

Inside I have discovered, already installed, nodes to communicate with IBM IoT Watson. Nice.

How hot is my PI?

If you want to measure the temperature of the CPU of your Raspberry PI, you can simply issue the command

root@iotgateway1:~# vcgencmd measure_temp

temp=46.0'C

A little bit hot!

NodeJS and IoT: Node Red

Next thing I'm going to explore is Node-Red.

Node-Red is a Visual Language, developed by IBM Emerging Technologies, that can be used to rapidly develop integration flows for IoT Application.
It is based on JavaScript and NodeJS.

It is available as part of IBM Bluemix PaaS, but since it is OpenSource you can install it on any environment where NodeJS is available. For example you can install it on a Raspberry PI or on a Intel Edison Board.

I have already written a short post on the subject:

http://lsaetta.blogspot.it/2016/04/visual-integration-tools.html

Stay tuned for updates on the subject!

Secure MQQT (2) with RabbitMQ

The next step has been configuring the RabbitMQ broker I have installed on my RPI to use TLS/SSL

It has worked.

The configuration file is located under /etc/rabbitmq

This is the final configuration, enabled for SSL and MQTT.

MQTT port used is 8883 (the default).

[{rabbit,        [{loopback_users,    []},

                 {ssl_options, [{cacertfile,"/etc/rabbitmq/certs/ca.crt"},

                          {certfile,  "/etc/rabbitmq/certs/server.crt"},

                          {keyfile,   "/etc/rabbitmq/certs/server.key"},

                          {password,  “<insert here>"}

                         ]}

                 ]},

 {rabbitmq_mqtt, [{default_user,     <<"guest">>},

                  {default_pass,     <<….>>},

                  {allow_anonymous,  true},

                  {vhost,            <<"/">>},

                  {exchange,         <<"amq.topic">>},

                  {subscription_ttl, 1800000},

                  {prefetch,         10},

                  {ssl_listeners,    []},

                  %% Default MQTT with TLS port is 8883

                  {ssl_listeners,    [8883]},

                  {tcp_listeners,    [1883]},

                  {tcp_listen_options, [{backlog,   128},

                                        {nodelay,   true}]}]}

].

From the RabbitMQ Web UI, accessible at the URL:

http://iotgateway1:15672/#/

you can easily monitor the flow of messages.

Some snapshot from the WebUI

 

 

Java and Edison: Configuration, not Code

I decided to try to see if it was possible, and how difficult, to develop a configurable Java program for Intel Edison.

What do I mean as configurable?

I wanted a Java program able to run and:

1. Read a set of analog sensors connected, in a continuous loop

2. Be able to specify through a configuration file (config.properties) the type of sensors and the pins used

3. Be able to send a MQTT message to a MQTT broker, containing all the readings from sensors

4. Be able to specify the broker destination in the config file.

It is still a trial, but I succeeded. The configurable parameters are:

1. Type of sensor.

2. Pins used

3. Interval between readings

4. URL of the broker

One of the problems was that the UPM classes have not a uniform interface. For some classes the method to be used is getValue(), for others a different signature.

Therefore I have defined a Sensor Interface and a set of classes, extending the UPM class for the relative sensor and implementing the Sensor Interface.

This way all the object created for sensors are inserted in a List<ISensor> and I can literate.

The repository for the code is:

https://github.com/luigisaetta/edison-java-projects/tree/master/RoomStation

Inside you can also find an example for the config.properties.

For the tests I have used:

1. Intel Edison, with Arduino Board;

2. Grove Shield

3. Grove Temp, Grove Light and Grove TP401 Gas sensor

4. RabbitMQ MQTT broker, installed on a RPI.

This is the format of JSON msgs sent. Formatted using Google GSON library. 

{
   "id":"thunder10",
   "type":"Edison",
   "date":"May 23, 2016 9:16:13 AM",
   "readings":[
      {
         "type":"Grove.Temp",
         "unit":"C",
         "value":"25.0"
      },
      {
         "type":"Grove.Light",
         "unit":"LUX",
         "value":"324.0"
      },
      {
         "type":"Grove.TP401",
         "unit":"PPM",
         "value":"83"
      }
   ]
}

 

Nice.

Experimenting with Docker

The nice thing with Docker is that you can easily and quickly setup an environment where you can test new products.

In my IoT Gateway the MQTT broker is Mosquitto. It works fine. But it has no monitoring interface.

I’m thinking about to test RabbitMQ as MQTT broker. It has a nice Web UI, with monitoring and admin capabilities. It is a little bit more complicated (RabbitMQ doesn’t start natively with MQTT, you need to enable a plug-in) but it can be installed on RPI.

I decided to run a quick test following my colleague G. Provinciali blog’s advice:

https://devopschannel.com/2016/05/12/docker-weblogic-e-kitematic/

I installed Docker and Kitematic GUI on my MacBook and then I downloaded Docker's official RabbitMQ image.

Then, some steps to enable MQTT and expose port 1883 and… it was working.

and here a screenshot of RabbitMQ Web UI.

 

As client, I have used mosquitto_sub and  Eclipse Paho GUI client. Worked fine.

Ok, next step is installation on RPI. Stay tuned.

IoT Gateway

An important component in an IoT Architecture is an IoT Gateway.

A Gateway is an important link between the world of Things and Sensors (and actuators) and the world of Enterprise Applications.

Normally connected things don't have the computing capabilities to run complex computation. Very often they don't have too much networking capabilities, but they are the best components to link to the physical world.
To avoid to put too much burden on the Things, in terms of computational capabilities and in term of networking we need something in between. This is an IoT Gateway.

As a part of my IoT training, I'm investigating what kind of software you can run on a "Open Source" IoT gateway.
For now, I have decided that the best platform to run a gateway is Raspberry Pi 2.

This is the liste of the software that I have successfully run on it:

• Mosquitto (MQTT) broker;
• Node.js;
• Node-Red;
• MySQL;
• Redis;
• Python;
• Oracle Edge Analytics

I think that the best messaging solution, to connect sensor nodes with the Gateway is MQTT, and Mosquitto broker seems to work perfectly.