RFC: Normalize project about hacs_waste_collection_schedule

[mampfes]

Hi, thanks for sharing your helper entities. I would like to add them to the documentation (if this is ok for you), but for this some little pieces are missing: Could you please also share your initial waste_collection_schedule sensor configuration and some example png's?

Regarding normalization: I think there are a lot of different waste types out there in the world.. And I also think that there are always people who want to have their own naming for their local waste types. Normalization wouldn't help them and you still need a way to customize your appointment types. On the other side I see your problem, but I would solve it in a different way: You can already set an alias for every appointment type (see https://github.com/mampfes/hacs_waste_collection_schedule, section "Customize Source"). If you use this feature you don't have to translate it within your helper entities anymore and they become generic therefore.

Maybe the documentation is not obvious enough and I should add another example. What do you think? Would this fix your problem?

[boesing]

I would like to add them to the documentation (if this is ok for you)

Feel free.

Sensor config

waste_collection_schedule:
  sources:
    - name: awbkoeln_de
      args:
        street_code: <code>
        building_number: <building>
  day_switch_time: "23:59"

Screenshots

And I also think that there are always people who want to have their own naming for their local waste types

Overwriting enum translations from within the YAML configuration would be quite easy.
As you already mentioned in your comment, there is already a way to use an alias tho.
However, I am not sure if that would work when there are two appointment types on the same date as these are comma separated and thus there might be multiple values like blau, grau or grau, blau and so on. The more waste is scheduled, the merrier combinations would be available. One could solve that with using a list of enums for a specific date instead of having just a string value.

Normalization wouldn't help them and you still need a way to customize your appointment types

Well, I think it would as you dont have to override blue or papier or paper or whatever color that is in another country as you have a dedicated enum value for paper waste.

---

However, I see that this normalization wont suit your needs and thus there is no need to put that much work in that kind of refactoring.

Anyways, thanks for your time. 👍