Brilliant.tech switch Integration

Feature Requests
21

Good luck selling those now… given the recent announcement of the company’s financial troubles and their cloud dependence.

22

For anyone else who isn’t aware, the company behind Brilliant has laid off all their staff after running out of money. Apparently their assets are for sale.

Maybe someone can pick up the assets and improve the connectivity. The hardware was cool.

23

Step 1: Someone can pick up the assets…

24

After years of trying to integrate Brilliant into HA, I finally succeeded. I added Brilliant to my old smartthings account (which I stopped using when i migrated to HA) and added smartthing to my HA. I don’t think you even need a smartthings hub. I see my Brilliant switches as “Smartthings switches” in HA and can dim and control them. They also now pop up in my Alexa because HA is connected yo Alexa.

Also theres a binary device in Home Assistant I can control from my Brilliant screen. I made a virtual device “proxy” in smartthings that shows up on both Brilliant and HA. In HA i have a simple automation that gangs the virtual proxy smartthings device with the actual device so when either the proxy or real device turns on, the real or proxy turns on (and vice versa turning off). Again don’t think you need a physical smartthings hub to do this.

25

Could you elaborate on how to create this device “proxy” in SmartThings, and how you connected a HA device using an automation?

26

They are now under new ownership and may take a different direction. I have reached out to the new investors to see if they will open up to HA in the future. Will update once I hear back

27

Anyone have any updates on this? I used to use emulated hue successfully with my Brilliant controller, but pairing with the controller now requires a button press on the (virtual) Hue hub, which emulated hue does not support. The diyHue add-on looked promising as it has the ability to emulate the button press, and I was able to get it paired and working with the official Hue app, but the Brilliant controller does not see the emulated button press during pairing (like the Hue app does) for some reason.

My controller is in the guest bedroom, and my primary use case is to use the Brilliant touch screen to control the zigbee window shade in the room, but I’m no longer aware of any solution for that.

28

Not as far as I know. I think if someone were going to build this they'd have done it a long time ago.

I still use use my Brilliant switches, but I use the Homekit emulation. It works great on one switch, and a second one flakes out every few months and it drops the Homekit connection. I can fix it by opening the Brilliant app, which somehow resets the Homekit config.

29

tldr; (aka AI slop below); diyHue works, LLM install or point it to the docs in my repo for now and it can get it working. Also have mqtt working on a rooted panel, solves the homekit flakiness (or you can keep homekit and have it monitor and reboot the panel when it behaves badly)

Credit where credit is due first: I got it working tonight with diyHue!! For what it’s worth, Anthropic’s Fable assistant refused repeatedly — it balked the moment the job needed root SSH to the panel. Codex (GPT-5.6-sol) happily obliged and honestly did a lot of the legwork.

@trnovak — the good news is diyHue can drive a Brilliant panel; the reason your pairing fails isn’t diyHue itself, it’s two things the panel does that a stock diyHue setup doesn’t satisfy:

  1. Discovery is mDNS, not UPnP. The panel looks for a _hue._tcp bridge over mDNS (that’s why emulated_hue, which is UPnP-only, never shows up). diyHue advertises mDNS correctly, so this part is fine.
  2. The panel pins the Philips Hue CA and does real TLS chain validation. Its Hue client trusts a specific bundled CA, not the system trust store — so diyHue’s self-signed cert gets rejected during the TLS handshake, before the link-button step even matters. That’s the wall you’re actually hitting when “it works with the official Hue app but not the panel.”

The fix is two root-SSH steps, and the second one is the part that isn’t obvious — the CA alone is not enough:

  1. Trust: append your own CA to the panel’s pinned Hue bundle and have diyHue serve a leaf signed by it, so the TLS handshake validates.
  2. Register the bridge manually: even with the CA in place, the panel’s normal “press the button” pairing flow still won’t complete against diyHue — it just sits on “searching.” You have to register diyHue by writing the credential (its IP + a diyHue API user) directly into the panel’s Hue config on its internal message bus.

Do both and the panel treats diyHue as a paired Hue bridge; a wall slider then drives any HA-managed bulb — or your Zigbee shades — fully local, no SmartThings, no cloud.

I wrote up the whole thing — the three “walls” (mDNS discovery, link-button pairing, pinned-cert TLS) and how each is handled, plus a runbook:

For your shades specifically: expose them to HA as usual, tag the entity with diyhue: include, and they’ll show up as controllable tiles on the panel.

Full disclosure: today this is genuinely fiddly. Realistically you’re either comfortable on the panel’s root shell hand-writing thrift bus values, or you’re handing a coding LLM your credentials and letting it do the legwork — which is basically how I got here tonight. Neither is a great answer for a normal user, which is exactly why I want it baked in: I’m working on folding the whole CA append + bridge registration into the brilliant-mqtt integration so it’s automatic. That’s the same integration that already replaces the flaky HomeKit Controller path for these panels (no more dropped pairings / setup_retry), so the goal is one setup that gives you reliable panel entities and local Hue-style control of your HA devices from the wall — no shell, no handing your secrets to a bot.