Looking to be efficient, confused by 3 options

Configuration
,
1

I have an automation that triggers on the state change of a button press and I want to update an input_datetime helper at that time. I’ve run across 3 options but can’t for the life of me figure out which is more efficient or should be used or why. There’s also a really good possibility that I’m just over thinking it, I do that :roll_eyes:.

Below are the 3 options that I believe to be valid, any insight would be greatly appreciated, thanks.

# Option 1:
- action: input_datetime.set_datetime
  data:
    timestamp: "{{ now().timestamp() }}"
  target:
    entity_id: input_datetime.my_input_datetime

# Option 2:
- action: input_datetime.set_datetime
  data:
    timestamp: "{{ trigger.to_state.state|as_timestamp }}" #or even "{{ as_timestamp(trigger.to_state.state) }}"
  target:
    entity_id: input_datetime.my_input_datetime

# Option 3:
- action: input_datetime.set_datetime
  data:
    timestamp: "{{ states('input_button.my_button')|as_timestamp }}" #or even "{{ as_timestamp(states('input_button.my_button')) }}"
  target:
    entity_id: input_datetime.my_input_datetime
2

I guess saving microseconds is still saving something. Not any kind of expert but the first one has to pull on a python library so it I’m guessing is not the most efficient. Also possibly some weirdness with update frequency I think.

Perfect question for 123, though, listen to him.

3

Does the automation do anything else?

If it doesn’t then I suggest replacing it with a Trigger-based Template Sensor. When triggered by a button-press, set its template to report the current date and time (in ISO8601 format), and set its device_class to timestamp. You’ll have a useful Timestamp sensor.

4

Yes it does have other actions, I even have an if: then: else: wrapped around this and one of those triggers another automation.

I actually started with a Trigger-based Template Sensor but it became inadequate.

5

Funny, the first one I pulled directly from the documentation example.

6

In that case, I would go with {{ now().timestamp() }}

1 Like
7

I won’t question your goals, and I have no doubt that @123 is spot-on.

My own wisdom I’d offer here, though (and, ignore me if you know better for your purposes), is unless you’re actually highly resource-constrained, one of the weightier concerns when choosing how to structure code is to pick the option that is most readable, even if you suspect, under the hood, that it might not strictly be the most efficient. That holds here, I think, because the conglobulation of YAML and Jinja2, for a combination of reasons, is pretty difficult to read. I understand that a lot of effort goes into the platform–not only HA, but also the platforms it itself is based on, such as Python–to make it as optimized as possible no matter how you structure your code at the top level.

It’s one thing to have the code fresh in your mind just after you’ve written it, but then six months later when for some unexplained reason your lights go on the fritz or your HVAC turns the heat on in the middle of summer… I’ve definitely faulted myself for trying to be way too clever in those situations!

2 Likes
8

Why bother converting to timestamp at all when you could just use the state of the triggering input_button by using datetime instead of timestamp…?

- action: input_datetime.set_datetime
  data:
    datetime: "{{ trigger.to_state.state }}"
  target:
    entity_id: input_datetime.my_input_datetime
9

We’re all focused on saving a microsecond or two in a quest for efficiency but, for all we know, the undisclosed automation may contain inefficiencies that are an order of magnitude greater.

@HappyCadaver

Please post the automation so we can review it.

10

I was afraid someone might ask that. It’s actually part of a whole ‘Package’ and I will post it for review once it’s ready (planning to share it with the community), but it’s also of a personal nature and I’m unwilling to expose that at this time. I do appreciate your willingness to help though, thank you for that. Thank you all who have taken the time to read and respond.

I’m really just looking for best practices at this time and the reason for those best practices. I’m at the 4th iteration of this package trying to refine it for a balance of readability and efficiency, but I got stuck on this particular item. The first iteration was horrific and I knew it, but it functioned.

@Didgeridrew, would that work if the input_datetime helper was a time only helper? I’m using a combination of both and just figured that timestamp would give me consistancy throughout the package… no having to break up the datetime object and worsening the readability.

11

No, it would not.

1 Like