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.
The tile type is explained at the top of the tile messages page in the “Message Field Data Types” section.
user_y are the tiles positions in a 2D space relative to the other tiles. This is explained under the Tile Positioning section.
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, 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_y values. So the application will prepare messages for each tile. Does that make sense?
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.