When Radarr Integration was "updated" last year several sensor were not migrated to the new functionality

[taw123]

The problem

While it is SINCERELY nice that the (not quite so) new Radarr implementation was modernized to fix many of the old API issues that many of us worked around, it seems that not all the functionality was preserved in the migration.

In addition it would be nice overall to see a standardization of the Radarr and Sonarr entities, where appropriate (allowing for the differences inherit in serial/episodic content). This even more appropriate request given the rebasing (aka merger/unification of the core for) of Sonarr and Radarr. HOWEVER that of course will have to be for a later FEATURE REQUEST, which this is NOT.

The original integration provided for a sensor.radarr_upcoming (like the sensor.sonarr_upcoming), that provided an entity with the number of movies, and attributes that container the individual items. Which the "calendar" items MAY provide some of this functionality. And I IMAGINE it is POSSIBLE for someone to create a templet sensor to recreate the original sensor by somehow walking the content created and putting all that into the sensor as attributes but this is hugely inefficient waste of labor required now for EVERY person who simply wants the same functionality/representation they previously had under the old integration (which btw is the same as the CURRENT Sonarr integration)...

I also don't SEEEM to have ANY indicator per calendar item what the release type actually is of the given entry. Per the Radarr integration documentation:

A calendar entity will also be created indicating the day of release and the type of release, such as Cinemas, Digital, or Physical.

Yet when I look at the Calendar entities I see the following. Perhaps I misunderstand the user oof the calendar or what the documentation is claiming, but I expected each entry to have some data/field/icon/selector/something to indicate if the entry was a release date for theater/digital or physical release which I don't see in the attached screenshot.

Please don't interpret this issue as a complaint or or worse yet as a self-entitled demand it's intended as neither. I STRONGLY suspect with sufficient free time on my hands I probably could cook up a solution to address my OWN concerns as I mention above using a templet sensor (when I understand it well enough), but it seems a shame that those who might not know how to do this will lose/not have the same core functionality. I would offer to help if I understood MUCH more about HA internals AND Python in general as a language.

Thanks for your consideration, and any possible assistance, Regards.

What version of Home Assistant Core has the issue?

Core v2024.4.2

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant Container

Integration causing the issue

Radarr

Link to integration documentation on our website

https://www.home-assistant.io/integrations/radarr

Diagnostics information

N/A

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

[home-assistant[bot]]

Hey there @tkdrob, mind taking a look at this issue as it has been labeled with an integration (radarr) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of `radarr` can trigger bot actions by commenting: - `@home-assistant close` Closes the issue. - `@home-assistant rename Awesome new title` Renames the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign radarr` Removes the current integration label and assignees on the issue, add the integration domain after the command. - `@home-assistant add-label needs-more-information` Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue. - `@home-assistant remove-label needs-more-information` Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

---

radarr documentation radarr source _{^{(message by IssueLinks)}}

[tkdrob]

Many times when things need to be fixed, the standards change on the project and require integrations to conform to those new standards. Many people run HA on low spec hardware and extra attributes require extra database storage. They are therefore not allowed in most cases. The release type was indeed something I wanted to include but it was not part of the calendar standard. @allenporter is your guy is see how we can change that.

I see you put a lot of effort into writing this. Have you posted this in the community forum? This would be classified as feature requests and those are not tracked here. The season of "What the heck" was a big success and this kind of thing could be put there when the time comes. Smaller chunks are always better. So it would be good to slice this up into smaller asks.

[taw123]

Thanks to the quick response, and the kind statement about the effort I put into documenting the issues and exploring alternatives I could personally implement.

While I understand and appreciate the goal to try to hold the line on system requirements, I would proffer that my comment was about MAINTAINING functionality so in THEORY there would be no overall system penalty in preserving the existing attributes. However as I said I honestly do understand the thinking you conveyed and realize no matter what I say on this, it's a debate that I will not win so I would rather not waste more of your time with that.

Regarding the documentation bug/missing functionality of the Radarr calendar entity... Will the Radarr documentation be revised to MATCH the CURENT functionality or is a change in the functionality expected that will bring the delivered function in line with document and intent. Clearly in the short term the document should be turned to call out that currently the feature is not fully implemented. While this is less than ideal as that means there will be NO WAY to replace the attributes functionality, it will save us all from multiple people like myself wasting time tying to figure out where the release details are, and filing their own bugs...

While I didn't originally consider this as a "new" feature, thus didn't file it as a feature request, I probably waited a bit to long after the old integration was removed, and given the push back you mention I agree with you that I should file a proper feature request. I'm concerned however that prospects for this are rather low given how long it took to get THIS update through after the old integration broke (many of us just hacked up the old integration to use the updated radarr apis). Also I think some serious thought should be given to rationalizing the functionality across the various integration (Radarr, Sonarr, Lidarr), rather than just slapping something together, but that's the system architect in me... lol. The user just wants his attributes back 😉

Thanks again for your considerate response and when I know what's going on with the calendar entity I'll file the/an appropriate PR.

Have a good weekend!

[allenporter]

Services with response values are my best suggestion with a solution to return additional data. (e.g. a custom service that returns the addtional data here). Slowly, template entity functionality is being added to the UI, but its not there yet for actions/services (acknowledge the point made here)

[taw123]

TY again.

If I might prevalent upon you for one final question that I apologize must have be gotten lost in my overly verbose previous postings…..

Given the documentation references functionality NOT CURRENTLY in the shipping integration is there a plan and timeline to either bring the doc in line with current functionality OR is the functionality likely to soon match the documents. If it is the later is there an expected timeframe for when we might see the release types populating the calendar?

thanks for all your patience on the matter.

[issue-triage-workflows[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.