在之前的米家APP中，我们有的时候想封装一组操作，例如我想定义一个名叫“离家关闭所有灯”的操作，我需要通过创建一个批量控制，将所有灯的关闭封装在一个批量中。

然而，即使我们在一个批量中全部操作都是可以被本地化的，但当我们在另外一个自动化中调用这个批量控制，这个自动化还是会被定义为云端执行，例如下面的例子：

创建完一个批量控制后，通过它的更多设置查看。

我们可以看到，这个批量控制上本地执行的。

现在，我们创建一个自动化，并且在该自动化中调用这个批量控制。

此时，我们再点开该自动化的执行方式，就会发现，这个自动化将会是云端执行。

如果是云端执行，那么就意味着这个自动化要去米家的服务器绕一圈再回来，执行的响应速度就会慢很多。怎么使它变为本地执行呢？

在有中枢网关的“虚拟事件”之前，我们的做法，是通过一个可以本地的“虚拟开关”来触发关闭全部灯的动作，而不是创建一个批量执行。

例如，我们用一个闲置的可蓝牙Mesh接入中枢网关的通断器的自动化来作为触发（而非使用批量控制）：

因为这个自动化里面的全部设备都是可以本地化执行的，所以这个自动化也是本地执行：

此时，当我们想要触发“关闭全部灯”时，只需要在另外一条自动化中，控制这个自动化中的触发条件即可：

而此时，这一条自动化中，所有的设备也是可以本地执行的，因此，它的执行方式也是本地。

这样，我们就实现了把一个批量的“关闭全部灯”做到了完全的本地化。

但是这个方案里面有一个问题，就是我们必须要有一个闲置的可本地执行的开关或其他设备，这就增加了成本，如果需要有很多类似的批量操作，我们的成本就会蹭蹭蹭往上涨。而且，还存在一个细节，就是我们需要控制好这个设备的开关状态，例如上面截图中，我就漏了要把这个开关状态重置为关闭状态的步骤。

而如果我们购买了中枢网关，就可以直接使用中枢网关的虚拟事件来替换上面的那个开关的设计，一分钱不花，想要多少批量就有多少批量。（当然，如果你没有中枢，也没必要为了这个设计而去花钱，走云端也不是不行。）

首先，你需要将中枢的固件升级到最新。接下来，我们在上面那个方案的触发条件中进行修改，把原来基于开关的触发条件删掉

并重新添加触发条件，添加时，选择中枢网关，选择“虚拟事件发生”：

点击选中之后，会进入到一个新界面，在新界面，会让你输入文字，此时，你可以输入任何内容，但是要把输入的这段内容记住。

完成之后，点击确定，保存这条自动化，这样你就建立了一个基于中枢网关虚拟事件的批量操作。

接下来，就是修改我们前面用来触发这个批量操作的那个自动化，添加执行动作时，选中中枢网关，此时，它的选项变成了“产生虚拟事件”：

点进去之后，和我们前面看到的一个输入界面几乎一样，此时，把你之前输入过的内容，再输入一遍：

再点确认，保存自动化。这样，你就得到了用于调用“关闭全部灯”的批量操作的自动化任务。

此时我们进到它的更多设置里面，看到它的执行方式也是本地。

这样，我们就完成了我们的这个配置。

在这次设计中，我们实际上目的是为了创建一个批量控制，但是这个批量控制是基于中枢网关的虚拟事件来实现的，由于中枢网关本身就是一个本地化的载体，因此，它的执行也是本地化的。

我们可以灵活应用虚拟事件，因为它是通过你输入的文本来识别的，因此，可以存在无限多个虚拟事件，只要你管理的好，就可以利用虚拟事件实现非常多的能力。你可以关注我的B站，我还找到了用虚拟事件实现延迟条件判断的方法。