 Hello, everybody. I am Quen from Vietnam. So I come here to share my experience about applying open source software to build our mushroom farm, IoT mushroom farm. And this one is not for only mushroom farm because later on we expand it to other fields as well, like in Hero Ponech farm and Perth house. So this is about me for you to know. So I come here for a year for a long time and I contribute to some open source software projects. And now I am working at Reconnect startup from Vietnam. The guy before me, I think he already do very good in introducing how useful IoT mushroom farm can do. So I don't need to repeat again. So I will skip this part. Now, different from his setup, my system consists of the activator, the sensor node and the gateway. Here we don't use any cloud server because we build server ourselves and not only it correct the environment condition but we also use to control the bump the plant to moderate the condition in the farm. And the gateway is also play the role of local server because we build our farm in play with very poor internet connection. So we need the local server to control the farm automatically without the internet. So that if the internet go down, the system still can run. So this is some image from what we build. We put some sensor next to the mushroom. And here are the humidity fear. We use this to control the humidity in the farm because the mushroom needs a lot of humidity. And we also give it some light. So now here the software start. We build the software with Python and Django. And it's in the form of a web app so that we can accept it via browser in any devices like in the PC or in mobile phone. And for the database, at first we use Postgres to store the sensor data but later on we change to InfructDB because the data is time-seried. Other data like farm like user, we still use PostgresQL. And this software running in a Linux computer, we need some software to integrate it to the operating system. Like for ARM Linux, we need the device G overlay and to manage the services, we use system D. And we separate, this is how the architecture of the software is. So we separate each to three modules. Module control view is for web UI and for displaying. The collector module to collect the data from the sensor and the module control center is to control the activator like Bum and Fun. And we also need to periodically pack up the database so that when something bad happens we can recover the database. The database is uploaded to gandesh disk. We use gandesh disk because it is free. And to improve the speed of the software we also need to rebuild the Postgres in test. This is the UI of our software, the control software. So this is moved by view. This is the cloud. This is already our photo. Now we change the display bit. Here is the UI for controlling. And here we set up for the system to run automatically. So when the temperature goes high it will base on this setup and control the fan to make the temperature go in the range we want. So here are four conditions that we control for the mushroom. And later on when we expand to hierophonic and put how we add more conditions here. So this is how we accept the system via internet because we are not only in the farm. And as you know that our system runs locally in the farm. So we need a way to accept from internet. Our first method is to use VBN. So our software running here. And we are here in a different network. So we set up it with a public server to build a VBN network. This green line. So that our laptop and all the local server in our farm are in the same local network. This is the software that we try to build a VBN. So at first we try how much but then we stop it because the windows client is very unstable. One member of our team he use windows so we also need to support windows. And the second one that we try is sub ether VBN. And now we use the wide guard. Very new VBN solution in videos. And this is the second method that we do forwarding on router. I think this method is very well done. So I don't need to go deeper. So this is the challenges we face when we build our system. So the first challenge is about the hardware. So the first challenge about the hardware because we use a big robot embedded computer. So here do you know the Raspberry Pi? And we use the big robot instead of Raspberry Pi because of the internal memory. The big robot doesn't use SD card. So it's more stable when stored database. And so we connect directly the ball with our devices like the bomb and the farm. So we have to show the problem of hardware connection. So here we are GBIO. We connect to the GBIO port of the ball and we require root permission to control on that port. And our software needs to run in normal user. So we have to do some check to able to control the GBIO port. Other issue is about the nature of multi function of big robot bin. So one bin can this time it's GBIO or that time it can be BWM. And so we have to apply some specific solution about embedded computer to control this bin. And other issue is that the buildable doesn't have RTC clock. So every time it started the time in the machine chain and not correct. So we need internet. Sometimes we need the ball to be connected with internet to update the time. There is also some problem with the software inside like the DNS. So if the DNS not working the time also wrong. And we have to fix the software also. About the database issue. As first we store the sensor data in normal schema of database. And because it produce a lot of data. So every day it write more than 80,000 records to the database. So time by time we found that our system run very slow on big robot. And we at first we try to diagnose to see what is the wrong point in our database setup. And we found some SQL operation that's slow. And we apply some index to fix it. But because the data is very big so we don't index on the whole database. But we only index on recent record. And we need to regularly rebuild the index. So that is keep the old data and only build index for the most recent data. And after that we change to another database solution. We apply in frontdb and we move on the sensor data from watch press to in frontdb. In frontdb is more specific about time series database. So it provides some future. Some good future to act on this kind of data. Like it have the future to automatically summary old data. Like at first we collect data for every 10 seconds. But with this future we will now sampling old data to 10 minutes. When we try in frontdb for a time we compare with our own solution with watch press SQL and we found out for the speed is the same as our solution of indexing. But the in frontdb day by day consumes a lot of RAM. And so now in our machine the process the in frontdb process it takes its own mod be the mod here be in the machine. And now we are thinking about change another solution. We recently found time scale DB is the extension on the process create and is the focus about time series database. But we haven't had a chance to try it because it doesn't support ARM now. Because our deployment to the customer one we have a system running on ARM on buildable and other farm we deploy on mini PC. For mini PC it's easy to set up time scale DB but for ARM for buildable there is still not the ARM buildable time scale DB yes so we haven't tried it. Okay now my talk is finished now. Do you have any question? SST for the temperature and for the carbon dioxide we change a lot. Now recently we use the mmhz17. No that one is for carbon dioxide for the temperature we still use SST. And for humidity the SST is measure both temperature and humidity. And for soil temperature I forgot the name but most of the sensor we buy from the F robot. Yeah the distributor.