while it would be so very nice to have it at least update every hour?
seems to only need 1 small edit in line 107?
change
update_interval=timedelta(days=1),
to
update_interval=timedelta(hours=1),
while it would be so very nice to have it at least update every hour?
seems to only need 1 small edit in line 107?
change
update_interval=timedelta(days=1),
to
update_interval=timedelta(hours=1),
Or, alternatively, have it respect the scan_interval option.
The docs state:
Platforms that require polling will be polled in an interval specified by the main component. It is possible to overwrite this scan interval for any platform that is being polled by specifying a
scan_interval
configuration key.
and the updater seems to require polling, so per the docs it should support setting an optional scan_interval (with the current once-per-day as a default), right?
I suspect it is to do with server load!
I personally don’t think it’s a good idea to rush people into updating immediately like this, because there’s been occasions where builds had to be pulled or multiple releases dropped in a single day (for example the 0.107 release had .2, .3, and .4 all in the same day).
In addition to that, it’s a ton of extra resources and bandwidth for the update server, for little to no real benefit.
Allowing more advanced users to customize this through scan_interval
like @Silicon_Avatar suggested is the best route IMO. I’m also the type of user who likes to update right away, but I don’t think that’s a good default behavior.
LOL how about a sensor that doesn’t alert to .0 releases, many people wait until .1
That would be fine too, Id be able to live with that
though, I fear if server load really would be an issue, and everybody sets scan_interval to 5 minutes, (because, well, everybody wants a reliable sensor, especially on the updates) that would harm even more…
setting it to every 2 hours then? in for a compromise…
btw, having the binary_sensor report adequately doesn’t mean one needs to update immediately. Everyone will feel for that now, and indeed, wait for the .1 release, unless one is really confident (or adventurous)
I work in the telecom industry. One of the biggest surprises I had as a young engineer was when someone calculated how much a radio system would be loaded if all radios reported their location regularly.
It is huge. Even a 10 minute interval would fill the radio channel capacity 200 % just in a small area like an airport. You really need to be careful with any algorithm that polls or pushes data at intervals instead of being event driven.
of course that would be best, but how to implement that in updater?
The normal way is that the client opens a socket and waits for an event to be transmitted.
But with all us users that is an awful lot of sockets that will be open. More than you can handle on a single IP address. Someone have to pay for that server load.
Or you can use the version
integration:
sensor:
- platform: version
name: Current HA Version
source: local
- platform: version
name: Last HA Version
source: hassio
image: intel-nuc
and then have an automation:
- alias: HA - Update Available
initial_state: true
trigger:
- platform: state
entity_id: sensor.last_ha_version
condition:
- condition: template
value_template: >-
{{ states('sensor.last_ha_version') != states('sensor.current_ha_version')
and trigger.from_state.state != trigger.to_state.state }}
action:
- service: persistent_notification.create
data_template:
title: "Update Available"
message: "Home Assistant {{ states('sensor.last_ha_version') }} is available."
- service: notify.mobile_app_xx
data_template:
title: "Update Available"
message: "Home Assistant {{ states('sensor.last_ha_version') }} is available."
data:
data:
push:
sound: default
yes, and of course that’s why the updater is implemented the way it is…
still once a day is very slow, id still like to hear from the devs what upping that would mean, say minimum per 2 hours, ( or maybe 4 times a day if anywhere near possible)
sure, and we all do
but that’s more of a therapy covering the symptoms than a proper diagnosis and preventing them in the first place.