Add openhue extension

[thibauult]

Description

OpenHue brings Philips Hue smart lighting control directly into Raycast. Quickly manage your entire lighting setup without leaving your workflow.

Features:
• Control Lights - Turn individual lights on/off, adjust brightness and colors
• Control Rooms - Manage entire rooms at once
• Activate Scenes - Browse and activate your favorite Hue scenes with a single action
• Easy Setup - Guided setup wizard to connect to your Hue Bridge (auto-discovery supported). The extension also supports the well-known ~/.openhue/config.yaml configuration file

Requirements:
• Philips Hue Bridge connected to your local network
• The extension will guide you through obtaining an API key during setup

Screencast

openhue-raycast-demo.mov

Checklist

• I read the extension guidelines
• I read the documentation about publishing
• I ran npm run build and tested this distribution build in Raycast
• I checked that files in the assets folder are used by the extension itself
• I checked that assets used by the README are placed outside of the metadata folder

[raycastbot]

Congratulations on your new Raycast extension! 🚀

Due to our current reduced availability, the initial review may take up to 10-15 business days.

Once the PR is approved and merged, the extension will be available on our Store.

[greptile-apps]

Greptile Summary

This PR adds a comprehensive OpenHue extension for controlling Philips Hue smart lighting from Raycast. The implementation includes individual light control, room management, and scene activation with a well-designed setup wizard.

Key Changes:

• Control lights with on/off, brightness, color, and temperature adjustments
• Manage entire rooms at once with grouped light controls
• Browse and activate scenes with multiple activation modes
• Auto-discovery setup wizard with manual IP entry fallback
• Proper SSL certificate verification using Hue's root CA
• Rate limiting to prevent HTTP 429 errors from the bridge
• Support for ~/.openhue/config.yaml configuration file

Issues Found:

• Manual Preferences interface definition in src/api/client.ts (lines 10-13) should be removed since it's auto-generated in raycast-env.d.ts

Previous Issues:
All previously reported issues have been addressed - CHANGELOG uses {PR_MERGE_DATE} placeholder, metadata folder with screenshots exists, README and package.json licenses match (MIT), and the manual Preferences in src/api/types.ts was noted in previous reviews.

Confidence Score: 4/5

• This PR is safe to merge with minimal risk after addressing the style suggestion
• Score reflects well-structured code with proper error handling, security practices (SSL verification), and rate limiting. The extension follows Raycast conventions and includes comprehensive features. One minor style issue with manual Preferences definition doesn't affect functionality but should be cleaned up for consistency.
• Pay attention to extensions/openhue/src/api/client.ts for the Preferences interface removal

Important Files Changed

Filename	Overview
extensions/openhue/package.json	Correctly configured extension manifest with proper metadata, dependencies, and screenshots present in metadata folder
extensions/openhue/src/api/client.ts	Manually defines Preferences interface (lines 10-13) despite auto-generation in raycast-env.d.ts; otherwise solid implementation with SSL verification and rate limiting
extensions/openhue/src/lights.tsx	Clean implementation of lights control UI with proper state management and error handling
extensions/openhue/src/rooms.tsx	Well-structured room management with scene activation and archetype-based icons
extensions/openhue/src/scenes.tsx	Proper scene activation with multiple activation modes (active, dynamic_palette, static)
extensions/openhue/src/setup.tsx	Comprehensive setup wizard with auto-discovery, manual entry, and proper state management

[greptile-apps]

_{22 files reviewed, 4 comments}

_{Edit Code Review Agent Settings | Greptile}

[pernielsentikaer]

Thanks for your contribution 🔥

How is this compared with Raycast Store: Hue by @pindab0ter - it feels pretty similar to me

I converted this PR into a draft until it's ready for the review, please press the button Ready for review when it's ready and we'll have a look 😊

[pindab0ter]

It looks nice.

@thibauult could you have a look at the existing Hue extension to see if yours offers anything the existing extension doesn't? Then we could consider adding that.

[thibauult]

Hi @pernielsentikaer and @pindab0ter, thanks for the feedback!

I completely understand the concern regarding similarity. To provide some context, this extension is part of the OpenHue open-source initiative. Our goal is to build a unified ecosystem for Philips Hue, which already includes our CLI and an upcoming MCP Server.

The main differentiators for the OpenHue extension are:

API-First Foundation: We use the OpenHue API to generate our client code. This allows us to implement new Hue features and API changes almost instantly across the entire ecosystem, including this Raycast extension.

Ecosystem Synergy: Users who already use OpenHue for their CLI or automation workflows will find a consistent experience and configuration here.

Future Roadmap: Because of our automated tooling, we plan to quickly expand into advanced features (like detailed sensor management and entertainment area sync) that align with our broader project goals.

I have huge respect for the work @pindab0ter has done with the existing extension. My intent isn't to compete, but to provide an "official" entry point for the OpenHue ecosystem within Raycast. I’m more than happy to collaborate or ensure our feature sets diverge in a way that provides unique value to Raycast users!

I’ll move this back to 'Ready for Review' once I've addressed all the checklist items as expected 👍🏻

[thibauult]

Skipped: This PR changes more files than the configured file change limit: (333 files found, 180 file limit)

Hi @pernielsentikaer! Is there a way to bypass the greptile-apps limit?

[pernielsentikaer]

@greptileai can you do a fresh review of this PR?

[pernielsentikaer]

@thibauult I have now increased the file number, let's see if it works 🙂

[greptile-apps]

_{321 files reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

style: Remove manual Preferences interface - auto-generated in raycast-env.d.ts

Suggested change

	interface Preferences {
	bridgeIP?: string;
	applicationKey?: string;
	}
	// Preferences are auto-generated by Raycast from package.json

Context Used: Rule from dashboard - What: Don't manually define Preferences for getPreferenceValues() or commends Argument interfa... (source)

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

[pernielsentikaer]

Here you go @thibauult

[pindab0ter]

I've tried to see what OpenHue offers that Philips Hue doesn't; what differentiates it. I'm also not sure how the extension would then differ from Hue from the end user's point of view, other than using a different route to achieve the same effect.

It is not my role or place to determine whether this extension should be allowed or not, but I am genuinely curious!

[thibauult]

Thanks for the thoughtful question @pindab0ter, it’s a fair one!

To be fully transparent: yes, at least initially, OpenHue and the existing Hue extension will look quite similar from an end-user perspective. They solve the same core problem and expose comparable actions. I don’t want to pretend otherwise.

Where OpenHue differs is less in immediate features and more in intent and trajectory:

OpenHue is part of a broader initiative (CLI, libraries, future services) with the goal of providing consistent tooling around the Hue ecosystem, not just a standalone Raycast integration.

This includes shared configuration and state (like the well-known ~/.openhue/config.yaml file) and, over time, tighter bridges between tools rather than each one re-implementing setup, discovery, and auth independently.

Future features will follow that same philosophy (deeper API surface, sensors, entertainment, automation-oriented use cases), but I agree those are not all visible yet.

Regarding duplication: I personally don’t see a strong issue with having two similar extensions in Raycast, especially when they are driven by different ecosystems or design goals. From what I’ve seen, Raycast already hosts multiple extensions that overlap functionally but differ in scope, UX, or target audience. Users can then choose what best fits their workflow.

---

That being said, I fully respect your perspective and don’t expect you to arbitrate on whether this extension should exist or not. I mainly wanted to clarify the intent and positioning behind OpenHue. I’m comfortable leaving it at that and letting the maintainers decide how this fits within the Raycast ecosystem. Thanks again for taking the time to review it and for the constructive discussion.

[pindab0ter]

Thank you for your detailed response! I had not heard of this project before. While I don't think I'll be using it myself (as I am perfectly happy with the functionality provided by Philips Hue and their app) I can definitely see why people would use OpenHue.

[pernielsentikaer]

Looks good to me, approved 🔥

[github-actions]

Published to the Raycast Store:
https://raycast.com/thibauult/openhue

[raycastbot]

🎉 🎉 🎉

We've rewarded your Raycast account with some credits. You will soon be able to exchange them for some swag.