Figured it out, found it in the logs
2022-06-23 10:13:53 ERROR (SyncWorker_1) [homeassistant.loader] The custom integration 'hdhomerun' does not have a version key in the manifest file and was blocked from loading. See https://developers.home-assistant.io/blog/2021/01/29/custom-integration-changes#versions for more details
That’s not this integration. Did you add the GitHub repository from the first post as a custom repository in HACS?
LOL thats very confusing, HACS has an integration built into the master repo, i thought that was this
Thanks for this excellent custom component @uvjim
It “just works” with hassos unlike the “default” hdhr integration thats in hacs repo - that requires libhdhomerun to be installed to use it.
Just realised that I’d not released the previous beta however, there were some updates that needed doing so…
2022.8.1 is now out: -
pyhdr
pyhdhr
pyhdhr
async_forward_entry_setups if availableIt’s been a long time since I did any work on this integration… I’ve just pushed a beta that starts to make use of the new translation capabilities for the entity names etc. Some of the code has been tidied up a bit and a fix put in that was making UDP discovery a little slower than it should have been.
2023.2.0 as this allows all of the translation features that are in use now.Thank you for your continued effort on this!
No problem. I thought it needed some love again.
There were no complaints from the beta release so 2023.4.1 has now been released. Details as per: here
@uvjim are you running the 2023.6.x version of HA Core yet? With that version, all of the entities except for the tuner count, reset button and tuners themselves are unavailable.
These are the only records in the logs:
Error fetching hdhomerun_tuner_status_12313041 data: Device not found ([ip address redacted])
_async_data_coordinator_tuner_status_update (12313041) --> Device not found ([ip address redacted])
Forced update failed. Entity update.hdhomerun_hd_homerun_update not found.
The device itself is still working and its IP address has not changed (DHCP reserved).
I have one of the betas running as I’ve just been moving the development environment over to docker. I haven’t tested this integration in it yet mind you.
I’ll take a look today.
Absolutely no rush. I’ll do some digging and more restarting in the meantime.
I’ve had a quick look and there is something funky happening in the new versions of Home Assistant. I’ll have a look when I get time as there seems to be some issues around translations for the Config Flow as well. When I add a new device it defaults to using the UDP method to poll the tuners and fails the HTTP method even though it should be available. I’ll dig in a little deeper when I get the time.
UPDATE: if you need it the main branch should have a fix for devices that are in HTTP mode. I’m still looking into what is happening with the config flow.
UPDATE 2: turns out the Config Flow problem was between keyboard and seat. There is another update that I need to put in and then I should have a release out for you.
2023.6.1 of this integration has now been released which should address the issue you reported @WhimsySpoon.
Working perfectly now, thank you!
Is HTTP preferable over udp for these devices? I think mine is operating in http mode.
The discovery should be automatic. Putting SSDP discovery aside, when you add the integration, whether you provide an IP address or not, it’ll use UDP to ensure the tuner is there. The discovery process then checks to see if the tuner can be reached using HTTP. If it can can, it should use HTTP for all future things.
When using HTTP mode there are more entities available to you as the integration can gather more information from the HTTP API.
You can find which mode you’re in by looking at the device in Home Assistant (I decided to put the mode in there - see below).
Not all tuners have the HTTP API available, I don’t have any of those, but have hopefully made it so they can still be used - I did my testing by stopping discovery from attempting HTTP querying.
Hopefully that explains a bit more about how that process works.
As a side note, I now know why the issue you saw occured, it was down to the bump in Python version to 3.11 and the way the HTTP API URLs were being built. They should be fine now for all versions of Python but, I’ll leave a note in the code to switch to the built-in StrEnum (now standard in 3.11) at some point in the future. It was this PEP that did it: PEP 663 – Standardizing Enum str(), repr(), and format() behaviors | peps.python.org
Thank you for the detailed explanation, that all makes sense. Mine is reporting HTTP so I’m pleased it’s using the preferred one!
Thank you again for all of your efforts on this.
Thank you very much for this integration and the Lovelace card code! I have it installed on my HDHomeRun DUO and it works great! I have one question: what size should I make the icon files? I have been messing around with 256x256 and other sizes, and can’t seem to get one that fits properly.
Thank you again!
I don’t use that functionality I’m afraid. The size would be dependant on which card you were using and how it frames that in the location for the picture.
AHA! 
Thank you for the prompt reply!
I keep learning about HA, even after 2+ years using it. I suppose the icon representation will also depend on how Lovelace shrinks the card to show multiple columns. Back to the drawing board!
Thank you!
