Closed andrew-kennedy closed 3 months ago
Thanks for this PR. I'll test out the changes on my local system and perform the merge if I don't notice anything amiss after testing for a couple days. Thanks again and happy holidays!
Hi, I got a chance to run this code and it seems something isn't quite right.
When I just replaced the files in my HA instance and rebooted (to simulate an in-place upgrade for existing users) everything seemed to work.
A problem occured when I removed and re-added the integration (to simulate a fresh install for new users). I wound up with a single HyperHDR light entity and 9 automatically disabled 'none' entities and even after manually enabling all of them they do not get properly identified.
I'm not sure why everything is getting created as 'none' instead of their proper component names (HDR, Smoothing, Forwarder, etc).
I reinstalled the old/currently-available custom component, rebooted Home Assistant, then removed and readded the integration and everthing appears back to normal with all of the extra switches being assigned their proper component names again.
When you have time please take another look at the code in the PR to see what might be causing the components to get named 'none' and after we can both verify that it's working as desired, for both existing and new users, it can be merged.
Any progress in this ?
Strangely, I also now can't get the lights to load proper names etc on the latest version of home assistant. Using the version that was current on December 11th, when I put this PR up, I was able to get all the switches to load their proper names just fine, even after I had added and removed the integration during the debugging process. Now, using the same code, even after a reboot it doesn't get the correct switch names. I've gone and carefully diffed all my files with the latest Hyperion integration files and nothing stands out to me, and I don't have the time to dive in deeper at the moment.
One issue could be that I tested this PR against HyperHDR v19 and I'm now using the v20 beta and it doesn't seem to get the proper switch names. Perhaps something did change in the json api?
Version 20 is now officially released.
Hello, Thank you guys
I've observed Nones on hyperhdr v20, but apart from that, everything seems to be functioning perfectly. I really appreciate that this pull request eliminates the frozen priority channel. 👍 I'm going to stay on this PR until it is fixed further/merged
Closing this PR as I've just created my own fork of hyperion-py and hyperion-ha that don't rename every constant/variable to "HyperHDR" from "hyperion" as that makes tracking the diffs from the official component way harder. My fork of the official hyperion-ng component synthesizes stuff from this fork as well as hyperhdr-py. It lives at https://github.com/andrew-kennedy/hyperhdr-ha
I'm still having the "none" names issue in entities but it seems to be working.
@andrew-kennedy i don't know how to otherwise contact you, because on https://github.com/andrew-kennedy/hyperhdr-ha i cannot open an issue.
@mhoogenbosch I added issues to my project, but I haven't really had the time recently to figure out what the deeper issue is with communication with HyperHDR and what the naming issues is. I've been moving house and quite busy.
This hyperHDR integration had ceased to work with the latest HyperHDR version 19.0.0.0 so I looked at what changes had been made to the hyperion integration since 05/2022, the last major update to this project, and brought it up to speed with the changes since then. Ever since I did this, the hyperHDR integration has been working great again. Looks like the hyperhdr-py library does not yet need to be updated.