IoT for Around the House: Sensors, MongoDB, and REST API on Onesait Platform (Part 3)

uriotnews

And so we arrive to the third and -for now- last entry in our adventure about connecting a sensor at home and sending the measurements to the Onesait Platform.

In the first entry, we saw how to choose the working environment and set up both the ontology and the API service to ingest the data. In the second part, I told you how to hook the cables between the boards, how to configure the Arduino IDE to work, how to write the code that collects and sends the measurements to the Platform, and how to see that it was indeed received correctly.

Well, today we are going to talk about how to represent the data in a moderately attractive way, because viewing a string of data may be good, but is perhaps not optimal when I want to see what’s the temperature right now or was during the last hour. This entry is just a sample of what you can do, meaning that, if you master SQL, HTML/CSS and/or JavaScript, you can set up something very interesting.

Here we go. The objective is to create a Dashboard in the Platform that shows us the information from the sensors. Just for variety, we can show the information of the two sensors, in real time, in boxes (option A) or in the home blueprints (option B), and show the accumulated information of the last hour in a graph. To put it another way, we can do this:

You can navigate between the tabs to see the different representations of the data. To see the «Home Map» option properly, I recommend you to see the Dashboard in large size.

To get this, first we are going to generate some Datasources in which the existing data in the ontologies will be processed, and the output for what we are going to need will be formatted. Then, we are going to generate the Gadgets where we are going to represent the data from the created Datasources. When we have them, we will only have to add those to the Dashboard and – that’s it!

Creation of the Datasources

Let’s start with the «harshest» part of this topic, which involves SQL queries. The first thing is to ask: What are we going to need?

We want to represent in a Gadget the real-time values (in other words, the last records) of temperature and humidity for each room in the house. Therefore, we will have to obtain the last temperature value and the last humidity value (obviously ordered by date) for each type of sensor. No sooner said than done, let’s get to it.

We navigate to the menu Visualization and GIS > My Datasources, and once there, we create a new Datasource, filling in the fields as indicated below:

  • Identification: the first Datasource that I am going to create corresponds to the sensor in the dining room, so I will give it a name to relate it to: «arduinoDHT22_diningRoom_last» (remember that, if you are following the steps of this tutorial, you cannot duplicate the names, so I recommend you add your initials or something similar to the name you give the Datasource).
  • Select ontology: here we will select the ontology in which we are storing the data, which in my case is «arduinoDHT22».
  • Maximum records: we leave this one as «1», because we are only going to recover one object.
  • Refresh time: this point is important. The value specified here will be the time in seconds that the Datasource will use to update its data. That is to say, if we say 60 seconds here, as in my case, it will update its data by reading the ontology every 60 seconds. Thanks to this option, every minute we automatically obtain the last value.
  • Description: in this short field, you can enter a description of what your datasource does.
  • Datasource query: this is where we make magic using SQL to obtain what we want from the ontology. I think it’s better if I explain this part bit by bit, sowe are going to see it carefully below.

Generating the Datasource Query

If you’re fluent in that SQL with Quasar thingy (here they talk about that, in Spanish), you’ll surely do a much better job than I’m going to do. If not, come with me on this dangerous path to the promised query.

Say that we start from this query:

This will return everything in the ontology.

But we are not interested in all the existing fields – we only want the sensor identification, its location, temperature, humidity and date. Considering this, we will generate a query that returns only that information, ordered:

This query gives us something closer to what we are looking for:

Next, we will filter the sensor’s location, so that we can differentiate between the living room and the office. We will do this by adding a «WHERE» condition differentiating between ‘Dining Room’ and ‘Office’. If you have used different names, this is where you will have to filter them:

In this case, the output will be the same I’ve shown you before, but by changing it to ‘Office’, it outputs something like this:

Nevertheless, the data we are recovering go from beginning to end. In other words, the first data is the oldest one, and the last one is the most recent one. We are interested only in the last value, so we are going to order the query in a descending order (most recent first), using the «timestamp» field.

Yeah, I know: we don’t have a timestamp field because I am too lazy and I don’t send that from the sensor when I’m measuring. I’m sure someone has thought about it, but has been less lazy than me and added it. Great. In my case I will use the timestamp of the data intake in the ontology. Isn’t that perfect?

This timestamp is not in the object «arduinoDHT22», but in another object at the same level called «contextData».

We want to filter the query from that field so that the most recent information is displayed first.TO do this, we will update the query using the «ORDER BY» in «DESC» mode. We will also include the timestamp as one of the values to be recovered.

The data is now correctly sorted. Give a look at the measurement times so that you can see that this is not a swindle:

The first data is from 14:52 (notice that is in UTC+0, not +2), the second is from 14:51, the third is from 14:50… Meaning that this is just as we wanted. However, we have way too many data when we are only interested in the last one. Well, this is easy to solve: Just add a «LIMIT» and that’s it:

And with this, we now have it last record obtained from the sensor:

We now have to repeat this with a similar Datasource, but for the office instead of the dining room. You only have to change ‘Dining Room’ for ‘Office’ (again, in my case), so I leave that to you.

The other type of Datasource we are going to create corresponds to the one we are going to use to generate the temperature evolution graph for the last hour. The idea here is to recover the last sixty temperature records corresponding to the dining room. The query is very similar to what we have previously generated:

The result is a list of the last 60 temperature records in the dining room.

It seems simple, doesn’t it? Well, let me tell you that we have finished the dangerous path, and now we move on to the paint and color part.

Generating the Dashboard

Some people prefer to first create the elements they are going to use, and later create the dashboard to embed them. That’s not me at all. Therefore, from the Visualization and GIS > My Dashboards menu we will create a new «Dashboard» for our sensor project.

When creating it, we will enter the following information:

  • Identification: the name the Dashboard will have. For this tutorial, I’ve given it the name «arduinoDHT22_infoPanel», but, like in previous cases if you are doing the tutorial too, modify the name with your initials or something. You already know that you cannot duplicate names.
  • Description: here you can enter some text describing your Dashboard.
  • Public: if you want anyone to be able to access it without being registered. For example, my dashboard is public, so that I can embed it in this blog so that you can check it, without logging.
  • Category and Subcategory: I’ve left those empty, but you can fill them in if you want.

Create Dashboard

Once we have created the Dashboard, we will decorate it to our liking (header, background colour, etc.) and leave it ready to be filled with gadgets.

Preparing the Gadgets

Let’s now generate our first Gadget, with cute colours and icons, to shows us the temperature and humidity in one of the rooms.

This type of Gadget we are going to create doesn’t have a predefined template. Instead, we will have to create it from scratch (that’s why we don’t do it from the Gadget creator). To do this, from the Dashboard itself, click on the ( + ) button and, in the different options that appear, choose the «Template» option.

When we’re asked whether we want to use any template or not, we say no. This will generate an empty gadget that looks like this:

By selecting the three vertical dots at the top right, we will access the Gadget menu. From the different options available, we select «Edit», which will open the Gadget’s code editor.

If you have worked before with Gadgets like this, there is no mystery to that: To the left, we add the HTML and CSS code (we are going to make a, let’s call it a mini web page), and to the right we include the JavaScript code necessary to make the logic and stuff.

For my example card, I have created a list of sorts in which the temperature is shown with a temperature icon, then the humidity with a humidity icon. Explained on a code level, this would look more or less like this:

Anyone knowing a bit of HTML here can mount their card as they want. The previous code is just an example, but with a couple of details to highlight.

The first one has to do with the images of the temperature and humidity icons. Instead of linking them to something external, I’ve generated them in SVG format and introduced them raw as a data:image/svg+xml background element in DIV (thus the long string of letters and numbers). This is a quick solution because it avoids dependance on external elements, but maybe you prefer to be more traditional and link to some image you may have around.

Another point to indicate is the name of the classes; the container’s class name is «diningRoom», so we can identify it and differentiate it from other rooms (in case you use more than one sensor, as is my case). There is also a class called «temperature» and another one called «humidity». This is important because, from these class names, we will identify the DOM element to which we will add the Datasource’s temperature and humidity values. If you want to change the names, just keep that in mind.

Then, we will add the function logic with JavaScript in the right panel of the Gadget. Among the different functions that appear by default, we will use the second one, «drawLiveComponent». This function is executed every time the Datasource is modified – which in our case is once per minute as we have defined, which is when we receive the data from our sensor.

At the code level we will enter this:

There’s not much mystery to what we do here. From the Datasource, we retrieve the temperature and humidity values, then we select the DOM element with the class name assigned to the dining room («diningRoom» in my code), and substitute the content of the elements named after the temperature and humidity class name, with their corresponding value.

If we then compile and synchronise the changes, save the Dashboard and update it, the box we have prepared should be receiving and displaying the temperature and humidity data.

If you have a second sensor (or more), I leave it to you to create the corresponding Gadgets but it’s essentially the same, only changing the room identifier and the Datasource that you apply.

With this, we are finished. Now you can visualize it on your mobile phone, tablet or laptop, pronto and at a glance (if you have put the Dashboard as public, of course. Otherwise you’ll have to log in to enter).

If you want to get creative, you can play with the Gadgets and create something more customized. For example, my second tab, «Home Map», shows a pseudo-reliable representation of the rooms in my house, and you can see at a glance the temperature in each room. I’ll show you a screenshot because what you would see on the embedded Dashboard is mobile phone-size and this must be seen on a wide screen:

Now, each of you can decide what they want to show: Here each one can organize it as he wants; put the data in the center of each room, put a clock about the update, modify the background colors according to thresholds of temperature, etc. These gadgets would also be of the «Template» type, so HTML + CSS + JS provides you with a world of possibilities.

Next, we are going to move on to the second type of Gadget we wanted to create: the one with the temporal evolution.

This Gadget can be created from the Dashboard itself, or from the Gadget Manager. We are going to do it with the latter for the sake of change, so we will navigate to the Visualization and GIS > My Gadgets menu, and we will create a new one.

Here we will only have to choose a name for the Gadget, and the Ontology or Datasource with which we will feed it.

  • Gadget Name: for this example I have used a name that is easy to identify: «arduinoDHT22_diningRoom_temperature_lastHour».
  • Ontology or Datasource: here I have chosen the Datasource that we have created at the beginning, that of «arduinoDHT22_diningRoom_temperature_lastHour» (yes, same name as the Gadget).

Once we have entered this data, we will have to choose the type of Gadget we want. From the different options, I have selected the «line» one.

Next, the Gadget configurator will appear. There, we will have to specify the parameters that it requests. The important thing here is to indicate that we want to show the time, the field «timestamp», on the X axis; and the value of the measurement, in this case, the field «temperature», on the Y axis. Then we choose some color that we like and the graph is ready.

And that was it. Yes, seriously. We have successfully created a time chart with the information of the last hour (or more precisely, of the last sixty records).

This graph corresponds to the room temperature, but you can also generate the humidity graph (in the same or a different Gadget), the graphs of another room if you have more than one sensor, etc.

Well, now we have completed this trilogy of how to connect an IoT sensor to the platform and how to represent it visually.

I hope you liked it, and if you have any questions, or you can’t do this, or you simply wanna say hello, just leave a comment. See you next time.

You can find part 1 here and part 2 here.

This UrIoTNews article is syndicated fromDzone