Can't pair with Philips Hue
NUPnP gives me three IDs and three internal IP adresses, but I have one bridge and three bulbs. This really confuses me!
Yesterday, I managed to pair Hue with f.lux by chance (I guess?) just pressing the button on the bridge randomly.
Now I tried your suggestion anyway. Yet the problem with the missing beep and the pairing only working randomly persists. Once out of five tries though, a minute after trying to pair again, f.lux started beeping and wouldn't stop, even though I had pressed the button on the bridge already.
I suspect it has something to do with the polling frequency or a delay somewhere, because before I moved, my lamps would update almost perfectly in synch with my screen and now it takes them at least a minute to react to a change from f.lux. I do not have this problem with the Hue app, Google Home or my dimmer, the lights respond instantaneously to them.
Another issue you might want to look into is f.lux freezing upon unchecking the box for Philips Hue under the connected lights tab.
If you only have one bridge, it should only report one bridge. Hmm, I wonder if we're stuck waiting for one of the "missing" bridges to respond.
If you hold down "Ctrl" while launching f.lux it will skip the meethue.com check and use UPnP on the LAN instead. (I should put a pref in for that if it's useful - it was just there for my testing.)
Launching f.lux with Ctrl did the trick, all lag was eliminated. Thank you!
It still doesn't beep when trying to pair, but for me, this is a non-issue, since now, the setup works just as I wanted.
Okay, I've tested this for a week now. Everytime I reboot my computer, f.lux reverts to checking meethue.com instead of using UPnP. Is there a way I can enable the UPnP check on startup so I don't have to delete the process and start f.lux again with Ctrl held down?
Btw in case this issue is new: When I exist f.lux using the exit option in the menu, the visible programm terminates, but the the process stays alive somehow.
herf last edited by herf
I think I put up a test build with a registry key for this:
It adds two new prefs, so to turn off meethue, you would go to regedit and add:
HKCU\Software\Michael Herf\Preferences\meethue = REG_DWORD 0
Sorry for the late answer. Was too busy to care about my lights or my sleep cycle. Works like a charm now, thanks a ton!
Can a bridge be specified manually? I tried opening flux by holding ctrl and specifying the regedit key, no luck.
I can put the manual info in regedit if that's where the info is stored but not sure what the key/values should be.
To be fair I'm using: https://github.com/mariusmotea/diyHue which works with all hue android apps anyway. I do have Yeelights but those aren't pairing directly either.
@herf Yeah nothing on https://www.meethue.com/api/nupnp since I'm not using the official hub, but direct connection works fine via LAN IP & username using other software including the official hue apps. I also have upnp disabled on my router/firewall.
I figured the 1 was meant to be a 0 above and tried that too, no luck. Let me ask this, after Flux establishes a connect to the bridge via LAN, what regedit entries are created for the connection information if any? I can try putting them in manually with the username & ip for the hub, I have both.
@poxin We don't cache IP addresses in the registry - they have to be found with meethue or UPnP. Does UPnP work for your config?
We do store the pairing IDs per bridge in HKCU\software\f.lux Software LLC\hue
I guess if we saved static IP addresses we'd have to know if you're switching networks (like work/home) so we could avoid spamming your work LAN or something like that.
@poxin I guess some clients look if you're on a /24 and just try connecting to all possible hosts, but we don't do that. ;)
@herf Yeah even the official one (android app) will scan your local network to find a hub, at least it did for me. For other apps I just hard-coded a static IP in. Would rather use flux but this has been an alternative to get a similar experience: https://github.com/stefanwichmann/kelvin
Yeah I see what you mean about saving the information if you had it configured on a portable device. My setup is just running it on a desktop that stays in one place but could see why that might be an issue.
In the end they are actually YeeLight bulbs with LAN enabled on them, but those don't work either. Does flux have any debug information I can check? Would rather just get rid of the hue bridge completely, going this route was a work-around.
After looking the official app and other programs use a SSDP service that is UPnP based which works fine. The official Phillips one is closed on a private cloud which requires a unique device authentication hash, so no go with that method on my end. Bummer.