Server for IoT devices and Mobile devices using Wifi Network
Berenguer, Joaquin
Joaquin Berenguer - Server for IoT devices and Mobile devices using Wifi Network, The server is developed in Python 3.4, using MySQL5.6 The mobile device application is developed using Kivy. The application in the IoT device is developed in C. The IoT device is a hardware device using ATSAMD21 from Atmel, and wifi is made using ESP8266. The security used is sha256, standard in Python. And the IoT device using the crypto device ATECC508A, that generate also sha256. - The server is developed in Python 3.4, the information is stored in a MySQL 5.6 database. All IoT devices, Mobile Devices and Windows or Linux Desktop are registered in the database. All type of messages that are understood by every type of device, is also registered. A map between which device could access which device is also stored in the database. With this info, any mobile registered could send a message to a device. The message arrives to the server that resend the message to the IoT device, receive the answer and resend to the Mobile device. The Mobile device and the IoT device, could be anywhere, as the server is public, have the registration of every device connected. The mobile device application is developed using Kivy. The application in the IoT device is developed in C. The IoT device is a hardware device using ATSAMD21 from Atmel, and wifi is made using ESP8266. The security used is sha256, standard in Python. And the IoT device using the crypto device ATECC508A, that generate also sha256. The server start a thread for every device connected, the communication between thread is made using queues. During the presentation, the server is going to be presented, and IoT device is shown, no demo is going to be made. A library to manage the database, is used for easy access to the database, and have database independence, also will be shown. Prerequites: Python 3.4, sha256, threading, queue, mysql.connector, relational database.
 Okay, so let's welcome Hakim Berengar with a talk about Internet of Things. Yeah. 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 what's going on there. Okay. We are in front of some big business in front of us. As you could see here, more, by 2020, more than 25 million apps is going to be there. 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 decimage of data that are going to be managed is going to be huge as well. 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 reflect the good feedback to the control, again, sensors send right information to the data source. In order to go ahead with this, I have implemented something regarding a server that manages those kind of devices. We'll see the environment, the architecture, the server functionality, some security 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 events, alarms, sensors, and actuators and what I think about the future about this? Environment is Python 351 for the devices that are accessing the server is, you know, there is 3.4, but the server actually is based on threading and queues. They share nothing. They communicate each other using queues. The database being used is MySQL and MySQL connector comes from Oracle and some personal leaves that are going to be used as well for MySQL and for managing USB or general functions. They actually, everything is running in Ubuntu 16. 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 themselves into the server. So they send a message to the server, well, here I am. My name is that or whatever. If this is okay, if this is a right device registered in MySQL database, then the day I get the server adapts a new thread for this device. If not, the thread is terminated and it is rejected, the communication. So is what any of these devices, it doesn't matter where they are using Wi-Fi, is what they need to do. We will see later what kind of devices are those. On the other hand, Kiwi as is in the text that you 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. So any of these devices are going to connect also to the MySQL database using a password. When that's done, they are ready to send messages to any of these devices below. 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. We could know all these kind 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 to the server and give us what kind of measurement these devices is having it. So this is the way that's happening. So we have connected using your user and password. We have a persistent connection that will be valid for the rest of the presentation and all these devices are ready to answer any message that we are going to send. As I have said, the frontend is a Flask, Flask.io. The messages and from modules are executed using this Flask.io 1.4. To send messages from the devices to the application, to the Flask application, we are using Flask.io client in Python. As we 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 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 environment of Python, okay, we execute everything that we want. Just defining naming of the message and the name space. And by the server, what we have is that every time a server is waiting for connections from the IoT device, once we connect it, what we start is a thread socket, a thread queue, and those are blocked waiting for the message. They are doing nothing. In the future, I think I think I could be better by the moment is running on threads, taking into account that 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. So the parameters to define a device at the end of the day is we need to know what kind of device, the idea of the device, the serial number, the server name, and the server port. These five that are stored in each of the IoT devices, the first thing they are going to do is using 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 here. We are going to have MkR1000, we see later, that we'll use flash memory or EMCC with black bone or SD card with raspberry. The serial number by definition is never sent through the network in order to have more security. We will see later how this is going to happen. In different servers, the only thing that we 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 disnoic pay. The message format always has three fields of mandatory, which is origin, destination, a 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 we want to send is this one. The rest of the fields depends on the message. We will have parameters on there that will have variable length and we'll finish with IoT. IoT is using SHA256. We are using Haslip SHA256 in Python and in C implementation for MkR1000 because it needs to be in C, we are using AdMail documentation and there is SHA256. Devices are grouped by customer. Again, IoT devices from one customer could talk with those around. Inside the server, what we have is an origin thread that is sending to the key or the destination. From the key or the destination goes to the device. The device executes the function and comes back with the results. Who goes to the origin key and from there to the destination. We are sending this from this origin to the destination. We want to have, well, we could read the gyroscope of the device and then it's accumulating here what's going on. But the system is always the same. Using Qs and threads and sending the message. We are going to define two types of devices. Low consumption and we have here, for example, device. This is the size of this device. It's nearly nothing. This is the battery that we could attach to this. With this, we could have it on your device 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. We have here Wi-Fi and we have, oh, okay. Right. So with this, we have low consumption. Two, three weeks we could have with this. We have a lipo. A lipo so. The 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. That's, you have here the calculations if you like to have more information. The Wi-Fi most, the normal thing is this is a client, a station, 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. These are the advanced modules that have been used. So all of them are Linux embedded. One of them are Debian and these we are, we're using here also a Python. Raspberrybee is about 45. We could use OpenCV. In this case it's more because the information or the commendation is not good enough and the contract you could have with Raspberrybee is not all limited permissions you have there. Media and education is where we could apply. This is good for, also has an Ubuntu inside, Ubuntu embedded board. We use 3.4 Python and it's good for the ones who have already things done with Arduino. For me the favor is this one, Big O'Bong Green Wireless. It's about 44. There is a lot of documentation, Texas Instruments CPU with Debian or Ubuntu is the one you want and this is good for industrial environments and also commercial products because you have any kind of protocols, communication. It's this one here. The mobile and desktop devices, the only thing that is needed is that a web browser that supports WebSocket because we need, as I have said, a persistent connection. We have that using Flask and Shokita Yo. That's alarms and events. We need alarms from 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 these messages 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 this text area downstairs but also are registered in the database. We are producing information from every one of the devices that we have in front of us and they are producing information that we are going to analyze or treat in any manner. If we send the same event again, we stop sending us more events. That's the way how we generate alarms and events. Actuators, we can see here any kind of sensors, it depends on you, which ones because it's above any kind of application and 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 this camera that is, this is a Raspberry UC 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 drive there. We could write pixel, we say okay, we want to write pixel number, I know, 26 and we send it and here we have the color. We could say okay, blue or whatever. When we have sent this pixel, pixel number, whatever we have sent is on, we could send letters or we could send messages as well. Any kind of possibilities are on top of what, green or... This is what we could do with writing and any kind of message that writes goes in that direction. In the future, again, software is the most important, either C or Python extension of Python using C and many applications are going to develop around this. Products like Civili or from Login, ThinkSpeak or 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. The industry will take advantage of substituting the actual solutions that are in the market. That's all. Thank you. Does anyone have any questions? If nobody has a question, then let's thank you again. Thank you and goodbye.
 Okay, so let's welcome Hakim Berengar with a talk about Internet of Things.  Yeah.  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  what's going on there.  Okay.  We are in front of some big business in front of us.  As you could see here, more, by 2020, more than 25 million apps is going to be there.  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 decimage of data that are going to be managed is going to be huge as well.  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 reflect the good feedback to the  control, again, sensors send right information to the data source.  In order to go ahead with this, I have implemented something regarding a server that manages those  kind of devices.  We'll see the environment, the architecture, the server functionality, some security 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 events,  alarms, sensors, and actuators and what I think about the future about this?  Environment is Python 351 for the devices that are accessing the server is, you know,  there is 3.4, but the server actually is based on threading and queues.  They share nothing.  They communicate each other using queues.  The database being used is MySQL and MySQL connector comes from Oracle and some personal  leaves that are going to be used as well for MySQL and for managing USB or general functions.  They actually, everything is running in Ubuntu 16.  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  themselves into the server.  So they send a message to the server, well, here I am.  My name is that or whatever.  If this is okay, if this is a right device registered in MySQL database, then the day  I get the server adapts a new thread for this device.  If not, the thread is terminated and it is rejected, the communication.  So is what any of these devices, it doesn't matter where they are using Wi-Fi, is what  they need to do.  We will see later what kind of devices are those.  On the other hand, Kiwi as is in the text that you 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.  So any of these devices are going to connect also to the MySQL database using a password.  When that's done, they are ready to send messages to any of these devices below.  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.  We could know all these kind 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 to the server and give us what kind of measurement these devices is having it.  So this is the way that's happening.  So we have connected using your user and password.  We have a persistent connection that will be valid for the rest of the presentation and  all these devices are ready to answer any message that we are going to send.  As I have said, the frontend is a Flask, Flask.io.  The messages and from modules are executed using this Flask.io 1.4.  To send messages from the devices to the application, to the Flask application, we are using Flask.io  client in Python.  As we 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 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 environment of Python, okay, we execute everything that we want.  Just defining naming of the message and the name space.  And by the server, what we have is that every time a server is waiting for connections from  the IoT device, once we connect it, what we start is a thread socket, a thread queue,  and those are blocked waiting for the message.  They are doing nothing.  In the future, I think I think I could be better by the moment is running on threads,  taking into account that 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.  So the parameters to define a device at the end of the day is we need to know what kind  of device, the idea of the device, the serial number, the server name, and the server port.  These five that are stored in each of the IoT devices, the first thing they are going  to do is using 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 here.  We are going to have MkR1000, we see later, that we'll use flash memory or EMCC with black  bone or SD card with raspberry.  The serial number by definition is never sent through the network in order to have more  security.  We will see later how this is going to happen.  In different servers, the only thing that we 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 disnoic pay.  The message format always has three fields of mandatory, which is origin, destination,  a 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 we want to send is this one.  The rest of the fields depends on the message.  We will have parameters on there that will have variable length and we'll finish with  IoT.  IoT is using SHA256.  We are using Haslip SHA256 in Python and in C implementation for MkR1000 because it  needs to be in C, we are using AdMail documentation and there is SHA256.  Devices are grouped by customer.  Again, IoT devices from one customer could talk with those around.  Inside the server, what we have is an origin thread that is sending to the key or the  destination.  From the key or the destination goes to the device.  The device executes the function and comes back with the results.  Who goes to the origin key and from there to the destination.  We are sending this from this origin to the destination.  We want to have, well, we could read the gyroscope of the device and then it's accumulating here  what's going on.  But the system is always the same.  Using Qs and threads and sending the message.  We are going to define two types of devices.  Low consumption and we have here, for example, device.  This is the size of this device.  It's nearly nothing.  This is the battery that we could attach to this.  With this, we could have it on your device 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.  We have here Wi-Fi and we have, oh, okay.  Right.  So with this, we have low consumption.  Two, three weeks we could have with this.  We have a lipo.  A lipo so.  The 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.  That's, you have here the calculations if you like to have more information.  The Wi-Fi most, the normal thing is this is a client, a station, 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.  These are the advanced modules that have been used.  So all of them are Linux embedded.  One of them are Debian and these we are, we're using here also a Python.  Raspberrybee is about 45.  We could use OpenCV.  In this case it's more because the information or the commendation is not good enough and  the contract you could have with Raspberrybee is not all limited permissions you have there.  Media and education is where we could apply.  This is good for, also has an Ubuntu inside, Ubuntu embedded board.  We use 3.4 Python and it's good for the ones who have already things done with Arduino.  For me the favor is this one, Big O'Bong Green Wireless.  It's about 44.  There is a lot of documentation, Texas Instruments CPU with Debian or Ubuntu is the one you  want and this is good for industrial environments and also commercial products because you have  any kind of protocols, communication.  It's this one here.  The mobile and desktop devices, the only thing that is needed is that a web browser that  supports WebSocket because we need, as I have said, a persistent connection.  We have that using Flask and Shokita Yo.  That's alarms and events.  We need alarms from 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 these messages 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 this text area downstairs  but also are registered in the database.  We are producing information from every one of the devices that we have in front of us  and they are producing information that we are going to analyze or treat in any manner.  If we send the same event again, we stop sending us more events.  That's the way how we generate alarms and events.  Actuators, we can see here any kind of sensors, it depends on you, which ones because it's  above any kind of application and 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 this camera that is, this is a Raspberry UC 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 drive there.  We could write pixel, we say okay, we want to write pixel number, I know, 26 and we send  it and here we have the color.  We could say okay, blue or whatever.  When we have sent this pixel, pixel number, whatever we have sent is on, we could send  letters or we could send messages as well.  Any kind of possibilities are on top of what, green or...  This is what we could do with writing and any kind of message that writes goes in that  direction.  In the future, again, software is the most important, either C or Python extension of  Python using C and many applications are going to develop around this.  Products like Civili or from Login, ThinkSpeak or 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.  The industry will take advantage of substituting the actual solutions that are in the market.  That's all.  Thank you.  Does anyone have any questions?  If nobody has a question, then let's thank you again.  Thank you and goodbye.
Joaquin_Berenguer_-_Server_for_IoT_devices_and_Mobile_devices_using_Wifi_Network__0_2291.png Joaquin_Berenguer_-_Server_for_IoT_devices_and_Mobile_devices_using_Wifi_Network__2292_3203.png Joaquin_Berenguer_-_Server_for_IoT_devices_and_Mobile_devices_using_Wifi_Network__3204_4175.png Joaquin_Berenguer_-_Server_for_IoT_devices_and_Mobile_devices_using_Wifi_Network__4176_8987.png Joaquin_Berenguer_-_Server_for_IoT_devices_and_Mobile_devices_using_Wifi_Network__8988_10463.png Joaquin_Berenguer_-_Server_for_IoT_devices_and_Mobile_devices_using_Wifi_Network__10464_13835.png Joaquin_Berenguer_-_Server_for_IoT_devices_and_Mobile_devices_using_Wifi_Network__13836_14135.png Joaquin_Berenguer_-_Server_for_IoT_devices_and_Mobile_devices_using_Wifi_Network__14136_14519.png Joaquin_Berenguer_-_Server_for_IoT_devices_and_Mobile_devices_using_Wifi_Network__14520_15227.png Joaquin_Berenguer_-_Server_for_IoT_devices_and_Mobile_devices_using_Wifi_Network__15228_16475.png Joaquin_Berenguer_-_Server_for_IoT_devices_and_Mobile_devices_using_Wifi_Network__16476_18959.png Joaquin_Berenguer_-_Server_for_IoT_devices_and_Mobile_devices_using_Wifi_Network__18960_20927.png Joaquin_Berenguer_-_Server_for_IoT_devices_and_Mobile_devices_using_Wifi_Network__20928_23903.png Joaquin_Berenguer_-_Server_for_IoT_devices_and_Mobile_devices_using_Wifi_Network__23904_24059.png Joaquin_Berenguer_-_Server_for_IoT_devices_and_Mobile_devices_using_Wifi_Network__24060_25871.png Joaquin_Berenguer_-_Server_for_IoT_devices_and_Mobile_devices_using_Wifi_Network__25872_27215.png Joaquin_Berenguer_-_Server_for_IoT_devices_and_Mobile_devices_using_Wifi_Network__27216_27467.png Joaquin_Berenguer_-_Server_for_IoT_devices_and_Mobile_devices_using_Wifi_Network__27468_28011.png
Okay, so let's welcome Hakim Berengar with a talk about Internet of Things. Yeah. 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 what's going on there. Okay. We are in front of some big business in front of us. As you could see here, more, by 2020, more than 25 million apps is going to be there. 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 decimage of data that are going to be managed is going to be huge as well. 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 reflect the good feedback to the control, again, sensors send right information to the data source. In order to go ahead with this, I have implemented something regarding a server that manages those kind of devices. We'll see the environment, the architecture, the server functionality, some security 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 events, alarms, sensors, and actuators and what I think about the future about this? Environment is Python 351 for the devices that are accessing the server is, you know, there is 3.4, but the server actually is based on threading and queues. They share nothing. They communicate each other using queues. The database being used is MySQL and MySQL connector comes from Oracle and some personal leaves that are going to be used as well for MySQL and for managing USB or general functions. They actually, everything is running in Ubuntu 16. 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 themselves into the server. So they send a message to the server, well, here I am. My name is that or whatever. If this is okay, if this is a right device registered in MySQL database, then the day I get the server adapts a new thread for this device. If not, the thread is terminated and it is rejected, the communication. So is what any of these devices, it doesn't matter where they are using Wi-Fi, is what they need to do. We will see later what kind of devices are those. On the other hand, Kiwi as is in the text that you 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. So any of these devices are going to connect also to the MySQL database using a password. When that's done, they are ready to send messages to any of these devices below. 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. We could know all these kind 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 to the server and give us what kind of measurement these devices is having it. So this is the way that's happening. So we have connected using your user and password. We have a persistent connection that will be valid for the rest of the presentation and all these devices are ready to answer any message that we are going to send. As I have said, the frontend is a Flask, Flask.io. The messages and from modules are executed using this Flask.io 1.4. To send messages from the devices to the application, to the Flask application, we are using Flask.io client in Python. As we 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 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 environment of Python, okay, we execute everything that we want. Just defining naming of the message and the name space. And by the server, what we have is that every time a server is waiting for connections from the IoT device, once we connect it, what we start is a thread socket, a thread queue, and those are blocked waiting for the message. They are doing nothing. In the future, I think I think I could be better by the moment is running on threads, taking into account that 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. So the parameters to define a device at the end of the day is we need to know what kind of device, the idea of the device, the serial number, the server name, and the server port. These five that are stored in each of the IoT devices, the first thing they are going to do is using 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 here. We are going to have MkR1000, we see later, that we'll use flash memory or EMCC with black bone or SD card with raspberry. The serial number by definition is never sent through the network in order to have more security. We will see later how this is going to happen. In different servers, the only thing that we 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 disnoic pay. The message format always has three fields of mandatory, which is origin, destination, a 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 we want to send is this one. The rest of the fields depends on the message. We will have parameters on there that will have variable length and we'll finish with IoT. IoT is using SHA256. We are using Haslip SHA256 in Python and in C implementation for MkR1000 because it needs to be in C, we are using AdMail documentation and there is SHA256. Devices are grouped by customer. Again, IoT devices from one customer could talk with those around. Inside the server, what we have is an origin thread that is sending to the key or the destination. From the key or the destination goes to the device. The device executes the function and comes back with the results. Who goes to the origin key and from there to the destination. We are sending this from this origin to the destination. We want to have, well, we could read the gyroscope of the device and then it's accumulating here what's going on. But the system is always the same. Using Qs and threads and sending the message. We are going to define two types of devices. Low consumption and we have here, for example, device. This is the size of this device. It's nearly nothing. This is the battery that we could attach to this. With this, we could have it on your device 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. We have here Wi-Fi and we have, oh, okay. Right. So with this, we have low consumption. Two, three weeks we could have with this. We have a lipo. A lipo so. The 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. That's, you have here the calculations if you like to have more information. The Wi-Fi most, the normal thing is this is a client, a station, 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. These are the advanced modules that have been used. So all of them are Linux embedded. One of them are Debian and these we are, we're using here also a Python. Raspberrybee is about 45. We could use OpenCV. In this case it's more because the information or the commendation is not good enough and the contract you could have with Raspberrybee is not all limited permissions you have there. Media and education is where we could apply. This is good for, also has an Ubuntu inside, Ubuntu embedded board. We use 3.4 Python and it's good for the ones who have already things done with Arduino. For me the favor is this one, Big O'Bong Green Wireless. It's about 44. There is a lot of documentation, Texas Instruments CPU with Debian or Ubuntu is the one you want and this is good for industrial environments and also commercial products because you have any kind of protocols, communication. It's this one here. The mobile and desktop devices, the only thing that is needed is that a web browser that supports WebSocket because we need, as I have said, a persistent connection. We have that using Flask and Shokita Yo. That's alarms and events. We need alarms from 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 these messages 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 this text area downstairs but also are registered in the database. We are producing information from every one of the devices that we have in front of us and they are producing information that we are going to analyze or treat in any manner. If we send the same event again, we stop sending us more events. That's the way how we generate alarms and events. Actuators, we can see here any kind of sensors, it depends on you, which ones because it's above any kind of application and 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 this camera that is, this is a Raspberry UC 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 drive there. We could write pixel, we say okay, we want to write pixel number, I know, 26 and we send it and here we have the color. We could say okay, blue or whatever. When we have sent this pixel, pixel number, whatever we have sent is on, we could send letters or we could send messages as well. Any kind of possibilities are on top of what, green or... This is what we could do with writing and any kind of message that writes goes in that direction. In the future, again, software is the most important, either C or Python extension of Python using C and many applications are going to develop around this. Products like Civili or from Login, ThinkSpeak or 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. The industry will take advantage of substituting the actual solutions that are in the market. That's all. Thank you. Does anyone have any questions? If nobody has a question, then let's thank you again. Thank you and goodbye.
huge. And the decimage of data that are going to sensors are going to send to be stored will be security that is needed. What type of IoT devices could be used here? What kind of access from communicate each other using queues. The database a right device registered in MySQL database, then it is rejected, the communication. So is what any devices are connected to the server. We could use for the rest of the presentation and all these devices are ready to answer any message that we application, to the Flask application, we are the message, which is the message containing that every time a server is waiting for connections from the IoT device, once we connect it, what we start is a thread socket, a thread Haslip SHA256 in Python and in C implementation Devices are grouped by customer. Again, IoT battery that we could attach to this. With this, the information to anywhere. We have here Wi-Fi could resend the message to the following one. It's this one here. The mobile and desktop area downstairs but also are registered in the could send letters or we could send messages as