Possible to listen for scenes activations?

[thundergreen]

I have an idea where i need to create a sensor once a scene has been activated. Using the even call-service gives me this nice piece of code:

{
    "event_type": "call_service",
    "data": {
        "domain": "scene",
        "service": "turn_on",
        "service_data": {
            "entity_id": "scene.evening_light"
        }
    },
    "origin": "LOCAL",
    "time_fired": "2020-04-21T19:48:42.472930+00:00",
    "context": {
        "id": "bb8e9486138a4c45b0feda4386005a93",
        "parent_id": null,
        "user_id": "9f64f27b8c134e0aa5e8bd26ac59ff0a"
    }
}

Can i Use this also for the sensor and if how? :) Would highly be interested as THIS was exactly what I was looking for some days ogo :)

[azogue]

Hi @thundergreen,

That event filter is not possible with the current version, because of the sub-filtering you need (filter events with a nested dict inside, like {"service_data": {"entity_id": "scene.evening_light"}}

I will try to make a fix for that kind of situation. The sensor aimed to filter simple events with just specific key: value pairs inside. To filter "call_service" for specific service_data, fine-grained filtering is needed.

Also, I just discovered a bug in the event filter: In

eventsensor/custom_components/eventsensor/sensor.py

Line 108 in bcabeae

if self._event_data.items() < event.data.items():

it should use <=, not <. I will also fix that.

[azogue]

@thundergreen, with the changes I'm doing right now, it will be possible to do what you want :)

In your case, the yaml would be:

sensor:
  # Sensor to retain the last time a specific scene is turned on 
  - platform: eventsensor
    name: Last activation
    event: call_service
    state: service_data.entity_id
    event_data:
      domain: scene
      service: turn_on
      service_data:
        entity_id: scene.evening_light

  # Sensor to retain the last activated scene, with custom mapping for pretty states 
  - platform: eventsensor
    name: Last scene
    event: call_service
    state: service_data.entity_id
    event_data:
      domain: scene
      service: turn_on
    state_map:
      scene.evening_light: Evening
      scene.afternoon_light: Afternoon
      scene.other: Other scene
      # ...

The 1st sensor would look only to that specific scene, the 2nd one would update for any scene being turn_on, showing the scene as state.

I suppose the 2nd one is more useful, right?

BTW, thanks for your input here, this usage suggestion opens new possibilities for this sensor as a very useful debug helper.

Wait a bit for the next release, which enables UI configuration (and no more HA restarts) and makes this possible.

A preview ;-)

[Mariusthvdb]

HI Eugenio,
this is getting more beautiful on each thought you share, wow.

also, seems to be getting close to what I use the CC variable for: recording the last motion in the house. Would an event like a motion sensor turning on be possible to record using your eventsensor? and store the in the history?

currently using:

automation:
# Update Last Motion variable
  - alias: 'Update Last Motion'
    id: 'Update Last Motion'
    trigger:
      platform: state
      entity_id:
        - binary_sensor.laundry_sensor_motion
        - binary_sensor.dining_table_sensor_motion
        - binary_sensor.auditorium_sensor_motion
        - etc, etc,etc
      to: 'on'
    action:
      - delay:
          seconds: 2
      - service: variable.set_variable
        data:
          variable: last_motion
          attributes_template: >
            {
                  "history_1":"{{variable.state}}",
                  "history_2":"{{variable.attributes.history_1}}",
                  "history_3":"{{variable.attributes.history_2}}",
                  "history_4":"{{variable.attributes.history_3}}",
                  "history_5":"{{variable.attributes.history_4}}"
            }
#                  "history_6":"{{variable.attributes.history_5}}",
#                  "history_7":"{{variable.attributes.history_6}}",
#                  "history_8":"{{variable.attributes.history_7}}",
#                  "history_9":"{{variable.attributes.history_8}}",
#                  "history_10":"{{variable.attributes.history_9}}"
#            }
        data_template:
          value: >
            {{trigger.to_state.attributes.friendly_name|replace(' sensor motion','')}}:
            {{as_timestamp(states.variable.last_motion.last_changed)|timestamp_custom('%X')}}

[azogue]

seems to be getting close to what I use the CC variable for: recording the last motion in the house. Would an event like a motion sensor turning on be possible to record using your eventsensor? and store the in the history?

Hi @Mariusthvdb,

No, I don't think it would be a good usage. In fact, you are confusing terms there. A motion sensor turning on is not an HA event. It is a state change.

Another thing is that any entity state change fires a state_changed event, but those are forbidden to listen for in this CC, as a safety measure (as the created sensor also will fire events of that kind when it changes)

What you have there is too complex for my taste :)
I would solve it with an appdaemon app, if a template sensor is not sufficient. I would not follow the variable CC way, but it is only my opinion. Also, you are mixing strings with json, so it appears to be a hell of a manual parsing right there. Does it work? (if so, why do you want to change it?)

[Mariusthvdb]

yes it works right now, and has been for almost 3 years.. I was indeed thinking of the state_changed event, not so much the state change itself.

a template sensor isn't sufficient as that cant record the history in its attributes, like this:

was merely thinking your new eventsensor could catch this too, and maybe allow to leave the CC Variable, since that isn't updated in a long long time, and your CC is brand new, keeping up with the latest of developments ;-)

Must admit I have no idea how this could be done in Appdaemon.

[azogue]

cc @Mariusthvdb

Must admit I have no idea how this could be done in Appdaemon.

You're welcome :)

Check this commit: azogue/hassio_config@e212999

[Mariusthvdb]

magic!

I'll enable recorder on the sensor.

thank you very much! this is so cool, and very very immediate. hugely impressed.

I have 1 other automation using the CC variable, and immediately started to check if I could easily rebuild the last_motion to use my daylight variables, but am lost...

If you have would have another spare moment, might I kindly ask you to have a look at this, and see if AD can handle that too. Don't feel any pressure what so ever, don't want to impose.

  set_daylight_variables:
    alias: 'Set Daylight variables'
    sequence:
      - service: variable.set_variable
        data:
          variable: virtual_light_daylight
          attributes_template: >
            {
                  "history_1": "{{ variable.state }}",
                  "history_2": "{{ variable.attributes.history_1 }}",
                  "history_3": "{{ variable.attributes.history_2 }}",
                  "history_4": "{{ variable.attributes.history_3 }}",
                  "history_5": "{{ variable.attributes.history_4 }}"
            }
        data_template:
          value: >
            {{tostate}} : {{states('sensor.virtual_light')}} :
            {{states('sensor.poort_buiten_motion_sensor_light_level')}}
      - service: input_number.set_value
        data_template:
          entity_id: input_number.solar_angle_outside_light
          value: >
            {{states('sensor.solar_angle')}}
      - service: input_number.set_value
        data_template:
          entity_id: input_number.virtual_light
          value: >
            {{states('sensor.virtual_light')}}
      - service: variable.set_variable
        data:
          variable: solar_angle_outside_light
          attributes_template: >
            {
                  "history_1": "{{ variable.state }}",
                  "history_2": "{{ variable.attributes.history_1 }}",
                  "history_3": "{{ variable.attributes.history_2 }}",
                  "history_4": "{{ variable.attributes.history_3 }}",
                  "history_5": "{{ variable.attributes.history_4 }}"
            }
        data_template:
          value: >
            {{states('sensor.solar_angle')}}
      - service: variable.set_variable
        data:
          variable: virtual_light_outside_light
          attributes_template: >
            {
                  "history_1": "{{ variable.state }}",
                  "history_2": "{{ variable.attributes.history_1 }}",
                  "history_3": "{{ variable.attributes.history_2 }}",
                  "history_4": "{{ variable.attributes.history_3 }}",
                  "history_5": "{{ variable.attributes.history_4 }}"
            }
        data_template:
          value: >
            {{states('sensor.virtual_light')}}

[azogue]

cc @Mariusthvdb

If you have would have another spare moment, might I kindly ask you to have a look at this,

Too much Marius, don't overdo it. With what I showed to you I think it is sufficient, you should be capable of continuing from it. Also, big off-topic here.

[thundergreen]

Thanks a lot @azogue that sensor extends my possibilities in automations a lot