a bug and a couple feature requests

[petep0p]

great to see the new version! i added a service for every calendar just because i want to see them all. a few things came up:

• the "naming style" option is not being respected. no matter what you set it to, the cross-quarter calendar shows the Celtic names only. the Chinese calendar shows English only.
• the old four seasons calendar has entities for all seasons, and you can see when each is coming up. i think it might be nice to be able to see that for the other calendars as well. i understand that would be a lot of entities, so maybe they could be disabled by default? if that doesn't sound like something you'd want to add, then it could also be good to have at least an entity for the upcoming event and when it will happen.

reason being, i don't even know what all the different Chinese solar events are and it would be good to be able to see them all and know when they're coming. it would also be possible to build visual calendars on a dashboard if all that info were available.

thanks for the great work!

[petep0p]

@moerk-o, i was looking deeper into it, and i can see all the terms in the states view in developer tools. i might be able to put something together and submit a PR for adding those entities. problem is, I'm not really a strong coder. would you be willing to accept PRs if I'm assisted by AI?

[moerk-o]

First things first: contributing is genuinely welcome, I'd love to have you involved @petep0p. 🙌

On AI-assisted PRs: totally fine, no reservations at all. This entire integration is AI-built, so how the code gets written doesn't matter to me.

Before we get into the "how", though, I'd like to step back to the "whether". I need to share some thoughts about the need for more entities.

Here's my thinking: every event is already exposed today. The current_period / current_term sensor carries an events attribute listing all of them with their dates (that's the states view you found in dev tools), and next_*_change gives you the upcoming one. You can already build dashboards and automations off that (or, if you don't, AI can).

So my hesitation isn't about the effort, it's that one entity per event means ~24 extra entities per Chinese device, and I've deliberately tried to keep this integration lean (same reasoning led me to not multiply sensors on the Four Seasons calendar earlier). If the goal is mainly "have them all as entities for completeness", I'm inclined to leave it as-is for maintainability and to avoid clutter.

But if there's a concrete use case the events attribute can't cover well, something you're actually trying to build and the attribute makes awkward or impossible, I'm all ears, and I'd happily reconsider.
Can you share what you're picturing?

And anyone else reading along who'd find this useful, please chime in too!

[petep0p]

oh, interesting! i actually didn't even think to look at the attributes. i probably can work with that - I'll give it a shot. i did see that these were all visible in the states in developer tools, but completely spaced on the attributes.

but this still leaves the display term bugs to be addressed... that i will also take a crack at, but if you already know what's going on and can get it out faster that's even better!