2022.12: Scrape and scan interval

My first statement came from my decade-plus of experience in software development, including 5 years as a software product manager. During that time we had to rebuild multiple standalone components to “feature parity”. Every time we did that was what feature parity meant. You never move everything over, you always audit and deprecate the mistakes.

I found the link after by searching the term “feature parity”. The first 3 results were about “feature parity” as the term applies in software development and they all supported what I said. I picked that one from the resultset because it seemed more easily digestable then this one.

If mirriam webster disagrees then oh well. In the real world of software development, what I said is what it means.

I bow to your experience in software development, I too have over 40 yrs in the industry.
I was merely pointing out the non-techy “real-world” definition and therefore most people’s understanding of the term. i.e communicating why there might be a confusion over the term.

Who is Mirriam Webster? :slight_smile:

Fair enough.

Lol got me there. merriam-webster, whoops

Merriam’s sister.

1 Like

To be honest, I find this absolutely complicated. Slowly scan interval will be removed from everywhere and all your entities will need to have automations built for them, even when scan interval does the required job. Then you end up with a long list of automations and you cannot even group or tuck them away to do not clutter the whole place.

You can just leave it out and let the integration choose the scan interval. So that you don’t need to adjust anything. And if you want to, you have full control over the updates. You can even force updates during periods of the day when it’s going to be used. It might be more complicated, but it adds features that people have been asking for in scan interval for years and it works with the UI and old yaml integrations.

Agree, I use a lot of different scan_intervals for a lot of sensors. Will be some effort to migrate them to automations. Despite the effort it‘ll make it less intuitive as the sensor‘s logic is split at 2 places: configuration & automation.

I hope there will come a better approach to generically update entities

I maybe have read it wrongly in a PR/Issue whatever before. But what I remember at that place the whole scan interval option was ditched in favour of the automation setup.
If it is there, then no problem. But ditching it just to make the user to build an automation to do the same is an insane idea. And I think about newbies generally. I understand what possibilities it gives with changeable frequency etc.

My god, its’ really not a big deal.
You can put them all in 1 automation, and it’s really not much effort.

- alias: 5 minute scan interval
  trigger:
  - platform: time_pattern
    minutes: '\5'
  action:
  - service: homeassistant.update_entity
    target:
      entity_id:
      - sensor.entity1
      - sensor.entity2
      - sensor.entity3
      - sensor.entity4
      - sensor.entity5
2 Likes

Please think a bit, You are using HA for 7 years. Then someone comes along (a newbie) adds an integration and would not understand why is it not updating, and realises that it has to build an automation just to update that (every!) entity in that integration.

I don’t want to argue about this. Everything can be done many ways in HA, we all know that.

But currently many things goes absolutely against what the whole streamlining is about. It just makes more clutter and complexity, and confusion for newbies.

5 Likes

Beginners aren’t thinking about scan intervals. They aren’t. They are thinking about getting their sensor working in the UI without writing yaml. That’s it.

This scenario won’t happen. Because there’s a default interval all entities update at. So when they start up, it will work and they won’t even question it.

The only reason to make an automation is to change the default update interval, that’s it.

1 Like

tbh:

The major issue here is, that someone who knows HA is giving arguments “hat a newbe” would think - or do…
The reason behind this seems clear to me:

The “known” behave has changed - and the user is required to adapt his workflow or what he’s used to be.

A newbe would maybe question: “why does my integration does not pull updates?”

  • he would get the answer: “create an automation” - and everything is fine.

A newbe isn’t addicted to any “known” workflow that others has developed over a couple of years.
He would just do what was recommended.

And I think, that’s a big topic for most of the recent changes, when it comes to design or to other areas where we have developed some expectations “how it should be”…

Although, I can understand the main complaint behind this - and I think, I’ve already seen tickets or even PRs to change the scan interval (?) [but atm I am not 100% sure]

2 Likes

The reason for this change was so that every integration that uses a scan interval, has a meaning interval built into it from the get go.

Old yaml based integrations all defaulted to 30 seconds. Now, each integration has a meaningful interval built into it, they are not all 30 seconds. Some have a higher frequency, some have a lower frequency and the goal is so that you never even have to think about changing it.

However, if you want to change it from the default, you have an option. Disable the polling and write an automation. Or keep the default polling and add additional updates. The choice is yours, all done via the UI and you can get as complicated as you want.

The majority of beginners will not adjust this, they won’t even think twice about this because their sensors will work out of the box.

1 Like

Polling or not polling, that is the question…

I just find it as a level of not necessary complexity by manually adding automations to do polling. As an advanced feature, yes, I absolutely get it, set up what you want, but as a starter why to stress with it?

The whole “let’s create an automation for this basic feature” idea is equivalent to the The enterprise smart home syndrome.

4 Likes

but as a beginner you don’t have to think about automations at all, since there is a default polling active.
It’s probably just not the setting you had before… ?!

1 Like

The first when I saw this whole scan interval vs automation controversy was in an issue regarding tomorrowio as I can remember. (Months ago…)

Over there the integration tries to be clever to handle the rate limitation of the website.

I might have misunderstood but my impression was that the scan interval polling will go away (feature will be removed) and the user will be given the full control only by using automations.

If that is/was not the full intention then I am sorry for the whole confusion.

The default scan interval is 10 minutes for scrape. If you want to alter it, you have to make an automation. Otherwise you don’t. Also, you can still just use YAML with scrape you just have to transition to the new style. And yes, configuring via yaml still lets you set scan_interval.

1 Like

No scan interval still exists, it’s just not listed in the docs for rest (Not sure why). But you can make an automation using homeassistant.update_entity if you want a non-periodic scan interval.

I get now what was the intention from @petro’s previous comment.

But I find it still far fetched from streamlining. Integration option of the scan interval vs creating an automation for it.

Anyhow, thanks for the input!

Or just have one automation:

trigger:
  platform: time_pattern
  minutes: '*'
variables:
  entities:
    sensor.entity_1: 5
    sensor.entity_2: 10
    sensor.entity_3: 100
    sensor.entity_4: 2880
    ...
  total_mins: "{{ (now().timestamp() / 60) | int }}"
action:
  repeat:
    for_each: "{{ entities | dictsort }}"
    sequence:
      if: "{{ total_mins % repeat.item[1] == 0 }}"
      then:
        service: homeassistant.update_entity
        data:
          entity_id: "{{ repeat.item[0] }}"

Alternatively if it bothers you that the scan interval is now in this automation, can add it to the entities with customization as an attribute. Then use it in a similar automation like this:

trigger:
  platform: time_pattern
  minutes: '*'
variables:
  entities: >-
    {{ states | rejectattr('attributes.scan_interval', 'undefined')
      | map(attribute='entity_id') | list }}
  total_mins: "{{ (now().timestamp() / 60) | int }}"
action:
  repeat:
    for_each: "{{ entities }}"
    sequence:
      if: "{{ total_mins % state_attr(repeat.item, 'scan_interval') == 0 }}"
      then:
        service: homeassistant.update_entity
        data:
          entity_id: "{{ repeat.item }}"

I don’t have that many things with scan interval but if it becomes a problem I’ll most likely add an automation like this to mine.

6 Likes