![]() 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. 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. 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. To do this, go to the Alexa app, tap More, Skills & Games, then tap Search. If you still get issues, one final thing to try is to change the ZigBee channel of your Hue Bridge. Sometimes the Alexa Skill can lose its connection to the Hue, and the easiest way to fix it is to remove and re-add. Hopefully the motion sensor will work okay after this. Follow the on-screen instructions to re-add it and set it up again. it’s all in the source code, and heavily debated. Select Hue Motion Sensor or Hue Outdoor Sensor. If even a single one has the orange dot, repeat 1-3 again. 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. Go back to 'Settings' -> 'Software update' -> and see under 'Devices' if any have the orange dot / 'Device is unreachable' (give it 60 seconds to rebuild the mesh). 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. ![]() PHILIPS HUE BIG ISSUE ON WIRELESS CONNECTION QUICK PERMANENT FIX. no communication between Hub and Ha (this would be a true error, caused by possibly many things) No Tradfri Firmware Update Required When Pairing With Philips Hue.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. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |