If else depending on weekday

Configuration
1

Hi,

I have this automation:

- id: automation
  alias: automation
  trigger:
  - platform: time
    at: '00:00:00'
  condition:
    condition: time
    weekday:
      - fri
      - sun
  action:
  - service: input_datetime.set_datetime
    target:
      entity_id: input_datetime.end
    data:
      time: '22:15:00'

is it possible to set the time depending on the weekday?
time: "{{ '23:30:00' if weekday == fri else '22:15:00'}}"

Thanks in advance

2

And this automation works? Where do you get this target: from, that’s only for blueprints, that shouldn’t work with normal automations.

For your time depending on the day, use the weekday function:

time: "{{ '23:30:00' if now().weekday() ==  4 else '22:15:00' }}"
3

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' }}"
2 Likes
4

Ah okay, good to know. Makes it even more confusing for new starters xD

1 Like
5

… and old-hands alike :laughing:

6

Thanks, thats working :slight_smile:
This target is from the input_datetime documentation.

Is it possible to have some kind of “or” or “and” in it?

now().weekday() ==  4 or 5
7

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.

8

Thanks alot, to both of you, working as expected now :slight_smile:
And I removed the condition so that it is running everyday.

1 Like
9

Just FYI, expect to see a lot more use of target: in future. It’s use will be formalised soon, though backward compatibility will be maintained.

https://github.com/home-assistant/architecture/discussions/495

10

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’ :man_shrugging: - 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.

11

The link I posted was about documenting things properly.

The use of target will clear up confusion like this:

12

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) :wink: