oneM2M 中的执行器控制
Actuator Control in oneM2M
我阅读了有关在 OneM2M 中进行双向通信的文档。我知道这样做的一种方法是使用订阅和通知系统。假设我们有一个如下图所示的示例。 IN-AE（智能手机）想要打开 ADN-AE2 的灯。假设注册和资源创建已经完成，并且 ADN-AE-2 已经订阅了 ADN-AE-2 中的灯容器。
因此，oneM2M 涵盖了 IN-AE 如何发送灯光控制请求以及 ADN-AE-2 或 ADN-AE-1 如何接收来自 IN-AE 的请求并执行它的部分。但是，如果 ADN-AE-2 无法控制光线而控制它时发生故障怎么办。应该是什么场景？内容实例已根据 IN-AE 发送的请求创建。
1- ADN-AE-2 是否应该创建另一个容器的先前状态的内容实例
2- ADN-AE-2 是否应该删除未执行的内容实例（那么其他接受通知并成功执行的订阅者呢）
如果执行器不能做动作，推荐的方法应该是什么？
http://www.onem2m.org/tr-0034/procedures/actuator-switch-control
这是异步通信中的普遍问题。当接收方从未收到命令，或者只是无法执行命令时会发生什么（无论出于何种原因，例如它正忙于做其他事情或请求超出某些参数）？
您的两个选项都有效，但在ADN离线时不起作用，导致ADN-AE2无法执行程序。此外，即使 ADN 始终在线，当有不止一个其他 AE 想要控制 ADN-AE2，或者当 IN-AE 不耐烦地一次又一次地设置所需状态时，这两个程序都会出现问题。这通常可能会导致竞争条件。
我建议重新考虑两个 AE 之间的通信方案，并将原始 Container 拆分为两个：一个 Container 用于 target 状态，另一个 Container 用于 状态状态。 target Container 被 AE（ADN-AE2 除外）用来设置所需的状态。 ADN-AE2 收到创建新 ContentInstance 的通知并采取相应行动。然后它在反映新内部状态的 state 容器中创建一个新的 ContentInstance，这将通知 IN-AE 反映变化。
下图反映了此模式的示例资源结构：
AE ─┬─ Container_target ─── ContentInstances* ◀═══ Container for desired state, set by other AEs
│
└─ Container_state ─── ContentInstances* ◀═══ Container for actual state, set only by this AE
当节点之间的连接并不总是可靠时，或者当状态更改请求的结果并不总是得到保证时，这是异步通信中的常见模式。执行请求的责任在于 ADN-AE2，重试或对失败做出反应的频率的策略在于 IN-AE。
我阅读了有关在 OneM2M 中进行双向通信的文档。我知道这样做的一种方法是使用订阅和通知系统。假设我们有一个如下图所示的示例。 IN-AE（智能手机）想要打开 ADN-AE2 的灯。假设注册和资源创建已经完成，并且 ADN-AE-2 已经订阅了 ADN-AE-2 中的灯容器。
因此，oneM2M 涵盖了 IN-AE 如何发送灯光控制请求以及 ADN-AE-2 或 ADN-AE-1 如何接收来自 IN-AE 的请求并执行它的部分。但是，如果 ADN-AE-2 无法控制光线而控制它时发生故障怎么办。应该是什么场景？内容实例已根据 IN-AE 发送的请求创建。
1- ADN-AE-2 是否应该创建另一个容器的先前状态的内容实例
2- ADN-AE-2 是否应该删除未执行的内容实例（那么其他接受通知并成功执行的订阅者呢）
如果执行器不能做动作，推荐的方法应该是什么？
http://www.onem2m.org/tr-0034/procedures/actuator-switch-control
这是异步通信中的普遍问题。当接收方从未收到命令，或者只是无法执行命令时会发生什么（无论出于何种原因，例如它正忙于做其他事情或请求超出某些参数）？
您的两个选项都有效，但在ADN离线时不起作用，导致ADN-AE2无法执行程序。此外，即使 ADN 始终在线，当有不止一个其他 AE 想要控制 ADN-AE2，或者当 IN-AE 不耐烦地一次又一次地设置所需状态时，这两个程序都会出现问题。这通常可能会导致竞争条件。
我建议重新考虑两个 AE 之间的通信方案，并将原始 Container 拆分为两个：一个 Container 用于 target 状态，另一个 Container 用于 状态状态。 target Container 被 AE（ADN-AE2 除外）用来设置所需的状态。 ADN-AE2 收到创建新 ContentInstance 的通知并采取相应行动。然后它在反映新内部状态的 state 容器中创建一个新的 ContentInstance，这将通知 IN-AE 反映变化。
下图反映了此模式的示例资源结构：
AE ─┬─ Container_target ─── ContentInstances* ◀═══ Container for desired state, set by other AEs
│
└─ Container_state ─── ContentInstances* ◀═══ Container for actual state, set only by this AE
当节点之间的连接并不总是可靠时，或者当状态更改请求的结果并不总是得到保证时，这是异步通信中的常见模式。执行请求的责任在于 ADN-AE2，重试或对失败做出反应的频率的策略在于 IN-AE。