I donât think thatâs correct. I think it is for use in automations, and you can make use of it in blueprints.
Unfortunately, it seems to be a bit of a secret how itâs supposed to be used, so weâre all in the dark waiting for someone to provide a decent doc explaining it.
That said, I agree that in this case it is definitely not a âgoodâ use, because itâs an extra layer of complexity for zero benefit
- id: automation
alias: automation
trigger:
platform: time
at: '00:00:00'
condition:
condition: time
weekday:
- fri
- sun
action:
service: input_datetime.set_datetime
data:
entity_id: input_datetime.end
time: "{{ '23:30:00' if now().weekday() == 4 else '22:15:00' }}"
I think the devs need to decide whether they want this platform to be ânewbie friendlyâ or not. They continually talk about making it easier for anyone to use, and then start implementing complicated and confusing syntax without telling anyone how it works, and wonder why the forums are full of ânewbiesâ that are struggling to do simple stuff.
SureâŚ
time: "{{ '23:30:00' if now().weekday() in [4, 5] else '22:15:00' }}"
⌠but bear in mind that currently your trigger and condition make it so that thereâs only Friday and Sunday, so the weekday will only be one of those two when the template is evaluated.
To be fair, I donât mind them changing things if itâs âbetterâ and/or âmore powerfulâ, but target: has just suddenly appeared, and is only documented very briefly in the blueprints documentation.
And it appears that itâs only purpose is so that you can either use an entity_id or an area - but that being the case, surely just adding the ability to use the area: key under data would have been easier, neater and backwards compatible.
Or, easier still, allow putting an area as a value for entity_id (in the same way as you can also use âallâ or ânoneâ in that field)
service: light.turn_on
entity_id: my_area
Seems to be adding more complication for the sake of it, which is the opposite of of ânewbie friendlyâ - and its even worse because it isnât documented properly.
The problem is now that target has already been invented, so theyâre not going to go back and review whether it was even necessary in the first place, but it needs to be properly documented so we can understand what itâs for and work with it.
The use of âdataâ would have done the same without the need for a new key and the added complications, if theyâd just fixed the two edge-cases where you had to put the entity_id at the service level (which was already contrary to the guidelines when that issue was raised in 2019)