hmmmm… i guess not, my z2m network is about 38 devices and really reliable.
Also two xiaomi body sensors are going well its all about this hue motion thing
but thanks for the hint at the moment i’m thinking about updating cc2531 firmware but this is a courageous project 
For what it’s worth: The custom component was at least 2-3 seconds faster at detecting motion than the native component. I’ll be sticking with the custom component until the issue is resolved. FYI: I am on the v2 hue bridge. I am not blaming anyone for the issue but the response time for the native component is slow enough to be nearly useless for me.
Note: I only compared the response times once. Since the issue is sample frequency related I should have tested multiple times to get a good estimate of the actual difference because the result I got depends upon where in the sampling interval I happened to trigger the motion.
.
How do I change the components?! 
I’m on .94 and I’ve not seen any errors that’s been reported recently
that good to hear. Could you please share your settings, so we can confirm all is fine?
thanks!
I use Deconz. I used a hue motion in the past but switched to Aeotec Multisensor because of the temp and humidity sensor, but the hue motion sensors worked perfectly fine for me.
Maybe it’s the best if you post your question in the ZigBee2MQTT thread
I confirm that the patch works on home-assistant 0.94.3
Thanks for fixing it!
What does the device_tracker part of this do? I’m still getting an error from this, so wondering if I can just remove that part.
I have Hue lights, dimmers & motion sensors. Would removing the device_tracker line from my config stop anything working??
you guys should seriously consider getting a conbee: https://phoscon.de/en/conbee
I have now got rid of all my 3rd party hubs, and now have clear skies (no cloud) setup is a sinch and no flaky work arounds…
Not to say that I don’t love and admire @robmarkcole work, but with the constant change to the Home Assistant environment, it is good to have something that just works and is not reliant on a big companies cloud API which they may or may not continue to support…
You are right in Many ways, but I don‘t want to miss some features my Hue Bridge has!
First is Hue Entertainment! I Love it and I also use it 
Second is to control my lights with Alexa, for free! My wife and son love this Feature!
Third, my hue Dimmer has less features with deconz than with my Hue hub!
For my sensors or rooms where I don’t Need this Features I use deconz as well.
Just ordered one!
yes, but essentially, the hue hub and software thereon is largely under the control of Philips, they can change or whatever they want to this platform as it is an extension of their cloud.
If for example, they found a security issue, they would then force an update to the hub which could potentially break the api access (I had this happen to me about 3 times, to the point where philips just started reponding to my tickets by sending me a new hub…I have actually become quite friendly with some senior technicians at hue now through this. I have about 4 of them (hubs not engineers now lying around at home. ) I also had an incident whereby the hub would keep renaming and mixing up the names of my bulbs, causing endless headaches downstream (I have about 30 bulbs)
So whilst I know that there are loads of features (like the entertainment and switch functions) built into the hub, for me, it is much better talking to the zigbee network directly as opposed to via the hub, but each to the own… I thought I would simply share my humble opinion… 
Like I said, I used the custom component from @robmarkcole and it worked brilliantly, my house just started getting very busy when I started to add the xiaomi kit, and reliability started failing to my bulbs… all my bulbs now work much better since I use conbee with xiaomi and hue and all other zigbee on the same network…
Interesting, I’ve had the exact opposite experience. I have 36 lights, a motion sensor, and 6 FOH switches on my Hue bridge and it has been absolutely rock solid. In 4 years I’ve never once had an issue controlling lights or anything of that nature.
I also have 5 sets of Lightify Gardenspots which were absolute crap when connected to the Lightify hub. I have 7 Keen Home vents which were absolute crap when connected to the Keen Home hub. I’ve since connected those 12 devices directly to Home Assistant with an Xbee and they’re much better, but still nowhere near as reliable as my Hue system. Heck, Home Assistant in general isn’t as stable, and I’m running it on an enterprise server with dual 16-core CPUs, 52GB of RAM, dual PSUs, etc.
As this point I’ve basically decided that I’m replacing all non-Hue Zigbee devices with Hue products or Z-Wave.
interesting… it all depends on so many variables, including your home wifi setup and channels, size of the property, type of hue bulb (v1,2,3 etc) etc etc etc… for me, I had 2 lights that will simply not connect to my hue hub regardless of what version bulb I was using - 1 outside the front door and the other outside the back door, each were quite close to another internal bulb… since I moved to conbee they connect no problem… everytime… I suppose it is simply trial and error until you find a way to appease the household connectivity anomaly gremlins…
FWIW I moved my motion sensors to Deconz too and find they are lightning - I don’t think that there was an issue with this plug in, I found that the Hue Hub kept going offline. Interestingly, the hub is still servicing lights only now (about 25 of them) and hasn’t gone offline once. Deconz is running on a standalone Pi.
Big thanks to @robmarkcole though for all his work on this - worked really well for the year or so I used it.
I’m stuck with this. I have this automation to use the same Hue Tap Switch button to open and stop a cover at any point, not only a 100%. One click, it starts opening, next click it stops. Basically, the template reads the state of the cover and only activates cover.stop when it detects it is opening, otherwise it opens. Now according to @Caladera here, I’m using 4_click as a condition, not as a trigger, because otherwise there is no change in "to:" when pressing the same button.
My problem is, since the trigger is the state change of the cover, once the cover stops and changes from “opening” to “open”, the automation runs again and cover.open fires once more. So basically the cover stops for a second and keeps opening.
Any help?
- id: '1560748807274'
alias: Office Tap Switch Button 4
trigger:
- entity_id: sensor.tap_switch
platform: state
condition:
- condition: state
entity_id: sensor.tap_switch
state: 4_click
action:
- service_template: >
{% if is_state("cover.shelly_shsw_25_0047f0", "opening") -%}
cover.stop_cover
{% else %}
cover.open_cover
{% endif %}
data:
entity_id: cover.shelly_shsw_25_0047f0@phairplay
just for completeness sake: Ive just updated to 94.3 and no errors are displayed, the device_tracker seems to work as before.
Maybe the configuration checker wasn’t correct after all:-)
update
forget the above, after having updated successfully, and seeing the device_tracker doing its job, I decided to give another restart (had changed several other things) and I get a config error:
which is rather peculiar, since I also see this:
now what…?
no, it would simply not create the device_tracker for your phone, all other sensors are in the other components.
I am still amazed this is happening and no one has an answer, doesn’t anybody use the device_tracker at all maybe so no errors are displayed?
there must be a solution somewhere…
If anything, choosing the name huesensor for the custom components was adding to the confusion to say the least. I am now looking for an answer why the device_tracker.huesensor isn’t found…;-|
It simply isn’t a sensor, but a device_tracker.
By separating the components in 3 parts, as was done a few iterations ago, giving a better name would have been possible. The Hue Custom component could have been called hue_custom, (and not huesensor) and create sensor, binary_sensor and device_trackers with that name.
that put aside, it really hope @robmarkcole could shed some light here how to get the device_tracker back on track again in 94.3.
Since I have the config files in a small package, Ive also tried to remove it there and place the device_tracker in device_tracker.yaml, but that makes no difference, same error is thrown.
I’ve now disabled the custom component for the device_tracker, because if not, HA won’t restart, erroring out on the config check, making this a bug of importance…
Sorry for not getting back sooner (I’ve been away)
Why are using it as a device tracker?
I’m currently running 0.94.0
all i have is the below in my sensor yaml file
- platform: huesensor
ip_address: 192.168.1.1
token: -mytoken