Thing+ IOT Smart Greenhouse Project in Japan — A Practical Overview Featuring Temperature & Humidity Sensing

Leland Creswell from Daliworks
10 min readFeb 19, 2018

--

Ryan Kim, in the field at our Smart Farm project

Edit: Technical details on this solution can also be seen on our website “Use Cases” section here.

Hello all.

Today I want to introduce to you a Smart Farm pilot project that we have recently completed in Japan. It was focused on digitalizing a complex of greenhouses, bringing their physical parameters, previously not being consistently recorded, into a digital representation to help improve the productivity of the farm, as well as to reduce costs and improve their security.

This project was accomplished using Thing+, our IOT cloud platform, and could be easily customized, white-labeled and deployed by anyone with a greenhouse, or any SI or ICT company serving customers in the greenhouse agricultural field. If you have interest in doing so, please do get in touch with our team.

Designing the Solution

The first step towards the project was getting in touch with a partner of ours working in Japan who had expertise in the agriculture vertical — specifically greenhouses. Together with them, over the course of a few weeks, we outlined the requirements of a specific customer and what IOT hardware could be used to collect the necessary data, while overcoming the range and penetration challenges.

The project called for reading temperature and humidity data from 6 different points inside of the greenhouse every 15 minutes, as well as tracking the status of each greenhouse door — whether it was open or closed at any point in time.

Identical greenhouses using the same heat/ventilation config, yet still seeing ~8–10 degree differences

Temperature and humidity readings are critical to determine if heating/cooling curves in each greenhouse are optimal or not. The greenhouses that this project are aimed towards are currently doing manual checks of temperature/humidity from time to time to set initial seasonal/time of day-based heating and ventilation. However, throughout the day, the environment continuously changes, including not just weather (clouds, heat/cold spikes throughout the day) but also the actual amount of light getting into the greenhouse. Add to that the fact that conditions change from month to month (greenhouse getting dirty, people forgetting to close the greenhouse doors, small holes/tears in the walls, etc..) and it is easy to see why you would want to have continuous data collection.

Unattended greenhouses are a great target for thieves

Status on whether doors were open or closed was also deemed an important part of the project due to the incidence of robberies where entire greenhouses full of watermelons or other high-value produce were stripped bare by thieves. Installing and paying for a traditional security solution (cctv/etc..) is quite expensive and so instead of this, simply checking when doors are open/closed could be used to automatically set alarms and improve the security of the greenhouses, in addition to catching problems with people leaving doors open.

With a constant stream of data on temp/humidity across six specific parts of each greenhouse, a large amount of money can be saved on heating and ventilation costs, not to mention the savings in labor along with productivity gains, firstly through manual alarms and analysis, and then later, through automation. Security would also be improved by simple indication of the current door status, which could be checked by the operator/owner at all times of the day, as well as via automated alarm.

One might ask, “Isn’t this already being done by greenhouses?”. We thought that too, but between the hardware issues, as well as the cost of traditional industry-standard systems & software being so incredibly high, a majority of the market does not have any form of continuous data collection currently installed.

Solution Software, Application & Backend

On the application/software side, the greenhouse operator/owner of course needed a method to actually monitor the data coming in, receive alarms based on out of range data, and a way to analyze that data.

Towards the interface needs, we took the Thing+ UI as a base and made a few specific customizations inline with the requests of our partner.

Our default dashboard — includes a mapping widget, but is not focused on it

The main requirement was to move from a dashboard consisting of data widgets, to a dashboard focused around a map representation of the farm.

The default dashboard, using a map visualization as the focus instead (prototype UI)

There was an additional need to have a very focused “drill down” for each greenhouse, that would show the sensor data, along with the 24 hour data movement, all in a single view. While this can also be done using our default UI, there were specific layout requests from the greenhouse owner.

A “drilldown” for a single greenhouse, showing all the critical data in a single view (prototype)

Alarms for temperature and humidity data going out of bounds was set using the normal Thing+ rules engine. For critical events, such as doors being opened at strange times, direct SMS messages were used as the form of alarm. For less critical events, alarms went directly to the timeline of the farm, where the alerts would immediately notify the operator that something out of range had occurred.

On the backend side, data transfer and storage needed to be rock solid and so the Amazon AWS Japan cluster was used. Thing+ by default is based on Amazon AWS, so it was also used here for compute, data transfer and storage.

Finally, since LoRaWAN was used, we required a network server for the project — in particular, one that could be scaled up. For this purpose, we went with LorIOT’s LoRaWAN network server solution. LorIOT have shown the ability to scale up and work with very large commercial projects in the past, so we felt confident going into things that if the project turned out to be well received, we could continue the momentum forward to a large commercial deployment.

Solution Hardware

To start with, due to the greenhouse complex being spread over a fairly large area (maximum range required ~ 600 m), and multiple small buildings being in the way, we needed something that had long range with good penetration of walls/buildings. For this, we chose to go with a LoRaWAN based solution.

There are many alternatives that could have been used, including some proprietary systems, but in this case, we wanted to avoid any issues with vendor lock-in, as well as access to a large ecosystem of devices in case new sensors/automation options were requested by the partner in the future. It helps that we are also a member of the LoRa Alliance. ;)

RisingHF Outdoor Gateway

The gateway used was a RHF2S008 from RisingHF. The gateway is designed for outdoor use, with the maintenance requirements being quite low. We are hoping to see this sit outside for years without needing any attention. Power was through a POE (power over ethernet) connection, though it was a bit of a pain to get it installed due to the long POE cable required.

On the sensor side, we used RisingHF’s own temperature and humidity sensors as they are UV protected and are resistant to the typical conditions you see inside of a greenhouse.

Finally, we *were* going to use the TABS door and window sensors from Tracknet for checking to see if doors were open or closed at different times of the day. However, and as you will see below in our “installation journey”, these sensors were not suitable for the greenhouse doors, and so we will be updating the project to use PIR motion sensors inside the greenhouse instead… this article will be updated at that time when we have the new hardware out in the field. :)

An Overview

Finally, Tata sim cards were used in the RisingHF gateway to provide the 3g backhaul necessary to get data collected from the sensors out to the Thing+ cloud.

Solution Development & Journey

The first step to actually getting the solution out to the field, tested, and successful was to do initial testing of the RisingHF and Tracknet devices here at our office in Seoul to ensure they were capable of reliably transmitting data in the manner we expected.

The devices are usually tested at the factory and sent directly, but since this is new hardware for us, we did testing at the office as well.

Testing at the office went without major problems for the RisingHF equipment. However, for the Tracknet door sensors, we encountered some small issues that, as previously mentioned, prevented us from being able to actually install them on-site at the greenhouses.

Too bad. :(

After testing, verifying and binding the equipment at our office, a few of our team flew out to Japan in order to get everything installed and put together correctly. As this was the first project we did using this equipment, we wanted to do some of our own testing in the field to reference for future partners, so we sent the best.

The greenhouses are built together into rows of six greenhouses per block

Once getting to the site, it was quite cold. However, once getting inside, it’s unbelievable how different the environment is.

A typical mid-day temperature inside the greenhouse

The gateway (RisingHF RHF2S008 for reference) was set in a central, elevated location. With the maximum required range being only ~600 meters, things went as we planned and connectivity was excellent from gateway to the furthest sensor device.

RisingHF gateway installed at high elevation

Inside each greenhouse, we then installed the temperature and humidity sensors.

And finally, after everything was installed, we verified that the data was coming in correctly through matching manual temperature and humidity readings with what we saw via the dashboard.

Within the first day, together with our partner, we immediately saw issues with the heating and ventilation systems. Some readings over 50 celcius (!!) were being recorded in some parts of a few greenhouses, with the average in most of them being over 40 C. Seeing that the optimum growth temperature was around 32 C, the amount of waste was truly astounding, and quite a shock to the owner of the complex as well.

The process to modify the seasonal settings and timings of the heating and ventilation system was immediately begun and it’s hoped that problems like this will be continuously surfaced and resolved due to the availability of data.

Outcome & Next Steps

Monitoring and analysis of the data by the farm operator and partner over the coming months should uncover more areas where efficiency and processes can be improved. With the data being continuously collected and available later on for analysis, all that is required is to plug the optimum numbers in, and see where the real-world values are not matching up.

This is an example of problems that can easily be seen when collecting data continuously — poor plants

In addition to the immediate changes made to the heating and ventilation systems, uncovered pretty much before we had even left to head back to Korea, the watering schedule and other farm-specific processes will continuously be optimized to try to fit what is optimal vs what is *actually happening* in the field.

Alarms and rules in testing

Alarms are in place for unexpected swings in temperature & humidity, and for now, unexpected events will be handled directly by the greenhouse operator. However, automation of the heating and ventilation systems is already in the works — be sure to check back here later for coverage of that process.

Reaction to the project’s initial effects was extremely positive and we have already had a request to roll in CO2 and solar radiation tracking to the solution which I hope to share with you in a future article that expands on this article.

We intend to roll this out on a larger commercial scale in Japan *soon* after CO2 and Solar radiation has been added and tested. Seeing as how important these two variables are for growing crops, we, along with our partners in Japan, are very excited to get this sort of data monitoring and analysis actually out there, at low cost, without any of the restrictions that greenhouses have been previously grappling with.

Conclusion and Parting Words

In the past, it has been very expensive to set up a fully wireless system capable of tracking important data inside of a greenhouse environment. Applications and solutions made by major industrial players in the field are, and continue to be, proprietary and extremely expensive. However, with the advent of long range, open source options such as LoRaWAN, getting data out of the physical world and digitized is simple and very inexpensive.

Thing+ has been designed out of the gate to support this sort of hardware and use case, providing the application, backbone and software pieces of the puzzle that are needed to create something that can be used by a business out in the real world. We support full white-labeling out of the box and are interested in working with partners to create shared success, instead of trying to shove expensive proprietary systems down your throat.

Come check us out. :)

And finally, please feel free to leave a response here and engage.

-Leland

--

--

Leland Creswell from Daliworks

Writing about our projects and the things our team learns in the field of IOT.