💬 Entity State Notification

Could you explain what you’ve tried to configure? I have no problems with a minimal setup like an entity, the state and a notify device.

Hello Panhans,

thanks for the blueprint.
I use your blueprint to notify my Android phone about my open windows.
I also have the notification display the time for how long the window has been open.
But I have noticed that the automation behaves strangely when the window is briefly closed and then reopened.
I get the notification on my phone after the set time.
After the set repeat time, the repeat notification also comes and the window open time is also updated.
If the window is now briefly closed and then reopened (e.g. to put it in the tilt position), the Android notification is also removed when it is closed.
But the old repeat message still comes in the set repeat time.
In addition, the new message about the reopening also comes in the set period.
I suspect that the old repeat event is not canceled and then after the set time it is checked whether the state is still open. The status is also opened by closing and reopening.
The old repeat event should actually have been canceled.
As if I trigger the stop function for the Android message, the active waiting event should also be canceled when the window is closed.

Is this behavior working as designed?
Or do I have to configure something special?

I test the current Github version 2.3.0, but the older one have the same result.

1 Like

I’d just pushed an updated. The bug should be fixed. But there is one breaking change depending on the time options. I switched them to duration selectors. So maybe you have to delete the period duration and for duration in yaml and reset them or just delete your old automations and create them new.

Version: 2.4.0

Great blueprint, works well. Thank you!

I use it for sauna current temperature while it is heating.
All the functionality is there but i was wondering if there is an option to make periodic notifications less promiment - I need periodic updates for updating current temperature state in notification message. Currently it triggers new notification, would be nice to be able to just update the message of existing notification so my phone does not light up every time it’s updated. First world problems.

1 Like

You can set a custom channel for the notifications in the blueprint settings. After at least one notification got fired you can navigate in your companion app to companion app settings → notifications / notification channels → select the configured channel and mute it in the settings menu.

Don’t know if this is also possible on iOS. But I know that on iOS I can push a custom sound or no sound with the notification service call. But I have no device to test this here. If you are on iOS just let me know.

@panhans I’m not sure if its mentioned but beyond the breaking changes for duration this requires Home Assistant Core 2024.6 or greater due to the collapsible section features. Just noting for others trying to upgrade. I’m going to give the custom trigger and custom actions a test (I had a custom TTS component in fork but it wasn’t very extensible)

1 Like

after upgrading to 2024.7 I had to log out of the browser and back in to force the update (which changed the behavior of collapsed sections in blueprints)

Yes, had the same issue but reloading with renew the cache did it. (Win: SHIFT+F5) (Mac: cmd+shift+R)

1 Like

Example use case with this blueprint and Custom component (TTS/Alexa)

I did have an issue with the custom component not executing immediately but seemed to execute after the timeout period passed. I created a PR with the working code i’m using. Issue

When any door/window is left open for 5 minutes do the following

  1. Send Notification to Phone
  2. Send message to script to speak on alexa device
    Alexa script uses scenes to capture the current state, set volume to some level, then return to previous state after executing.

Automation YAML

alias: "Door/Window left open Notification "
description: ""
use_blueprint:
  path: panhans/persistent-binary-open-notification.yaml
  input:
    sensor_entity:
      - binary_sensor.alarm_panel_1_zone_7
      - binary_sensor.alarm_panel_1_zone_5
      - binary_sensor.alarm_panel_1_zone_4
      - binary_sensor.alarm_panel_1_zone_6
      - binary_sensor.alarm_panel_1_zone_1
      - binary_sensor.alarm_panel_1_zone_12
      - binary_sensor.alarm_panel_1_zone_8
      - binary_sensor.alarm_panel_1_zone_9
      - binary_sensor.alarm_panel_1_zone_10
      - binary_sensor.alarm_panel_2_zone_6
      - binary_sensor.alarm_panel_1_zone_11
    notify_device: 4ba8cc67d62b8fe0e7975932c497431d
    group: Door-Window-left-open
    active_state: "on"
    title: "{{ entity_name }} {{ state_attr(sensor,'device_class') }} is open"
    message: "{{ entity_name }} {{ state_attr(sensor,'device_class') }} is open"
    ha_notification: true
    notification_color:
      - 255
      - 0
      - 0
    custom_condition:
      - condition: time
        after: "08:00:00"
        before: "23:30:00"
    custom_action_on:
      - service: script.alexa_tts
        data:
          message: >-
            {{ entity_name }} {{ state_attr(sensor,'device_class') }} has been
            left open
    period:
      hours: 0
      minutes: 10
      seconds: 0
    for_time_m:
      hours: 0
      minutes: 5
      seconds: 0

Script Yaml

alias: Alexa TTS
sequence:
  - service: scene.create
    data:
      scene_id: before_alexa_tts
      snapshot_entities:
        - media_player.ecobee_mainfloor
    enabled: true
  - service: media_player.volume_set
    data:
      volume_level: 0.75
    enabled: true
    target:
      device_id: cb9425897ba3ed9541837a62f0d5e5e1
  - service: notify.alexa_media
    data:
      data:
        type: tts
      target: media_player.ecobee_mainfloor
      message: >-
        <audio
        src="soundbank://soundlibrary/sports/golf/golf_07"/><amazon:emotion
        name="disappointed" intensity="high"><amazon:effect name="drc">{{
        message }}</amazon:effect></amazon:emotion>
  - service: scene.turn_on
    data:
      entity_id: scene.before_alexa_tts
    enabled: true
mode: single

2 Likes

Hi panhams,
the periodic bug is still exists.
I updatet the bluprint to version 2.4.0 and created a new automatition.
(HA core is 2024.7.2)

alias: Test2 Fenster offen
description: ""
use_blueprint:
  path: panhans/entity_state_persistent_notification.yaml
  input:
    sensor_entity:
      - input_boolean.test_fenster
    for_time_m:
      hours: 0
      minutes: 2
      seconds: 0
    notify_group: BachiAppsNotity
    title: "{{ entity_name }} ist offen"
    message: >-
      Achtung: {{ entity_name }} ist schon {{ ((now() - [sensor] | expand |
      map(attribute='last_changed') | first).total_seconds() / 60) | int }}
      Minuten lang geöffnet
    stop_button_text: Benachrichtigung deaktivieren
    period:
      hours: 0
      minutes: 2
      seconds: 0
    status_bar_icon: mdi:window-open-variant
    notification_color:
      - 255
      - 255
      - 0
    channel: Fenster/Türen
    group: offene Fenster

Here is my tested situation:
17:14:30 turn sensor on
17:16:31 notification received
17:17:10 turn sensor off
17:17:15 turn sensor on
17:18:31 notification received << this should not happend (from first sensor on?)
17:19:11 notification received << this should not happend (from first sensor off?)
17:19:15 notification received
17:20:00 turn sensor off

If i turn off the sensor after the first mobile notify was received and turn on the sensor in a short time, then i get three periodic notifications on my phone.

17:18:31 and 17:19:11 are both pntc_event.

1 Like

Sry, for that inconvenience. I did some changes to the latest version. My tests look promising. I wait for your feedback. :slight_smile:

Hi panhans,

here is my feedback.
I updatet the blueprint to version 2.4.1.
I testet again my tests.
Sorry, the problem is still exists.
Remember, duration and periodic are 2 minutes in my tests.

14:46:00 turn sensor on
14:48:00 notification received >> correct from 1st on
14:49:10 turn sensor off
14:49:15 turn sensor on again
14:50:01 notification received << this should not happend
14:51:15 notification received >> correct from 2nd on
14:52:01 notification received << this should not happend
14:52:14 turn sensor off

After sensor is switch to 1st OFF and then to 2nd ON, periodic notifications from the 1st ON should not be happened.

Do you need the traces from this test?

Hi panhans,

i found a solution for the periodic problem.
I will send you a pull request on github.

1 Like

Atm I am a little busy but I am looking forward to review your request theses days. Thank you for your effort!!!