 OK, zato povedaj, Hakeem Berengar, z njegovosti o internetnih vse. 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. OK, we are in front of some big business in front of us. You could see here, 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 OK, 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 against 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 even alarm sensors and actuators and what I think about the future about this. Environment is Python 351 for the devices that are accessing the server, it's not there, it's 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 lives that are going to be used as well for MySQL and for managing USB or general functions. Everything is running in Ubuntu 16. This 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, whatever. If this is okay, if this is a right device, register it in MySQL database, and then the day I get the server adapts a new thread for this device. If not, the thread is terminated and is rejected in 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, Kivi as is in the text that you have already in the schedule in the task 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 web sockets and any web browser that supports web sockets 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 and we could know all these kind of functions that really are now a possibility to have in those devices. We could say, OK, we want to know temperature pressure or 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 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 front end is a flash application as socket.io. The messages and to and from modules are executed using this socket.io 1.4. And to send messages from the devices to the application, to the flash application we are using socket.io client in Python. As we can see here. And how is this going? In 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, and what type of function we want to execute. And once it's in the environment of Python we execute everything that we want. Just defining the naming of the message and the naming space. Inside the server what we have is that every time a server is waiting for connections from the IoT device once to be connected 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 now 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. With 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 will 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 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 no IP. The message format always have three fields that mandatory, which is origin, destination and message type as we have seen here in the application. The origin is this web browser, destination is disconnected module and the type of message that we want to send is this one. The rest of the fields that depends on the message, we will have parameters on there in variable length and we will finish with EOT. Security is used using SHA256. We are using Haslip SHA256 in Python and in C implementation for MKR1000, because need to be in C we are using Atmel documentation and there is SHA256. Devices are grouped by customer. So only IOT devices from one customer could talk with those around. So inside the server what we have is an origin thread that is sending to the key of the destination. From the key of the destination goes to the device, the device execute the function and come back with the results, who goes to the origin queue and from there to the destination. We could again send the we are sending this from this origin to the destination we want to have well, we could read 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 queues and thread and sending the message. So we are going to define devices, low consumption and we have here example of device. This is the size of this device is nearly nothing and this is the battery that we could attach to this and with this we could have we 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 here we have here wifi and we have oh, okay. Right, so with this we have low consumption, 2-3 weeks we could have with this, we have a lipo a lipo so. The wifi range that these devices have is more or less the same as a laptop. In 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 wifi most normal thing is this is a client, a station but also could be used to have a range extension used as well as an access point and that mean 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 most of them are Debian and these we using here also a Python. Raspberry B is about 45 we could use OpenCV in this case is more because the information or documentation is not good enough and the contract you could have with Raspberry is not all limited permissions you have there, media and education is where we could apply it. PCDuin is good for also has Ubuntu inside, Ubuntu embedded board we use 3.4 Python and is good for the ones who have already things done with Arduino and for me the favor is this one, big or long green wireless is about 44 there is a lot of documentation Texas instrument CPU with Debian or Ubuntu is the one you want and is good for inducing environments and also commercial products because you have any kind of protocols communication is 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 ShockDio and that's alarms and events so 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 below we use this event and we send this message what usually should happen is that the device is sending us events that will appear here downstairs in this area so any several seconds in this demo are going to be in 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 are going to analyze or treat in any manner if we send the same event again we stop sending us more events and 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 sensors could be used in the case of actuators what we name an actuator is everything that we have is applied from the device to the environment as a matter of example we could again go to the application and use also this camera that this is a raspberry you see is about 5 or 6 cm by 6 cm and we have here 64 let's say leds or lamps because the only thing we want to do is provide there we could write pixel we say ok we want to write pixel number 26 and we send and here we have we have the color we could say ok blue or whatever and when we have send this pixel pixel number whatever we have said is on letters or we could send messages as well so any kind of possibilities are on top of what in green or so this is what we could do with writing and any kind of send a message that writes goes in that direction in the future again software is the most important or python extension of python using c is and many applications going to develop around this products products like civilly or from log in log main think speak or 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 ok that's all thank you does anyone have any question ok so if nobody has a question then let's thank you again here in kidscap.bb you have the condition from here thank you and goodbye