What's happening in my house ? Elegant way to distinguish “real human interaction” events

Configuration
1

I’m trying to implement a robust “vacancy” logic for entire areas or tags in cases where I do not have a reliable presence detection devices.

In a whole room I can have different devices producing either events or state change events.
The process to list them is quite cumbersome and I feel something is missing in home assistant. We cannot figure quickly which event is an event from a human or from something else (script, automation …)

From now I am listing all events which are real human one and filter events so I know it is produce by human:

type: shelly.click
    filters:
      device: "shellyswitch25-E09"
      click_type: "btn_down"
    friendly_name: "inter et1_intdbl_entree_haut"
type: state_changed
    filters:
      entity_id: "binary_sensor.shellyswitch25_40f8f_channel_1_input"
    friendly_name: "inter et1_int_wc 1"

Is there a cleaner, maintainable way to achieve this result ?

2

I have been usingTommy recently. It works well. It is quick way to setup almost mww quality sensor that covers large areas. I recently removed from my devices as it was not compatible with latest version of esphome but he said he was looking into and he is responsive. If I add in future it will probably be separate from my Voice devices.

I currently do not have an opinion of this other than it does work as advertised. I was suprised and impressed.
It is not open source and I cannot see code.
Long term I expect I will stop using and move on but you never know.

EDIT
espectre is a similar opensource project but Tommy look more polished/complete at the moment.

1 Like
3

I looked at the thread title and sighed, that you may have been too late for Halloween and ghost detectors in the castle.

Do areas support what you are looking for?

4

Yes we can: How to use context

Three conditions are all you need.

5

Hi everyone, I’m the creator of ESPectre, and I wanted to let you know that I’ve just released version 2.0.0, which addresses exactly this kind of use case!

The new version is a complete rewrite and is now fully based on ESPHome (the previous version used ESP-IDF), making it seamlessly integrated with Home Assistant.

Key features for vacancy detection:

  • Binary sensor that exposes IDLE/MOTION states - perfect for creating automations based on real human presence
  • Adjustable sensitivity threshold directly from Home Assistant - no need to reflash or reconfigure the device
  • Still completely open source

This should give you a much cleaner and more maintainable way to detect actual human activity in your rooms, without having to manually list and filter all possible input events.

The IDLE/MOTION detection works reliably across large areas and can be fine-tuned for different room types and sensitivity requirements directly through the HA interface.

Feel free to reach out if you have any questions!

1 Like
6

There is this:

##########################################################
## Diagnostic: What caused the State Change
##########################################################
- id: what_caused_the_state_change
  alias: What caused the State Change
  description: 'What caused the State Change'
  initial_state: TRUE
  mode: queued
  trigger:
  - platform: state
    entity_id:
    - light.kitchen_can_lights
    - light.kitchen_pendants
  condition: []
  action:
  # Physical
  - choose:
    - conditions:
      - condition: template
        value_template: '{{ trigger.to_state.context.parent_id == none }}'
      - condition: template
        value_template: '{{ trigger.to_state.context.user_id == none }}'
      - condition: template
        value_template: '{{ trigger.to_state.context.id != none }}'
      sequence:
      - service: variable.set_variable
        data:
          variable: vh_diagnostic_message
          value: '{{ trigger.entity_id }} likely Physical switched to {{ trigger.to_state.state |upper }}'
          attributes:
            parent_id: '{{ trigger.to_state.context.parent_id }}'
            user_id: '{{ trigger.to_state.context.user_id }}'
            context_id: '{{ trigger.to_state.context.id }}'
  # Automation
    - conditions:
      - condition: template
        value_template: '{{ trigger.to_state.context.parent_id != none }}'
      - condition: template
        value_template: '{{ trigger.to_state.context.user_id == none }}'
      - condition: template
        value_template: '{{ trigger.to_state.context.id != none }}'
      sequence:
      - service: variable.set_variable
        data:
          variable: vh_diagnostic_message
          value: '{{ trigger.entity_id }} likely Automation switched to {{ trigger.to_state.state |upper }}'
          attributes:
            parent_id: '{{ trigger.to_state.context.parent_id }}'
            user_id: '{{ trigger.to_state.context.user_id }}'
            context_id: '{{ trigger.to_state.context.id }}'
  # User Interface
    - conditions:
      - condition: template
        value_template: '{{ trigger.to_state.context.parent_id == none }}'
      - condition: template
        value_template: '{{ trigger.to_state.context.user_id != none }}'
      - condition: template
        value_template: '{{ trigger.to_state.context.id != none }}'
      sequence:
      - service: variable.set_variable
        data:
          variable: vh_diagnostic_message
          value: '{{ trigger.entity_id }} likely UI switched to {{ trigger.to_state.state |upper }}'
          attributes:
            parent_id: '{{ trigger.to_state.context.parent_id }}'
            user_id: '{{ trigger.to_state.context.user_id }}'
            context_id: '{{ trigger.to_state.context.id }}'
    default: []
#

9f58d4c26ecbf53ddbb35cca88956ede8502da41

To be honest, I don’t know if this is valid anymore. I used to use it for detecting user vs automation based events and it worked well. But that was some time ago. In any case the code is included if you want to give it a go. You’ll need to change the set_variable command to either a persistent notification or something else though. I left it in place for the sake of how it was coded.

7

Yes it is.