TillFleisch / ESPHome-HLK-LD2450

ESPHome support for the HI-Link HLK-LD2450 millimeter wave sensor (external component) with support for custom zones using convex polygons.
MIT License
105 stars 19 forks source link

Setting delayed_off filter results two state changes at the end of the delay period #24

Closed toml0006 closed 3 months ago

toml0006 commented 3 months ago

TLDR: if occupancy detected → cleared → detected inside a time window defined by delayed_off the sensor will publish two state changes - OFF immediately followed by ON at the end of the delayed_off window.

Using the following configuration

LD2450:
  uart_id: uart_bus
  flip_x_axis: true
  fast_off_detection: true
  max_detection_tilt_angle:
    name: "Max Tilt Angle"
    initial_value: 40°
  min_detection_tilt_angle:
    name: "Min Tilt Angle"
    initial_value: -40°
  max_detection_distance:
    name: "Max Distance"
    initial_value: 4m
  max_distance_margin: 30cm

  occupancy:
    name: Occupancy
    filters:
      delayed_off: 10s
    #   delayed_on: 500ms
    #   settle: 10s
  target_count:
    name: Target Count

In the case below, I am sitting in front of the sensor holding very still so the sensor state clears. As you can see from the logs, 10s after the sensor initially detects 0 targets, the OFF state is sent.

[13:05:10][D][sensor:093]: 'Target Count': Sending state 0.00000  with 0 decimals of accuracy
[13:05:19][D][binary_sensor:036]: 'Occupancy': Sending state OFF

11s later, I move into the detection area triggering an ON state - so far so good

[13:05:10][D][sensor:093]: 'Target Count': Sending state 0.00000  with 0 decimals of accuracy
[13:05:19][D][binary_sensor:036]: 'Occupancy': Sending state OFF
[13:05:30][D][binary_sensor:036]: 'Occupancy': Sending state ON
[13:05:30][D][sensor:093]: 'Target Count': Sending state 1.00000  with 0 decimals of accuracy

Next, I hold very still to clear the presence detection 13:05:37, after which I move again 13:05:38.

[13:05:10][D][sensor:093]: 'Target Count': Sending state 0.00000  with 0 decimals of accuracy
[13:05:19][D][binary_sensor:036]: 'Occupancy': Sending state OFF
[13:05:30][D][binary_sensor:036]: 'Occupancy': Sending state ON
[13:05:30][D][sensor:093]: 'Target Count': Sending state 1.00000  with 0 decimals of accuracy
[13:05:37][D][sensor:093]: 'Target Count': Sending state 0.00000  with 0 decimals of accuracy
[13:05:38][D][sensor:093]: 'Target Count': Sending state 1.00000  with 0 decimals of accuracy
[13:05:47][D][binary_sensor:036]: 'Occupancy': Sending state OFF
[13:05:47][D][binary_sensor:036]: 'Occupancy': Sending state ON

The problem: notice how at 13:05:47 the Occupancy state rapidly flips from OFF to ON. The net result of the occupancy state is ON, but I have the occupancy tied to an automation watching for both states. Since this happens so fast, the first automation is not complete by the time the second state change again triggers the automation - this means the second execution is ignored and the end result is that the OFF automation is fired even though the current state is ON. My current bandaid to the rapid state change is to put a 3 minute duration check on the OFF state change.

It is totally possible that I don't understand how filters are supposed to work; to me, it seems that with delayed_off: 10s in the above configuration the ON state change would only fire if the sensor detected presence after 10s of no presence detection. Or put in context of my example above: I am surprised to see the last two log messages where any state change is published.

TillFleisch commented 3 months ago

I was able to replicate this, good catch! I'll have a look once I find some time.