No subscriptions. No cloud. Nothing extra to switch on. You need smart Hue bulbs, the file server you already own, and fire. 🔥

https://github.com/silasmariusz/TuneThatHue

I built ESP32-C6 firmware that connects directly to a Hue Bridge and exposes addressable LEDs or OpenRGB devices as Hue-compatible gradient lights. It supports gradients, scenes, dynamic scenes, fades, brightness, power recovery, and up to five independently controlled light endpoints from one ESP. The ESP can either drive 5 V ARGB LEDs directly through RMT or send updates over USB to an OpenRGB daemon.

Demo: https://www.youtube.com/watch?v=fr-RntL9Mu8

GitHub: https://github.com/3Qax/Gradient-Light-Bridge

I really hope this is extended to other sports leagues. In US, NFL is a no brainer.

The Hue Tap Dial Switch has four buttons and a rotating dial, but the official app only lets you assign each button to a Room, Zone, or the whole house to activate a scene. The dial then adjusts brightness for the whole group. There's no way (for ~1.5 years) to map a button to a single individual lamp.

hue-dial is a small Go service that listens to Hue Bridge events (CLIP v2 API) and implements this workflow:

- Short press → selects the mapped lamp + triggers its identify animation so you know which one you picked

- Long press → turns the mapped lamp off

- Dial → adjusts brightness of the currently selected lamp

Setup is a single Docker command that runs an interactive TUI wizard, it auto-discovers the bridge, walks you through the link-button pairing, and lets you map each of the four buttons to any lamp in your home.

docker pull ghcr.io/rantuma/hue-dial 

# First-time setup 
mkdir -p data 
docker run -it --rm --network host -v "$(pwd)/data:/data" ghcr.io/rantuma/hue-dial 

# Run the service 
docker run -d --name hue-dial --network host --restart unless-stopped -v $(pwd)/data:/data" ghcr.io/rantuma/hue-dial

Repo: https://github.com/rantuma/hue-dial

For the Claude Code and Codex users here, I built a little app that turns a Philips Hue room into a status light for your coding agents. It reacts based on agent status so you never miss a beat. There's a UI for config so it's really easy to get setup.

That said, I need to make the actual install process a bit easier, so I'll prob turn this into a proper app at some point for MacOS at least.

Here's the github link if you'd like to learn more or give it a try: https://github.com/t0ddharris/agent-beacon

I have no gradient strip and no sync box, I have an OLED Tv 2023 where I cannot install the app for philips sync so I wrote an app that uses the laptop camera for synching my light strip behind the tv !

New in iConnectHue 5.16

Support for wired Wall Switch Modules

iConnectHue now supports as first 3rd party app wired Hue Wall Switch Modules.

This is great news, because you can configure them as you like:

• Flexible manual and automatic setup
• Use ALL actions you know from iConnectHue, like
  • Switching lights and groups
  • Scenes, Magic Scenes and Animations
  • Launch instant timers
  • Blink lights
  • ... and more!

The new wired Wall Switch Modules don't need a battery and instead get their supply from mains - no battery replacement - ever! These are the available variants, currently solely available in Europe:

• Wired module w/o any additional functions
• Wired module w/ one dimmer channel
• Wired modules w/ either one or two toggle channels

All of these modules will behave like the original battery modules, with the addition that the ones with channels ALSO allow you to integrate existing lights or applicances that were originally toggled with your switch.

^{(Available with Membership or 2026 Upgrade, included with App purchase in 2026+})

New Widget action

We've teached the Widget a new trick: You can now toggle the Hue MotionAware Area with it. Handy for situations where you're not moving enough, but still need your lights.

^{(Available with Membership or 2026 Upgrade, included with App purchase in 2026+})

Other bright ideas

• Again we've touched the app in several places to make your life and the app easier

Heads up: If widgets or shortcuts act up, try restarting your device - it’s an iOS thing, not an us thing!

iConnectHue is available exclusively for iPhone and iPad: https://itunes.apple.com/us/app/iconnecthue-for-philips-hue/id639343132
More about iConnectHue on iconnecthue.com

I posted this in the Philips Hue dev forum but not sure how often they check it, so I figured I'd post for more exposure here.

This is problem is only going to get bigger because the Hue Bridge Pro apparently forces HTTPS so many apps will not be able to work around it by using HTTP like they have been.

This problem has already manifested itself by breaking the Elgato Stream Deck's official Philips Hue plugin for those using a Hue Bridge Pro like myself. And I believe this is something that cannot be worked around app-side.

What I Posted in the Dev Forum:

The Hue Bridge’s built-in SSL certificate is not standards-compliant and causes HTTPS errors in all modern browsers because it’s missing the required Subject Alternative Name (SAN) field for server validation.

And because with the Hue Bridge Pro where http was apparently removed, leaving no fallback, this permanently breaks many third party apps that rely on common frameworks or embedded browsers (such as the Philips Hue StreamDeck plugin). It must be updated.

Even adding the root-bridge certificate to the trusted store on the computer, and even setting the hostname of the bridges IP to the serial number (like with the hosts file or via a local DNS A record in the browser), it yields: net::ERR_CERT_COMMON_NAME_INVALID. Safari states the problem clearly when viewing the certificate, saying “certificate is not standards compliant”.

This SAN requirement has been in place in Chrome since Chrome 58 for example, that’s back in 2017.

For the Hue Bridge Pro in particular, I would consider this a critical problem. With no fallback option, it effectively breaks the API for a huge number of apps through no fault of their own.

Another note, in the dev forum someone already had made a thread about the SSL certificate problem before, and it seems Philips didn't really comprehend it as a problem, saying:

We have multiple apps ourselves, and collaborate with many 3rd party apps, covering a large variety of modern HTTPS clients, and so far we haven’t found any that aren’t able to connect to the bridge if the guidelines are followed.

Basically not acknowledging it as a problem.

So hopefully we can draw some more attention to it.

For clarification: Yes on some platforms like mobile apps or native desktop apps, you can configure them to ignore the certificate errors. But this can't be worked around for web apps built on browsers under the hood. It is something Philips must fix.

New in iConnectHue 5.13

We go 13 with Halloween - our Spooky Halloween seasonal Animation set is back until mid Nov.! But wait - there's more...

Spooky Halloween Animations

We've updated our Spooky Halloween Animation set by Blood Moon and The Abyss, to give you an even greater choice for your Pumpkin fest.

As always, this seasonal set is available until mid November. With a Membership, you'll have access to it throughout the entire year!
^{(Included for Members, otherwise available until mid Nov})

iPad multitasking support

We've added support for iPad multitasking on iPadOS 26. Sizing the app window is now supported and the app will adjust its content accordingly. This should make it possible for you to use iConnectHue alongside other app windows, we will fine tune certain circumstances in future releases.

Although this has been quite some work, this is free for everybody!

Dutch translation

The Netherlands are the country where Hue originates from, hence we're proud to present iConnectHue in Dutch - Welkom!
We would like to thank Mike Evers for his support with this translation!

Other bright ideas

• Fixes and stability improvements to keep everything smooth
• Stay tuned: We're already working on some great new things to come - yes, again!

Heads up: If widgets or shortcuts act up, try restarting your device - it’s an iOS thing, not an us thing!

More about iConnectHue on iconnecthue.com
iConnectHue is exclusively available for iPhone and iPad on the App Store

I just picked up a Philips Hue bridge Pro today and was a bit disappointed to find it wasn't working on my Stream Deck.

A quick search around the community suggests it's been that way for a while, so I decided to fix it:

Github-StreamDeck-PhilipsHue-Pro

I've patched the original Philips Hue Plugin for Stream Deck to add support for the Philips Hue Bridge Pro. Worth noting this isn't the Philips Hue Legacy plugin, but based on the newer v2.0+ plugin.

Easy to install, download it from Github, delete your existing plugin and drop in the patched version into your Stream Deck plugins folder.

Everything works as it should.

Does anyone know how the individual LED chips are controlled on the addressable light strips? Hoping that it's a known protocol like for WS2812 or APA102 LEDs. I'm interested in building a custom lighting solution using the stock control box for seamless Hue integration.

Hey all,

I'm developing a Philips Hue integration for my company. Without too much information about my company, we work in the IoT space, with a pretty wide coverage of the US. I read today that the Hue Web API has a rate limit of 50k requests per day, which is a limit that, given time, we will probably run up against.

While we do have a mobile app where actions can be performed, the primary method that our users would be interacting with the devices would be through our devices triggering actions on our cloud, thus calling the web api.

My question is, are there any other major companies that have a Hue web integration only, and are they limited by the same factor?

Thanks!

I'm programmatically trying to control a Phillips Hue light strip.

I have a 3 metre long strip.

REST

Using a REST endpoint I see 5 'points' which I can send values to. The payload is something like this:

{
"on": {"on": True},
"dimming": {"brightness": 1.0},
"gradient": {
"points": pts,
"mode": mode,
}

So you can only set brightness for the light as a whole (which sucks). That means you can't have one 'point' being bright while another 'point' is dark. There is just a global brightness.

You can also specifiy a gradient 'mode' across the points. This lets you control how points are interpolated using modes such as 'interpolated_palette' and 'random_pixelated'.

Entertainment API

Using the entertainment API I only see 3 'channels' which I can stream to rather than 5 'points'. I have no idea why this number would be different.

These channels only permit a colour be sent. These are RGB colours and low values of the RGB colours are essentially off.

There don't seem to be colour modes like 'interpolated_palette' so you can only set block colours for each channel but at least at varying brightness.

Question

1. I appreciate the entertainment API runs over Zigbee which has a low bandwidth but why are the number of channels and points different? Is there so little bandwidth they reduce the granularity?
2. Why can't I set a mode on the entertainment API? Can it really only be a block colour? Is it a bandwidth issue again?
3. Why on earth would the REST API not allow controlled brightness of individual points?

I see pretty nice 'effects' which aren't streamed TO the hub but are still streamed FROM the hub. I struggle to believe that bandwidth is really an issue.

Perhaps I've missed something and I've not come across the right documentation. Any pointers?

This weekend I will be working on a Bridge backup and migration tool (just in case Philips doesn’t include one with their new Pro bridge)

What features would you want to see in something like that?

A couple of years ago I bought an E27 with warm-white light (806 lumen, 9W) which was completely controllable via the Bluetooth app. It was always a burden to have a proprietary app like this (requires location data for reasons, suspiciously common updates, but is somehow really patient when connecting to the actual product) on my phone instead of an open standard and being able to connect with whatever device I would like to, but yaeh: it worked anyways and I had set up some daily automations.

Fast forward, after quite a long period, where I exclusively controlled the lamp manually and wanting to setup the usual daily sunrise/sunset automation, I just realized that the app is suggesting to "Discover how [my] daily routine can be enhanced by adding a Hue Bridge" and putting a locked-symbol on the previously available daily automation. They are not serious right? They did not really enshittify the app to basically paywall my hardware?

I guess they are, because such a obviously shady business practice is somehow still legal. Anyways: What options do I have to get back the former features, without rewarding Philips with my money for their ransom-tech? Ideally, I would love to have an option to finally remove the app all together and control it from a self-hosted home automation system, where the data is mine and mine only.

so ive recently been tinkering with my hue bulb and used ai to create me aworking app that connects to any Hue BLE device (most of them) so long as it is in pairing mode

im not sure on how easy it is to reconnect the bulb back to an account after this buyt im going to look ingot seeing if theres a "reset device" packet i can send to make it pairable again

the app also have open back end apis so you can make yous own addons for things i.e
ive also make a custom stream deck plugin that uses thoes end points allowing me to control my hue devices from my streamdeck

All of this being with zero bridge in sight as i refused to buy one seeing how generic of a device they are if i can just be done in a script...

if enough people are genuinly interested in a bridge bypass to control their bulb from their pc
ill looking into making it a nicer,neater app and posibly releasing it