Replies: 6 comments 10 replies
-
|
Well written spec, only one comment (maybe more pops up when I start implementing): the client should be able to request the current local time, providing a timezone name in the request. The server might run in UTC, so servertime alone is not sufficient. Converting to local time is nothing trivial for a memory constrained client, especially with DST on/off rules. |
Beta Was this translation helpful? Give feedback.
-
|
Quick question before I land the shape on this: what would the client actually use local time for? Where I can see it earning its keep is smart-sync scheduling, so you can wake at local-time-aligned moments (top of the hour, 7am local, sunrise-ish) without needing an NTP sync. Anything else you'd lean on it for? Painted frames already have the rendered date baked in by the server, so display doesn't need it. Logging timestamps can be stamped server-side when /log POSTs land. So the real value is probably in client-side scheduling decisions; happy to ship whatever shape genuinely helps once I know how you'd use it. |
Beta Was this translation helpful? Give feedback.
-
|
That looks good, thanks. I must say I cannot keep up with your pace but I really appreciate your work! Another suggestion, this time regarding |
Beta Was this translation helpful? Give feedback.
-
|
Repo created: https://github.com/bablokb/tessarae-device-circuitpython Nothing usable in there yet, but just to sum up: the client will support all boards that are supported by CircuitPython and are powerful enougth to drive a display. A second prerequisite is a suitable hardware abstraction layer file for the hardware. Important to note: one of the supported hardware types is "GENERIC_LINUX_PC". This works with CircuitPython+Blinka+PyGame. This hardware type is ideal for prototyping, since it can emulate any screen-size thus allowing development and testing without the slow deployment steps needed for real hardware. And in the end you could even run a dashboard on your multi-feet large desktop monitor. My implementation plan now is to first create a library for the REST API and then implement a suitable data-provider and ui-provider for the application. |
Beta Was this translation helpful? Give feedback.
-
|
I seem to have problems with the name of this project. I renamed my repo now: https://github.com/bablokb/tesserae-device-circuitpython I also created the repo for the library https://github.com/bablokb/circuitpython-tesserae (no content yet) |
Beta Was this translation helpful? Give feedback.
-
|
@bablokb, quick question: would you be comfortable if I added a I was thinking something neutral like "CircuitPython · client in No urgency. Just want your call before I touch the site. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
TL;DR
@bablokb is scoping a generic CircuitPython client for Tesserae, one codebase covering 400+ boards via CircuitPython's existing display libraries. To support that work (and any future third-party clients), there's now a full client protocol spec covering REST, MQTT, pairing, frame formats, and the steady-state loop:
📖 Client protocol spec (lives in the docs site, version-controlled, tracks
main)Why this thread
The spec is the authoritative reference, but conversations about ambiguities, edge cases, design tradeoffs, and progress updates happen here so others doing related work can follow along.
Status
device-pico-bin(RP2350 C++ firmware, same wake / fetch / paint / sleep shape) is the closest in-tree analog for studying the existing pattern.binformat on CircuitPython. The spec recommends PNG given howadafruit_imageloadand the standard display library palette mapping already handle it;.binis faster + lower memory but means porting the 4-bpp nibble unpacker.How to contribute
Spec source lives at
docs/dev/client-protocol.md; PRs welcome (especially "I tried this and it doesn't quite work" feedback I can encode into the doc).Beta Was this translation helpful? Give feedback.
All reactions