Build Intelligent IoT Gateway in a Few Easy Steps
Intelligent IoT Gateway is the core pillar of enterprise Internet of Things (IoT) architecture because it enables real time decision-making at the edge, secures downstream devices and optimizes network utilization. In this lab, you’ll learn how to build the Intelligent IoT Gateway with open source software in a few simple steps.
This Gateway can be implemented on a physical hardware (x84 64 bit) or a virtual machine running RHEL 7.2. The main components of the Gateway are:
Red Hat Enterprise Linux to provide Enterprise class foundation
JBOSS Fuse to transform sensor data and route it to end points
JBOSS BRMS to enable real-time decision making at the edge
JBOSS A-MQ to arbitrate sensor data
The task of configuring the gateway system including installing required software is automated through Ansible. Once the Gateway is provisioned, we’ll put it into action by starting JBOSS Fuse, building & deploying the pre-built routing and business rules services. We’ll then start sensor app that sends temperature data using MQTT to the JBOSS A-MQ broker. These messages will be forwarded to the services that we started earlier. Finally, we’ll be creating the business rules to trigger desired action when the sensor value reaches a threshold.
Host System: Ansible
Gateway: Download JBOSS Fuse 6.2.1 from the Red Hat Customer Portal and save it in the Downloads folder
Step 1 - Prepare the system using Ansible
We’ll use the automation tool Ansible to remotely provision our Gateway system by installing required components.
Open a terminal and enter the following commands:
[user@localhost ~]$ git clone -b Virtual-Lab-1-Host https://github.com/RedHat-IoT/Virtual_IoT_Gateway.git
Update the host file [Virtual-IoT-Gateway/Ansible/host] with IP address of the Gateway and place the public key of the host on the remote Gateway (Ansible uses ssh to communicate with remote system). You can learn how to setup Ansible here.
Note: For the Gateway, we’re using username = 'demo-user' and password = 'change12_me'.
Update the Ansible playbook BuildGW file [Virtual-IoT-Gateway/Ansible/BuildGW] for the username for your gateway: set_fact: user='user name'
Launch the Ansible playbook by entering the following commands:
[user@localhost ~]$ cd Virtual_IoT_Gateway/Ansible [user@localhost ~]$ ansible-playbook BuildGW
Let the Ansible run through the tasks in the playbook. Once Ansible is finished, we’re ready to start work directly on the Gateway
Step 2 - Login to the Gateway
username = 'demo-user' password = 'change12_me'
Step 3 - Start JBoss Fuse Server
Open a new shell and enter the following commands:
[demo-user@localhost ~]$ cd [demo-user@localhost ~]$ cd IoT_Summit_Lab [demo-user@iotlab IoT_Summit_Lab]$ ./runJBossFuse.sh
Wait for the Red Hat JBoss Fuse to complete the start procedure
Red Hat JBoss Fuse needs to install the 'camel-mqtt' OSGi features to process MQTT messages.
Enter the following simple command on the 'JBossFuse' command prompt
JBossFuse:karaf@root> features:install camel-mqtt
Minimize this shell to keep JBOSS Fuse server running in the background
Step 4 - Build and Deploy Camel Route
The sensor data will be transformed and routed by a camel route provided in this project. Now we need to build the Red Hat JBoss Fuse project and deploy it to our running JBoss Fuse server. We’ll use the provided script to build and deploy the project.
In a terminal, perform the following commands
[demo-user@iotlab Software_Sensor]$ cd [demo-user@iotlab ~]$ cd IoT_Summit_Lab/ [demo-user@iotlab IoT_Summit_Lab]$ ./runRoutingService.sh
We can verify that the Camel route has been deployed by logging into JBOSS Fuse admin cosole see details
Step 5 - Create Business Rules
One of the important functions of Intelligent IoT Gateway is trigger action if the sensor data meets certain condition defined by business rules. In this section we’ll learn how to create business rules service. This service will work the following way:
Sensor data is read from a Message queue
Sensor data is handed over to the rules execution engine that triggers action per defined rules
Altered data is placed into another defined Message queue
We’ll use MS Excel based decision table to define the business rules. The following image shows an example of a Decision Table where each row represents a rule. The blue columns are 'conditions' and the yellow column define an 'action'.
Rules syntax is pretty simple: If some condition then some action
The rules system is capable of reading the rules from a spreadsheet and compile them into rules in the above syntax. For this lab, sample business rule spreadsheet is provided that can be used to create new rules.
The columns in this table represent the following:
Alerting Rule: Name of the rule. It is optional field but very useful for debugging
Device Type: Type of device reported by the sensor
Payload: Number-range this rule will need to match with
Result: Action triggered by the rule i.e. changing value to 0 or 1
Open the sample rules spreadsheet: 'DecisionTable.xls'
Create two rules by filling in the following information
Rule 1: If we get a temperature reading between 0 and 60, change the result field to 0
Rule 2: If we get a temperature reading between 61 and 100, change the result field to 1
Note: In the 2nd rule Payload, add a space between “61,” and “100”
Note: Save the spreadsheet in MS Excel format
The details on the Business Rules Service are here
Step 6: Build and Run the Business Rules Service
Now that we have added a few rules to our decision table, we need to build a new version of the service and start it.
Enter the following commands in a terminal
[demo-user@localhost IoT_Summit_Lab]$ cd [demo-user@localhost ~]$ cd IoT_Summit_Lab/ [demo-user@localhost IoT_Summit_Lab]$ ./runRulesService.sh
It should display following output < output truncated > AMQ-Broker tcp://localhost:61616 ready to work!
Device-Type = temperature Device-ID = 4711 Payload = 70 Result = 1 ---------------------- Sending <?xml version="1.0" encoding="UTF-8" standalone="yes"?><dataSet><timestamp>18.05.2016 10:46:22 766</timestamp><deviceType>temperature</deviceType><deviceID>4711</deviceID><payload>70</payload><required>0</required><average>0.0</average><errorCode>1</errorCode></dataSet>
Step 7: Test Rule Service
We will try this service by sending a test message via the Software Sensor to our setup. The following should happen:
Software Sensor sends a message with a high value via MQTT
Routing Service will pick it up, transform the message and send it to an AMQP message queue
Business Rules Service will take the transformed message from the queue and will put it in another AMQP message queue, but only if it meets the business rule condition
Enter the following commands in a new terminal
[demo-user@localhost Desktop]$ cd [demo-user@localhost ~]$ cd IoT_Summit_Lab/ [demo-user@localhost IoT_Summit_Lab]$ ./runHighSensor.sh
It should display following output
Starting the producer to send messages Sending '70,0'
AMQ-Broker tcp://localhost:61616 ready to work! Device-Type = temperature Device-ID = 4711 Payload = 70 Result = 1 ---------------------- Sending <?xml version="1.0" encoding="UTF-8" standalone="yes"?><dataSet><timestamp>17.05.2016 15:08:59 265</timestamp><deviceType>temperature</deviceType><deviceID>4711</deviceID><payload>70</payload><required>0</required><average>0.0</average><errorCode>1</errorCode></dataSet> ----------------------
Another way to verify that the message was properly processed is to take a look at Red Hat JBoss Fuse console via 'http://localhost:8181', The count of messages enqueued and dequeued shoud now show that one message has been taken from 'message.to.rules' and placed into 'message.to.datacenter'.
Note: Fuse console login/password is admin/change12_me
--------------------- End of Lab ---------------------