16

I have a number of Philips Hue bulbs at home, but they are only used pretty much like classic on/off-no-color light bulbs today, mainly because I do find electric switches more useful than pulling out my iPhone or correct HueTap just to turn the light on/off. - Every time the Hue bulb is switch off, it forgets its state and always comes back on at 100% brightness in white color.

After lots of googling (and not finding any solutions) I wonder whether I am missing the point and why others do not have this problem.

I am certainly not keen on doing software or even hardware work here, but if I had a reasonable idea I'd love to evaluate such path:

  • is there anything planned from Philips to fix this? The last firmware update did not help and Philips product support explained that this is not a bug, it is just the way it is designed.
  • any new "stateful" bulbs?
  • any work-arounds like patched / custom bulb or bridge firmware?
  • any recommendation on how to tackle this problem?
  • Assuming the Hue bulbs themselves do not have any memory installed, I guess they always switch on at 100% brightness and then register with the bridge? And this would be the earliest possible moment to restore the previous state?
  • Can this problem be solved using Hue SDK? (how long does it take for a turned on bulb to be controllable by the Hue Bridge? What is the quickest way for a Java program to get notified of a bulb being electrically turned on?)
  • any chance to get the previous state restored in a quicker way if using some ZigBee protocol/techniques directly?

Any hints are much appreciated.

Best regards, Christian

user5479199
  • 163
  • 1
  • 6
  • I'm voting to close this question as off-topic because "I am certainly not keen on doing software" makes it so for Stack Overflow (and "or even hardware work" for SuperUser as well). – Jongware Oct 24 '15 at 13:57
  • I'm voting to keep the question open: At least the OP mentions, that he would evaluate the path of "doing software". And I was wondering about the same question (see my answer below). However, I'd suggest to remove the first, second and fourth bullet point of the questions. – Stephan Oct 24 '15 at 21:50

1 Answers1

11

I agree that it might be irritating that the last state of a light bulb is not being preserved. There is a thread on the developer site of Hue, which gives some insight:

  • Apparently, there are internal discussions on this topic. The team at Philips hesitates to implement a restore of the previous state due to "security reasons": A user could be left in the dark, if she uses the electrical switch, but the previous state was "off". This opinion has been reiterated in a tweet. There is no definite conclusion in the thread yet.
  • You can do a workaround and continuously record the state of each bulb, and restore, if necessary. There is a Node.JS script on GitHub that seems to be doing exactly this. If you want to run this as a stand-alone solution, buy a Raspberry Pi (or something similar).

One problem with an SDK based solution is the latency: In my setup, it takes between 3-9 seconds to recognize a light bulb as being switched on and about 20-30 seconds to recognize a light bulb being switched off.

Here is my Python code for monitoring the reachability of my light bulbs, using python-hue-client:

from hueclient.api import hue_api
from hueclient.models.light import Light
from datetime import datetime
from subprocess import call


if __name__ == '__main__':
    my_ids = (1, 4, 5) # IDs of my light bulbs

    def handle(resource, field, previous, current):
        print "{} {}: changed reachability from {} to {}".format(datetime.now().isoformat(), resource.name, previous, current)

    hue_api.authenticate_interactive(app_name='test-app')

    # register my light bulbs
    for id in my_ids:
        light = Light.objects.get(id=id)
        print "{}: reachability is {}".format(light.name, light.state.reachable)
        # Monitor only the reachability of the light
        light.monitor(field=lambda l: l.state.reachable, callback=handle, poll_interval=0.1)

    print("Starting monitoring. Control-c to exit.")

    # Start the monitoring loop
    hue_api.start_monitor_loop()
Stephan
  • 372
  • 3
  • 7
  • Stephan, thank you very much for your detailed reply! I have added an entry to the Hue developer thread aswell. The timings (3-9s to restore) you have mentioned are very useful to me. Just one more question: I assume that roughly the same delays would apply in a Rasberry or Arduino based solution? – user5479199 Oct 26 '15 at 06:54
  • @user5479199 Yes, the delay is independent of the capabilities of the client hardware, because the monitoring does not require signicant CPU power. The Python code running on Raspberry will have the same delay. – Stephan Oct 26 '15 at 09:30
  • Thank you, Stephan.
    I was naively thinking that the process of turning on a bulb is something like this:

    #. Light bulb is turned on
    #. Light bulb registers/announces to Bridge via some ZigBee packets
    #. Bridge actively informs listeners or listener does next polling.

    I have no idea how much time which of these tasks take.
     – user5479199 Oct 27 '15 at 11:33
  • If it is task 2, which takes most of the time, then there is no way to improve.

    If it was task 3 causing most of the delay, then I was wondering whether a ZigBee USB sniffer could detect the bulb registration earlier and then consequently send out the command to restore the previous state earlier.

     – user5479199 Oct 27 '15 at 11:34
  • Only in case you have tried already: if a script constantly sends out commands to the bridge to restore the previous state (no matter whether the bulb is on or off), how long does it take to restore the previous state when the bulb comes back on? - From what I have read so far it takes about 0.1s to send a command. So the observed delay should be roughly the time for task 3.
     – user5479199 Oct 27 '15 at 11:34
  • I'd advise you to test your specific setup and expectations on your own, the Hue dev website has pointers on how to start. Even if it works for me, it doesn't mean that it works for your installation. All I can say is that the hub does not register light bulb immediately if it is physically switched on. – Stephan Oct 30 '15 at 12:09
  • This is one of my biggest bug bears with most home automation solutions. They neglect the physical wall switches in most use cases. I am aware of the reasons the devs took this approach but believe it to be very short sighted and could have been fixed in other ways (one example: when a light is physically turned on, it asks the bridge what state it should be in. If the bridge detected a power outage, then report back "GO FULL BRIGHT" otherwise, return the previous level). I personally LOVE the lights, I just wish the bridge was open source and/or that we have more control (of our own lights!) – Madivad Apr 28 '16 at 11:59