When I upgraded from 0.91.4 to 0.92.2, my custom hue sensors got renamed and for each motion sensor device it is returning one binary_sensor and two sensors. I did not change any directory structure but updated my sensor names in lovelace and it started working.
You have to reneame, because you might see only the integrated sensors. Check, if you got the CC Sensors and then follow the installation instructions (__init__py and manifest.yaml) in case of missing them
I had an __init__py that was almost empty. It had “”“the hue sensor component”"". I deleted that line and then upgrade. And it’s working. THX!!
Hi,
Noticed that there should be updates available. I have downloaded from github - https://github.com/robmarkcole/Hue-sensors-HASS.git and replaced all the files in Hue-sensors-HASS/custom_components/ huesensor / into my /config/custom_components/huesensor/ directory.
I still have this on my screen, what am I doing wrong.?
Same issue here 
yep, me too!
So, I assume I’m doing nothing wrong 
custom_updater/tracker-card combo is stupid…
It relies on a “VERSION” / “__version__” tag inside the files to determine the “installed” version. example
So although the custom_updater.json file have the correct content, it will show wrong local version…
Now works. from today I saw 1.4 on current version.
HI all
a short update on the state of this CC: Now that there is an official HA integration for Hue sensors I am freezing this (CC Hue sensors) repo - meaning I will not be accepting any new features. Instead I encourage contribution of features to the official HA codebase. I know many people rely on this repo e.g. for remotes, so will consider any PR which address breaking changes that affect this repo, but these are the only PR which will be considered.
Many thanks
1 Like
Also the motion sensor response is so much faster than the official one…
For me, at this point, if I would have to use the official one, it would be almost useless…
Fair enough as long as this component keeps running.
The official one is completely useless for me.
Why is the official one useless?
because the reaction time is too slow.
Switching on a light, when I already touched the wall on the other side of the room is definately too late
1 Like
I agree
with the sensors there is a second or 2 delay, yet this CC is instant
The official one isn’t useless, per se, but it isn’t that useful either when motion sensors are considered.
The only Hue devices I use are the motion sensors & remote (purchased specifically for use with this Custom Component). This CC works nearly instantaneously while the official one consistently falls ~4-5 seconds behind in registering motion… not very useful for activating stair lighting on an as-needed basis.
I am running HassIO 0.90.1 and recently upgraded after which my Hue Switches stopped working. I restored from a snapshot and they work again. I have seen references on this thread to a ‘great migration’ but am finding it very hard to positively identify exactly what it is I have to change to make my Hue switches work on more recent versions. I am not interested in switching to the built in component given the performance issues that have been reported on this thread.
Is there perhaps a wiki somewhere that clearly states what has to be changed - or if there is a post in this thread with detailed instructions, could someone point me to it please?
Many thanks
Steve
Is there a specific reason why the official implementation is so much worse than the CC? The delay makes integration pointless.
Per balloob in the native component’s Github issue:
I personally got a lot of attacks and shit for the hub being unavailable all the time, my code being bad. Turns out that people are just hitting the hub with a ton of requests all the time. We should not increase the request rate, as it will get us unavailable hubs again, and I get all the blame.
It’s not our fault has an Hue that is not suitable for motion sensors. If you want to have a super fast rate, feel free to use the custom component or feel free to contribute a request manager for Hue that maintains rate limit, backs off sensor requests, prioritizes commands etc. But don’t come in with requests to just lower the scan interval, as that’s not a solution.
So the hub can get unresponsive if too many requests are coming in too frequently (apparently it’s worse with V1 hubs). Balloob would prefer Hue change their system, which they are apparently working on (but with no announced timetable for availability):
https://www.reddit.com/r/Hue/comments/agfqks/ama_with_george_yianni_founder_of_hue/ee759rm/
Assuming Hue does eventually release the feature into the wild, sensor (and possibly light) data would be pushed (via webhook or similar mechanism) to Home Assistant or other external systems, resulting in virtually instantaneous updates with no polling performance hit. That’s the ideal outcome, but until/unless they do, we’ll have to choose between slow native or ‘fast’ custom components, with the caveats each bring. Or someone has to work out how to do what balloob suggests in his second paragraph above and submit it for inclusion in HA.