Improve waste sensor setup and device editing

[PrzemyslawKlys]

Summary

This PR redesigns the Waste Collection Schedule UI around Home Assistant device-backed waste pickup sensors.

Instead of sending users through the legacy multi-step sensor editor, setup now creates clear waste sensor devices during onboarding. Each waste sensor can then be configured from its own device page using normal Home Assistant entities.

What Changed

• Creates one device-backed waste pickup sensor per selected collection type during onboarding.
• Adds an optional combined "next waste pickup" sensor that can show multiple same-day pickups together, for example Bio, Śmieci in 10 days.
• Moves sensor display settings to each waste sensor device page, including display mode, date format, display language, state text presets, advanced templates, filters, and removal.
• Adds localized display presets for all translation languages currently shipped by the integration: English, Polish, German, French, and Italian.
• Removes the legacy bulk sensor editor from the config/options flow so users only have one clear editing model.

Pain Points Addressed

• Simple display changes were hard to find because sensor editing lived deep inside the integration options flow instead of on the sensor/device page users naturally open.
• Renaming/customizing collection text could be confusing because source collection aliases and sensor display names were edited in the same wizard-style flow, making it easy to end up with unfriendly raw names or duplicate-looking names in Home Assistant.
• Dashboard-friendly output required writing templates manually, which made common changes like Bio in 13 days, in 13 days, or Today / Tomorrow / in 13 days unnecessarily fragile.
• A small template typo could make a sensor become unknown; the new preset selectors make the safe/common paths clickable while still keeping custom templates available for advanced users.
• Creating, editing, and deleting waste sensors used to be mixed with source-level options. This PR separates those concerns: source/calendar options stay in the integration flow, while waste sensor lifecycle and display settings live with the relevant device.
• A combined "next waste pickup" sensor can now preserve multiple pickups on the same day instead of forcing users to create separate dashboard chips or lose context.

Migration Experience

Existing UI-configured sensors are migrated automatically when the config entry is set up after upgrading.

• Existing sensors options are preserved.
• Sensors that do not yet have a stable internal sensor_id get one added to the config entry options automatically.
• Existing name-based sensor unique IDs are migrated to stable ID-based unique IDs in the entity registry where possible, so existing entity IDs, custom names, dashboard references, and history should continue to work.
• Existing sensors appear as their own waste sensor devices and receive the new configuration entities automatically.
• Source settings and collection type customizations are unchanged.
• No manual recreation or user-facing migration wizard should be required.

YAML-created sensors continue to use the existing YAML configuration path. The new device editing experience is for config-entry/UI-managed sensors.

Why

The previous flow made simple changes, such as renaming a waste sensor or making its state text dashboard-friendly, hard to discover and easy to break with a mistyped template. This keeps onboarding simple, while still preserving advanced configuration for users who need it.

The intended user flow is:

1. Add the waste source/location.
2. Select which detected waste types should become sensors.
3. Open the relevant waste sensor device page for everyday changes.
4. Use advanced entities only when custom templates or filtering are needed.

Screenshots

Each waste type is represented as its own device, so it is easier to find, edit, disable, or remove.

New sensors can be created directly from the integration device page.

Each waste sensor has its own focused configuration page. Common settings are visible by default, while advanced options remain available when needed.

State text can be selected from ready-made presets instead of requiring users to write templates blindly.

Display language presets make the generated text easier to match to the user's Home Assistant language or dashboard preference.

Waste sensor devices can be disabled or removed from the normal Home Assistant device menu.

Latest Sync Notes

• Merged current upstream master into this PR branch after upstream moved to v2.23.0.
• Resolved the options-flow conflict by keeping the new grouped options layout and adding upstream's fetch_interval_days setting there.
• Added follow-up hardening for sensor defaults, dispatcher cleanup on reload, and template validation before saving custom template text.

Validation

• python -m py_compile custom_components/waste_collection_schedule/config_flow.py
• python -m py_compile custom_components/waste_collection_schedule/sensor.py custom_components/waste_collection_schedule/sensor_config_helpers.py custom_components/waste_collection_schedule/text.py
• python -m compileall -q custom_components/waste_collection_schedule tests/test_sensor_device_config_helpers.py tests/test_sensor_structured_attributes.py tests/test_type_aliases.py
• $env:PYTEST_DISABLE_PLUGIN_AUTOLOAD='1'; python -m pytest tests/test_sensor_device_config_helpers.py tests/test_sensor_structured_attributes.py tests/test_type_aliases.py -q

[markvp]

I love this idea.

What would be migration experience for existing users and their existing sensors?

[PrzemyslawKlys]

There is an automatic migration path (i've updated the main PR description), not a manual/user-facing one. Existing UI-configured sensors are preserved. On first setup after upgrade, sensors without a stable internal sensor_id get one added, and existing name-based unique IDs are migrated to stable ID-based unique IDs in the entity registry where possible. That should preserve existing entity IDs, custom names, dashboard references, and history. Existing sensors then appear as their own waste sensor devices and receive the new configuration entities automatically. YAML-created sensors continue to use the existing YAML configuration path.

In my upgrade test, I did not manually touch or recreate the existing entities. After upgrading, the integration auto-migrated the existing UI-created sensors during setup. The existing sensor configuration was preserved, stable sensor_id values were added internally, and the sensors appeared as separate waste sensor devices with the new configuration controls.

So the intended migration experience is: existing UI-created sensors keep working automatically, no manual recreation required. The visible change is that those sensors are now represented as individual devices so they can be edited more naturally from the Home Assistant device page.

More real-world upgrade testing from other existing installations would definitely be helpful, especially for setups with renamed entities, older config entries, or more complex sensor/template configurations.

[PrzemyslawKlys]

One UX decision that may be worth discussing is the “create sensor” section shown here.

The current approach is explicit: detected waste types are available to create, and once created they can be configured, disabled, or deleted from the normal Home Assistant device/entity model. This avoids creating entities the user may not want.

An alternative would be to automatically create sensors for every detected collection type and let users disable the ones they do not need. That would remove the slightly awkward Home Assistant button state of Press, but it would also create more entities/devices by default and may feel noisy for users with many detected waste types.

I kept the explicit create/disable/delete model because it feels safer and more intentional, but I’m open to feedback if maintainers prefer auto-creating everything.

[markvp]

I'd like to think about this a little. I agree that we can improve the experience, but I'm not entirely sure this is the right design. Keeping this open pending further thought, discussion, input from others.

[PrzemyslawKlys]

I've improved this PR slightly and fixed existing conflicts

[markvp]

I'll be honest @PrzemyslawKlys - I love the idea behind this. I have been trying to find ways to improve the interaction myself - but I'm not the original author of this package and I don't feel that I can adjust the direction of this package so significantly without some kind of feedback from other maintainers @5ila5 and @bbr111 or the original author @mampfes

[PrzemyslawKlys]

I understand and I will accept any decision, or wait time it requires. I will probably maintain my own version even if it gets closed and just keep on 'porting' the changes to my own :-) What I can offer is ability for this feature to be opt-in. To preserve the old way, use as you fit. The problem is once you optin, going back is going to be a problem, and that I guess makes it risky for users who may click it by accident and the complains will start. They would have to remove, start from scratch. Of course this all assumes the new model isn't better 🙂 and people won't prefer it over the old way. But to each their own or however that goes and I would prefer not to make assumptions what people like or dislike.

[bbr111]

@markvp @PrzemyslawKlys
I'll try to take a closer look at this next week.

[jan-tdy]

I'll also try to take a closer look at this next week.