What's a better solution?

Configuration
21

Wow, I have 88 alexa_media_g************n@g****] listeners?!?

I also saw that I misspelled timer.finished once in my automation (timer.finisged) :blush:

1 Like
22

Sorry Phil but I think you have ‘shocked’ quite a few people here and it seems there may be a few follow on questions ,

Here’s some :smiley:

So when I went through my various switch triggers and changed them from a slot 1 start time, a slot 1 off time, a slot 2 on time and a slot 2 off time replacing them with a binary sensor on a sensor.time update and then a largish template for the value, it may not have been just my imagination that the system loading ‘seemed’ less ?

@Mariusthvdb 's contention above was not refuted by you, so I’m assuming “entity_id: sensor.time” only triggers once per minute ?

Is there anything else that we can do on a general set of principals to reduce this burden.
I think we’ve established that it doesn’t seem to matter that much but "any tick I can save … "
(i.e. tips and tricks ???)

Edit:
Sorry, just re-read this, I need to clarify that I did not peceive any difference, it’s just that in general the average CPU loadins ‘seemed’ to be lower. But they do seem to vary through the day anyway.

23

I believe it works like this:
Its state changes every minute but at each clock tick (i.e. every second) it is evaluated to determine if 60 seconds have past since its last state-change.

1 Like
24

Hmmm ! So again by implication a template trigger that tests as : -

    trigger:
      - platform: template
        value_template: "{{ states('sensor.time') == states('input_datetime.id_switch_h1_tmeslt1_on') [0:5] }}"

‘Might’ be (say) ‘30’ times less loading than Marius’s (you just happened to be here :rofl: ) : -

  trigger:
    - platform: time
      at: '00:00:01'

I think the landscape has changed a bit for me if this is the case :man_shrugging:

Or Better Still … ??? …

    trigger:
      - platform: template
        value_template: "{{ states('sensor.time') == '18:30' }}"
25

Sorry, missed your question.

The first trigger will “fire” once a day. But the way it is implemented, there is code that will run once a second to see if it’s time for it to fire.

The second trigger will fire whenever sensor.date changes state (or more accurately, whenever it causes a state_changed event to occur.) But the way it’s implemented, there is code that will run once a second to see if it should change state.

Why would you do that? If your automations work, why would you waste your time doing such an exercise?

26

Possibly, if those people are not familiar with how the code works. It’s no secret. The project is open source; anyone can look at it.

What is a switch trigger?

What is a slot 1 start time?

That’s not a trigger. It’s a parameter of something. You’ll have to supply more context.

I think people have taken this the wrong way. I was simply trying to provide more insight into how things work because a question was raises as to what was more efficient. I’ll repeat:

27

Again, you’re overthinking it. Write the automations the way that makes the most sense to you. Don’t worry about implementation details. If your system is overloaded, then minor tweaks to automation triggers probably won’t cut it anyway. If you system is that overloaded then you probably need faster hardware.

28

Well, I won’t now :wink:
Feared as much…thanks for your precise explanation and answer.
As always!

29

@Mutt

Look at it this way:

  • Home Assistant will always be looking for something to do at each clock tick (i.e. each second).
  • Any time-based trigger or integration (like Sun, Time, etc) is evaluated at each clock tick.
  • For a time-based entity, its state will change when the requisite number of clock ticks has passed. In the case of sensor.time that’s 60 ticks.
  • For a time-based trigger, it will fire when the current time (evaluated each tick) matches the scheduled time.

tl;dr

  • Home Assistant evaluates things every second.
  • Those things fire or change state only at their designated time.
30

A trigger (for an automation) for a switch (socket outlet or similar)

My switches were set up to have two ‘on’ slots, say 08:00 to 10:00 and then say 18:00 to 20:00, so 08:00 would be slot 1 ‘on’ time

Yeah, I meant ‘as used’ in the sample triggers posted

:rofl:, don’t we all.? :rofl:
Nah ! the pi 3 runs at 3 % the pi 4 at 1 %
I’m not exactly worried.

@123 Taras, very little of what you write is ever tl;dr :smiley:

I just find this stuff VERY interesting fascinating

Thanks to all

1 Like