Announcing the Tile Protocol

[daniel_hall]

Hi everybody,

LIFX is pleased to announce the release of tile messages in our public LAN API. There are two new pages, one provides an overview of using the Tile, and the other documents the actual messages involved. Devices supporting the Tile messages will be marked with chain in our product information file.

The Tile messages are designed to enable control of the LIFX Tile. This API is just the beginning, we plan to implement and support more messages in future firmware versions. Stay tuned!

We would love to hear your feedback.

Daniel.

[superg]

Based on the documentation looks like more Tile-like multizone products are coming soon as some parameters should be hard-coded for Tile.

I don’t know why first tile with index 0 is called master. According to documentation it is no different to zone 0 in LIFX Z. Probably related to unannounced products or upcoming functionality as well.

StateDeviceChain message last field is of type ‘16 Tile’ but this type is not explained anywhere.

In general documentation uses very few words. If I was developing for Tile I would need to test many messages myself how they work with Tile.

Documentation refers to ‘user_x’ and ‘user_y’, message StateTileState64 refers to ‘x’ and ‘y’. If they are referring to same coordinates please explain this further.

So user can set coordinates to Tiles but it is not supported to set colors on multiple Tiles with SetTileState64 -message even if you set coordinates so that they cover multiple Tiles? Documentation says for Tile x and y should be set to 0 and width to 8.

Tile control page has typo, it reads ‘Tile Mesages’.

[daniel_hall]

Based on the documentation looks like more Tile-like multizone products are coming soon as some parameters should be hard-coded for Tile.

Haha, protocol design, especially in embedded contexts is about building for what you have now, but also trying to predict the future. There are no immediate plans for another tile like device.

I don’t know why first tile with index 0 is called master.

Thats probably more of an internal thing. Tile 0 is the only one that enables its Wifi and connects to the Wifi network.

StateDeviceChain message last field is of type ‘16 Tile’ but this type is not explained anywhere.

The tile type is explained at the top of the tile messages page in the “Message Field Data Types” section.

Documentation refers to ‘user_x’ and ‘user_y’, message StateTileState64 refers to ‘x’ and ‘y’. If they are referring to same coordinates please explain this further.

user_x and user_y are the tiles positions in a 2D space relative to the other tiles. This is explained under the Tile Positioning section.

x and y in the TileState64 message refer to the top left of the rectangle where you place the pixels. On the tile it only makes sense to send 0 and 0, but these fields are included for consistency with some other messages to be implemented soon. This definitely needs a diagram though. I’ll get one drawn and added to the documentation. For now though, assume the TileState64 message is for replacing all of the pixels on a tile at once.

So user can set coordinates to Tiles but it is not supported to set colors on multiple Tiles with SetTileState64 -message even if you set coordinates so that they cover multiple Tiles? Documentation says for Tile x and y should be set to 0 and width to 8.

The controlling application is responsible for deciding which pixels end up on which tiles based on the user_x and user_y values. So the application will prepare messages for each tile. Does that make sense?

Tile control page has typo, it reads ‘Tile Mesages’.

Fixed.

Thanks for the detailed feedback, I feel like we have a lot of improvements to make to the documentation over the next few days. Hopefully this will make things clearer, but feel free to keep asking us questions.

[superg]

Is it possible to control Tile (and Beam) with previously introduced multizone messages as well? Does it accept SetColorZones-message for example?

[mclark]

Thanks for the new release! I’m currently incorporating the new Tile messages into the Python library lifxlan. It has been fun making cool programs like this rainbow animation!

However, I’m experiencing something strange with the StateDeviceChain message. According to the protocol docs, the first byte should be the start_index, the second byte should be the total_count, and the third byte and beyond should be the tile_devices.

Problem: If I read the StateDeviceChain payload that way, the start_index is the correct value (0), but the total_count is wrong (213 or 255 depending on the light), and all the Tiles have gibberish values.

Solution: Read the Tiles starting at the second byte. If I do that, the start_index and the tile_devices are correct…but I’m not really sure what has happened to the total_count value. Looking at the raw bytes from the packet, I don’t see a byte with the correct count (5) anywhere in the payload.

Maybe there’s a problem on my end, but I thought I would throw it out there for now.

Thanks for all the work on this!

[mclark]

If you look at their respective features on products.json, Beam supports multizone messages, but Tile does not.

[delfick]

oops, I made a mistake when I wrote the documentation.

It would appear that total_count is actually last, not second.

I’ve updated the documentation to reflect this.

Stephen.

[mclark]

Awesome, thanks!!

[delfick]

No probs!

Sorry for the confusion!

[kurin]

Are there any plans to modify the tile protocol to take orientation into account (e.g. like a user_theta)? My tiles aren’t all mounted vertically and there are some neat effects that I can’t take advantage of because the edges don’t line up.

Also, will this ever be available over the RESTful API as well?

Thanks!

[daniel_hall]

We released the details for fetching the accelerometer data from the Tile here:

Announcing Tile accelerometer data

It is my pleasure to announce we have released documentation for the accelerometer data on the LIFX Tile. Using this data you can determine which way the tile is rotated and modify SetState64 messages to take this into account. Essentially each Tile item in a StateDeviceChain message has accel_meas_x, accel_meas_y and accel_meas_z as the first three fields (each is a signed 16-bit integer). These fields represent acceleration in the X, Y and Z axis respectively (the Z axis protrudes from the f…