人体传感器中的移动检测情况传感器建议n分钟未检测到人体移动后置为‘无人’

[hzcoolwind]

设备信息
lumi.sensor_motion.v2
制造商：Aqara

传感器：
移动检测传感器移动检测情况
（sensor.lumi_cn_lumi_158xxxxxxx_v2_motion_state_p_2_1）

目前情况：
一旦检测到有人移动，该传感器即为‘有人', 不论之后以否检测到人体移动一直为‘有人’

建议：
N分钟内未检测到人体移动，置为‘无人’， N分钟内检测到有人移动，仍然为‘有人’， N分钟的N重置。

[JimmyKmi]

人体传感器没有状态，重置需求可通过自动化实现。若需转换为状态可以考虑用辅助实体。

[fjndwnx123]

hzcoolwind 想表达的可能不是需要增加“State”。而是移动传感器的 sensor 这个 entity 的数值始终都是“有人”。而查看 Attributes 能发现，这个变量的可能取值是有“有人” 和 “无人” 这两个 Possible states 的。但实际情况却是，哪怕目前传感器面前已经没人很长时间的，其数值始终为 “有人”。他的建议也是 “N分钟内未检测到人体移动，置为‘无人’” 。这样就可以把移动传感器作为某个自动化的 trigger 了 （例如如果“无人”就关闭某盏灯）。而实际上手机里小米的app是有这个自动化 trigger 选项的。这也是我困惑的地方，为什么 home assistant 里面的 entity 无法实现这一点。

[hzcoolwind]

如果没状态这个sensor.lumi_cn_lumi_158xxxxxxx_v2_motion_state_p_2_1 不如去掉吧， 当然如你所说自动化实现是没问题的，通过事件来检测，但是这个sensor确实让人困惑

[refined-fish]

我也有一个 lumi.motion.bmgl01 人体传感器，似乎目前这种人体传感器对于是否有移动都是通过 事件event 上报的，没有 状态 的说法。虽然有 传感器 类型，但明显功能与我们预期的 “有人/无人” 完全不一样，猜测可能是最开始硬件设计的问题，这些设备在米家中的显示很可能是借用了额外的软件判断逻辑。这确实不便我们使用HomeAssistant（与此类似的例子还不少，尤其是不符合米家标准的带*自定义实体）

[JimmyKmi]

hzcoolwind 想表达的可能不是需要增加“State”。而是移动传感器的 sensor 这个 entity 的数值始终都是“有人”。而查看 Attributes 能发现，这个变量的可能取值是有“有人” 和 “无人” 这两个 Possible states 的。但实际情况却是，哪怕目前传感器面前已经没人很长时间的，其数值始终为 “有人”。他的建议也是 “N分钟内未检测到人体移动，置为‘无人’” 。这样就可以把移动传感器作为某个自动化的 trigger 了 （例如如果“无人”就关闭某盏灯）。而实际上手机里小米的app是有这个自动化 trigger 选项的。这也是我困惑的地方，为什么 home assistant 里面的 entity 无法实现这一点。

如 @refined-fish 所说，这个传感器有人无人是没有status的，即当初定义的时候有人是一个spec event，无人是另外的event。如果要做按照我的理解只能集成把无人的event和有人的event合一下做个status。无人的delay也不是那么好实现自定义。具备解决的可能性，具体方案还要看看是否所有的传感器有人/无人上报用的参数以及传的数据都标准等，实际操作有待考究。
此外*的spec是厂家自定义的，具体实现方法那更是五花八门。

[refined-fish]

如果要做按照我的理解只能集成把无人的event和有人的event合一下做个status。无人的delay也不是那么好实现自定义。具备解决的可能性，具体方案还要看看是否所有的传感器有人/无人上报用的参数以及传的数据都标准等，实际操作有待考究。

@JimmyKmi 如果官方能给出解决逻辑那简直太妙了，我现在在自动化中都是使用 “移动event”一旦触发当做有人，和“无人移动时间sensor”一旦发生变化当做无人，比如下图：（not逻辑是为了避免离线上线也触发）

虽然大佬提到了自建辅助传感器，但是我没想到太好的思路，例如如下的失败配置，不知道大佬有没有什么好点子🤦‍♂️

{% if states('sensor.lumi_cn_blt_3_19qdk57tglk00_bmgl01_no_motion_duration_p_2_2') != 'unknown' and
      states('sensor.lumi_cn_blt_3_19qdk57tglk00_bmgl01_no_motion_duration_p_2_2') != 'unavailable' and
      (now() - states.sensor.lumi_cn_blt_3_19qdk57tglk00_bmgl01_no_motion_duration_p_2_2.last_changed).total_seconds() < 1 %}
    无人移动
{% elif is_state('event.lumi_cn_blt_3_19qdk57tglk00_bmgl01_motion_detected_e_2_1', 'triggered') %}
    有人移动
{% else %}
    未知
{% endif %}

[fjndwnx123]

在 @refined-fish 提到的方案的启发下，我尝试了一下 helper （应该就是辅助传感器？），我的做法是在 configuration.yaml 里面增加一个 template 配置（ template 是 helper 的一种，而根据官方文档， trigger 类型的 template 无法在图形界面配置，因此我在 configuration.yaml 里添加）效果挺不错的，算是在一定程度上实现了我想要的效果。代码如下所示：（如果需要复制的话，可能需要根据你的配置文件的情况将整体缩进略作调整）

- trigger:
    platform: state
    entity_id: event.lumi_cn_lumi_xxxxxxx_v2_motion_detected_e_2_1
    not_to:
      - unknown
      - unavailable
  binary_sensor:
    - name: motion_sensor_state_1
      unique_id: motion_sensor_state_xxxxxxx
      auto_off: 120
      state: "true"

这里使用 trigger 类而非 state 类 的 template 的原因是，trigger 类只会在trigger 发生时触发，而 state 类监测的更多更频繁，尤其是涉及到时间相关的参数。虽然我这里的用法似乎两者差异不大，但出于个人喜好还是尽可能使用 trigger 类 template。

这里的 state:"true" 的作用是让 trigger 被侦测到的时候，就将这个虚拟开关置成“开”。而 auto_off: 120 官方文档中介绍这个 state 被置成 true 之后过 120 秒会自动变成 off。值得一提的是，官方文档中对 auto_off 的描述会让人感觉是 “120秒后，不论如何都会自动变成 off” 那如果人一直在传感器面前活动，岂不是会每隔 120 秒就 off 一下。但实际上我自己验证下来，这个 auto_off 是能起到我们想要的效果的——也就是如果人一直在传感器面前活动，它始终都会处于 on 的状态。 这里之所以设置 120 秒是因为小米的人体传感器本身的采样间隔是1分钟，只要大于 60 秒即可。我出于个人的习惯设置成了120秒。

注：
如果复制上述代码，请注意 entity_id: 字段修改成你的传感器的数值，并且根据自己的喜好设置一个 unique_id。如果你添加了多个 template，它们的 unique_id 需要不同。