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!
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ā.
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.
Thats probably more of an internal thing. Tile 0 is the only one that enables its Wifi and connects to the Wifi network.
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.
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?
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.
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.
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?