Assume we have an integration which updates some entities periodically.
A user may need to control a frequency of these updates.
If the integration has “scan_interval” supported, a user may set it to a huge number and then update entities manually by calling a “homeassistant.update_entity” service.
If the integration has no “scan_interval” supported and is controlled in UI -a user may switch off a periodical polling:
and then update entities by that “homeassistant.update_entity” service.
But still integrations update entities on HA startup - and this may be not a desired behaviour since it may cause an increased load.
Suggest to provide an option to disable updating entities on HA startup for integrations.
Imho they could be “unknown” - then I may catch it in a template sensor and restore the last state myself if needed.
The initial point was to NOT perform many updates on startup - do it only when a user says it.
P.S. a very useful point from your side, thank you.
That’s a very good point. I think for consistency it should be set to unknown, and if not to cumbersome a “retain previous value” option could be given (à la MQTToptimistic mode).
I’ll add my use case in support of this feature request.
SpeedTest Integration has its own built-in scheme for determining upload/download bandwidths, but the values it reports are highly inaccurate when WAN links are very high speed. I instead use the official speedtest binary/executable to get much more accurate values and I feed the values to the SpeedTest integration. To keep the SpeedTest integration from running its own scheme, I simply turn off polling. As pointed out, the SpeedTest integration runs its own scheme at startup which again outputs inaccurate values, so yes I would support SpeedTest not running its own scheme at startup.
I’m fine with the initial value being unknown.
(P.S. there are alternative solutions for my particularly use case, namely not using the SpeedTest integration and using my own sensors, but I prefer to use the integration)
