LIFX LAN protocol V2 documentation
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
header
messages
workflows
README.md Correct links to DeviceGetService message. Jun 25, 2015
header.md Add the `tagged` field to the C struct Aug 3, 2015
tools.md
workflows.md

README.md

LIFX Developer Home | LAN Protocol. LiFi Labs, Inc. © 2015. All rights reserved. Usage of this documentation is bound by the [LIFX Developer Terms] (http://developer.lifx.com/terms.html).

LIFX LAN Protocol V2

Table of contents

Overview

This documentation is intended for third-party developers creating client applications, which interact with LIFX lightbulbs over the LAN by sending and receiving, then parsing LIFX Protocol messages.

The LIFX Protocol consists of messages that are used to control and obtain the state of devices (specifically lightbulbs).

Each message is composed of a header and a payload.

Headers contain the message size, type, routing, response flags and more. Payloads contain information germane to a specific message type.

To interact with LIFX lightbulbs over the Internet (Cloud or WAN), see the LIFX HTTP API documention.

Transport layer

The LIFX Protocol utilizes UDP/IP for all messages covered by this documentation.

Numeric data-type byte-order is little-endian

Message description

All LIFX Protocol messages start with the header, which is covered in the Header description.

The header contains the message type field. There are two categories of messages detailed in this documentation, (1) messages understood by all devices* and (2) those messages specific to lightbulbs.

The message type determines the format of payload. The various message payloads are covered in the Device and Light messages documentation.

Most interactions consist of a number of messages transmitted between the client and the device. Some common message exchanges are shown in the Workflow diagrams.

Often, device discovery is a good place to start. In which case, the discovery workflow, along with the Device::GetService and the Device::StateService messages are relevant.

* Protocol designers like to think ahead. Don't get too excited ... LIFX only manufactures and sells network connected lightbulbs !

Limits

  • Maximum recommended message transmit rate to a device: 20 per second

Disclaimer

Using undocumented message types or field values, sending poorly formed messages or excessive message rates to LIFX devices and/or LIFX services may result in unexpected device or protocol message behavior.