Z-Wave 700应用程序框架第三章 – Z-Wave架构

Z-Wave 700应用程序框架第一章 – Z-Wave协议概述
Z-Wave 700应用程序框架第二章 – Z-Wave远程协议概述 
Z-Wave 700应用程序框架第三章 – Z-Wave架构

图5显示了ZAF的架构以及它与硬件和Z-Wave协议的关系。

图5，Z-Wave Plus应用框架架构

ZAF由三个模块组成:

• 传输层Transport Layer:

这一层处理与该协议的所有通信，包括单播、组播、多通道封装、绑定命令的分发等。

• 命令类Command Classes

这些模块解析和合成命令类帧。

• 实用工具类 Utilities

实用工具由不同的模块组成，包括那些用于处理特定于与SDK捆绑在一起的WSTK和BRD 8029板的I/O通信的模块。其他模块有电池监控和固件更新等。

该框架实现了事件驱动的应用程序设计。

该框架提供了用于开发更简单应用程序的内置特性。传输缓冲区是互斥保护的，以确保应用程序一次只有一个传输请求作业(非请求事件)。只有在传输请求作业完成或超时时才释放发送缓冲区。框架可以同时处理一个请求作业和一个响应作业。

ZAF分为以下两个文件夹:

• /CommandClasses/包含CC模块。所有CC模块共享ZW_tx_mutex模块提供的一个受保护的传输缓冲区。ZW_tx_mutex模块实现了两个传输缓冲区，一个用于请求调用，一个用于响应调用。
• /ApplicationUtilities/包含实用工具模块和传输层的接口。其中一些模块用于简单的MMI-setup，如按钮和LED处理。其他模块，如association_plus、battery_monitor、battery_plus和ota_util是更复杂的实用模块，它们与CC和客户端应用程序接口。

1. 应用程序内存限制条件

以下内存资源可用于认证的应用程序开发，包括Z-Wave Framework和Utilities:

• 64kb的Flash内存用于可执行代码
• 8 kB的RAM用于临时数据

以上限制不能超出。违反这些限制可能会损害与未来SDK版本的兼容性。

引导加载程序驻留在单独的10 kB存储区域中，并不是经过认证的应用程序的一部分。

在构建过程结束时，可以启用一个特性来计算和输出代码大小、非易失性内存分配以及SRAM内存使用情况。

作为Python 3.x的先决条件。必须在系统路径上安装并可用。

所做的更改只应用于特定的项目。如果存在多个项目，则按照每个项目的步骤进行操作。

在创建一个项目后，或已经有一个项目做以下工作:

• 右键单击项目文件夹，如图所示，然后选择“properties”:

• 出现下面的对话框:

• 选择“C/C++ Build”-> “Settings”.
• 然后是“Build Steps”。

在此选项卡中，可以在bash环境中运行命令。如上所述，没有pre-build命令，但是我们有一个用于签名构建二进制文件的post-build命令。

在这里，我们将把以下内容附加到这个已经存在的命令的末尾。

(删除“旧命令”)

<old_commands> && arm-none-eabi-size -A "${BuildArtifactFileBaseName}.axf" > "${BuildArtifactFileBaseName}_codesize.txt" && python "${StudioSdkPath}/protocol/zwave/Scripts/size_info_gen.py" -p -i "${BuildArtifactFileBaseName}_codesize.txt"

• 完整的字符串是' To enable ':

"${CommanderAdapterPackPath}" gbl create "${BuildArtifactFileBaseName}.gbl" --app "${BuildArtifactFileBaseName}.hex" --sign "${StudioSdkPath}/protocol/z-wave/BootLoader/sample-keys/sample_sign.key" --encrypt "${StudioSdkPath}/protocol/z-wave/BootLoader/samplekeys/sample_encrypt.key" --compress lz4 && arm-none-eabi-size -A "${BuildArtifactFileBaseName}.axf" > "${BuildArtifactFileBaseName}_codesize.txt" && python "${StudioSdkPath}/protocol/z-wave/Scripts/size_info_gen.py" -p -i "${BuildArtifactFileBaseName}_codesize.txt"

• 完整的字符串是“To disable”:

"${CommanderAdapterPackPath}" gbl create "${BuildArtifactFileBaseName}.gbl" --app "${BuildArtifactFileBaseName}.hex" --sign "${StudioSdkPath}/protocol/z-wave/BootLoader/samplekeys/sample_sign.key" --encrypt "${StudioSdkPath}/protocol/z-wave/BootLoader/samplekeys/sample_encrypt.key" --compress lz4

• Output

演示应用程序有相应的代码大小信息生成，这些文件可在SDK的以下位置:

C:SiliconLabsSimplicityStudiovXdevelopersdksgecko_sdk_suitevX.Xprotocolz-waveAppsbincodesize

完整路径在您的系统上可能有所不同，X是版本号

2. SmartStart

Smart Start特性是该协议的一部分，它自动处理包含过程，而无需用户与设备进行物理交互。当设备第一次通电时，它会告诉世界它已经准备好了，很有可能附近的控制器会听到这个，并包含设备。如果包含进程超时，它将在给定时间后再次重试。

3. 开始SmartStart包含

当应用程序调用带有参数"E_NETWORK_LEARN_MODE_INCLUSION_SMARTSTART"的"ZAF_setNetworkLearnMode()"时，SmartStart包含过程就开始了。

Z-Wave协议通过以下事件使用命令状态处理程序通知应用程序包含的状态:

• EZWAVECOMMANDSTATUS_NETWORK_LEARN_MODE_START
• EZWAVECOMMANDSTATUS_LEARN_MODE_STATUS

EZWAVECOMMANDSTATUS_NETWORK_LEARN_MODE_START事件包含一个状态，告诉包含是否成功启动。

EZWAVECOMMANDSTATUS_LEARN_MODE_STATUS事件可以包含几个不同的状态:

• ELEARNSTATUS_SMART_START_IN_PROGRESS
• ELEARNSTATUS_LEARN_IN_PROGRESS
• ELEARNSTATUS_ LEARN_MODE_COMPLETED_FAILED
• ELEARNSTATUS_ LEARN_MODE_COMPLETED_TIMEOUT
• ELEARNSTATUS_ ASSIGN_COMPLETE

ELEARNSTATUS_SMART_START_IN_PROGRESS表示控制器智能启动进程已经启动。

状态ELEARNSTATUS_LEARN_IN_PROGRESS表示经典包含到控制器的过程已经启动。

如果状态为ELEARNSTATUS_ LEARN_MODE_COMPLETED_FAILED，应用程序必须重置其NVM并重新启动。

如果状态是ELEARNSTATUS_ LEARN_MODE_COMPLETED_TIMEOUT，应用程序必须重新进入智能启动包含进程。

4. 配置SmartStart包含

当终端设备处于智能启动状态时，它会发送多个包含请求，其间的延迟会增加。缺省情况下，最大包含请求间隔设置为512秒。

最大包含间隔可以在应用程序中更改。在电池驱动的产品中，如果预计该产品将长期处于智能启动包含中，可以使用更高的值来节省电池电量。当功耗不是问题时，可以使用较低的值来确保更快的智能启动包含。

修改最大包含间隔的命令为:

函数：- void ZAF_SetMaxInclusionRequestIntervals(uint32_t intervals)设置最大包含请求延迟的功能。
参数：- uint32_t intervals 最大包含请求延迟128秒的步骤。有效范围是5-99

包含请求将按下表所示的间隔发出:

5. 电源管理

电源管理由Z-Wave协议处理。协议禁止所有监听设备进入除EM0和EM1以外的任何能量模式。侦听睡眠终端设备可以进入能量模式EM0-EM2，非侦听设备可以进入EM0-EM2和em4-休眠模式。

ZAF/ApplicationUtilities中引入了一个叫做PowerManagement的新模块。如果侦听睡眠终端设备或非侦听应用程序希望在给定时间内保持清醒，则该模块用于与协议通信。该模块使注册所谓的电源锁成为可能，当启用时防止处理器进入低功耗模式。电源锁可以在可选的毫秒数后设置为超时，也可以无限期地启用，直到被一个新的函数调用取消。(通过将超时值设置为零可以启用无限电源锁。)

电源锁以下表中描述的两种配置之一进行注册:

6. True Status模块

True Status模块实现了生命线报告的需求，如文档“Z-Wave Plus v2 Device Type Specification”中指定的那样。

True Status模块的主要组件将在以下小节中描述

6.1 True Status 引擎(TSE)

TrueStatusEngine组件位于ZAF_ApplicationUtilities_TrueStatusEngine文件夹中，由以下源文件组成:

• ZAF_TSE.c
• ZAF_TSE.h

TSE实现了注册和处理状态更改事件的功能，节点希望向其生命线关联组成员报告这些事件。

状态变化可以由远程通知中的命令或本地更改(例如按下按钮)触发。

公共函数：

bool ZAF_TSE_Init();

 初始化True Status引擎的函数。在初始化过程中由ZAF调用。

bool ZAF_TSE_Trigger(void* pCallback, void* pData, bool overwrite_previous_trigger);

用于注册状态变化事件并在预定义的延迟之后触发将报告发送到生命线组成员的函数。延迟目前被定义为250毫秒。延迟是一种防止网络碰撞和避免因状态快速变化而产生冗余报告的手段。

该函数还负责将报告发送给相关的生命线组成员; 也就是说，它不会将报告发送到发出导致状态改变的命令的生命线目的地。当前实现最多可以在队列中保存3个不同的状态更改请求，等待预定义的延迟过期。在此期间的其他请求将被丢弃。

参数：

- pCallback: 指向回调函数的指针，该函数用于向生命线组成员发送状态更改报告。(下一节将详细描述)。

- pData: 指向一个数据结构的指针，该数据结构将作为参数传递给pCallback函数。pData指向的结构必须首先包含一个RECEIVE_OPTIONS_TYPE_EX变量，该变量指示触发更改的接收帧的属性。本地更改还必须在pData结构中包含RECEIVE_OPTIONS_TYPE_EX。

- overwrite_previous_trigger: 一个布尔参数，指示是否应该丢弃pData结构中具有相同pCallback和相同源端点的前一个触发器。将其设置为true以覆盖以前的触发器，设置为false以堆叠所有触发器消息。

如果成功返回true。如果无法处理请求(队列已满)，则为False。

6.2 True Status回调功能

True Status Callback函数由几个函数组成，这些函数实现了向生命线关联组成员发送实际状态更改报告的功能。这些函数在每个相关的命令类模块中实现。

真正的状态回调函数的参数传递到ZAF_TSE_Trigger()函数(在前一节中描述),它将由真实状态引擎执行发送状态更改报告的相关生命线小组的成员,一次一个。

一个True状态回调函数实现的例子可以在BinarySwitch Command Class中找到:

void CC_BinarySwitch_report_stx(TRANSMIT_OPTIONS_TYPE_SINGLE_EX txOptions, s_CC_binarySwitch_data_t* pData);

参数：

- txOptions: Tx选项从True Status Engine传递，并带有向给定的生命线成员发送状态更改报告所需的目的地参数。

- pData: 指向先前在调用ZAF_TSE_Trigger()时注册的数据结构的指针。包含要发送的报告的命令数据。

需要注意的是，True Status Callback函数必须只通过单播地址发送状态变化报告，而不是通过组播。因此，确保只使用Transport_SendRequestEP()传输函数，因为它也在CC_BinarySwitch_report_stx()实现中完成。

6.3 True Status序列流

下面的图显示了binarswitch示例的两个用例的函数调用流:1)由远程通知的命令触发的状态更改，和2)由本地更改触发的状态更改(例如，按下按钮)。

• 用例1—由Remote Note中的命令触发的状态更改:

• 用例2 -由本地更改触发的状态更改