Will checking conditions on 20 automations every five seconds tax the system? And what when it is doing scrapes?

Configuration
1

I have made an automation that does a scrape every five seconds to see what my media player zones are playing. I will run a separate one on every zone, and two different media players, so there will be 20 running. It is only necessary to do that when the player is actually playing, so I have the condition like this:

alias: "Foobar: Oppdatere radioinfo hvert 5 sekund når den spiller"
description: ""
triggers:
  - trigger: time_pattern
    seconds: /5
conditions:
  - condition: state
    entity_id: media_player.foobarsone9
    state: playing
actions:
  - action: homeassistant.update_entity
    metadata: {}
    data:
      entity_id:
        - sensor.foobar_sone_9
mode: queued
max: 10

Does it tax the system at all (Docker, Pi5) to have these running all the time? And does it tax the system noticeable when they actually do the scrape every five seconds because the player is playing? I would guess no, but I’d like to be sure.

2

Any unnecessary process adds load. - Not a fair question. So if you’re doing something unnecessary, you potentially have 100% load savings by eliminating it.

So the question is… Why are you doing this? And why a trigger template sensor. (they’re usually for things that are hard to grab otherwise. Generic states aren’t hard. (read: you can just put the state of the system on that card if it’s display only rather than creating something to store it then show it)

1 Like
3

I guess the question was badly worded, yeah. I don’t mind load, I am wondering about load that is becoming a problem in the real world, which is why I stated the Pi 5 and Docker.

This part of the system is to scrapte info from Foobar2000 when somebody turns on a radio, and then send it from Hass to the house touch screen, which does not run Hass, but a HTML webserver of my own making. TThe state of the sensor will be sent to this system on state changes, in other words when the playing now info changes. But I want the scraping going to change the info when the radio channel changes it.

The Foobar2000 integration grabs some info (probably the same way, since it is connecting to the same web address), but unfortunately it’s not grabbing the info I want. HTML scraping is the only way to do it, as far as I can see.

4

Ok so I think i get what you’re trying to do. You want one thing that changes to be ‘watched’ because that gets fed downstream to something else?

Ok. think of it this way. Try to get as much of this into triggers rather than timers. You’re stuffing a sensor every five minutes whether it needs it or not?

Why not instead of the time trigger change the trigger to be the change of state of the other entity. You may also consider an availability template of the source sensor so that it doesn’t flap when it’s not working.

That way it only changes if there’s a state change on the underlying sensor and it will change IMMEDIATELY if there is one.

(HA is just a massive state engine. The more you can do with triggers the better)

5

Every five seconds, actually. But you’re right, of course! That would be much better, if not for one thing: The radio stations are very fickle. Sometimes the rest of the info is stuck for hours, while only the info I want is changing. That means that it wouldn’t update at all.

6

In that case try doing this…

You can have multiple triggers… :wink:

One on change that gets the now - then one every X minutes to catch up?

7

That sounds like a good plan! How do I trigger it the first time the playback info changes and then every five seconds until the playback info shows that playback has stopped? I would prefer not to use activation and deactivation of the automation, if possible. That can sometimes be messed up on a reboot of the Pi.

8

I’d do it like this:

triggers:
  - trigger: time_pattern
    seconds: /15
  - trigger:
      - platform: state
        entity_id: media_player.foobarsone9

Note my syntax may be wrong - look it up. But I think you get the point.

  1. pops on ANY change to state of that entity - that should happen way before 15 seconds… Even if it’s ‘stuck’ if it’s ‘that stuck’ you have other problems.
  2. every 15 (or 30, 45, 60, etc.) the thing will refresh even if there was no state change whatsoever. It’s long enough to catch up but also long enough you NOTICE something is wrong and can investigate.
1 Like
9

Thank you very much, I will use that! :+1:

10

Cool - interested if it works

11

It does! I set it to 40 seconds just to test, and it fires when something changes in the Foobar-integration. Problem solved!

1 Like
12

NICE - so just keep creeping that number up until it’s ‘good enough’

So belt and suspenders AND you’re driving off triggers now.

1 Like
13

Yeah, and my pants are forged in a polystyrene ball to boot… :joy: Btw how can I do that availability template you mentioned? The scrape sensor is unavailable as soon as the playback stops. Sorry, I meant the Foobar that it picks up the stuff from! The scrape sensor stays on.

Never mind, that was an error here, it shows as long as the timer runs! :grin:

1 Like
14

And back again… Sorry, I was right the first time. The scrape sensor goes unavailable after a certain time. Is there a template I can use for availability that doesn’t set it as unavailable, but something useful, like “Off”?