Scope
EdgeX framework from EdgeX foundry speeds time to market by offering replaceable reference providers for device-data ingestion, normalization, edge intelligence and sharing to assist new IoT information providers and superior edge computing functions. Extra particulars about EdgeX at Hyperlink
The scope of this case examine is to leverage and train the performance of EdgeX framework and display monitoring temperature and humidity sensor. Industrial grade temperature and humidity transmitter, SHT20 is used for the case examine. Typical block diagram utilizing EdgeX is beneath.
Excessive degree information circulate:
- Learn the temperature and humidity values of SHT20 Sensor.
- Leverage EdgeX framework working on Raspberry Pi to offer gateway performance.
- Utilizing EdgeX framework microservices, course of the sensor information and ship it to Cloud.
- Actuate LEDs to ON/OFF when temperature readings cross threshold values.
Ubuntu and EdgeX Set up
Ubuntu Set up
Raspberry Pi 3B and Raspberry Pi 4 are used for this case examine. Raspberry Pi will boot from the Working System current within the Micro SD-Card. I’ve put in Ubuntu 20.04 LTS model on Micro SD-Card utilizing Raspberry Pi supervisor. Detailed steps of set up could be discovered at Hyperlink
Earlier than booting Raspberry Pi utilizing Micro SD-Card which is put in with Ubuntu, make the next adjustments in SD-Card. With out these adjustments, ports might be disabled by default.
a) To allow USB ports for keyboard, add following line in /boot/config.txt file.
b) To allow HDMI ports for show, add following traces in /boot/config.txt file.
- hdmi_force_hotplug=1
- hdmi_drive=2
c) To allow SSH, contact a file “ssh” in /boot listing.
Booting the Raspberry Pi
- Join the next to Raspberry Pi.
- Energy twine for energy provide
- USB port for Keyboard enter
- HDMI port for monitor output
- Web entry with LAN cable or Wi-Fi
- Energy On and boot the gadget
- Login with default credentials (ubuntu/ubuntu) and replace password
- Get the IP tackle assigned utilizing command “sudo ip addr”
- As soon as Web entry is configured, we are able to SSH to Raspberry Pi from one other gadget for distant entry.
Set up EdgeX on Ubuntu
There are a number of methods to put in EdgeX on Ubuntu. Detailed steps for the set up are discovered at Hyperlink
Snap manner of putting in EdgeX micro providers is simple. However the microservice is in read-only filesystem of snap. If there is a matter to debug in any of the microservice, say EdgeX gadget service, it received’t assist with snap put in microservice as we can’t modify the configuration to allow debugs or modify code so as to add extra logs.
To beat the read-only downside of snap put in EdgeX microservices and so as to add extra debugs within the code, we are able to pull the code from GitHub, then construct and run. Initially I’ve used snap put in EdgeX microservices. However later migrated to construct it from GitHub repository.
Sensor System Validation
Sensor used for this case examine is Industrial Grade Temperature & Humidity Transmitter SHT20 Sensor Excessive Precision Monitoring Modbus RS485. Sensor SHT20 sends temperature and humidity values with the a number of of 10. After receiving the values, we have to divide them by 10 to get the right readings. Extra particulars concerning the sensor at Hyperlink
Sensor SHT20 communicates with RS-485 protocol. Industrial USB to RS485 Bidirectional half duplex serial line converter is used for sending and receiving values from Sensor. Extra particulars about converter at Hyperlink
Following is the logical from side to side circulate of knowledge utilizing RS-485 to USB converter.
Raspberry Pi ←→ USB-to-RS485-Converter←→ SHT20 Sensor
Precise connectivity used within the case examine is captured beneath. Jumper wires are used to attach Sensor and Converter.
Studying values
Goal is to examine the performance of the sensor with out utilizing EdgeX in first place. In order that we are able to validate if Sensor is working as anticipated or not. I’ve examined the Modbus messages from sensor with a C program. In C program, libmodbus library is used, which offers the APIs to ship and obtain messages in Modbus protocol.
[email protected]:/residence/ubuntu/check# gcc -o readVaules read_sensor_values.c `pkg-config –cflags –libs libmodbus`
[email protected]:/residence/ubuntu/check# ./readVaules
Setting slave_id 1
Opening /dev/ttyUSB0 at 9600 bauds (N, 8, 1)
[01][04][00][01][00][02][20][0B]
Ready for a affirmation…
<01><04><04><01><4A><02><19><1B><04>
Temperature = 33.000000 & Humidity = 53.700000
[email protected]:/residence/ubuntu/check#
Decoding Modbus messages
Let’s decode a pair of messages despatched to and acquired from the Sensor.
Request Despatched to Sensor: 01 04 00 01 00 02 20 0B
| Despatched | Decoding |
| 1 | Slave ID |
| 4 | Operate, read_input_registers |
| 00 01 | Register tackle |
| 00 02 | No of registers to learn |
| 20 0B | CRC |
Response acquired from Sensor: 01 04 04 01 4A 02 1A 5B 05
| Obtained | Decoding |
| 1 | Slave ID |
| 4 | Operate, read_input_registers |
| 4 | Bytes Rely |
| 01 4A | Knowledge 1, Temperature |
| 02 1A | Knowledge 2, Humidity |
| 5B 05 | CRC |
Temperature worth acquired is 0x014a, which is 330 in decimal. SHT20 sends the values in a number of of 10, so temperature is 33.0 levels. Equally, Humidity worth acquired is 0x021a, which is 538 in decimal. SHT20 sends the values in a number of of 10, so Humidity is 53.8 %RH.
4. LED Actuation Validation
To examine the wanted performance of breadboard connections with LEDs, following gadgets are required.
• Breadboard
• LEDs
• Resistors
• Jumper wires
I’ve referred to get the sufficient understanding wanted for this case examine. And for GPIO understanding I referred
Confirm LED connectivity
Like Modbus connectivity verification, right here too goal is to confirm the breadboard and LEDs connectivity with out utilizing EdgeX in first place.
I’ve made logical diagram of connecting GPIO pins of Raspberry Pi with LEDs current on breadboard utilizing Circuit Diagram offers a handy manner of depicting the connections.
I’ve examined the LEDs performance with a python program. Package deal RPi.GPIO offers a category to manage the GPIO on a Raspberry Pi. Breadboard precise connections and output of inexperienced LED glow is depicted beneath.
Finish-to-Finish Knowledge circulate
Goal of the case examine is to make use of EdgeX framework to:
- Learn the information from the Sensor and ship it to Cloud and
- Actuate LEDs at any time when temperature studying reaches higher or decrease threshold values.
Following is the high-level block diagram of the Finish-to-Finish Sensor information circulate.
Corresponding bodily connections are depicted beneath. Raspberry Pi is the IIoT gateway.
Micro Companies inside EdgeX
Knowledge circulate indicated with Blue arrows are from southbound to northbound i.e., from Sensor to Cloud. Knowledge circulate indicated with Orange arrows are from northbound to southbound i.e., from Utility Service to LED actuation.
Knowledge circulate from Southbound to Northbound (Sensor to Cloud):
- Modbus System Service will retrieve the temperature and humidity values from Sensor utilizing Modbus messages for each 5 seconds. Pulling information for each 5 seconds is configured utilizing Auto Occasions in Modbus System Service.
- Modbus System Service applies scale issue of 0.1 earlier than sending the sensor information to Core Companies.
- Sensor information is saved quickly in Core Companies and acquired on the Utility Service based mostly on the configuration inside Utility Service.
- Sensor information values could be fetched and verified utilizing Core Command REST APIs.
- Utility Service will ahead sensor values to the Cloud configured within the configuration.toml file.
- We will monitor the sensor values utilizing the IBM Cloud Portal.
Knowledge circulate from Northbound to Southbound (Utility Service to LED actuation):
- Utility Service will ship the sensor information to Guidelines Engine based mostly on the configuration. Kuiper is the Guidelines Engine.
- Guidelines Engine must be added with the required guidelines, previous to receiving the sensor information from Utility Service, in order that it may well actuate utilizing the Core Instructions of the GPIO System Service talked about within the guidelines.
- LEDs which should go ON/OFF are already configured in GPIO System Service. For this case examine, pin GPIO-12 is configured with Pink LED and pin GPIO-14 is configured with Blue LED. Core Instructions of GPIO-12 and GPIO-14 are added with corresponding guidelines in Kuiper.
- Threshold values for case examine are, Blue LED should glow if the temperature worth goes beneath 28 levels and Pink LED should glow if the temperature worth goes above 30 levels. Between 28 levels to 30 levels each the LEDs must be off.
- Sensor Knowledge acquired from Utility Service is analyzed by Kuiper and as per the configured guidelines, Core Instructions of GPIO System Service are actuated when threshold values are reached.
- Primarily based on the instructions triggered by Kuiper, GPIO System Service will actuate the corresponding LEDs to ON or OFF.
Analyzing the Knowledge Move
Following part analyzes the information circulate at varied phases, when despatched from Southbound to Northbound and vice versa.
Modbus System Service
Modbus System Service will retrieve the temperature and humidity values from Sensor utilizing Modbus messages for each 5 seconds. Modbus logs from the case examine are beneath.
2021/03/02 14:35:21 modbus: sending 01 04 00 01 00 01 60 0a
2021/03/02 14:35:21 modbus: acquired 01 04 02 01 50 b8 9c
Decoding above messages despatched to and acquired from the Sensor
| Despatched | Decoding |
| 1 | Slave ID |
| 4 | Operate, read_input_registers |
| 00 01 | Register tackle |
| 00 01 | No of registers to learn |
| 60 0a | CRC |
| Obtained | Decoding |
| 1 | Slave ID |
| 4 | Operate, read_input_registers |
| 2 | Bytes Rely |
| 01 50 | Knowledge, Temperature |
| b8 9c | CRC |
Temperature worth acquired is 0x0150, which is 336 in decimal. SHT20 sends the values in a number of of 10, so temperature is 33.6 levels.
Core Service
Sensor information values fetched utilizing REST APIs of Core Command are as follows.
Utility Service
Utility Service will ship the information to IBM Cloud, which is configured within the configuration.toml file. Utility Service logs when information is shipped to Cloud are captured beneath.
degree=DEBUG ts=2021-03-21T14:35:48.355521757Z app=AppService- supply=runtime.go:59 msg=”Processing message: 5 Transforms”
degree=DEBUG ts=2021-03-21T14:35:48.36118818Z app=AppService- supply=filter.go:44 msg=”Filtering by DeviceID”
degree=DEBUG ts=2021-03-21T14:35:48.364375438Z app=AppService- supply=filter.go:86 msg=”Filtering by ValueDescriptor”
degree=DEBUG ts=2021-03-21T14:35:48.367788325Z app=AppService- supply=conversion.go:62 msg=”Remodeling to JSON”
degree=DEBUG ts=2021-03-21T14:35:48.371520359Z app=AppService- source=mqtt.go:138 msg=”Despatched information to MQTT Dealer”
degree=DEBUG ts=2021-03-21T14:35:48.37480595Z app=AppService- supply=context.go:80 msg=”Marking occasion as pushed”
Snapshots of Sensor information from IBM Cloud portal, are beneath.
Guidelines Engine
One other Utility Service will ship the information to Guidelines Engine. Kuiper, which is Guidelines Engine, will actuate the LEDs by triggering the corresponding GPIO Core Instructions, when configured temperature thresholds are crossed. Kuiper receives the sensor information despatched by the Utility Service and applies the foundations that are preconfigured for actuation.
For the case examine, following are the steps to configure guidelines in Kuiper.
bin/kuiper drop stream edgex_data
bin/kuiper create stream edgex_data”() WITH(FORMAT=”JSON”, TYPE=”edgex”)”
bin/kuiper create rule red_led_on -f rule1.txt
bin/kuiper create rule red_led_off -f rule2.txt
bin/kuiper create rule blue_led_off -f rule3.txt
bin/kuiper create rule blue_led_on -f rule4.txt
From the above listing, rule1.txt will actuate purple LED on when temperature worth goes greater than 30 levels, rule2.txt will actuate purple LED off when temperature worth is lower than 30 levels. Equally, rule3.txt will actuate blue LED off when temperature worth goes greater than 28 levels, rule4.txt will actuate blue LED to on when temperature worth is lower than 28 levels. Logs when purple LED is actuated are beneath.
[email protected]:/residence/ubuntu/new_testing/kuiper/kuiper/_build/kuiper-1.1.1-4-g24892eb-linux-aarch64# tail -f ./log/stream.log
time=”2021-03-02 14:35:21″ degree=information msg=”sink consequence for rule blue_led_off: [{”TemperatureDegC”:33.6}]” file=”sinks/log_sink.go:16″ rule=blue_led_off
time=”2021-03-02 14:35:21″ degree=information msg=”sink consequence for rule red_led_on: [{”TemperatureDegC”:33.6}]” file=”sinks/log_sink.go:16″ rule=red_led_on
As a substitute of LED actuation, mandatory actions could be taken for Industrial use case.
GPIO System Service
GPIO gadget service will make the LED ON/OFF when Core Command of corresponding GPIO pin is triggered by Kuiper. Snapshots of LED actuation together with stay values in IBM Cloud portal are beneath.
I’ve decreased the temperature of the Sensor by wrapping it with an icepack.
Points confronted throughout Integration
Migrating from Snapcraft EdgeX to working microservices from GitHub code
Snap manner of putting in EdgeX micro providers is simple. However the microservice is in read-only filesystem of snap. If there is a matter to debug in any of the microservice, say EdgeX gadget service, it received’t assist with snap put in microservice as we can’t modify the configuration to allow debugs or modify code so as to add extra logs.
To beat the read-only downside of snap put in EdgeX microservices and add extra debugs within the code, we are able to pull the code from GitHub, then construct and run.
Sensor precision worth is misplaced throughout conversion
Sensor SHT20 sends the values as a number of of 10 with Modbus protocol. After we use the sort as INT16 for the gadget useful resource two bytes of sensor information is acquired however whereas making use of scale issue of 0.1 precision worth is misplaced. For instance, 30.3 diploma Celsius is shipped by the sensor as 303. After making use of scale think about Modbus System Service, temperature worth is 30 as an alternative of 30.3
Raised situation with EdgeX discussion board at Challenge fastened with rawType and documented at
6.3 Kuiper is unable to parse the sensor information worth whereas making use of guidelines
Whereas making use of guidelines for actuation, Kuiper is unable to parse the sensor information when rawType is utilized in gadget useful resource. Logs for a similar are beneath.
time=”2021-03-09 12:33:32″ degree=warning msg=”fail to get worth for TemperatureDegC: strconv.Atoi: parsing “3.220000e+01″: invalid syntax” file=”extensions/edgex_source.go:153″ rule=led_off
time=”2021-03-09 12:33:32″ degree=warning msg=”No readings are processed for the occasion, so ignore it.”
Raised situation with EmqX discussion board. After debugging with EmqX crew, understood that situation is with Core Service the place previous information varieties for gadget sources will not be up to date with new information varieties when gadget profile is modified.
Raised one other situation with EdgeX discussion board. Challenge is accepted by EdgeX crew and might be addressed as a part of v2 (/api/v2). For now, workaround is to delete the Modbus gadget profile, manually take away worth descriptor entries from Core Knowledge and register the Modbus gadget profile once more.
Vijay Kumar Gopu, working as a Technical Specialist with HCL applied sciences. I’ve working expertise within the space of Virtualization and Wi-fi Core Community.
