Zone Occupancy Sensors are unreliable

[tomkessler]

Submitting this ticket after talking with Brandon Harvey about this issue.

I have my MSR-2 mounted on a post of the desk in my office. I'd like to be able to know if my office is occupied in that (1) I'm sitting at my desk or (2) I'm somewhere else in the room.

I set up the Zone endpoints accordingly, yet the Zone Occupancy sensors seemed very unreliable. See here how the "Zone 1 Occupancy" is OFF (Green box) yet the radar clearly sees something within the 150cm range.

I traced this back to the fact that the Zone Occupancy sensors are based on "Radar Detection Distance" and "Radar Detection Distance" seems unreliable.

For example, sitting at my desk with my legs fairly close to the sensor ...

Note how the "Radar Detection Distance" shows 0cm but the "Radar Still Distance" shows 30cm with a "Radar Still Energy" of 100% (the 2 Still values are accurate, given my legs are 30cm away; not sure why overall "Radar Detection Distance" shows 0cm).

So, what I did was mock up a couple template sensors for my use case as follows. I can imagine many ways to enhance these, but this was a quick POC to determine if I could output more reliable occupancy. These seem to be working much more reliably than the builtin Zone sensors.

binary_sensor:

  - platform: template
    name: "Radar Desk Occupancy"
    id: radar_desk_occupancy
    device_class: occupancy
    icon: mdi:motion-sensor
    lambda: |-
      if (((id(radar_has_still_target).state) && ((id(still_distance).state < id(radar_z1_end).state) && (id(still_distance).state > id(radar_z1_start).state))) || ((id(radar_has_moving_target).state) && ((id(moving_distance).state < id(radar_z1_end).state) && (id(moving_distance).state > id(radar_z1_start).state))))
      {
        return true;
      } else {
        return false;
      }

  - platform: template
    name: "Radar Room Occupancy"
    id: radar_room_occupancy
    device_class: occupancy
    icon: mdi:motion-sensor
    lambda: |-
      if (((id(radar_has_still_target).state) && ((id(still_distance).state < id(radar_z2_end).state) && (id(still_distance).state > id(radar_z1_end).state))) || ((id(radar_has_moving_target).state) && ((id(moving_distance).state < id(radar_z2_end).state) && (id(moving_distance).state > id(radar_z1_end).state))))
      {
        return true;
      } else {
        return false;
      }

Maybe applying similar logic to the builtin Zone template sensors would make them more reliable?

[TrevorSchirmer]

Thanks for this, I just added the changes to our beta branch and we'll begin testing them out

[kevin-david]

How's beta testing going? I have a similar problem with my sensor where things get stuck in a Detected state. Trying out the beta branch to see if that fixes it.

[kevin-david]

So far I haven't seen much improvement on the beta branch and some sensors are going unavailable now. For example:

[TrevorSchirmer]

So far I haven't seen much improvement on the beta branch and some sensors are going unavailable now. For example:

Thanks for letting us know. This was a bug for the energy entities that another user was able to fix. In the latest beta it has been updated

[kevin-david]

Thanks, that was fixed, but I'm still seeing "sticky" zone occupancy sensors. At this point I might have to resort to a derived template sensor based on still energy - that seems to be the best proxy for occupancy across all zones AFAICT - for my application I don't really care which zone is occupied. Any other suggestions?

[maxi1134]

Hey guys,

I am possibly about to order a few MTR-1 to integrate into my installation and I am wondering if these issues are fixed as of today. I hope to rely on these for my zoning needs instead of the FP2s I have

[TrevorSchirmer]

Thanks, that was fixed, but I'm still seeing "sticky" zone occupancy sensors. At this point I might have to resort to a derived template sensor based on still energy - that seems to be the best proxy for occupancy across all zones AFAICT - for my application I don't really care which zone is occupied. Any other suggestions?

What is your still / moving distances at when this happens? I'll get back into looking at this.

[TrevorSchirmer]

Hey guys,

I am possibly about to order a few MTR-1 to integrate into my installation and I am wondering if these issues are fixed as of today. I hope to rely on these for my zoning needs instead of the FP2s I have

These were some improvements on the zone functionality and distance reporting. We have some beta firmware looking at improving it but it hasn't been merged into production yet

[codemonkey2k5]

Also having sticky zone's.