Cellular IoT Irrigation System for oneM2M + Nordic Thingy:91

Introduction

In the following tutorial, we will be showing how to use oneM2M, the Thingy:91 provided by Nordic Semiconductors, and cellular IoT to create a cellular smart irrigation system.

This will involve using the Nordic Thingy:91's humidity, temperature, and GPS sensors as well as external soil moisture and rainfall trigger sensors, and using oneM2M send this information to the oneM2M CSE or ACME using the cellular capabilities of the device. Data processing will be done to determine the most efficient watering amounts and that will be transmitted to an actuator program on another Thingy:91 that will turn on and off the control valves of the irrigation system accordingly. All of this and configurable user settings will be displayed on a webpage dashboard application.

oneM2M API Overview

To communicate between the ACME server, the dashboard AE, the calculator AE, and the Thingy:91 sensor and actuator AEs, we used the oneM2M API.

At the center of our oneM2M standards-based system is the ACME common services entity (CSE), where all information is managed and utilized as necessary. All REST API requests from AEs are sent to the ACME CSE where the requests are processed. The ACME will then send back the necessary response in normal REST API fashion.

To implement communication between all our devices and other resources, we create an application entity (AE) for each object on the ACME CSE. We then implement the necessary resources under each AE, such as containers, subscriptions, polling channels, content instances, etc. We make sure to add labels to each respective content and resources such that the resources of each device can be easier understood by other AEs in the oneM2M system.

For example, content instances from both Thingy:91 sensors and actuators will be labeled with their resource name path in the oneM2M resource tree so the dashboard (which subscribes to the respective containers) can determine where the information came from and display as necessary.

Additionally, the labels of any sensor AE are updated by the dashboard to include any actuators that they are linked to so that the data processing application can determine which actuators need to be updated whenever new data arrives on the CSE.

Each of the data processing, dashboard, or Thingy:91 programs include sample functions for sending oneM2M primitives to communicate to a CSE as well as how to parse the response.

Software Setup

Setting up the oneM2M ACME CSE

This project was developed and tested using version 0.9.1 of the ACME CSE. The first step for setting up the CSE is to host it on an Amazon Web Services (AWS) EC2 Instance. First, you must create an AWS account.

Create an AWS account here

The account creation process will require you to input your debit or credit card information. The first 750 hours of using your EC2 instance will be free, after that you will be charged. After you create your account, navigate to the AWS Management Console. Under the “Build a Solution” section, choose “Launch a virtual machine with EC2” as seen below.

Then, select the “Ubuntu Server 20.04 LTS (HVM), SSD Volume Type” (64-bit x86 version) from the Amazon Machine Image (AMI) list.

Now, choose the only option available for the free tier, as seen below.

Make sure to click “Next: Configure Instance Details” instead of “Review and Launch”. You still need to open the ports that you intend to use for the CSE! You can skip any modifications for “Step 3: Configure Instance Details, ” “Step 4: Add Storage, ” and “Step 5: Add Tags” parts of the creation process and proceed to the next step. In “Step 6: Configure Security Group, ” you need to add the ports that you will be using for the CSE. We opened ports 80 and 8080 as seen below. Port 22 is, by default, open.

We did not specify a source, which would allow anyone to access the CSE. However, if you are worried about allowing all IP addresses to access your instance, you can specify several IP addresses in the source field. Now, you can click on “Review and Launch.” When launching, you will be prompted to create a new key pair to allow you to connect securely to you instance via SSH, for example. Choose a name and download the key. Warning: after you download it, you will not be able to download the key after it has been created! Keep the.pem file in a safe place on your computer in case you want to ever SSH into the instance. Now, you should be on the “Launch Status” page. Click on the “view instances” button to look at the newly created instance. Now, you should see the instance.

You can hover over the “-“ under the name field and click to name your instance. Next, from the toolbar on the left, click on “Elastic IPs” under the “Network & Security” section. We need to assign an elastic IP to the instance in case you ever decide to stop the instance from running. AWS changes the IP address when you rerun an instance. However, using an elastic IP will prevent that from happening.

When you navigate to the “Elastic IPs” page, click on the “Allocate Elastic IP address” button on the top right. You do not need to modify any option on this page. Now, click on the “Allocate” button on the bottom right. Click on your newly created elastic IP address under the “Allocated IPv4 address” column. You should be redirected to next page. Click on the “Associate Elastic IP address” button as seen below.

Now, choose your instance from the dropdown list and click on “Associate” as seen below.

Now, you have created an EC2 Instance and associated it with an elastic IP address. The next step is to access your instance. Click on “Instances” from the “Instances” section of the toolbar on the left.

Click on the ID of your newly created instance under the “Instance ID” column. You should see the following page now.

Click on the “Connect” button as seen above to access the command line of your instance. You can also access the command line using SSH and the key you’ve created in the previous steps! Click on the “Connect” button to access your instance’s command line, or, if you prefer to SSH into your instance, click on the “SSH client” tab and follow the instructions to do so.

Now, you can clone the ACME oneM2M CSE into the newly created instance. We developed and tested this system using ACME v0.9.1. Before running your CSE, first install the required packages by running the following command:

python3 -m pip install -r requirements.txt

If that doesn’t work, you can install the packages individually using the following command:

python3 -m pip install cbor2 flask isodate paho-mqtt requests rich tinydb

Now, you need to copy the configuration file “acme.ini.default” to a new file “acme.ini” to make any adjustments to the configuration. Do not modify the “acme.ini.default” file. Perform this action using the command below:

cp acme.ini.default acme.ini

Now, edit the “acme.ini” file to set your CSE’s IP address. Choosing the editor of your choice, modify the “cseHost” field under the “IN Configuration” section to be the elastic IP associated with your AWS EC2 instance. If you chose to use a different port than 8080, then also modify the “httpPort” field to reflect that.

Now, the next step is to move into the “init” folder of the CSE. Modify the file “acp.createACP.json” to change the “chty” field to be from [1] to [1, 23]. This will allow the dashboard and the data processing applications to subscribe to the CSE base in order to receive notifications for when a new child gets created or deleted under the CSE base. So, your “acp.createACP.json” file should look as follows:

Now, we would like to keep the CSE open and always working, so we can take advantage of tmux commands to do so. Create a new tmux session by running the following command:

tmux new -s cse

This would create a tmux session with the name “cse”. Now, you can run your CSE with the following command:

python3 -m acme

Now, your CSE is up and running. You can access the CSE webUI by pasting <cseHost>:<httpPort> on your web browser. To leave your CSE running in the background, just close your SSH session window or the AWS command line window. Do not type “^C” or “exit” in the command line. “^C” will stop the CSE from running and “exit” will terminate the tmux session. If you ever want to go back to access this session, connect to your instance again and run the following command:

tmux attach-session -t cse

This will attach you back to your session and show you the CSE logs on the command line. Again, if you are done, just close the SSH session window or the command line window, do not type “^C” or exit. Congratulations! Now, you have a CSE that runs 24/7.

Setting up the Dashboard Application

The first step to setting up your dashboard application is to create an AWS EC2 instance. Follow the same steps for creating an instance for the CSE to create another for the instance to hold this application. In the “Step 6: Configure Security Group” section of the instance creation, make sure to open port 8050. This is the port that will be used to access the dashboard on a browser. You still need to keep port 8080, or whatever port you choose, open. This is needed for the HTTP server to handle subscription notifications.

Move the dashboard folder from the GitHub to this instance. Before running the dashboard application, you must set your dashboard configurations. Modify the “dashCfg.cfg” file by adding this instance’s elastic IP under the “appIP” field, the opened port (8080 or whichever one you prefer as long as it’s not 8050) of this instance under the “appPort” field, the elastic IP of the CSE EC2 instance under the “cseIP” field, the cse port (default is 8080) under the “csePort” field as shown below.

This dashboard also uses a map from the mapbox studio. First, sign up for mapbox. After verifying your email, you should be redirected to the page below. Copy the default public token and paste it under the “mapboxToken” field in the “dashCdg.cfg” file.

This dashboard uses the Lè Shine map design from the mapbox gallery. First, add the map to your account’s mapbox studio. Then, click on the 3 dots on the top left and copy the map link from there as show below and paste it under the “mapboxMapLink” field in the “dashCfg.cfg” file.

The last step before running the application is to download all the required packages. To do, run the following command:

pip3 install dash dash_daq pandas

Now, the dashboard application is ready to run. If you intend to keep it always open, you can follow the same process done for the CSE (using tmux). To run the dashboard application, you run the following command:

python3 app.py -c dashCfg.cfg

The dashboard application should be running now. You can access it from your web browser by going to <appIP (elastic IP)>:8050.

How the Dashboard Application Works

When the dashboard application first runs, it registers itself with the CSE as an AE, creates an ACP to allow notifications from other resources, and creates a subscription under the CSE base to get notified of any sensors and actuators that get registered or deregistered. The dashboard application has two tabs. The first tab, as shown below, displays a device’s sensor data.

From the dropdown list, you can select a Thingy:91 acting as a sensor and its sensor values will be displayed. When this tab first loads, the application sends a discovery resource to retrieve all the AEs acting as sensors. Then, the dropdown list gets populated. Once a device is selected from the dropdown list, the application will subscribe to the AEs containers if it hasn’t done so yet, populate the graphs, and obtains the latest values all sensors by sending a GET request to each container.

The second tab, as shown below, allows for sensor and actuator control.

On the left panel, you can link a sensor with an actuator. The purpose of linking a sensor with an actuator would be for automatic irrigation. The data processing will monitor all sensor devices and decide when to commence the watering process. Thus, linking a sensor with an actuator is required to establish correspondence. The dropdown lists here populate in the same way as the on in the previous tab does. When an actuator and sensor are chosen and linked, the application will send a GET request to obtain both AEs. Then, the name of the actuator will be appended to the label of the sensor AE by sending a PUT request to the sensor AE. The name of the sensor will be appended to the label of the actuator AE in a similar manner.

The top panel gives the user control over the frequency at which a sensor collects and sends data. When a sensor device is selected from the dropdown list and the values are submitted, the application will create content instances under each container below the settings container that is a child resource of that sensor.

The bottom panel allows the user to manually control a valve. When an actuator is selected, a user can engage manual override. This disables any automatic irrigation functionality. When this mode is engaged, the application creates a content instancewith a value “10” under the “requestedState” container of the actuator AE. The first bit signifies whether manual override is on or off. Under this mode, the user can manually turn on or off the valve.

When a user decides to turn on the valve, the application creates a content instance with a value “11” under the “requestedState” container of the actuator AE. If a valve is turned off, the application creates a content instance with a value “10” under the “requestedState” container of the actuator AE. This panel also allows the user to monitor the state of the control valve. This indicator updates in a similar way to the rainfall trigger indicator in the first tab, subscribing to the “actuatorState” container of the actuator AE.

Setting up the Data Processing Application

To start uploading the Data Processing program, create an AWS ec2 instance as previously described in the CSE section. In the “Step 6: Configure Security Group” section of the instance creation, make sure to open port 8000. This is needed for the app to communicate with the CSE and the HTTP server to handle subscription notifications.

Download the dataProcessing folder from the GitHub, there are a few configuration settings to change.

The appIP and appPort should be changed according to the AWS instance settings, and the csePort and cseID should be changed based on the settings of the ACME CSE section.

Once this is done, connect to the instance as described earlier and upload the dataProcessing.py file.

Then run the command “python3 dataProcessing.py” and the application will have started. Close the session without killing the process.

Below is a State Diagram of the data processing program.

It will create itself as an AE on the CSE and set up a subscription to be notified of creations that happen at the CSE base. Once it receives a notification of a sensor AE creation, it will subscribe to that AE. It will then be notified of creations under the AE and subscribe to CNTs. Once it receives notifications of new CINs being created under the containers, it will retrieve all the sensor data from these CNTs and calculate a new valve state.

The program then parses the label of the sensor AE it received the CIN from to determine which actuators the new state needs to be sent to. The program will retrieve the latest requested state for those actuators to ensure we are not in manual control mode from the dashboard. If we are in automatic mode for that actuator, it will then send the new state to the requested state container. This process repeats every time the program receives a notification of new CINs being created under a sensor AE.

Hardware Setup

Setting up the Development Environment for the Thingy:91

Now that the cloud server and processing application have been installed and are running, it is time to start using the hardware.

The first step in setting up the Thingy:91 is to download and set up the necessary applications, as well as download firmware and modem update files and update the Thingy:91.

We will want to use the MCUboot method to update the Thingy:91. Nordic provides a very straightforward guide on how to do both processes, as well as flashing a precompiled ‘asset tracker’ application and activating the SIM card that comes with your Thingy:91.

One thing that isn’t super clear is which of the three types of firmware files to use – you should use the “img_fota_dfu_hex” ones with MCUboot. If you receive errors stating ‘the device is not in MCUboot mode” – just power it off and retry entering MCUboot, it can be finicky at times. Note that there has been a UI change for nRF Connect for desktop, but the functionality is identical to previous versions.

Nordic Thingy:91 (nordicsemi.com)

There is also a video to follow along with: Getting Started Thingy:91 Video

The nRF52840 is one of two chips on the Thingy:91, along with the nRF9160. Generally speaking, programs and modem updates are flashed to the nRF9160 while the connectivity bridge firmware is flashed to the nRF52840.

After following Nordic's guides, you should have uploaded a firmware file to the nRF52840, a firmware file to the nRF9160, and a modem firmware file to the nRF9160 through the programmer app on the nRF Connect for Desktop application. After this, you should have activated an nRF Cloud account, the included SIM card, and seen the data from the Thingy:91 appear on the nRF Cloud website.

At this point, we will set up to develop and upload our own custom oneM2M programs to the Thingy:91.

Your nRF Connect for desktop app will look something like this below:

We want to go ahead and install the “LTE Link Monitor” and “Toolchain Manager” applications. The “Programmer” application should be already installed as part of the earlier setup guide from Nordic.

Also download and install VSCode: VSCode Website

Once these finish, open the “Toolchain Manager” app. You will see multiple nRF Connect SDK versions, pick the latest version, and click install. Our team used up to version 1.7.1.

Once these finish installing, click the button “Open VS Code”. The Toolchain Manager will then check if you have the required extensions. It will look similar to this, though there may not be any installed when first opened:

Go ahead and install the missing extensions and launch VSCode.

Nordic includes a video playlist on how to work with VSCode and their applications. It’s worth watching if you want to go further and start developing on the Thingy:91:

nRF Connect VSCode Tutorials Playlist

The main page of VSCode will look something like this, we want to select the nRF Connect Extension:

You’re now ready to begin uploading custom programs to the Thingy:91. You can now jump to whichever program you would like to upload, the sensor or the actuator program.

After this, if you are interested in developing for or learning more about the Thingy:91 feel free to look at the great Nordic Infocenter (Prototyping Platforms in Directory, where Thingy:91 and Thingy:91 Getting Started has a lot of info on device) as well as the Nordic Devzone.

Flashing and using the Sensor Program

This section covers how to upload the oneM2M_sensor program

Configure and flash the sensor program

To upload the sensor program to the Thingy:91, first download the “sensor_oneM2M” folder from the GitHub in the code section. Go to the nRF Connection extension for VSCode (last step of general hardware setup), and click the Add application” option under the Applications tab.

Navigate to where the sensor_oneM2M folder is and select that folder.

You may have to specify where the nRF Connect SDK and Toolchain are located, if so, do this as shown below:

(Substitute paths for the paths on your computer)

After this you will see it added under applications, with a message under it saying, “No build configurations”. Mouse over the application name and click the “build configuration” button:

The Add Build Configuration screen will come up, all necessary options should autopopulate. (Note that this program is only compatible with the Thingy:91, so that is the only available board option).

Hit the “Build Configuration” Button:

Once this finishes, navigate under the “sensor_oneM2M” build tab

>Source files>Application>src>main.c and open main.c

There are a few configuration settings to set before uploading the software to theThingy:91.

The HTTP_PORT and SERVER_ADDR4 options should be set to the port and address of your oneM2M CSE instance (which was created earlier in the article). Optionally, if you are not using the rain sensor or soil moisture sensor you can disable their use by setting them to ‘false’ instead of true. The cseID and cseName should be set to the CSE you are using, if you did not modify this on the ACME then you can leave them as is.

The deviceName can be changed to personalize the device – this is necessary if you are going to use multiple sensors. The originator MUST be C + the deviceName by convention, as shown above.

Finally, we are ready to upload the program to the Thingy:91! Click the pristine build button under the Actions tab:

Note that VSCode may report errors in main.c when first opening it. You can usually ignore these and build the project where they will go away. If the problem persists you can usually close the workspace and reopen the application to resolve it.

To upload the program, we will use the MCUboot method; however, the external debug probe and nrf9160dk method is also available for those who have the hardware.

Go to the “programmer” app for nRF Connect for desktop and turn on the Thingy:91 in MCUboot mode.

Connect to the device and select the ‘add hex file’ and ‘browse’ option. Browse to your sensor_oneM2M folder, then go into build>zephyr and select the app_signed.hex file. The file will populate on the file memory layout section

Then select ‘Write’ and ensure it successfully writes to the Thingy:91. You can now turn it off.

This next section describes how to attach the external Rainfall and Soil Moisture sensors to the device, if you are not using this feel free to skip past it.

Refer to the Sensor Circuit Diagram under Schematics and circuit diagrams for how the devices should be wired.

A textual description is that: The red wire of the rain sensor should go to 1.8V source on the Thingy:91, and the black wire should go to Test Point 33 just below the central switch 3. The red and black wires of the soil moisture sensor should go to 1.8V source and ground respectively, while the yellow (Analog out) one is connected to Test Point 32 - just above switch 3.

It will look similar to below:

After flashing the program and optionally wiring the external sensors, open the LTE Link Monitor Application. Turn off the Thingy:91 and turn it back on (in regular mode, not MCUboot mode).

You will see the device become available in the LTE Link Monitor and can connect to it to see the terminal output from the program. A green LED will turn on when the device is finished initializing and starting to connect to the oneM2M CSE. (This LED could turn off and back on when first connecting to the CSE, be patient since it takes a while depending on cellular reception strength).

You can now go to the website and connect to the sensor to see the data it is sending and set user settings! At this point if you are not interested in how the program works, feel free to skip to the actuator section or mess around with the website.

Here’s some sample terminal output showing the device sending data to the oneM2M CSE:

How the Sensor Program works

For those interested in how the sensor program operates, here is a state diagram of the program:

The ‘Init’ state involves setting up device libraries such LTE network, GPS and ADC devices, etc.

The ‘Retrieve oneM2M ACP/AE’ state involves retrieving an Application Entity and its Access Control Policy in case it already exists. If it does not, it is created. Similarly, the ‘Retrieve oneM2M CNTs and its ACP’ state retrieves the sensor containers and their ACP if they exist. If not, these are created as well. The GPS is started at this point and searches for a fix on a background work thread, so that the main program can run and take over the radio when LTE functionality is required.

The main loop is where the program spends most of the time. Here, the user settings are retrieved from the oneM2M CSE and the internal temperature and humidity sensors, and external soil moisture sensor are sampled and averaged based on user settings. Then the rainfall trigger sensor is read, and GPS information is retrieved. After this the content instances are sent to the oneM2M CSE, and the device will wait a certain specified time before continuing the loop. It is during this wait that the GPS is unblocked and searching for a fix, so setting the transmit period user setting very short will mean it will take a very long time to find a GPS fix.

Below is a diagram detailing the oneM2M structure of the sensor program:

There is an Access control policy that grants access to the Application Entity itself, and then there is an ACP that grants access to the containers under the AE. The program sends Content Instances to each of these individual containers, which are stored and retrieved by the website to display as well as by the data processing application to determine actuator states.

The Settings Container’s Sub-containers hold the values for different user settings for the sensor program. numAverages determines how many readings will be taken from the soil moisture, humidity, and temperature sensors and averaged together, where a value of 1 means no averaging occurs. The samplePeriod setting controls how long to wait between sensor readings (when numAverages is greater than 1 and we are actually averaging). Finally, the transmitPeriod setting controls how often to send this data to the CSE. These settings can help to limit the data and power usage of the sensor program when it is being deployed.

A planned upgrade to this application is to use one or more <flexContainer> oneM2M resources that can be more efficient by having these settings available as custom attributes of the device.

Flashing and using the Actuator Program

This section covers how to upload the oneM2M actuator program and it's functionality.

Configure and flash the actuator program

To upload the sensor program to the Thingy:91, first download the “actuator_oneM2M” folder from the GitHub code section. Go to the nRF Connection extension for VSCode (last step of general hardware setup), and click the Add application” option under the Applications tab.

Navigate to and select actuator_oneM2M folder.

You may have to specify where the nRF Connect SDK and Toolchain are located, if so, do this as shown below:

(Substitute paths for the paths on your computer)

After this you will see it added under applications, with a message under it saying, “No build configurations”. Mouse over the application name and click the “build configuration” button:

The Add Build Configuration screen will come up, all necessary options should autopopulate. (Note that this program is only compatible with the Thingy:91, so that is the only available board option).

Hit the “Build Configuration” Button:

Once this finishes, navigate under the “actuator_oneM2M” build tab

>Source files>Application>src>main.c and open main.c

There are a few configuration settings to set before uploading the software to theThingy:91.

The HTTP_PORT and SERVER_ADDR4 options should be set to the port and address of your ACME CSE instance (which was created earlier in the article). The cseID and cseName should be set to the CSE you are using, if you did not modify this on the ACME then you can leave them as is.

The deviceName can be changed to personalize the device – this is necessary if you are going to use multiple sensors. The originator MUST be C + the deviceName by convention, as shown above.

Finally, we are ready to upload the program to the Thingy:91! Click the pristine build button under the Actions tab:

Note that VSCode may report errors in main.c when first opening it. You can usually ignore these and build the project where they will go away. If the problem persists you can usually close the workspace and reopen the application to resolve it.

To upload the program, we will use the MCUboot method; however, the external debug probe and nrf9160dk method is also available for those who have the hardware.

Go to the “programmer” app for nRF Connect for desktop and turn on the Thingy:91 in MCUboot mode.

Connect to the device and select the ‘add hex file’ and ‘browse’ option. Browse to your actuator_oneM2M folder, then go into build>zephyr and select the app_signed.hex file. The file will populate on the file memory layout section.

Then select ‘Write’ and ensure it successfully writes to the Thingy:91.

After this, open the LTE Link Monitor Application. Turn off the Thingy:91 and turn it back on (in regular mode, not MCUboot mode).

You will see the device become available in the LTE Link Monitor and can connect to it to see the terminal output from the program.

You can now go to the website and connect to the actuator and send manual actuator states!

Here’s some sample terminal output showing the device sending data to the ACME CSE. This specifically shows the code retrieving an actuator state of 1 from the PCH and setting the Test Point to 1.8 V as such. It also shows the start of creating a content instance in actuatorState.

This next section describes how to wire the circuit for the actuator, connecting the valve and the transformer through a relay so that the valve can be turned on or off. For now, we are temporarily using an Arduino that takes the voltage output from the Thingy, and then outputs the voltage at a more ideal current.

Please note: Due to the low current from the Thingy:91 output, we could not successfully find a circuit to activate the relay without using the Arduino Uno. When we find a more viable circuit, the circuit will be updated here.

Refer to the Actuator Circuit Diagram under Schematics and circuit diagrams for how the devices should be wired.

To upload the relay activation program to the Arduino, first connect the Arduino to the computer. Then, open the relayActivation.ino file from the GitHub in the Arduino IDE and select the board "Arduino Uno" and the correct COM port.

Then click the arrow button to upload it to the Arduino, once it finishes you can disconnect the Arduino and power it with a 9V battery for portability. It will look similar to below when the circuit is completed:

You are all done setting up and uploading the code to the Thingy:91 for the actuator! If you would like to learn more about the code functionality, please refer to the next section.

How the Actuator Program works

Here is a state diagram of the actuator program.

The ‘Init’ state, similar to the sensor program initializes the LTE connection and adp356x for outputting voltage.

Next, the code will try and retrieve an AE. If the AE is successfully retrieved, there is no need to initialize anything internally within the AE. If the AE does not exist, then we want to initialize the ACP for the AE, the AE, the ACP for containers, containers (CNT), and a subscription as well as a polling channel. Refer to the diagram below for the basic structure of actuator AEs and their trees.

The two containers under the AE are requestedState and valveState. CNT requestedState is used as a container for receiving what the requested valve state should be. We originally just simply retrieved this, but to better emulate a true subscription and notification system, we implemented a subscription under requestedState as well as a polling channel that will be used to essentially help the actuator device act as a http server without the power constraints.

After doing this, the code enters the mainLoop, where the main functionality of the programs exists. We start by calling to retrieve through the polling channel. The polling channel will send the first instance of a new CIN sent while it Is “polling” or send nothing if it times out. In the case of timing out, the actuator stays the same. Else, the actuator updates the state, changes the output voltage, and updates the most recent CIN in valve State. Since we are trying to mimic a server as much as possible, we do not wait a given period of time between retrieves as to keep the code running the polling channel as much as possible. The purpose of the valveState is to show that the actuator received a new state as well as make sure the dashboard can see the state of the water valve.

More On Polling Channels:

Due to the fact that the actuator is running on a cellular IoT device, we cannot run a full http server. This is due to the fact that http servers are power and data heavy. Additionally, LTE connectivity leads to changing IP addresses and ports, so creating a server would be difficult. To deal with such a problem, we used polling channels in oneM2M. Polling channels allow for us to send a retrieve that either sends back a notification from a previously created subscription or is empty if there are no notifications. If we can keep the uptime of the polling channel as a higher percentage of a main loop, we get closer and closer to implementing something close to a http server simulation.

Conclusion

After following this guide, you should have uploaded the ACME CSE, Dashboard, and Data Processing application to AWS instances, uploaded the relay activation program to the Arduino, and uploaded the sensor and actuator programs to the Nordic Thingy:91 as well as completed wiring their respective circuits.

You now have a smart IoT and cellular based irrigation system that can detect changes in air temperature and humidity, rainfall, GPS, and soil moisture to automatically determine whether to turn on or off watering. All of this with a cellular product with a battery that can be placed anywhere with cell reception and work remotely!