EdgeX Foundry试运行

简介: EdgeX Foundry试运行

简介

EdgeX Foundry是一个由Linux基金会发起的,且厂商中立的开源IoT边缘计算项目。它可以采集来自多个源的数据,并将这些数据转发到一个中央系统。EdgeX Foundry支持多种IoT设备使用的协议,如BACNET、OPC-UA、MQTT和REST。EdgeX Foundry由一系列运行在容器中的微服务构成,微服务之间使用REST API接口进行交互。

可以将EdgeX 作为一个上层服务和设备之间的媒介,例如,某个设备使用了BACNET协议,但上层服务并不支持该协议,此时可以使用EdgeX 将上层服务的REST API转换为设备期望的协议和格式。

可以使用EdgeX 提供的规则功能,基于输入创建动作触发逻辑,如当值A大于X式,执行一个pre-set命令。

通常会把EdgeX Foundry 安装在离传感器或产生数据较近的位置,如一个边缘网关应用附近。因此可能会安装上千个EdgeX,每个EdgeX负责各自数据的采集、转换和转发工作。

更完整的介绍,参见官方文档

安装

版本发布

可以在wiki上查看EdgeX的发布情况,当前最新版本名为Hanio,下一个版本名为Ireland。本次使用的版本为Hanio

最好使用已经发布的版本,官方的master分支可能不大稳定

部署

官方提供了使用docker-compose的安装方式。官方git仓库提供了所有版本的docker-compose文件,使用分支名区分:

EdgeX 提供了两个可视化工具:portaineredgex-ui-goportainer相当于一个简单的容器管理平台,edgex-ui-go相当于一个设备管理平台。

下载并运行docker-compose.yml即可,结果如下,最后两个就是可视化工具portaineredgex-ui-go

查看设备

执行如下命令查看已有的设备:

# curl http://127.0.0.1:48082/api/v1/device

更多参见EdgeX的官方API文档

创建设备

下面创建两种设备:

  • 传感器集群:生成温度和湿度数据
  • 一般设备:使用REST接口,支持命令

后续使用两种方式创建设备:

  • 手动方式:使用单独的REST命令创建传感器集群
  • 脚本方式:使用Python脚本创建一般设备

EdgeX使用设备配置文件作为添加新设备的简单方法。设备配置文件是一个描述设备、数据格式以及支持的命令的模板,它是一个文本文件,以YAML的格式上传到EdgeX,并在后续创建新设备时引用。一种设备类型只能有一个配置文件。

传感器集群

使用EdgeX Foundry REST APIs手动创建该设备,也可以使用脚本方式创建。下面使用Postman发送REST 请求,步骤如下:

  • 创建值描述信息
  • 上传设备配置文件
  • 创建设备

每一步操作都会用一个相同的主机IP地址,以及一个端口号。不同的端口号代表不同的微服务,例如:

  • 48080:edgex-core-data
  • 48081:edgex-core-metadata
  • 48082:edgex-core-command

创建值描述信息

值描述信息会告诉EdgeX转发的数据格式以及数据的标签。本例中,值描述信息分别给出了温度和湿度的值。

首先创建与湿度有关的值描述,可以看到最后返回了一个id

# curl -X POST http://127.0.0.1:48080/api/v1/valuedescriptor -d '{
   "name": "humidity",
   "description": "Ambient humidity in percent",
   "min": "0",
   "max": "100",
   "type": "Int64",
   "uomLabel": "humidity",
   "defaultValue": "0",
   "formatting": "%s",
   "labels": [
     "environment",
     "humidity"
   ]
}'
83d8ba2c-d12e-4531-99e6-213c3c84a895

创建与温度有关的值描述:

# curl -X POST http://127.0.0.1:48080/api/v1/valuedescriptor -d '{
   "name": "temperature",
   "description": "Ambient temperature in Celsius",
   "min": "-50",
   "max": "100",
   "type": "Int64",
   "uomLabel": "temperature",
   "defaultValue": "0",
   "formatting": "%s",
   "labels": [
     "environment",
     "temperature"
   ]
}'
0a8f5637-db7d-4108-8f48-03a116ad8726

可以使用curl http://127.0.0.1:48080/api/v1/valuedescriptor|jq查看已创建的值描述。

上传设备配置文件

下载设备配置文件并上传,可以看到也返回了一个Id'

# curl --location --request POST 'http://127.0.0.1:48081/api/v1/deviceprofile/uploadfile' --form 'file=@"/home/sensorClusterDeviceProfile.yaml"'
01373409-433d-4775-b7e1-4ede47daab80

可以使用curl http://127.0.0.1:48081/api/v1/deviceprofile|jq查看上传的设备配置文件:

创建设备

在创建设备之前需要注意以下两点:

  • 设备(REST设备)依赖名为"edgex-device-rest"的设备服务
  • 创建设备时使用的profile.name字段必须与上传的设备配置文件中的name字段"SensorCluster"相同

执行如下命令创建设备:

# curl -X POST http://127.0.0.1:48081/api/v1/device -d '{
"name": "Temp_and_Humidity_sensor_cluster_01",
"description": "Raspberry Pi sensor cluster",
"adminState": "unlocked",
"operatingState": "enabled",
"protocols": {
"example": {
"host": "dummy",
"port": "1234",
"unitID": "1"
}
},
"labels": [
"Humidity sensor",
"Temperature sensor",
"DHT11"
],
"location": "Tokyo",
"service": {
"name": "edgex-device-rest"
},
"profile": {
"name": "SensorCluster"
}
}'
a687ea40-13ca-4ed3-bb00-140ae84344a1

向EdgeX Foundry发送数据

向EdgeX Foundry发送温度和湿度数据:

# curl --request POST 'http://127.0.0.1:49986/api/v1/resource/Temp_and_Humidity_sensor_cluster_01/temperature' --header 'Content-Type: text/plain' --data-raw '23'
# curl --request POST 'http://127.0.0.1:49986/api/v1/resource/Temp_and_Humidity_sensor_cluster_01/humidity' --header 'Content-Type: text/plain' --data-raw '33'

使用curl http://127.0.0.1:48080/api/v1/event/count/Temp_and_Humidity_sensor_cluster_01查看该设备上的事件数:

读取传入的数据

# curl -X GET http://localhost:48080/api/v1/reading/device/Temp_and_Humidity_sensor_cluster_01/100|jq
[
{
"id": "b72e2fde-fe8c-41ed-baa4-dab0155bc53d",
"created": 1622629900723,
"origin": 1622629900721518000,
"device": "Temp_and_Humidity_sensor_cluster_01",
"name": "humidity",
"value": "33",
"valueType": "Int64"
},
{
"id": "07b596c3-248a-4800-b0f6-6d5cb58964b6",
"created": 1622629813141,
"origin": 1622629813139238100,
"device": "Temp_and_Humidity_sensor_cluster_01",
"name": "temperature",
"value": "23",
"valueType": "Int64"
},
...
]

到此为止,数据已经传入到EdgeX Foundry,短时间内会保存在Redis DB中。由于数据不会在边缘设备中保存太久,因此需要配置如何导出数据。

导出数据

EdgeX 为多种云服务和应用提供了exporters,为了简化,下面使用社区提供的配置将EdgeX的数据发送到公开的MQTT broker(基于Hive MQ)。

下载docker-compose.yml并运行,按照前面的方式添加设备(可能需要清除docker volume)。操作步骤可以见exporting-data。这样在公开的MQTT broker上就可以看到自己发送的数据。

可以在consul的Key/Value中设置

执行docker logs -f edgex-app-service-configurable-rules就可以查看数据发送日志:

level=DEBUG ts=2021-06-02T14:54:39.641349729Z app=AppService-rules-engine source=runtime.go:59 msg="Processing message: 1 Transforms"
level=DEBUG ts=2021-06-02T14:54:39.642895079Z app=AppService-rules-engine source=outputdata.go:38 msg="Setting output data"
level=DEBUG ts=2021-06-02T14:54:42.359115397Z app=AppService-rules-engine source=runtime.go:59 msg="Processing message: 1 Transforms"
level=DEBUG ts=2021-06-02T14:54:42.359264279Z app=AppService-rules-engine source=outputdata.go:38 msg="Setting output data"
level=DEBUG ts=2021-06-02T14:55:36.565067194Z app=AppService-rules-engine source=runtime.go:59 msg="Processing message: 1 Transforms"
level=DEBUG ts=2021-06-02T14:55:36.565268032Z app=AppService-rules-engine source=outputdata.go:38 msg="Setting output data"

总结

EdgeX后续的Roadmap如下,其中下个版本Ireland将会把API从v1升级为v2:

'Barcelona': October 2017
'California': July 2018
'Delhi': November 2018
'Edinburgh':  July 2019
'Fuji': November 2019
'Geneva': ~ April 2020
'Hanoi': ~ October 2020
'Ireland': ~ June 2021
'Jakarta': ~ November 2021
'Kamakura': ~ April 2022

本文只是一个EdgeX的试用,并没有深入讲解内部实现。总体上看EdgeX可以看作是运行在边缘设备周边的适配器,负责协议转换和数据的临时存储等。后续如果有机会涉及此方面工作再深入研究。

感谢Linux基金会以及该项目的贡献者。

参考

目录
相关文章
|
人工智能 运维 Kubernetes
OpenKruise 成为 CNCF 孵化项目:为大规模采用 Kubernetes 打开大门
OpenKruise 成为 CNCF 孵化项目:为大规模采用 Kubernetes 打开大门
OpenKruise 成为 CNCF 孵化项目:为大规模采用 Kubernetes 打开大门
|
存储 运维 Kubernetes
当开源遇上云,Amazon EKS Distro 与 KubeSphere 能擦出怎样的火花?
当开源遇上云,Amazon EKS Distro 与 KubeSphere 能擦出怎样的火花?
189 0
|
存储 消息中间件 监控
|
弹性计算 Kubernetes Cloud Native
招商银行 KubeVela 离线部署实践
本文将以 KubeVela v1.2.5 版本为例,介绍招商银行 KubeVela 的离线部署实践,来帮助其他用户在离线环境中更便捷的完成 KubeVela 的部署。
580 7
招商银行 KubeVela 离线部署实践
|
运维 前端开发 安全
30分钟体验云巧Workshop系列之一:10分钟部署
1. 目标交付场景是复杂的,而云巧作为面向产业的首个产业数字组件中心,目标正是解决复杂产业交付场景中的研发提效问题。我们在云巧官方首页有介绍云巧“可组装式”理念的白皮书,在“云巧快速上手”中有上手云巧的快速指引。但从理论、文档到实际落地之间还有不小的距离。本Workshop旨在通过一个贴近真实生产,但又相对比较简单的软件工作坊,让你可以亲手体验云巧的能力。2. 背景在首届云巧公益开发大赛中,云巧携
30分钟体验云巧Workshop系列之一:10分钟部署
|
运维 自然语言处理 Kubernetes
为 Serverless Devs 插上 Terraform 的翅膀,实现企业级多环境部署(下)
在上篇中,主要介绍了 Serverless Devs 多环境功能的使用,用户读完可能会些疑问,本文会就一些常见问题进行下回答。
|
存储 弹性计算 监控
为 Serverless Devs 插上 Terraform 的翅膀,实现企业级多环境部署(上)
Serverless Devs 离不开对云资源的操作,但支持新资源时需要开发相应的组件代码;​ 如果将环境模板的定义通过 Terraform IaC 来完成,在 Serverless Devs 的体系内不仅能良好地衔接,还能够极大拓宽用户领域;​ 用户可以通过编写 Terraform 文件来定义自己的基础设施,用 Serverless Devs 完成所有工作流的串联。​
|
运维 Kubernetes Cloud Native
OAM 与 KubeVela 项目整体捐赠进入 CNCF,让云端应用交付更加简单
2021 年 6 月 22 日,在云原生计算基金会(CNCF)的 TOC 例会上投票决议通过,Open Application Model (OAM) 和 KubeVela 整体成为 CNCF 官方沙箱项目
1391 9
OAM 与 KubeVela 项目整体捐赠进入 CNCF,让云端应用交付更加简单
|
运维 自然语言处理 Kubernetes
为 Serverless Devs 插上 Terraform 的翅膀,解耦代码和基础设施,实现企业级多环境部署(下)
在上篇《为 Serverless Devs 插上 Terraform 的翅膀,实现企业级多环境部署(上)》中,主要介绍了 Serverless Devs 多环境功能的使用,用户读完可能会些疑问,本文会就一些常见问题进行回答。
为 Serverless Devs 插上 Terraform 的翅膀,解耦代码和基础设施,实现企业级多环境部署(下)
|
传感器 边缘计算 运维
基于 OpenYurt & EdgeX Foundry 的云边端一体化解决方案
近日,OpenYurt 与 EdgeX Foundry 社区合作,完成了集成对接:从 v0.5.0 版本开始,OpenYurt 将正式支持部署和管理 EdgeX Foundry,并以云原生的方式管理端设备,双方将共同帮助开发者轻松、高效地解决物联网边缘计算场景下端设备管理和运维的挑战。
基于 OpenYurt & EdgeX Foundry 的云边端一体化解决方案