Allow multiple (batch) levers trigger and colors setting on HTTP API

Comments: 6

Oldest • Newest • Most likes • Fewest likes

• Add a comment
• 12 Mar
  Gin Fuyou System

  Highlighted comment
  
  "HTTP Batch requests" (suggested by <Hidden> on 2026-03-11), including upvotes (1) and comments (1), was merged into this suggestion.

  timberborn_webcam_sw4mqt.png

  Copy link to this comment
• 11 Mar
  Grant Merged

  Batch your lever update calls. If there is more than one request trying to be sent during a single tick, combine those requests into a single request. Something like:
  
  URL: /batch
  
  PAYLOAD:
  [
  "http://localhost:8080/api/color/HTTP%20Lever%201/ff0000",
  "http://localhost:8080/api/color/HTTP%20Lever%202/ff0000",
  "http://localhost:8080/api/color/HTTP%20Lever%203/ff0000",
  "http://localhost:8080/api/color/HTTP%20Lever%204/ff0000",
  "http://localhost:8080/api/color/HTTP%20Lever%205/ff0000",
  "http://localhost:8080/api/color/HTTP%20Lever%206/ff0000",
  ]
  
  Then in the Timberborn server, just load them into whatever system processes the URLs and voila! you'll be able to make LED screens using indicator grids without frame lag from the HTTP bottleneck!
  
  I've attached an image of my first attempt at making an LED screen. It works, it's just very slow, and that's only 144 pixels TOTAL.

  Copy link to this comment
• 12 Mar
  Gin Fuyou Admin Merged

  @Grant that not how networking operates.

  Copy link to this comment
• 13 Mar
  Grant

  @Gin Fuyou
  
  Each HTTP request has overhead, like parsing, serialization, and round-trip latency. If I'm only making a few requests at a time, I can get a great refresh rate. I tested with 144 levers at 24fps using a delta threshold so updates only fire when a pixel changes significantly. I had a great refresh rate when not making big movements where all 144 pixels update at once. When I did, the grid froze for multiple frames. The only variable was how many HTTP requests I was making every second.
  
  A batch endpoint is a standard pattern (GraphQL, bulk APIs) for exactly this. One round-trip instead of 144, server processes them the same way internally. It would take one new endpoint called /batch, and that endpoint would accept an array of URLs and just route each one internally.
  
  I've been a full stack dev for almost 6 years and still have a lot to learn, so I'd love to know what I'm missing about how networking operates if you'd care to explain what you meant!

  Copy link to this comment
• 13 Mar
  Gin Fuyou Admin

  Your payload structure doesn't make sense, that's what I mean.

  Copy link to this comment
• 13 Mar
  Grant

  Oh I thought you said it was the networking, but it's the payload structure? Did I get the JSON array syntax wrong? Is there some constraint that I didn't know about that wouldn't allow a POST with a body containing a stringified JSON payload? Would love specifics, I'm here to learn!

  Copy link to this comment