Heck, I’ve even created a sensor to check for the Hub not being overloaded.Īs said, it has been very reliable lately, and fingers crossed that will stay. (For example if I turn my kitchen lights off at the main switch my garage Hue goes unreachable as theyre too far away from the. If you still get issues, one final thing to try is to change the ZigBee channel of your Hue Bridge. Dont forget Hue is a mesh network so turning off lights at the wall can effect other bulbs further away from the bridge as when theyre powered on they are also acting as a repeater for other bulbs to get a signal. I probably should mention that the query is initiated from Hue UI on a node called and the error is mentioning not being able to use. Hopefully the motion sensor will work okay after this. If you have multiple wireless networks such as a guest network, a 2.4ghz network, and a 5.0ghz network please try to connect to each network and then go into. Follow the on-screen instructions to re-add it and set it up again. Since that is very unlikely, (we’ve all added to the Hue developers community and asked for that) all we can do is optimize the HA instance as much as possible. Select Hue Motion Sensor or Hue Outdoor Sensor. We can only hope Hue will one day change its api to a push, so HA won’t need to poll the Hub any longer. It would show a true unreachable (Hub cant see the light) and wouldn’t have to show ‘Unavailable’ (HA/Hue comm error)… While it is very handy to have that, on lights that don’t have power. Nor was it accepted to add the attribute itself. I’ve asked to split the logic on Api attribute ‘reachable’ (Hue communicating with Light) and ‘unavailable’ (HA communicating with Hue hub) but Paulus didn’t want that. it’s all in the source code, and heavily debated. I don’t see how the integration fails to get its allotted share of execution time.ītw, it’s not that the integration doesn’t get its allotted execution time, it’s a hard limit set in the Ha Hue core code within the polling should return. Which of course it isn’t, but its the state the Hue Hub records it to be, and that is being reported back to Ha because of the allow_unreachable: true : Have a look, my Garden terrace light is cut off power (because of a light sensor) and is reporting to be On with 50% brightness. In both case the lights can’t be controlled of course because they are unreachable… Right now we cant see if we have an HA-issue with the Hub, or if a light simply has no power. It does make a difference as you can see above, and would be really nice if we could distinguish between the 2 situations. I’ve asked the core dev team to relay that attribute into Hue core attributes, but was denied unfortunately. Hue sets the ‘reachable’ attribute to false, which is taken into account in the Hue logic) no communication between Hub and lights (this would be regular operation indicating the light had no power, or is broken eg, but the Hub still communicates with Ha.no communication between Hub and Ha (this would be a true error, caused by possibly many things).That wont fix HA not being able to control them when they are unavailable, it simply makes the HA interface show the state the lights were in when available before, as recorded in the Hub. That should be fixed by adding: allow_unreachable: true
0 Comments
Leave a Reply. |