Scan interval for yaml scrape sensors has been fixed: Scrape sensor does not respect scan_interval yaml config option · Issue #83750 · home-assistant/core · GitHub
2 Likes
lol that’s really funny. So after all this it was just a bug.
Welp glad its sorted. Everyone can continue scraping on their schedule.
2 Likes
This is such an elegant solution!
Is there a reason you reject the unknown scan interval attributes instead of selecting defined ones? I’m just curious to know if there is some subtle difference (such as performance) or just a preference.
In case anybody else also notices the “unknown” format string: I’ve never (in Python) seen %s (note the lowercase s). I couldn’t find it in the docs, but then I learnt this: Convert python datetime to epoch with strftime - Stack Overflow.
1 Like
taking the risk of being off-topic…:
interesting indeed, never saw that.
though Convert python datetime to epoch with strftime - Stack Overflow lists reasons we should Not use %s, and that reason seems simple, its not supported.
this probably indicates why:
and I am not focussing on the bit after the dot.
1 Like
There is, probably, a solid background under the decision not to move scan_interval in GUI. Is there a chance to know it and maybe discuss it?
It could be debatable if someone would like to have a scan interval less than 10 secs (but I can give examples it may be needed). But for cases where someone do not need to scrape more often than once a day, and, wouldn’t like to do this due to (for example) scraped service rules or its performance, this new limitation seems to be important step back.
There is no step back. The method to change scan interval on UI based integrations has been stated multiple times now. Once again, if you want to change the default polling frequency, turn off polling. Then create an automation using any trigger you want with an homeassitant.update_entity service call.
3 Likes
No good reason, I just forgot about defined lol. But I just tested and that works fine as well. I’m not sure if there’s a performance difference.
1 Like
Ah .timestamp(), right. That’s the one I was looking for. Yea that’s much better.
I wasn’t aware of the differences between the two although I’m not sure it matters in this spot since the whole point is simply to call it every x minutes. In this particular context it doesn’t really matter if it’s truly a multiple of x minutes since the epoch with accuracy. But I do like that I don’t have to do a string to int conversion with that.
Sorry I literally just typed that automation out on my phone in response to all this so I didn’t do a lot of editing and review. Probably would’ve caught stuff like that on my computer but I was pinned down by a tiny sleeping human so my options were limited 
I haven’t had the time to debug, but… creating automations to update scrape sensors will it not simply create two variants of update?
For instance:
update - default - 10 min
update - default - 10 min
…
update - automation - 480 min
update - default - 10 min
… and so on…
No
1 Like
I’d also like to point out that the only people who are against this change is always veterans. Every time HA moves an integration from Yaml to the UI, veterans voice displeasure. Beginners LOVE It. Scrape isn’t the first integration to move this direction with scan interval and it won’t be the last.
2 Likes
…and as soon as as the beginners, who initially loved it (because of its simplicity) become experts, they will begin to dislike it too (because of its inflexibility, inability for proper version control, having passwords in JSON files etc. - there has been enough discussion about this).
I still think that these kind of changes are a very bad idea. And there are much more important issues in HA to tackle than to implement such changes that nobody had asked for…
5 Likes
You are arguing this response without reading what the discussion was about because you saw “Move to yaml from the UI”. All your points have nothing to do with the topic we were discussing. Please don’t cherry pick my responses to push some agenda.
A volunteer made the change, not the main dev team. You can’t force volunteers to work on something they don’t want to work on… because then just just won’t provide updates at all.
Please don’t come back with some response to Yaml to UI shifts. We were discussing scan_interval. If you have complains about the YAML to UI changes, make a Social topic and leave me out of it. Thank you.
6 Likes
in addition: I’ve searched the forum a bit for “tomorrowio” - this seems to be integrated per “rest api” - which is different from scrape…
I don’t use any REST api nor do I use Scrape atm…
So I cannot confirm the behave for the rest integration, but I don’t beleive - that the scan intervall was removed completely 
[wouldn’t make much sense for such a sensor at all]
So… yes, I think - the whole conversation was somehow built on misleading interpretations and misunderstanding of each other
1 Like
pretty cool! So now we can add an input number and this way drive the frequency.
High time for someone to develop a HACS integration to manage scan intervals 
1 Like
and reinvent the wheel again!
2 Likes
I just tried your automation and it gave me an error.
I think you forgot the “repeat:” in the for_each sequence:
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] }}"
Once I added that then it seems to work.
1 Like
Huh. Yea I did, sorry about that. Good catch, will update my post
1 Like
Gotta laugh at the whole assertion that moving away from YAML is the right thing to do, only to see people posting examples of the work-around in YAML. Yes, editing YAML is easier. But adding the automation through the UI is not as straightforward…not by a longshot.