spook icon indicating copy to clipboard operation
spook copied to clipboard

Services `notify.` get reported as missing entities

Open formatBCE opened this issue 3 months ago • 10 comments

What version of Spook are you using?

4.0.0

What version of Home Assistant are you using?

2025.9.4

The problem

After installing 4.0.0 and rebooting, i got dozens of repairs - all pointing to using action notify.mobile_app_my_phone and referring that it's missing entity.

Should those be excluded? Would be nice to search for missing actions (services) too, but i don't think there's registry for them, right?

Anything in the logs? Paste it here!


formatBCE avatar Sep 25 '25 17:09 formatBCE

Try 4.0.1, which was published earlier today, it should be able to understand the difference between the action and entities now.

../Frenck

frenck avatar Sep 25 '25 18:09 frenck

Try 4.0.1, which was published earlier today, it should be able to understand the difference between the action and entities now.

Nice! Some are fixed.

Others, still displaying, are for the script I got, that receives "notify" action as field. Those still up... IDK though if it's something you want to fix - if not, I'll just ignore them.

formatBCE avatar Sep 25 '25 18:09 formatBCE

Can you share the faulty YAML?

frenck avatar Sep 25 '25 20:09 frenck

Here's the script i use for convenience:

alias: Send mobile notification
fields:
  f_who:
    name: Who
    required: true
    selector:
      select:
        options:
          - value: notify.mobile_app_me_blah_blah
            label: Me
          - value: notify.mobile_app_wife_blah_blah
            label: Wife
        multiple: true
  f_title:
    name: Title
    default: Home Assistant
    selector:
      text: null
  f_message:
    name: Message
    required: true
    default: ""
    selector:
      text: null
  f_tag:
    name: Tag
    default: info
    selector:
      text: null
  f_icon:
    name: Icon
    selector:
      icon:
        placeholder: mdi:home-assistant
  f_color:
    name: Color
    default: "#2302f7"
    selector:
      text:
        type: color
  f_persistent:
    name: Persistent
    default: false
    selector:
      boolean: null
  f_click:
    name: Click action
    default: ""
    selector:
      text: null
  f_actions:
    name: Buttons
    default: {}
    selector:
      object: null
sequence:
  - repeat:
      sequence:
        - data:
            message: "{{ f_message|default }}"
            title: "{{ f_title|default }}"
            data:
              ttl: 0
              priority: high
              tag: "{{ f_tag|default }}"
              clickAction: "{{ f_click|default }}"
              actions: "{{ f_actions|default }}"
              notification_icon: "{{ f_icon|default }}"
              color: "{{ f_color|default }}"
              persistent: "{{ f_persistent|default }}"
              sticky: "{{ f_persistent|default }}"
          action: "{{ repeat.item }}"
      for_each: "{{ f_who }}"
mode: parallel
icon: mdi:cellphone-information
max: 10

And then i use it like this in automation:

data:
  f_who:
    - notify.mobile_app_me_blah_blah
  f_tag: main_door_opened
  f_message: Main door opened
  f_icon: mdi:door-open
action: script.send_mobile_notification

I realize that i could define service inside based on the simple text field - but it's easier with selector...

formatBCE avatar Sep 25 '25 20:09 formatBCE

I'm also seeing services flagged that are used elsewhere in the YAML. For example, this syntax when using the retry integration:

action: retry.action
target:
   entity_id: "{{ thermostat_entity }}"
data:
   action: climate.set_hvac_mode
   hvac_mode: "{{ states('input_select.ecobee_mode') }}"
   validation: "[[ not is_state(entity_id, 'off') ]]"

or this syntax when dynamically selecting the service:

action: "{{ 'input_boolean.turn_on' if trigger.event == 'start' else 'input_boolean.turn_off' }}"
target:
   entity_id: input_boolean.guest_mode

That being said, I love this new feature! I caught a few old entities being referenced and one typo that has existed for months on a less frequently used logic branch.

ronaldheft avatar Sep 25 '25 23:09 ronaldheft

I filed a feature request with retry, not because I think it's an issue with retry, but to make sure they're aware of this too. I see two options for fixes off the top of my head, but I don't know what would be better.

I also wanna second that I REALLY like this new feature - it helped me fix a few minor things that had been annoying me. Thank you.

Option 1

My first thought is whether something like the service filtering (https://github.com/frenck/spook/pull/1076/files) could be added in a few additional places?

In particular it seems like https://github.com/frenck/spook/blob/main/custom_components/spook/ectoplasms/automation/repairs/unknown_entity_references.py#L247 is where it's needed, at least for the retry case. I suspect there are several other places that might help - perhaps even moving https://github.com/frenck/spook/pull/1076/files#diff-bf71f9c16379e62ff88ed7249693d8a203cbf7374af7b0a8355da05edb9d8f8dR531 to the top level somewhere like https://github.com/frenck/spook/blob/main/custom_components/spook/ectoplasms/automation/repairs/unknown_entity_references.py#L319 so that it's applied to all entity IDs?

I'm worried this would over-filter of course, and miss any errors where someone mistakenly puts a service/action where they should have put an entity ID.

Option 2:

Maybe some special casing around the fact that in all the above cases, the value which shouldn't be checked as an entity is in a field named "action"? This relies more on assumptions than option1, but it would catch errors where someone mistakenly enters a service instead of an entity.

gdgib avatar Sep 26 '25 14:09 gdgib

  1. For those working with retry, changing to use retry.actions instead of retry.action requires a bit of effort, but does seem like a valid work around. I tested this, and it makes sense given my limited understanding of the code.
  2. I found an interesting thing while testing - I wasn't seeing spook repairs about this when creating automations through the UI, only when doing it through configuration yaml in a package. That was unexpected so I tried reloading spook, reloading automations, etc (not restarting HA though I now realize). No matter what I did the UI created automations didn't trigger this, only ones in yaml config files in `packages. I don't have time right now to figure out why, just leaving the info here in case it helps.

gdgib avatar Sep 27 '25 15:09 gdgib

Hi everyone, I wanted to contribute. I confirm that only the automations located in different folders are having problems.

/config/packages/hacs_package_update.yaml)

Thanks for your efforts.

SPOOK VER. 4.01 HA 2025.9.4 RPI4 HASSOS

Spook found a ghost in your automations

While floating around, Spook came across the following automation:

Telegram HACS Update Notification (/config/packages/hacs_package_update.yaml) (automation.notifica_telegram_aggiornamenti_hacs_config_packages_hacs_package_update_yaml)

This automation references the following entities, which are not recognized by Home Assistant:

notify.mobile_app_iphone_di_xxxxxx To resolve this error, edit the automation (/config/automation/edit/None) and remove the use of these non-existent entities.

Spook 👻 Your friend

angelosan avatar Sep 28 '25 08:09 angelosan

I have no different folders, and don't use packages. Still have those.

formatBCE avatar Sep 28 '25 15:09 formatBCE

I have also the problem. The devices are ok, but spook reports: Die Automation „AI Event Summary“ (automation.ai_event_summary) hat eine unbekannte Aktion: notify.mobile_app_none. But the notify entities exists all.

rapton avatar Oct 05 '25 16:10 rapton