Configuration parameters of edge computing open source framework EdgeXFoundry

Notes on device profiles Notes on device profiles

This document gives a brief overview of the contents of device profiles, how these affect the behavior of the SDK, and how their elements are presented to the device service implementation.

This article provides a brief overview of the content of the device configuration files, how these files affect the behavior of the SDK, and how their elements are presented to the device service implementation.

The device profile

The device profile describes a type of device within the EdgeX system. Each device managed by a device service has an association with a device profile, which defines that device type in terms of the operations which it supports.

Device configuration files describe the types of devices in the EdgeX system. Each device managed by the device service is associated with a device configuration file, which defines the device type according to the operations supported by the device.

The profile contains some identification information - it has a name and a description, and a set of labels. It also indicates the brand name of the device to which it applies, and the manufacturer of that device.

The configuration file contains some identifying information-it has a name, a description, and a set of tags. It also indicates the brand name of the device to which it applies, and the manufacturer of the device.

This information is followed by three sections, “deviceResources”, “deviceCommands” and “coreCommands”.

This information is followed by three parts, "deviceResources", "deviceCommands" and "coreCommands".

coreCommands

This section specifies the commands which are available via the core-command microservice, for reading and writing to the device.

This section specifies the commands that can be read and written to the device through core-command microservice.

Commands may allow get or put methods (or both). For a get type, the returned values are specified in the “expectedValues” field, for a put type, the parameters to be given are specified in “parameterNames”. In either case, the different http response codes that the service may generate are shown.

The command may allow get or put methods (or both). For the get type,The return value is specified in the "expectedValues" field,forput type, the given parameters will be specified in "parameterNames". In both cases, the different http response codes that the service may generate will be displayed.

deviceCommands

These are presented at the “device” endpoint,

These are displayed on the "device" endpoint,

http://<device-service>:<port>/api/v1/device/<device id>/<command name>

This section defines access to reads and writes for multiple simultaneous values. Each deviceCommand should contain a get and/or a set section, describing the read or write operation respectively.

This section defines the read and write permissions for multiple simultaneous values. Each deviceCommand should contain a get and/or a set part to describe read or write operations respectively.

Each line of a get section indicates a deviceResource which is to be read, and the lines in a set section indicate deviceResources to be written. The values in these lines are as follows:

Each line in the Get part indicates the deviceResource to be read, and each line in the set part indicates the deviceResources to be written. The values ​​in these rows are as follows:

• index - a number, used to define an order in which the resource is processed.
• index-a number that defines the order of processing resources
• operation - get or set. Ignored in this implementation, mixing of get and set operations is not supported.
• operation-get or set. In this implementation, get and set operations are ignored, and the mixture of get and set operations is not supported
• deviceResource - the name of the deviceResource to access.
• deviceResource-the name of the device source to be accessed
• parameter - optional, a value that will be used if a PUT request does not specify one.
• parameter-optional, if the PUT request does not specify a value, use that value

deviceResources device resources

These are also presented at the “device” endpoint,

These also appear on the "device" endpoint,

http://<device-service>:<port>/api/v1/device/<device id>/<deviceResource name>

however if a profile contains a deviceCommand with the same name as a deviceResource, the deviceCommand will take precedence.

However, if the configuration file contains a deviceCommand with the same name as the deviceResource, the deviceCommand will take precedence.

A deviceResource specifies an individual value within a device that may be read from or written to as part of a command. It has a name for identification and a description for informational purposes.

deviceResource specifies a single value in the device that can be read or written as part of the command. It has a name for identification and a description for providing information.

The Attributes in a deviceResource are the device-service-specific parameters required to access the particular value. Each device service implementation will have its own set of named values that are required here, for example a BACnet device service may need an Object Identifier and a Property Identifier whereas a Bluetooth device service could use a UUID to identify a value.

The attributes in deviceResource are device service-specific parameters required to access specific values. Each device service implementation has its own set of named values, which are needed here. For example, the BACnet device service may require an Object Identifier and a Property Identifier, and the Bluetooth device service may use UUID to identify a value.

The properties section in a deviceResource describes the value. Conventionally each logical value is given two properties, named value and units. The following fields are available in a property:

The properties section in deviceResource describes this value. Generally, each logical value has two attributes, named value and unit. The following fields can be used in attributes:

• type - Required. The data type of the value. Supported types are bool, int8 - int64, uint8 - uint64, float32, float64, binary and string. Note that the undifferentiated Integer and Float types are deprecated in EdgeX and not supported by the SDK.
• type-the required information. The data type of the value. The supported types are bool, int8-int64, uint8-uint64, float32, float64, binary and string. Note that the undifferentiated Integer and Float types are not recommended in EdgeX, and the SDK does not support them
• readWrite - “R”, “RW”, or “W” indicating whether the value is readable or writable.
• readWrite-"R", "RW" or "W" indicates whether the value is readable or writable
• defaultValue - a value used for PUT requests which do not specify one.
• defaultValue-used to not specify the value of the PUT request
• base - a value to be raised to the power of the raw reading before it is returned.
• base-the value of the power that raises the original read value to the original read value before returning it
• scale - a factor by which to multiply a reading before it is returned.
• scale-the factor by which to multiply the reading before returning
• offset - a value to be added to a reading before it is returned.
• offset-the value added to the reading before returning it
• mask - a binary mask which will be applied to an integer reading.
• mask-the binary mask that will be applied to the integer read
• shift - a number of bits by which an integer reading will be shifted right.
• shift-the number of bits to shift the integer reading to the right
• minimum - a minimum value for data specified in set operations.
• minimum-the minimum value of the data specified in the set operation
• maxumum - a maximum value for data specified in set operations.
• maxumum-the maximum value of the data specified in the set operation

The processing defined by base, scale, offset, mask and shift is applied in that order. This is done within the SDK. A reverse transformation is applied by the SDK to incoming data on set operations (mask transforms on set are implemented in the driver)

The basis of processing definition, scale, offset, mask and shift are applied in this order. This is done in the SDK. SDK applies reverse conversion to the input data on the collection operation (implement the mask conversion on the collection in the driver)

The minimum and maximum values may be used to enforce a range limit on values provided in write requests. They are only valid for numeric data, ie ints and floats.

The minimum and maximum values ​​can be used to enforce range limits on the values ​​provided in the write request. They are only valid for numerical data, such as integers and floating point numbers.

The units property is used to indicate the units of the value, eg Amperes, degrees C, etc. It should have only one field, a defaultValue that specifies the units.

Unit attributes are used to express the value of the unit, such as amperes, degrees Celsius, etc. It should have only one field, a defaultValue of a specified unit.

The Device Profile in the C SDK Device Profile in the C SDK

When the SDK invokes the get or set handler method, parts of the device profile which pertain to the request are passed in the devsdk_commandrequest structure. This consists of the name, attributes and type of the deviceResource which is being queried or set.

When the SDK calls the get or set handler method, the part of the device configuration file related to the request will be passed in the devsdk_commandrequest structure. This includes the name, attribute, and type of the deviceResource to be queried or set.

Device service configuration options Device service configuration options

The device service configuration is held in TOML format. By default the SDK will load configuration from a file named configuration.toml in the res directory, but this may be changed using the --confdir, --file and --profile options.

The device service configuration is saved in TOML format. By default, the SDK will load the configuration from a file named configuration.toml in the res directory, but this may be changed using the –confdir, –file, and –profile options.

Configuration parameters are organized within a number of sections. A section is represented by a TOML table, eg [Service].

The configuration parameters are organized in many sections. A part is represented by a TOML table, such as [Service].

If the Registry is in use, configuration is contained in subfolders of edgex/core/1.0/<service-name>. The “Clients” section is not present in this scenario, as the Registry provides a specific mechanism for maintaining service information.

If the Registry is in use, the configuration is contained in the subfolder of edgex/core/1.0/<service-name>. There is no "Clients" part in this scenario, because the Registry provides a specific mechanism for maintaining service information.

When a device service is run for the first time with Registry enabled, it reads its configuration from a TOML file and uploads it to the Registry.

When the device service runs with Registry enabled for the first time, it will read its configuration from the TOML file and upload it to the Registry.

The value of any configuration element can be over-ridden with a value from a corresponding environment variable. The service first looks for an environment variable whose name is of the form

The value of any configuration element can be rewritten using the value in the corresponding environment variable. This service first looks for an environment variable with the same name as the table

<service-name>_<section-name>_<config-element>

< service-name > _ < section-name > _ < config-element >

and if that is not present, then tries

If not, then try

<section-name>_<config-element>

< section-name > _ < config-element >

For example, device-template_Device_MaxCmdOps or Logging_LogLevel.

For example, device template _ device _ maxcmdops or Logging _ loglevel.

Service section

Option selection	Type	Notes
Host	String	This is the hostname to use when the service generates URLs pointing to itself. It must be resolvable by other services in the EdgeX deployment. This is the hostname to use when the service generates URLs pointing to itself. It must be resolved by other services in the EdgeX deployment
Port	Int	Port on which to accept the device service's REST API. The assigned port for experimental / in-development device services is 49999. Port on which to accept the device service's REST API. The designated port for the experimental/development equipment service is 49999
Timeout	Int	Time (in milliseconds) to wait between attempts to contact core-data and core-metadata when starting up. The waiting time (in milliseconds) between attempts to contact core-data and core-metadata when starting up.
ConnectRetries	Int	Number of times to attempt to contact core-data and core-metadata when starting up.
StartupMsg	String	Message to log on successful startup. Message to log on successful startup
CheckInterval	String	The checking interval to request if registering with Consul
ServerBindAddr	String	The interface on which the service's REST server should listen. By default the server listens on all available interfaces. The interface on which the service's REST server should listen. By default, the server listens on all available interfaces
Labels	String	Labels, easy to distinguish different device services

Clients section

Defines the endpoints for other microservices in an EdgeX system.

Define the endpoints of other microservices in the EdgeX system.

Data

Option	Type	Notes
Host	String	Hostname on which to contact the core-data service.
Port	Int	Port on which to contact the core-data service.

Metadata

Option	Type	Notes
Host	String	Hostname on which to contact the core-metadata service.
Port	Int	Port on which to contact the core-metadata service.

Logging log

Option	Type	Notes
Host	String	Hostname on which to contact the support-logging service. Hostname to contact the support-logging service
Port	Int	Port on which to contact the support-logging service. Port on which to contact the support-logging service.

Device section

Option	Type	Notes
DataTransform	Bool	For enabling/disabling transformations on data between the device and EdgeX. Defaults to true (enabled). For enabling/disabling transformations on data between the device and EdgeX. Default is true (enabled)
Discovery/Enabled	Bool	For enabling/disabling device discovery. Defaults to true (enabled). Used to enable/disabling device discovery. Default is true (enabled)
Discovery/Interval	Int	Time between automatic discovery runs, in seconds. Defaults to zero (do not run discovery automatically). The time between automatic discovery runs, in seconds. Default is zero (do not run discovery automatically)
MaxCmdOps	Int	Defines the maximum number of resource operations that can be sent to the driver in a single command.
MaxCmdResultLen	Int	Not implemented. Maximum string length for command results returned from the driver. Not implemented. The maximum string length of the command result returned by the driver
ProfilesDir	String	A directory which the service will scan at startup for Device Profile definitions in 服务在启动时扫描设备配置文件定义的目录.yaml files. Any such profiles which do not already exist in EdgeX will be uploaded to core-metadata. 任何这样的配置文件不存在于 EdgeX 将上传到核心元数据
UpdateLastConnected	Bool	If true, update the LastConnected attribute of a device whenever it is successfully accessed. Defaults to false. 如果为真，则在设备成功访问时更新设备的 LastConnected 属性。默认值为 false
EventQLength	Int	Sets the maximum number of events to be queued for transmission to core-data before blocking. Zero (default) results in no limit. 设置在阻塞之前要排队传输到核心数据的最大事件数。零(默认值)不会导致限制

Logging section 日志记录部分

Option	Type	Notes 注释
LogLevel	String	Sets the logging level. Available settings in order of increasing severity are: TRACE, DEBUG, INFO, WARNING, ERROR. 设置日志级别。可用的设置按严重性的增加顺序是: TRACE，DEBUG，INFO，WARNING，ERROR
EnableRemote	Bool	If this option is set, logs will be submitted to the EdgeX logging service rather than written to a local file / stdout. 如果设置了此选项，日志将提交给 EdgeX 日志记录服务，而不是写入本地文件/stdout
File	String	If this option is set, local logs will be written to the named file rather than standard output. 如果设置了此选项，则将本地日志写入指定的文件，而不是标准输出

Driver section 驱动部分

This section is for driver-specific options. Any configuration specified here will be passed to the driver implementation during initialization.

这个部分是针对特定于驱动程序的选项。这里指定的任何配置都将在初始化期间传递给驱动程序实现。

Device service startup parameters 设备服务启动参数

Certain aspects of a device service’s operation are controlled by command-line options and environment variable settings. These are not stored with the service configuration as they may be required before the configuration is read - in particular, they may be required in order to locate the configuration. Each commandline option may be overridden by an environment variable.

设备服务操作的某些方面是由命令行选项和环境变量/服务设置控制的。由于在读取配置之前可能需要这些配置，因此这些配置不与服务配置一起存储——特别是，为了定位配置，可能需要这些配置。每个命令行选项都可能被环境变量控件覆盖。

Registry 注册

If configuration is to be obtained from the Registry, its location may be specified as a URL. The scheme part of the URL indicates the registry implementation to use. Currently the only supported implentation in the SDK is consul.http, where the URL takes the form consul.http://hostname:port.

如果要从注册表获取配置，则可以将其位置指定为 URL。URL 的 scheme 部分指示要使用的注册表实现。目前 SDK 中唯一受支持的实现是 consul.http，其中 URL 采用 consul.http://hostname: port 的形式。

Long option 长选项	Short option 短选项	Environment 环境
--configProvider	-cp	EDGEX_CONFIGURATION_PROVIDER	specifies the registry URL. 指定注册表 URL

Service name 服务名称

Typically a device service will have a default service name, eg device-modbus or device-virtual. However when an EdgeX deployment contains multiple instances of a particular device service, they must be assigned different names. This can be done by assigning an instance name on the command line. The instance name is then appended to the default service name, so if the bacnet device service is run with -i floor3 the service name will be device-bacnet_floor3.

通常设备服务会有一个默认的服务名称，例如 device-modbus 或 device-virtual。但是，当 EdgeX 部署包含特定设备服务的多个实例时，必须为它们分配不同的名称。这可以通过在命令行上分配实例名来实现。然后将实例名附加到默认服务名称，因此，如果 bacnet 设备服务使用-i floor3运行，服务名称将为 device-bacnet _ floor3。

Long option 长选项	Short option 短选项	Environment 环境
--instance	-i	EDGEX_INSTANCE_NAME	specifies the instance name 指定实例名称

Profile 配置

A service has a default configuration profile, but other profiles may be selected using this option. In file-based configuration, additional profiles may be defined in files named configuration-<profilename>.toml. In Consul, they are stored in KV-store folders named <servicename>;<profilename>.

服务具有默认配置配置文件，但是可以使用此选项选择其他配置文件。在基于文件的配置中，可以在名为 configuration-< profileename > 的文件中定义其他配置文件。Toml.在执政中，它们被存放在 KV-store 文件夹中，文件夹名为 < servicename > ; < profileename > 。

Long option 长选项	Short option 短选项	Environment 环境
--profile	-p	EDGEX_PROFILE	specifies the configuration profile 指定配置配置文件

Configuration directory 配置目录

For file-based configuration, this is the directory containing TOML files. The default value is res (note that this is a relative path).

对于基于文件的配置，这是包含 TOML 文件的目录。默认值是 res (注意这是一个相对路径)。

Long option 长选项	Short option 短选项	Environment 环境
--confdir	-c	EDGEX_CONF_DIR	specifies the configuration directory 指定配置目录

Configuration file 配置文件

For file-based configuration, this is the filename of the TOML configuration file. If this option is used, the --profile option will be ineffective.

对于基于文件的配置，这是 TOML 配置文件的文件名。如果使用此选项，-- profile 选项将无效。

Long option 长选项	Short option 短选项	Environment 环境
--file	-f	EDGEX_CONFIG_FILE	specifies the configuration filename 指定配置文件名

Timeouts 超时

Two additional environment variables control the retry behavior when contacting the registry at startup:

另外两个环境变量控制在启动时联系注册表时的重试行为:

Environment variable 环境变量
EDGEX_STARTUP_DURATION	sets the amount of time (in seconds) in which to attempt to connect to the registry before abandoning startup 设置在放弃启动之前尝试连接注册表的时间量(以秒为单位)
EDGEX_STARTUP_INTERVAL	sets the interval (in seconds) between attempts to connect to the registry 设置尝试连接到注册表之间的间隔(以秒为单位)

Device service metrics availability 设备服务指标可用性

Device services built with the C SDK support the EdgeX service metrics endpoint

使用 C SDK 构建的设备服务支持 EdgeX 服务指标端点

http://host:port/api/v1/metrics

This provides brief information on CPU and memory usage. Example output (formatted for clarity) is shown here:

这里提供了关于 CPU 和内存使用情况的简要信息:

{
  "Memory":
  {
    "Alloc":329072,
    "TotalAlloc":839680
  },
  "CpuLoadAvg":3.375,
  "CpuTime":0.027213000000000001,
  "CpuAvgUsage":0.0010293528009986004
}

The meaning of the fields is as follows:

这些字段的含义如下:

• Memory/Alloc : Amount of heap memory in use, in bytes. : 正在使用的堆内存量(以字节为单位)
• Memory/TotalAlloc : Total heap size, in bytes. : 堆总大小(以字节为单位)
• CpuLoadAvg : Average overall CPU usage for the last minute, as a percentage. * 最后一分钟的平均总体 CPU 使用率，以百分比表示
• CpuTime : The amount of CPU time used by this service, in seconds. : 此服务使用的 CPU 时间量，以秒为单位
• CpuAvgUsage: The amount of CPU time used by this service, as a fraction of elapsed time. : 此服务使用的 CPU 时间量，占占用时间的一小部分

Notes on writing a device service 关于编写设备服务的注释

This document aims to complement the examples provided with the EdgeX C SDK by providing insight into what actions should be performed in the various parts of a Device Service.

本文旨在通过深入了解设备服务的各个部分应该执行哪些操作来补充 EdgeX c SDK 提供的示例。

Fundamentally a Device Service is composed of a number of callbacks. These callbacks are provided by the SDK to allow the service to respond to different events. These callbacks (devsdk_callbacks) are as follows:

基本上，设备服务由许多回调函数组成。这些回调是由 SDK 提供的，以允许服务响应不同的事件。这些回调(devsdk _ callbacks)如下:

• init
• reconfigure
• discover
• get
• put
• stop

A device service must provide an implementation of each callback, except for discover (which may be NULL if dynamic discovery is not implemented) and reconfigure (which may be NULL if the service has no driver-specific configuration). A small amount of setup is required of a device service, this is usually performed in the main. A devsdk_service_t should be created, containing, amongst other fields the devsdk_callbacks and an impldata pointer which is passed back every time a callback is invoked. The service must then call devsdk_service_new to create the device service, devsdk_service_start to start it, and upon exit the service should call devsdk_service_stop, followed by devsdk_service_free to clean up.

设备服务必须提供每个回调的实现，除了 discover (如果没有实现动态发现，它可能是 NULL)和 reconfigure (如果服务没有特定于驱动程序的配置，它可能是 NULL)。设备服务需要少量的设置，这通常在主服务中执行。应该创建一个 devsdk service _ t，其中包含 devsdk _ callbacks 和一个 impldata 指针，这个指针在每次调用回调时返回。然后服务必须调用 devsdk service new 来创建设备服务，devsdk service 启动它，退出服务时应该调用 devsdk service stop，然后是 devsdk service free 来清理。

Init 初始化

Init is called when the device service starts up, its purpose is to perform protocol-specific initialization for the device service. This typically involves allocating memory for driver specific structures, initialising synchronisation mechanisms (mutex etc.) and setting up a logging client. The logging client is being provided to the implementation, most implementations will want to store the pointer in their impldata structure for later use. Any initialization required by the device should be performed here.

在设备服务启动时调用 Init，其目的是为设备服务执行特定于协议的初始化。这通常涉及为特定于驱动程序的结构分配内存、初始化同步机制(互斥等)和设置日志客户机。日志客户端是提供给实现的，大多数实现会希望将指针存储在它们的 impldata 结构中，以便以后使用。设备需要的任何初始化都应该在这里执行。

Reconfigure 重新配置

If the Registry is in use, then dynamic updates to configuration are possible. If an element of the driver-specific configuration is changed, this callback will be invoked with the new configuration settings passed through.

如果注册表正在使用中，则可以对配置进行动态更新。如果特定于驱动程序的配置中的某个元素发生了更改，将使用传递的新配置设置调用此回调。

Discover

In Discover, protocols which are able to perform discovery can do so. They must perform their protocol specific discovery and add devices using the edgex_device_add_device() method. Careful consideration should be given to whether this mechanism is required and how dynamically discovered devices can be intelligently and correctly mapped to device profiles.

在发现中，能够执行发现的协议可以这样做。他们必须使用 edgex _ device _ add _ device ()方法执行特定于协议的发现和添加设备。应该仔细考虑是否需要这种机制，以及动态发现的设备如何智能和正确地映射到设备配置文件。

Get

The Get handler deals with incoming requests to get data from a device. The following information is provided to the device service developer:

Get 处理程序处理从设备获取数据的传入请求。以下信息提供给设备服务开发人员:

• void *impl - The impldata pointer given as part of edgex_device_service. 作为 edge_device _ service 的一部分给出的 impldata 指针
• char *devname - The name of the device being queried. Char * devname-被查询的设备的名称
• devsdk_protocols *protocols - This provides information about the device that this get request is seeking to access. A list of protocols is supplied, each consists of a name and a set of name-value pairs representing the attributes required for that protocol. A function devsdk_protocols_properties() is provided which returns the name-value pairs corresponding to a named protocol. Devsdk _ protocols * 协议——该协议提供有关此 get 请求要访问的设备的信息。提供了一个协议列表，每个协议由一个名称和一组表示该协议所需属性的名称-值对组成。提供了一个函数 devsdk _ protocols _ properties () ，该函数返回与命名协议对应的名称-值对
• uint32_t nreadings - The following requests and reading parameters are arrays of size nreadings. Uint32_t 核磁共振读数-以下请求和读数参数是尺寸核磁共振读数数组
• const devsdk_commandrequest *requests - The name, attributes and type of each resource being requested. Const devsdk _ commandrequest * requests ——请求的每个资源的名称、属性和类型
• devsdk_commandresult * readings - Once a reading has been taken from a device, the resulting value is placed into the readings. This is used by the SDK to return the result to EdgeX. 读数-一旦一个读数已经从一个设备，结果值被放置到读数。SDK 使用这个函数将结果返回给 EdgeX
• const devsdk_nvpairs *qparams - This contains any parameters requested via the query string of the request URL. Const devsdk _ nvpairs * qparams-这包含通过请求 URL 的查询字符串请求的任何参数
• iot_data_t ** exception - The handler may store a string here containing details in the event of a read failure. Iot _ data _ t * * exception – 处理程序可能会在这里存储一个字符串，包含在读取失败事件中的细节

In general the GET handler should implement a translation between a GET request from edgex and a read/get via the protocol-specific mechanism. Multiple sources of metadata are provided to allow the device-service to identify what it should query on receipt of the callback.

通常，GET 处理程序应该通过特定于协议的机制实现来自 edgex 的 GET 请求和 read/GET 之间的转换。提供了多个元数据源，以允许设备服务确定在收到回调时应查询的内容。

Put

The Put handler deals with requests to write/transmit data to a specific device. It is provided with the same set of metadata as the GET callback. However, this time the put handler should write the data provided to the device associated with the addressable. The process of using the metadata provided to perform the correct protocol-specific write/put action is similar to that of performing a get.

Put 处理程序处理将数据写入/传输到特定设备的请求。它所提供的元数据集与 GET 回调相同。但是，这一次，put 处理程序应该将提供的数据写入与可寻址关联的设备。使用提供的元数据执行正确的特定于协议的 write/put 操作的过程类似于执行 get。

Stop

The stop handler is called when devsdk_service_stop is called. This handler should be used to clean-up all device service specific resources. Typically this would involve freeing any resources allocated during execution of the device service.

当调用 devsdk _ service _ stop 时，将调用停止处理程序。此处理程序应用于清理所有设备服务特定的资源。这通常涉及释放在设备服务执行期间分配的任何资源。

Optional handlers 可选的处理程序

An implementation may implement the device_added, device_updated and device_removed handlers, it will then be notified of changes to the extent of devices managed by the service. This may be helpful if special initialization / shutdown operations are required for optimal usage of the device.

一个实现可以实现 device _ added、 device _ updated 和 device _ removed 处理程序，然后它将被通知服务管理的设备范围的更改。如果需要特殊的初始化/关机操作来优化设备的使用，这可能是有帮助的。

An implementation may also implement the ae_starter and ae_stopper callbacks, in which case it will become responsible for the AutoEvents functionality which is normally handled within the SDK. This facility is currently experimental, it may be useful in scenarios where the device can be set to generate readings autonomously.

实现还可以实现 ae _ starter 和 ae _ stopper 回调，在这种情况下，它将负责通常在 SDK 中处理的 AutoEvents 功能。这个装置目前还处于实验阶段，在设备可以自动生成读数的情况下，它可能会很有用。