It shouldn’t. All we as 'helper’s need to know is that if they get a warning, their entity_id doesn’t exist. That’s either a fat finger moment, or they are trying to use the future entity_id: none
EDIT: Or in your case, you’re adding a future entity_id before the entity_id exists.
A warning is still something that gets shown in the log and it’s my opinion that warnings (and other log items) should only be written when they are meaningful. This isn’t one of those occasions and I think it’s just going to generate more I/O. The people that are using this method already know that the entity doesn’t exist and that’s what a config parameter will help with.
For newcomers and people just getting into the more advanced aspects of HA, then yes, the warnings are meaningful, however I think this is going to cause more confusion than anything else.
@pnbruckner: I added my comment to the RFC.
I’m sorry, I don’t agree. With the addition of entity_id: none you get exactly the same functionality as what you have. You just have to make changes. And now users can see when they incorrectly call out an entity_id. It’s a win win with no drawbacks, other than you have to make updates to your configuration.
I’m not disagreeing with the addition of entity_id: none nor do I care about having to change my config (we all keep our configs open 24x7 already, don’t we? 
).
My point is more to the forced logging of warnings about something we, as advanced users, already know with no way to turn it off. If entity_id: none solves that, then that’s awesome and I’ll gladly make the changes needed. But, not everyone is going to be happy about that (yeah, I know, “can’t please all the people all the time” lol).
[Edit]: I forgot completely about the logger: config. Ugh. 
STAT
What? You can turn off anything in the logger…
Hell, my logger litterally ignores all warnings:
# default: debug
default: error
logs:
#for this item anything below error will not be logged
requests.packages.urllib3.connectionpool: critical
frontend.js.latest: critical
py.warnings: critical
#homeassistant.components.waze_travel_time: debug
#haffmpeg.core: debug
My log stays at 2 lines unless I have errors. Those 2 lines are produced before logger takes in affect.
You’re absolutely right. I forgot all about the configurable levels (it’s been a long time since I’ve messed with logger:). I’ll edit my previous comment.
@123, @code-in-progress, @pnbruckner, @Mutt
Also, if you use notepad++ or visual studio code, you can find/replace all instances of <domain>.null with the following regex:
entity_id:(\s+)([\w]+).null
and replace with
entity_id: none
@petro do i understand it right, is this really just about dummy entities doing nothing?
because then the solution is easy.
just create them with AD and then they exist. you cant do much with things like lights that are created in AD (unless you add listeners for events, etc) but the entities would be there.
Yeah, pretty much. I don’t think it will affect AD users at all. I wasn’t sure what ad used when calling self.set_state. I use that quite frequently in my apps. I’m A-OK with it producing warnings in the appdaemon logs, just didn’t want it to producing errors in HA logs as well. AD only produces the warning on startup (when the entity is first created). HA would produce it every service call.
But that was all speculation.
A lot of the people in this thread don’t use appdaemon, so they’ve always used fake entities when performing if-then with Jinja in the regular automations when they don’t actually want to run the service.
the option is there for those people to also install AD.
with a simple app (3 or 4 lines) they could add their wanted dummys to a yaml file.
I don’t use AD, so I really don’t know anything about it. But from the discussion on the PR, I took that to mean that AD only interacts with HA’s State Machine, so using this suggested technique (of creating dummy entities) won’t work. The service call interacts with actual Entity-based objects, not the State Machine. But what do I know?! 
AD creates entities that are actually visibile and usable in HA.
its even possible to create fully working switches, lights, etc…
you dont need to use any service for that, but after the entities are created you can use services to change the entities.
at least that worked up untill now, i cant tell how severe the changes would effect AD, but with what i read up untill now, the AD way should still work.
and even if that wouldnt work anymore its possible to create the most simple app to create dummy mqtt entities.
Just an FYI. The PR was merged.
So for existing automations that use non-existent entity IDs, you’ll start to get warnings in an upcoming release. (I would guess 0.106.) The fix is to change them to none.
Maybe I should wait for 106 and the docs but does anyone know if, for example this would work when entity_id can be none?
- service: timer.start
data_template:
entity_id: >
{% if is_state('binary_sensor.hall_occupied', 'on') %}
timer.hall_motion
{% else %}
none
{% endif %}
duration: >
{% set r = state_attr('timer.hall_motion', 'remaining') ~ '-0000' %}
{% set t = strptime(r, '%H:%M:%S.%f%z') %}
{{ (as_timestamp(t) + 30) | timestamp_custom('%H:%M:%S', false) }}
i.e.
If the entity_id evaluates to none will it ignore and allow the duration.
Unlike scripts that check the correct arguments are being passed to it.
Not sure. I’ve tried figuring out when things are delivered to what build, and github is kind of confusing in that regard. I’m sure there’s a way, but I haven’t figured it out yet. @pnbruckner dev’s way more than I do, maybe he knows.
It will work just like when you supply all or one or more “real” entity_id's. I.e., it will still validate the parameters, etc. It just won’t actually perform the service on any entities.
EDIT: BTW, I should mention, until you have the version with the change you should probably not use none, because that would cause an error (since it doesn’t satisfy the standard entity_id format of DOMAIN.OBJECT_ID.)