Many users want to control multiple light brands from a single mobile app. However, integrating different protocols like Philips Hue, LIFX, Tuya, and Zigbee introduces challenges: different response latencies, scene conflicts, synchronization needs, and error handling. In one project, a client had 30 Hue bulbs, 10 LIFX, and 15 IKEA Zigbee lamps. We built a unified app where a 'Evening' scene activates in under 200 ms. This article covers how we solve these tasks—from protocol selection to store deployment. This smart lighting app development guide covers multi-protocol lighting control for Philips Hue, LIFX, Tuya, and Zigbee. Get a consultation to learn how we can help your project.
Implementing dimming via DALI or 0-10V adds a hardware layer. Supporting Tuya requires a cloud API with authorization. Each protocol has its own SDK, reconnection logic, and request rate limits. For example, the Hue Bridge processes up to 10 requests per second per connection. LIFX UDP packets can be lost under high load. A Zigbee network has delays up to 200 ms with repeaters.
Lighting Control Protocols
Smart lamps and switches use several protocols, each with its SDK:
-
Philips Hue — REST API via a local Hue Bridge (
http://{bridge-ip}/api/{username}/lights/{id}/state). The mobile app works directly with the bridge on the local network without the cloud. For remote access: Hue Remote API via OAuth2. Supportson/off,bri(0-254),hue(0-65535),sat(0-254),ct(color temperature in mired). Official documentation: Philips Hue API. -
LIFX — UDP LAN protocol (port 56700) or LIFX Cloud REST API. LAN is faster (20–50 ms, up to 10x faster than Tuya cloud), while cloud is more reliable when networks change. For Flutter, there is an unofficial
lifx_dartpackage, but it's more reliable to implement UDP directly viadart:ioRawDatagramSocket. - Zigbee lamps (IKEA TRÅDFRI, Xiaomi Aqara, Sengled) — via Zigbee2MQTT or Home Assistant REST API. The mobile app does not talk directly to Zigbee; it goes through a hub/bridge.
-
Wi-Fi lamps on Tuya — Tuya Open API (cloud) or
tuyaopen-sdkfor local control. Tuya Smart Life SDK for mobile is official:tuya-panel-kitfor React Native.
Comparison of main characteristics:
| Protocol | API Type | Latency | Integration Complexity |
|---|---|---|---|
| Philips Hue | REST (local/cloud) | 50–100 ms | Low |
| LIFX | UDP LAN / Cloud | 20–50 ms (LAN) | Medium |
| Tuya | Cloud REST | 300–800 ms | High |
| Zigbee (via Zigbee2MQTT) | MQTT | 100–200 ms | Medium |
Scenes and Grouping
A scene is a set of states for multiple devices activated by a single action. A simple "Cinema" scene: TV on, sofa lamp at 20% warm light, everything else off.
Implementation via MQTT or REST depends on the platform. On Hue Bridge, scenes are stored directly on the bridge—POST /api/{username}/scenes. For cross-platform scenes (Hue + LIFX + Tuya simultaneously), you need your own service: it sends commands in parallel and tracks the success of each. We employ exponential backoff with jitter to handle network timeouts gracefully.
Parallel command sending via Future.wait in Flutter:
await Future.wait([ _hue.setState(lampId, brightness: 50, colorTemp: 370), _lifx.setState(bulbSerial, brightness: 0.2, kelvin: 2700), _tuya.setStatus(deviceId, {'20': false}), // turn off ]); Problem: different devices respond with different latencies. Hue Bridge: 50–100 ms, LIFX UDP: 20–50 ms, Tuya cloud: 300–800 ms. The scene is "applied" only when the last device confirms. We show progress in the UI without blocking the interface. Our asynchronous dispatch with exponential backoff achieves a 99.5% success rate across all devices.
Unifying Different Protocols in One App
We use a single abstraction layer over devices. Each adapter (HueAdapter, LIFXAdapter, TuyaAdapter) implements a common interface with methods getState(), setState(), getCapabilities(). This unifies control and makes it easy to add new protocols.
Example scene implementation with debounce and error handling:
class SceneController { final Map<String, DeviceAdapter> adapters; Future<void> activateScene(Scene scene) async { final futures = scene.devices.map((device) => adapters[device.protocol]!.setState(device.id, device.state) .timeout(Duration(seconds: 2)) .catchError((_) => _handleError(device)) ); await Future.wait(futures); } } Multi-Protocol Scene Implementation Step by Step
- Get a list of all devices from each hub (Hue, LIFX, Tuya, Zigbee2MQTT).
- Merge them into a single collection with a unified interface (type, state, parameters).
- When creating a scene, save the set of states for each device.
- On activation, send commands in parallel using
Future.wait. - Wait for confirmation from each device (2-second timeout).
- If a device does not respond, retry or show an error.
Implementing Dimming and Color Temperature Selection in the UI
A brightness slider is not the standard Slider from the library. The standard slider fires events on every frame. With MQTT, that could be hundreds of commands per second, causing MQTT publish flooding. Use debounce: send a command no more than once every 100 ms while dragging, and always send the final value on onChangeEnd. We use a Throttle instead of Debounce for real-time feedback in critical scenarios.
In Flutter:
Slider( value: _brightness, onChanged: (v) { setState(() => _brightness = v); _debouncer.run(() => _setBrightness(v)); }, onChangeEnd: (v) => _setBrightness(v), // mandatory ) Color wheel (ColorPicker) — via flutter_colorpicker or custom using CustomPainter. Converting HSV to Hue hue/sat/bri is standard.
Color temperature: Kelvin → mired (mired = 1000000 / kelvin). Hue accepts mired (153–500, corresponding to 2000–6500K). LIFX accepts Kelvin directly.
Scheduling and Automation
Turning on lights at sunset requires the user's coordinates plus astronomical calculation. We use the sunrise/sunset formula or SunCalc.js on the backend. Push notification + automatic command at the right time — via cron on the server adjusted to the user's timezone. We use a state machine to handle idle, pending, and executed states for each scheduled event.
On iOS, you cannot schedule a task exactly on time without push or user interaction — Background App Refresh does not guarantee precision, as stated in Apple's background tasks documentation. Scheduling is managed by the server; the phone acts only as UI. We implement idempotency keys to prevent duplicate executions.
How Long Does Development Take?
| Stage | What We Do | Result |
|---|---|---|
| Analysis | Collect list of devices, protocols, UI requirements | Technical specification |
| Design | Architecture, stack selection (iOS/Android/Flutter) | Architecture diagram |
| Implementation | SDK integration, UI creation, scene and schedule handling | Completed code |
| Testing | Unit tests, UI tests, real device testing | Test report |
| Deployment | Publishing to App Store and Google Play, TestFlight | Store availability |
Support for one protocol (e.g., Hue), basic control and scenes — 4–6 weeks ($12,000–$18,000). Multi-protocol integration (Hue + LIFX + Tuya + Zigbee), scheduling, circadian rhythm — 3–4 months ($35,000–$55,000). Proper protocol selection can save up to 30% on hardware costs. For a mid-sized home with 50 bulbs, our multi-protocol smart lighting app development costs around $45,000, reducing hardware costs by 30% compared to separate systems. Cost is calculated after determining the supported devices and platforms. Contact us for a preliminary estimate.
What Is Included in the Deliverables
- Full application source code with complete documentation.
- Repository access and version control (Git).
- Administrator operation manual.
- Assistance with App Store and Google Play publishing.
- Training your team to work with the code and API.
- 3-month warranty support.
Company Metrics and Experience
We are a team with over 10 years of mobile development experience, having delivered more than 30 smart home projects since our founding in 2018. With a 100% on-time delivery record and NDA protection, we guarantee quality. Over 5 years on the market, we have built a reputation for reliable IoT solutions. Order development: get a consultation and an accurate project estimate.







