Non-existent or "dummy" entities will now be reported in a warning message

Configuration
1

Home Assistant has always silently ignored non-existent entities in automations and scripts. This behavior has allowed one to create automations containing so-called “dummy entities” that are quietly ignored by Home Assistant.

For example, this data_template returns lock.door only if it’s unlocked otherwise it supplies the name of a non-existent entity called lock.nothing.

    service: lock.lock
    data_template:
      entity_id: >
        {% if is_state('lock.door', 'unlocked') %}
           lock.door
        {% else %}
           lock.nothing
        {% end if }

Similar techniques have been used to call non-existent switches and scripts. The practice is fairly common and usually done in order to simplify the automation. The example I’ve shown could be rewritten using a condition but there are other situations where it’s not so simple.

I’ve offered the use of “dummy entities” as a solution in several posts:

In the last linked post (dated August 2019) I wrote:

Home Assistant will not (currently) complain about non-existent entities.

My inclusion of the word “currently” was prescient because that’s about to change. Be advised that the following PR will make Home Assistant report non-existent entities (initially as a warning):

If you don’t want warning messages in your system log, you may need to revise automations or scripts that use non-existent entities.

UPDATE

The PR was modified and will now permit the use of none to represent a valid “dummy entity”.

    service: lock.lock
    data_template:
      entity_id: >
        {% if is_state('lock.door', 'unlocked') %}
           lock.door
        {% else %}
           none
        {% end if }
3 Likes
2

I just hope this doesn’t affect appdaemon’s set_state. @ReneTode, does set_state call a service under the hood?

3

i dont believe so @petro

i dont even think there is a service to set_state.
and AD already reports when you use services for none existing entities (or at least HA complains if i remember correct)

4

This one annoys me as I’ve been using this a lot in my scripts. A much better “solution” to this (imho) would be to ONLY include the warnings during a manual call to homeassistant.check_config and maybe at startup. Another way to handle this would be to have a config setting that turns this off (this would be my preference).

1 Like
5

I’ll propose something that I fully admit sounds like a kludge but it’s a simple way to avoid warning messages without re-writing automations and scripts that use “dummy entities”.

Formalize dummy entities.

Allow each domain to have one valid dummy entity called null (or some other name the community prefers).

  • light.null
  • switch.null
  • script.null
  • cover.null
  • etc

If Home Assistant encounters an automation using lock.null it will behave the way it always has with a non-existent entity: it silently ignores it.

2 Likes
6

You could always just add the demo devices. There’s pretty much one for every domain.

My only issue with them is that they use “Real” names. I made a custom_component of them where I renamed everything to demo_x.

7

Can you elaborate on how it works? I added this to my lights.yaml file:

  - name: 'null'
    platform: demo

then ran Config Check with no errors, restarted, and no new entity appears in the States page. I reviewed the system log and the startup messages say nothing about loading the demo platform.

Obviously I’ve misunderstood how this works. How does one use the demo platform?

8

demo platform will create demo entities. I don’t believe name is an option. ‘light’ demo creates 3 lights:

light.light_1  Bed Light
light.light_2  Ceiling Lights
light.light_3  Kitchen Lights

Each have different supporting features. I created a custom_component of demo where I changed the names to what I want instead of stepping on the toes of my current libraries.

The created entities might have different entity_id’s that light.light_1.

EDIT:

Maybe later tonight i’ll make a custom null entity component and add it to HACS that does this with single features instead of these crazy demo ones.

EDIT 2:

These entities are really good for the testing that you always do btw… It’s what I use them for.

9

Anyone who feels strongly about this should probably comment on the PR. That’s the whole point of the PR and why it’s named “RFC: …” (i.e., Request For Comment.)

FWIW, I’ve suggested a new keyword, similar to all, that means “no entity.” But that’s just one idea.

By all means, add a comment to the PR. balloob is asking for input. Now’s your chance.

1 Like
10

I liked that option. entity_id: none. Seems the easiest. And would be supported everywhere pretty much instantly.

1 Like
11

Yes, that’s the idea, to add it to the central service processing method. The only problem with none is that is a YAML keyword, which results in Python None instead of a string 'none', but I suspect that would be easy enough to deal with in the schema.

12

I’m using 0.103.2 and the demo integration isn’t working as advertised for me.

I added this to lights.yaml:

  - platform: demo

It passed Config Check, I restarted Home Assistant and there are no new light entities listed in the States page. :man_shrugging:

Anyway, I like the suggestion to allow for entity_id: none

13

:man_shrugging: not sure what the problem is. Maybe it’s not available for release/non-dev and I accidentally got around that by making a custom_component of it.

14

Then you need to comment on the PR. Stating that here won’t help. :wink:

15

If none is a reserved word (but is the proper opposite of all) what’s an alternative word that isn’t reserved? What about nothing?

16

I think none is ok, and is the most appropriate. Yes, it’s a YAML keyword, and YAML will convert it to Python’s None, but again, I think that’s an implementation detail that is not difficult to deal with. So either of these could be made to be acceptable and equivalent:

entity_id: none
entity_id: 'none'

Remember, templates always return strings anyway, so in general this wouldn’t even be a problem. I doubt anyone would write:

service: blah.blah
entity_id: none

but they would write something like:

service: blah.blah
data_template:
  entity_id: "{{ ... else 'none' }}"

EDIT: BTW, there’s already a precedent for none. See the climate component and its “preset mode.”

17

I understand where you are going with this but how will this (the warning of ‘other’ non-existent entities) interfere with : -
a) people here helping on the forum ? (I write all sorts of sruff into a package file to help with solutions that don’t actually exist on my system, just to check the yaml and basic HA Syntax).
b) it’s also fairly common (due to the package concept but also possible without) to (say) write code for bedroom 01, test it decide that’s okay, then say okay I’ll copy this for bedroom02 and… BUT … I’ve not installed the devices yet

I think I agree with @code-in-progress to have a config setting to enable / disable
What have I missed ?

1 Like
18

I think you’re pointing at the wrong person. @pnbruckner is not the developer. Discuss this on the issue to actually talk with the developer.

what

yes this will now produce a warning in your logs, which you can safely ignore because you’re going to add it later.

Why, it’ll just be a warning, see response above.

19

Well it looks like a moot point. He added entity_id: none and area_id: none

1 Like
20

The bit preceeding was pertinent.

I’m not blaming Phil. I’m trying to gain more understanding of consequences and possible options before I weigh in on github with an irrelevant comment