entities not refreshing

[pjuster]

Name of Council

south-oxfordshire-district-council

Issue Information

I've just had it where my next collection date was the 30th of July (tomorrow) but the number of days to collection was three.

Reconfiguring the integration updated the sensors correctly.

this isn't the first time this has happened.

But surely I shouldn't need to do that.

thanks

Verification

• I searched for similar issues at https://github.com/robbrad/UKBinCollectionData/issues?q=is:issue and found no duplicates
• I have checked my address/postcode/UPRN works on the council's website
• I have provided a detailed explanation of the issue as well as steps to replicate the issue
• I understand that this project is run by volunteer contributors therefore completion of this issue cannot be guaranteed

[ashh87]

I've also seen this in the past few days, since installing the most recent updates.

[pacso]

I've just debugged this exact symptom on my own install (0.171.1) and found the root cause. It's a mislabelled config option, not a scraper problem.

Root cause

The config entry has a manual_refresh_only flag. When it's true, async_setup_entry passes update_interval=None to the DataUpdateCoordinator:

# custom_components/uk_bin_collection/__init__.py
if manual_refresh:
    update_interval = None
    _LOGGER.info(
        "%s Manual refresh only: no automatic updates scheduled.", LOG_PREFIX
    )

With update_interval=None, the coordinator only ever fetches once — via async_config_entry_first_refresh() during setup. So the data updates on HA restart or when the entry is reloaded (which is why reconfiguring "fixes" it), and then never again.

The problem is how the flag is presented in the UI. In translations/en.json (both the user and reconfigure_confirm steps), the checkbox bound to manual_refresh_only is labelled:

"manual_refresh_only": "Automatically refresh the sensor"

That's the inverse of what the field stores — there's no inversion in the save path, so:

• ☑️ "Automatically refresh the sensor" → manual_refresh_only: true → no automatic refresh
• ⬜ unticked → manual_refresh_only: false → refresh every update_interval hours

On top of that, the initial setup form defaults the checkbox to ticked (config_flow.py: vol.Optional("manual_refresh_only", default=True)), and async_migrate_entry adds manual_refresh_only: true to pre-v3 entries that lack the key. So plenty of users will have this set without ever knowingly choosing it, while the form shows them a reassuring ticked "Automatically refresh the sensor" box.

Workaround

1. Settings → Devices & Services → UK Bin Collection → ⋮ → Reconfigure
2. Untick "Automatically refresh the sensor" (yes, untick — the label is inverted)
3. Set "Time in hours between updates" to your preferred interval and submit

The reconfigure reloads the entry immediately. You can confirm it worked in the HA log — on setup it should now log:

[UKBinCollection] Automatic refresh every N hour(s).

instead of:

[UKBinCollection] Manual refresh only: no automatic updates scheduled.

Verified working on my install: scheduled refreshes resumed straight after the change.

Suggested fix

Relabel the checkbox to "Manual refresh only (disable automatic updates)" in strings.json / translations/en.json, or invert the field so the label and stored value agree. Happy to raise a PR.

[Welshdragon80]

Had same issue but for powys, tagging my seld so I csn see when its fixed.

Thanks

[pacso]

Had same issue but for powys, tagging my seld so I csn see when its fixed.

Thanks

It technically isn't broken. You can fix this immediately by just reconfiguring your setup and unticking the Automatically refresh the sensor checkbox.

[Welshdragon80]

Iv added homeassistant.update_entity into an automation I run for alexa to announce so hopefully that will fox it .

[pjuster]

thanks for all the work on this, its appreciated. I've disabled the "Automatically refresh the sensor" which seems counter intuitive!

[robbrad]

Traced this end-to-end. @pacso's diagnosis is right — it's the manual_refresh_only option, not the scrapers — and here's the full history of how it broke, plus a fix.

It used to work; a recent commit changed the behaviour

The flag has always been awkwardly named, but for a long time it was consistent with the UI and worked:

• Up to 0.170.x: manual_refresh_only=True made the coordinator poll (auto refresh ON). The setup default was True and the checkbox read "Automatically refresh the sensor" — so a default install auto-refreshed and everything was fine.
• 0.171.0: commit 4c2a9924 ("correct inverted manual_refresh_only logic", fixing Error 500 - Fenland #2174) flipped the runtime branch so True now means update_interval=None (auto refresh OFF), to make the code match the field name.

The flip made the code self-consistent by name, but the default was left at True, the label still says "Automatically refresh the sensor", and existing stored config was never migrated. So on 0.171.x:

• the default-ticked "Automatically refresh the sensor" box now disables polling, and
• every existing entry that had manual_refresh_only=True (the setup default) silently stopped auto-refreshing on upgrade.

Restarting or reconfiguring re-runs the one-time first refresh, which is exactly why those temporarily "fix" it and then it goes stale again.

The migration gap

There are two open PRs from @pacso (thank you!): #2196 (relabel only) and #2198 (introduce a positive auto_refresh_enabled flag with a sane default + correct label). #2198 is the better direction and fixes new installs. The remaining gap is existing installs: it reads legacy entries as auto_refresh_enabled = not manual_refresh_only, which assumes the post-flip meaning. But the flip changed what the stored value means without migrating it, so the boolean is genuinely ambiguous — pre-0.171 entries stored True meaning "auto on", and negating that leaves the whole upgrade population with no polling.

New PR: #2203

I've opened #2203, which builds on #2198 and adds a one-time config-entry migration (schema v3 → v4). To remove the ambiguity it takes a deliberate, maintainer-approved policy: enable automatic refresh for every existing entry on upgrade and drop the legacy key. That guarantees this regression is resolved for everyone regardless of which version wrote their config. Anyone who genuinely wants manual-only can untick the now correctly-labelled "Enable automatic data refresh" option.

Until a release lands, the immediate workaround stands: reconfigure and untick "Automatically refresh the sensor" (yes, untick — the current label is inverted).