REST API and Swagger

I have summarized the main point about using Swagger (and OpenAPI spec) to describe the interface of a REST API and to support the design and development of a REST API, in NodeJS, in a presentation on SlideShare

For those of you interested, here it is:

Swagger Presentation

Oracle Developer Gateway

It’s cool.

Here, in a single point, you find access to all the resources you need to develop with Oracle Technologies

Oracle Developer Gateway

(btw: as you probably already know, I do work for Oracle!)

Algorithm to filter sensors' noise.

A nice post on Predix IoT blog on how to use Kalman Filters to reduce the noise from sensors and detect anomalies.

https://www.predix.io/blog/article.html?article_id=2186

Home Automation (4): API and DB

I have decided to add to my Home Automation (Concept System) two important pieces:

• a REST API
• A Database

Home Automation (3): remote access

My ADSL provider has actived for me a public IP and, after some cumbersome configurations, I'm able to access the HomeAuto dashboard (see previous posts) from Internet.

I'm testing it, since I'm travelling by the train, and I should say that even on a 3G network, responsiveness is impressive.

Nice.

Artik and Node-RED: a short post

Well, after some work in a field (of grass?) you see that there are some paths recurring.

In the break, reading the documentation, I have seen that they have posted some documentation where they suggest to use NodeRED as a tool to test connections (for example through MQTT) to Artik Cloud.

Well, we have spent several posts blogging about NodeRED.

See you later. (Update: for more details, see my post of December, 20th)

Samsung Artik

Sounds really interesting.

Samsung has not only bought the Startup SmartThings, but have also developed an entire eco-system for developing and running IoT systems.

It is called Artik.

Artik is composed by:

• A set of development boards (Artik Modules)
• An IoT Cloud Service (Artik Cloud)
• SW to simplify the development of solutions, both on modules, gateways, Cloud (

What is really interesting, in my personal view, is that Artik has the broadest support for the protocols that are considered key in a IoT solution.

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.

Scientific Programming with Arduino

Well done.

Professors and researchers from Italian INFN have published a nice book on how to use Arduino for Scientific Programming.
If you:

• want to learn how to program Arduino in C
• want to learn how you can use Arduino for small Physics experiments

It can be a nice reading. Enjoy:

Scientific programming

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.

Oracle IoT Cloud Service: Assett Monitoring

Oracle IoT Cloud Service will offer some "mini SaaS" applications, almost ready to use.

The first available is the Assett Monitoring Application.
If you have access to one instance of Oracle IoT CS you can easily create your own instance of the Assett Monitoring Application and start configuring it.

Inside the application, you can define your Assett Types and associated Devices.
You can define Places on a Map and define the assumed location for these assetts.

Then you can start monitoring these assett and define Rules; for example rules that are fired when an assett leaves a floor or when some value coming from devices rises above a defined threshold.

A nice video showing what and how you can do all these things is available here:

Oracle IoT CS: setting up Assett Monitoring

 

And this is an example of what you can realize:

 

Intricacies and fallacies of Embedded Development

I have spent some hours yesterday evening evolving my Home Automation Solution.

Porting some code developed for the Arduino MKR1000 on an Arduino One (a clone) board, I hit a strange problem: the sprintf function was not working as expected.

Strange, at the beginning I thought. Unbelievable.
I made resort to the skills in C development built 25 years ago. A step-by-step debugging of few lines of code.
Then, after some googling, I discovered what the problem is:

MKR1000 is a board with a chip from ATMEL that is 32bit. Arduino Uno is NOT.
On many "so-constrained boards" the C standard library has limitations introduced to reduce the memory footprint. Especially regarding floating point numbers.
sprintf has one of these limitations.

Resorting to another function provided by ATMEL I resolved.

But the important point is: if it is embedded it has constraints. Limitation.
It is not a smaller version of an Intel chip (the one that you have on your MacBook).
And we must be aware of this.

Making Mistakes

In order to test MQTT with TLS on my MKR1000 board I decided to reuse the steps detailed in my May Blog's post:

Secure MQTT (TLS/SSL)

Well, I have discovered that I did some mistakes in the steps detailed to create SSL keys and certificates.

Now, all the steps should be OK.

Apologies.

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.