Server for IoT devices and Mobile devices using Wifi Network
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Part Number | 152 | |
| Number of Parts | 169 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/21162 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
InternetworkingEvent horizonFunction (mathematics)Physical systemComputing platformIndependence (probability theory)Internet der DingeCASE <Informatik>Server (computing)Source codeMobile appFeedbackIntegrated development environmentMobile WebInformation securityType theoryInformationTraffic reportingOrder (biology)NumberSound effectFunctional (mathematics)Cartesian coordinate systemComputer animation
02:08
Normed vector spacePhysical systemFunction (mathematics)Computing platformIndependence (probability theory)Type theoryWeb browserNetwork socketServer (computing)Order (biology)Link (knot theory)Thread (computing)Queue (abstract data type)Message passingInterprozesskommunikationMereologyDatabaseComputer architectureFunctional (mathematics)SequelStandard deviationCASE <Informatik>Cartesian coordinate systemVector spaceRight angleComputer animation
04:24
PressureNumberMethodenbankEuler anglesMessage passingPixelModal logicServer (computing)Insertion lossPressureCartesian coordinate systemMeasurementFunctional (mathematics)Computer animation
05:13
MethodenbankSystem on a chipMessage passingLibrary (computing)Message passingNetwork socketClient (computing)Connected spaceMethodenbankDebuggerCartesian coordinate systemEndliche ModelltheoriePresentation of a groupPassword
05:59
Chi-squared distributionWeightNetwork socketPressureMessage passingServer (computing)Library (computing)Client (computing)ClefSystem on a chipThread (computing)Serial portArchitectureDatabaseMereologyNumberField (computer science)Type theoryServer (computing)Web browserInternet der DingeGoodness of fitParameter (computer programming)Connected spaceMultiplication signIntegrated development environmentField (computer science)Thread (computing)Moment (mathematics)NumberSerial portMessage passingFunctional (mathematics)File formatMathematicsOrder (biology)PlastikkarteSoftwareMereologyFlash memoryVideo gameWhiteboardWordInformation securityGraph (mathematics)Traffic reportingBlackboard systemSemiconductor memory1 (number)
09:13
Annulus (mathematics)Message passingField (computer science)PressureDenial-of-service attackWeightMaxima and minimaEndliche ModelltheorieCartesian coordinate systemType theoryWeb 2.0Message passingKey (cryptography)ResultantSet (mathematics)ImplementationDecision theoryInformation securityParameter (computer programming)Queue (abstract data type)Variable (mathematics)Functional (mathematics)Thread (computing)Computer animationLecture/Conference
10:34
PressureWeightLine (geometry)Field (computer science)Euler anglesGoogolFermat's Last TheoremValue-added networkPhysical systemComputer animation
10:53
Data typeComputer programFormal languageCustomer relationship managementRead-only memoryFlash memoryCalculationRange (statistics)Wireless LANInsertion lossMetreDistanceMessage passingMobile appServer (computing)Event horizonRange (statistics)Software testingPoint (geometry)Order (biology)1 (number)Standard deviationTask (computing)Population densityConnected spaceEvent horizonWorkstation <Musikinstrument>WhiteboardCommunications protocolProduct (business)Client (computing)NumberCalculationBit rateInformationLaptopCondition numberIntegrated development environmentMetreInterprozesskommunikationCASE <Informatik>Different (Kate Ryan album)BefehlsprozessorScheduling (computing)Physical systemEndliche ModelltheorieMessage passingType theoryWireless LANGoodness of fitDesign by contractAreaMethodenbankQueue (abstract data type)Right angleWeb browserBookmark (World Wide Web)Mobile WebComputer animation
14:34
MIDIMessage passingLocal GroupServer (computing)Field (computer science)MethodenbankFunction (mathematics)Execution unitDenial-of-service attackEvent horizonMetropolitan area networkInformationEvent horizonFlow separationArea2 (number)Message passingDemo (music)DatabaseComputer animation
15:26
Server (computing)MassMessage passingEvent horizonMoment (mathematics)Type theoryReading (process)DistancePosition operatorLevel (video gaming)Water vaporConfiguration spaceTrigonometryCartesian coordinate systemEvent horizon1 (number)Integrated development environmentCASE <Informatik>Computer animation
15:56
Denial-of-service attackBookmark (World Wide Web)WeightMessage passingConfiguration spaceModal logicFluidIRIS-TGeometryComputer clusterRaw image formatDynamic random-access memoryPixelField (computer science)Amsterdam Ordnance DatumHTTP cookieDew pointCartesian coordinate systemNumberPixelGreen's functionComputer animation
17:15
Message passingConfiguration spaceServer (computing)Computer hardwareRight angleExtension (kinesiology)MereologyAreaCartesian coordinate systemCondition numberGroup actionFigurate numberField (computer science)FamilyConnected spaceProduct (business)MathematicsSoftwareComputer hardwareMessage passingGoodness of fitDirection (geometry)
18:31
MaizeComputerRed HatEstimationComputer animation
Transcript: English(auto-generated)
00:05
Okay, so let's welcome Joaquin Berenguer with a talk about Internet of Things. Thank you very much, good afternoon. I hope you like the presentation. We are going to talk, as he said, from Internet of Things that gives you a better idea of
00:25
what's going on there. Okay, we are in front of some big business in front of us. As you could see here, by 2020, more than 25 million apps are going to be there.
00:42
Well, it's difficult to have in four years so many applications, but okay, that's what they said. But in case that's not true, what is going to be true is that the revenue opportunity there is huge. And the gigabytes of data that are going to be managed is going to be huge as well.
01:00
As you could see here, the reports that all these sensors are going to send, to be stored, will be huge because the number of sensors around are going to be also huge. So new analytic engines are going to be needed because to give good feedback to the control, again, sensors send
01:25
bright information to the data source. In order to go ahead with this, I have implemented something regarding a server that manages those kinds of devices. We'll see the environment, the architecture, the server functionality, some security
01:42
that is needed, what type of IoT devices could be used here, what kind of access from mobile and desktop devices could be sent, and what are even alarms, sensors, and actuators, and what I think about the future about this. The environment is
02:01
Python 3.5.1. For the devices that are accessing the server, it's still not there, it's 3.4, but the server actually is based on threading and queues. They share nothing. They communicate with each other using queues.
02:23
The database being used is MySQL, and the MySQL connector comes from Oracle. And some personal links that are going to be used as well for MySQL and for managing USB or general functions. Everything is running in Ubuntu 16.
02:48
This is the architecture that is actually up and running. When any of these devices in this part are powered on, what they need to do is to register
03:02
themselves into the server. So they send a message to the server that, well, here I am, my name is that, or whatever, and if it is okay, if this is the right device registered in the MySQL database, then the reality server adapts a new thread for this device.
03:25
If not, the thread is terminated and is rejected the communication. So it's what any of these devices, it doesn't matter where they are using Wifi, it's what they need to do. We will see later what type of devices are those. On the other hand, Kivy, as is in the text that you
03:44
have already in the schedule, or Flask application, which is better, are using Socket.IO. That means we are going to, because we need a persistent connection, we are going to use Socket.IO WebSockets and any web browser that supports WebSockets is going to be valid.
04:05
So any of these devices are going to connect also to the MySQL database using username and password, and when that's done, they are ready to send messages to any of these devices below.
04:21
In order to have an idea of what's going on, we have here a small application that supports that, we have a small that, and then we have here, online, we have extracted what kind of devices are connected to the server. We could use this one, and we could
04:43
know all these kinds of functions that really are now a possibility to have in those devices. We could say, okay, we want to know temperature, pressure, humidity on that device. We send that to the server and give us what kind of measurement these
05:04
devices are having. So, this is the way that's happening. So we have connect using username and password, we have a persistent connection that will be valid for the rest of the
05:25
presentation, and all these devices are ready to answer any message that we are going to send. As I have said, the front end is a Flask plus Socket.IO. The messages to and from
05:41
modules are executed using this Socket.IO 1.4, and to send messages from the devices to the application, to the Flask application, we are using Socket.IO client in Python, as
06:01
we can see here. And how is this going? This is the part of the web browser. We define a number of messages for connection, for example, and this JavaScript is sent and at
06:24
the end of the day, what we are going to execute is a function in Python that receives the message, which is the message containing origin, destination, and what type of function we want to execute. And once it's in the
06:41
environment of Python, we execute everything what we want, just defining, naming of the message, and the name space. Inside the server, what we have is that every time a
07:05
server is waiting for connections from the IoT device, once one wants to be connected, what we start is a thread socket, a thread queue, and those are blocked, waiting for a message. They are doing nothing. In the
07:21
future, I think, I think I could be better. By the moment is running on threads, taking the kind of, those threads are corresponding to one customer, and every customer will have their own server. So this could be enough, but I think I will try to make it happen as well.
07:42
So the parameters to define a device at the end of the day is we need to know what kind of device, the ID of the device, the serial number, the server name, and the server port. With these five that are stored in each of the IoT devices, the first thing they are going to do is using
08:02
server name and port, connect to the port of that server, and the server using type of device, ID, and serial number will know if there is a good IoT device to be connected. Three types of devices are happening
08:21
here. We are going to have MKR1000 we see later, that will use flash memory, or EMCC with Blackbone, or SD card with Raspberry. The serial number by definition never is sent through the network in order to have
08:40
more security. We will see later how this is going to happen. And different server, the only thing that have is connect, change the port, and we will have another server useful for other devices that are going to be connected. Actually, the server name is probably using
09:01
this NoIP. The message format always have three fields that are mandatory, which is origin, destination, and message type, as we have seen here in the application. The origin is this web browser, destination is this connected module, and the type of message that
09:23
we want to send is this one. Okay, the rest of the depends on the message. We will add parameters on there that will have variable length, and we'll finish with EOT. Security is used using SHA-256. We are using
09:43
Haslib SHA-256 in Python, and in C implementation for MKR1000, because need to be in C, we are using Atmel documentation, and there is a SHA-256. And devices are grouped by customer, so only IOT devices
10:04
from one customer could talk with those around. So inside the server, what we have is origin thread that is sending to the key of the destination. From
10:21
the key of the destination goes to the device. The device executes the function and comes back with the result, who goes to the origin queue, and from there to the destination. We are sending from this
10:41
origin to the destination. We could read the gyroscope of that device, and then it's accumulating here what's going on. But the system is always the same, using queues and thread, and sending the message. So we're going to define two types of
11:02
devices. Low consumption, and we have here an example of a device. This is the size of this device. It's nearly nothing. And this is the battery that we could attach to this. And with this, we
11:21
could have it on your dress, and with that, you will have the possibility to do anything that you want, because you could connect this device to your phone as an access point, and from there goes the information to anywhere. So we have here wi-fi,
11:43
and we have a... Oh, okay. Right. So with this, we have low consumption. Two, three weeks we could have with this. We have a liposol. The
12:00
wi-fi range that these devices have is more or less the same as a laptop. If one laptop arrives to 100 meters, this could be the same or more. You have here the calculations if you like to have more information. The wi-fi mode, the normal thing is this is a client, a station,
12:22
but also could be used to have a range extension. These devices could be used as well as an access point, and that means that we could connect one with the other and extend the range, because we could resend the message to the following one. And these are the advanced modules that have
12:41
been used. So all of them are Linux-embedded, most of them are Debian, and these we are using here also a Python. Raspberry is about 45. We could use OpenCV. In this case, it's more because
13:01
the information or the recommendation is not good enough, and the contract you could have with Raspberry is not all limited permissions you have there. Median education is where we could apply it. PC doing is good for also has an Ubuntu inside, Ubuntu embedded board. We use
13:22
3.4 Python, and it's good for the ones who have already things done with Arduino. And for me, the favorite is this one, bigger one, green wireless. It's about 44. There is a lot of documentation, Texas instrument, CPU
13:41
with Debian or Ubuntu is the one you want, and it's good for inducing environments and also commercial products because you have any kind of protocols, communication, it's this one around here. The mobile and desktop devices,
14:01
the only thing that is needed is a web browser that support WebSocket, because we need, as I have said, a persistent connection. We have that using Flask and Shock.io. And that's alarms and events. So we need alarms from
14:22
the devices in order to send us directly messages if a temperature is above or below a number, but also we could schedule events that in our case will appear in the text area here below. We use this event, and we send this
14:42
message. What usually should happen is that the device is sending us events that will appear here downstairs in this area. So anything, any several seconds in this demo are going to be in
15:01
this text area downstairs, but also are registered in the database. So we are producing information from every one of the devices that we have in front of us, and they are producing information that we're going to analyze or treat in any matter. If we send the same event again, we stop sending us more events. And
15:26
that's the way how we generate alarms and events. Sensors, we can have seen here, any kind of sensors, it depends on you which ones, because it's above any kind of application, and
15:41
sensors could be used. In the case of actuators, what we name an actuator is everything that we have arrived from the device to the environment. As a matter of example, we could again go to the application and use, well, I have here also
16:03
this camera that is, this is a raspberry you see is about five or six centimeters by six centimeters, and we have here 64, let's say, LEDs or lamps or whatever, because the only thing we want to do is write there, we could
16:21
write pixel, we say okay, we want to write pixel number, I don't know, 26, and we send the, and here we have, we have the, the color, we could say okay, blue or whatever.
16:41
And when we have sent this pixel, the pixel number, whatever we have said is on, we could send letters, or we could send messages as well. So any kind of possibilities are on
17:01
top of what, in green or, so this is what we could do with the, with writing, and any kind of send a message that writes goes
17:20
in that direction. In the future, again, software is the most important, either C or Python extension of Python using C is, and many applications going to develop around these. Products like, products like Sivoli or from LogIn, LogMain, ThinkSpeak, or
17:42
Azure from Microsoft are good examples of what's going on in this area. Hardware will continue to integrate more parts of the application, decreasing price and size. Wearables are there, and we have seen them. And the industry will take advantage as well of substituting the actual solutions that are in the market.
18:05
Okay, that's, that's all. Thank you. Does anyone have any questions? Okay,
18:21
so if nobody has a question, then let's hear. In the GitHub, Joaquin.BB, you have the condition from here. Thank you, and goodbye.