Request current light state from bridge? about homebridge-hue HOT 11 CLOSED

Hi @ZoneMR
Actually I have, possibly making this dependant on the heartrate. I haven't implemented this yet as for now heartrate is fixed in config.json. Also, I doubt whether it's actually needed.

One of the reasons I created this plug-in, next to homekit-ifying (love that word, I'll be stealing it shamelessly) the sensors, was to receive updates in my homekit apps, without having to refresh them. Homebridge-hue retrieves the light states from the Hue bridge every heartbeat seconds, and pushes any changed value to homekit. When a homekit app requests value, homebridge-hue returns the latest value it retrieved from memory, rather than querying the bridge for each request. If you run homebridge -D, you can see debug messages of homebridge-hue's interaction with your bridge.

The experience you're describing seems odd to me. On refresh, your app should not be getting the latest update through homekit, but the latest bridge state, albeit delayed due to the heartrate interval. Could you double-check that? Also, you could try increasing the heartrate to reduce the delay. I use 2 seconds myself, but I've heard others using 1 second successfully.

from homebridge-hue.

I agree polling the lights when values are requested shouldn't be necessary, if light status is polled regularly as part of the heartbeat. I assumed the later wasn't implemented, as it wasn't functional for me.

I have two Osram Lightify bulbs which I can control manually using a Hue Dimmer. Their latest state is never reflected in HomeKit, despite waiting ample time for their state to be synced to the bridge and then polled by homebridge-hue.

I may have some time tomorrow to dig into the code and investigate further... I wonder if this has anything to do with the bulbs in question being Osram white bulbs rather than hue colour ones.

from homebridge-hue.

I don't have any Osram bulbs, only some Osram on/off plugs. I do find the bridge reports them as unreachable more often than the Philips lights, but when they are reachable, their status is updated in homekit. I don't yet expose the reachable attributes of lights to homekit (as I do for sensors), but you can check in the (gen2) native Hue app, under settings/Light Setup. Do you see updates of the Osram lights in the native Hue app when updating them through the dimmer? Do you have any Philips lights as well? If so, do they exhibit the same behaviour as the Osram lights?

If you could post a dump of your bridge config (see Troubleshooting in the README), I could have a look at the Osram lights, but I don't think white vs colour Osram bulbs should make a difference. I have a couple of Philips white lights (dimmable only) in addition to the colour lights and they work equally well.

When you have time, please check the output of homebridge -D to check whether homebridge-hue sees the state change and updates homekit. If it does, the issue might be with homekit or the homekit app.

from homebridge-hue.

Just published v0.0.18 which sets Status Fault when a light of (zigbee) sensor is unreachable. Unfortunately, the iOS 10 Home app doesn't seem to look at this characteristic (at least for lights), but other apps do, like Elgato's Eve.

from homebridge-hue.

Thanks - that's perfect :) Upon further inspection it turned out my bridge had started seeing my Osram bulbs as unreachable, even though it managed to control them fine. A restart of the bulbs seems to have addressed this.

How come the iOS Home app shows bulbs as unreachable just fine if they're on the 2nd gen Hue bridge or using home bridge-philipshue? Do these report unreachable status via a different characteristic?

from homebridge-hue.

You guessed it, @ZoneMR . The Gen2 bridge uses homekit accessory reachability, homebridge-hue uses the Status Fault characteristic. Accessory reachability is available only to homebridge plug-ins using dynamic platform accessories. Homebridge-hue still uses static platform accessories (see issue #4).

Are you sure about the homebridge-philipshue plug-in? Looking at their source code, it would seem that they simply report the light as Off when it's unreachable. They don't seem to report (un)reachability separately, like the Gen2 Hue bridge.

from homebridge-hue.

hi @ebaauw , first of all thanks for homebridge-hue, I love the many options it has.
I was (and am still) using homebridge-philipshue but decided to try out your project as homebridge-philipshue seems to get abandoned, as I want to switch to your project for my Hue (or mainly Lightify) devices.

So far it works very well - the only thing I "dislike" is that I use the Home-App respectively the Homekit-Buttons in the notification center. It is therefore problematic for me that the status of in my case the Lightify Plugs is not stated correctly. (it is however in apps like Eve, but as stated this is impractical for my usecase)

I unplugged on of my Lightify Plugs to see how your project reacts when they are not reachable.
Problem is I can turn it on and off as often as I want, it will always show the latest state I triggered and won't tell me that it couldn't actually reach the Plug.

Would it be possible for you to implement it the way homebridge-philipshue does it?

thanks in advance

from homebridge-hue.

Hi @GatoPharaoh

I suppose technically it would, but I'm not sure that would be a good idea. The problem is that the reachable attribute on the Hue bridge doesn't indicate whether a light is actually reachable by the Hue bridge, only whether the Hue bridge could reach the light the last time it tried to get its state. See my post at the Hue developer's forum.

Too often I find that the bridge reports a light as unreachable, while it can be reached just fine. In that case, I still want to (and can!) control the light. Marking it unreachable in HomeKit (as the gen2 Hue bridge does), would break that. Marking it as off (as homebridge-philipshue does) would not only show an incorrect state when it's actually on, it would prevent you from turning the light off through HomeKit. When the light is actually off, turning it on thought HomeKit would turn the light on, but still report it as off. Also, I don't want homebridge-hue to report a different light state than the Hue app (or any other app using the Hue API).

Actually, homebridge-hue behaves just like the official Hue app: it shows a potential issue (status fault/ unreachable), but still allows you to (try to) control the light, reporting back the (updated) state from Hue bridge. It's a pity that the built-in Home app doesn't support all the HomeKit functionality (i.c. the Status Fault characteristic), but I'm not too keen on working around its limitations. Apple did some improvements in iOS 10.2 and I expect them to continue to do so in future iOS updates.

from homebridge-hue.

that makes sense - I'll open a Radar at Apple to see if they might implement those characteristic in the Home-App - what characteristic would the Home-App need to be fully compatible with your project?
thanks for the heads up and keep up the good work :)

from homebridge-hue.

In this particular case: Status Fault, but there's plenty of other standard HomeKit characteristics and services they don't support, most notable:

• The Stateful Programmable Switch service and Output State characteristic I use for Hue Tap and Hue Dimmer switches;
• The Active characteristic I use to enable/disable sensors;
• The Speaker service and Volume and Mute characteristics, I use for my Sonos plugin.

from homebridge-hue.

does homebridge-hue check has the status of the lights connected to the deCONZ server?
I ask this question because when I have a case that a lightbulb is not responded in the home application, I cannot change the state on or off. Only through the phoscon application when I turn it on or off then the status in the home application instantly changes and works again.
The reason a bulb is not respond is that a member of my family sometimes switches it off through a wall switch.

from homebridge-hue.