You can’t disable polling with scan_interval. So what you’re saying isn’t correct. Unless you’re referring to something else?
1 Like
Thanks for creating issue.
I confirm that I have unifi integration, and logs was crazy about it, especially uptime they had an entry every second to indicate a change to the same value as before…
There is a Breaking Change that does not seem to be mentioned:
This messes up the iBeacon room detection
My two cents - given the way things are going it seems like everyone should expect scan_interval to gradually disappear everywhere. I’m on the fence about this. I get the reasons but it was handy for many integrations.
I don’t think speedtest is one of those integrations. In fact I personally think this change should go a step further and disable polling for speedtest by default. Basically almost force people to use a custom schedule with an automation. Why? It’s right in the docs:
While the speedtest is running your network capacity is fully utilized. This may have a negative effect on other devices using the network such as gaming consoles or streaming boxes.
Running speedtests all the time is a bad idea. By design it consumes as much bandwidth as possible squeezing out everything else. And if you cap it or de-prioritize it’s bandwidth so it doesn’t interfere with the things you’re actually doing then the results are inaccurate and therefore pointless.
Out of all the integrations that poll that I use personally, this was probably the first one I disabled polling for as soon as I was given the option. An automation like this simply works better then any scan interval for speedtest:
trigger:
platform: time_pattern
hours: '*'
minutes: '0'
condition:
or:
- "{{ is_state('zone.home', '0') }}"
- "{{ now().hour < 8 }}"
action:
service: homeassistant.update_entity
data:
entity_id: sensor.speedtest_ping
Now here’s a speedtest setup that works. Run it once an hour but only when no one is home or everyone is asleep. Customize the interval and conditions to your need (like if you have a better time range or better way to tell if people are asleep or other things that consume bandwidth during these times you don’t want to interfere with).
I think you’re trying to make a broader point about the scan_interval feature. Which is fine but I’ll just note that in my opinion, this particular change (removal of the option from speedtest specifically) is a weird hill to die on. Since the docs literally tell you it’s a bad idea to run speedtests all the time.
6 Likes
Not using the standard Speedtest integration, prefer to use own command_line sensors for Speedtest cli command (run this command on two different hosts to measure a speed in a DualWAN configuration).
But I wonder - is the standard Speedtest integration updates it’s sensors on HA reboot?
Yes, that would make the most sense. It would also avoids issues like ‘why is my HA using up xyz GB every day’ posts, which is almost always due to excessive speed testing. A speed test is a resource hungry operation that should be well timed.
That said, scan_interval makes a lot of sense for integrations that require regular lightweight timed calls by design, like REST, ping, command_line sensors, etc. Having an implicit and arbitrary hardcoded scan_interval by default, that can’t be adjusted but only disabled and replaced by a much more bloated boilerplate code is bad design and breaks orthogonality.
6 Likes
If polling is enabled - yes.
When an integration gets it’s data updates by polling then it polls immediately when it is loaded. That means during HA startup or if the integration itself is live reloaded (for integrations which support that). After that it starts it’s polling interval (whatever that may be) and updates every x minutes/seconds/hours following that initial one. If polling is disabled then it never polls unless update entity is called, not even on load of the integration.
Just an fyi, the command line integration is a polling integration so all this applies to it too. And since that one is yaml only polling can’t be disabled. You can set the scan interval arbitrarily high but it’ll still run the command every time the integration is loaded.
1 Like
Pffff … I am super frustrated… my HA (on odroid C4) is completly broken after the last update 2023.1.1 :(… Got few addons… I will spend many hours to recover…
EDIT ; after turned off/on my Odroid C4, HASSIO started again… I will check what was the problem
There is a lingering problem with addons not starting for some weird reason. Usual fix is a stop and cold start (ie not just restarting core). You may have struck this.
Too bad that polling is manageable for UI-controlled integrations only.
For some my command_line sensors I specified scan_interval=999999* but running on HA startup is not good.
Same issue over here after update, all entities related to DSMR integration report “Unknown”
from docs:
By default, a speed test will be run every hour. You can disable polling using system options and use the
update_entityservice to automate the speed test frequency.
I refer to default polling policy which is implemented with hardcoded frequency. Why the default polling is implemented? if new approach is to run it from automation, the component may not even provide this default behavior.
It doesn’t make sense to have built in scheduler just for fixed period.
1 Like
Same for the Pi-Hole Integration since 2023.1.0 and including 2023.1.1. All sensors are reporting as “unavailable”:
All polling integrations have a built in polling frequency. If you as a user don’t like it, you disable it and add your own. Making your own update frequency is optional, not required. That’s why it’s built in.
I’m not asking about the obvious.
I’m asking why such an inconsistent approach.
If there is built-in polling frequency - there should be no problem to make it configurable. The disable option for those who want a more complex scheduling plan is indeed a good choice.
However, keeping the built-in scheduler just for a fixed period does not make sense to me. Hence my initial question for the rationale.
2 Likes
It’s not inconsistent…
The UI uses a polling frequency that’s static and can be turned off and altered using the UI via an automation.
Yaml uses scan_interval.
Yes you can, you turn it off and build an automation. You can do whatever you dream up. It satisfies the need to configure a different polling rate. Or, if you’re like me, you can have it update only when you need the information by using an event to trigger the update. I use this to reduce API calls to avoid paying money for using APIs.
This functionality isn’t new by the way. The UI polling has been in there for ~3 years now. The early UI integrations are missing the functionality, I think speed test was the last.
Knowing the rational isn’t going to change the design and no one who’s posted so far knows the rational. Whoever dreamed this up would know the rational, and you’ll notice they aren’t posting. So repeating the question isn’t helping anyone, it’s just adding fuel to the fire.
3 Likes
For me the bmw_connected_drive integration is now partially broken.
Anyone else noticing that the remaining_battery_percent sensor isn’t updating ?
The value remains stuck at 99%, while all other metrics are currectly updating.
@rikroe ?
edit : just noticed, remaining_battery_percent refreshes while charging, yet doesn’t refresh while draining.
what fire? what repeating? I asked once getting several answers but not on my question. I didn’t even ask you to answer on behalf of others who don’t answer.
if you don’t know the answer - just do not response please. This way you save us from unnecessary noise.
and yes, current solution is inconsistent.
2 Likes
My guy, you kept asking me directly… That’s how the reply button works.
Ok I can confirm after each “restart”, my HA don’t start anymore (2023.1.1)… I have to turn on/off to have access again… Huge bug introduced.
EDIT … Pffff now even after a cold reboot… no more access…