Skip to content

Fleet & iOS·

The board joins the owner's tiny.technology fleet twice: as a daemon that runs prompts locally, and as an endpoint that tiny dials out to.

Daemon·

tiny-tech runs on the board as q-tiny.service, enrolled under the name uno-q. From any other device in the fleet the owner can send it a prompt and the board's local agent executes it with its own tools.

Verified 2026-09-09: the unit is active on the board, use_device list on the Mac shows uno-q as cli/linux-arm64 with capabilities mcp and files, and a use_device invoke round-trip from the Mac came back. Node is the distro's 20.19.2. Because tiny-tech's zenoh transport has no linux-arm64 build, a small JS stub replaces the native binding: the board is a fleet device (presence, tasks) but not a LAN mesh peer. See Setup.

The unit runs as user arduino, after network-online.target and arduino-router.service, with a pinned tiny-tech under ~/.tiny/daemon, identity in ~/.tiny/device.json, and model credentials from /etc/q/env. It is bounded for a shared 3.6 GB board: MemoryMax=900M, NODE_OPTIONS=--max-old-space-size=512, Nice=5, NoNewPrivileges=true, Restart=always.

Endpoint·

tinyai-id registers the board as an endpoint device, the same mechanism as fomo [endpoint/fomo-the-arm] and 3D printer [endpoint/bambu-x2d]. Tiny dials out to the dashboard with the owner token stored at enrolment.

field value
name q-the-brain
kind endpoint
platform q-the-brain
url https://q.cagatay.my
capabilities telemetry, chat, led, mcu, shell

What the worker calls on the board:

  • telemetryGET /api/telemetry, flat JSON.
  • chatPOST /api/chat with {"prompt": "..."}, expects {"result": "..."}.

The URL is stored as its origin, unchanged. Only a public https origin passes the app-side guard; the board's LAN address (http://192.168.1.210:8095) is for ssh, never for tiny. The device declares no camera or arm capability because none is attached.

This contract is pinned by tests/q-the-brain-endpoint.test.ts in tinyai-id. If the board's API drifts, the dashboard moves, not tinyai-id.

iOS·

A QBrain device panel in the Tiny iOS app, modelled on the Fomo arm panel. led is what the LED-matrix composer keys on, telemetry is what draws the vitals, chat is what use_device invokes. Build numbers continue from 74.

Status·

step state
endpoint contract test in tinyai-id verified green, IOS i1
owner token created on the board (~/.q/token, 0600) verified SUPERVISOR 19:32Z; it never leaves the board except over ssh
endpoint row registered in the fleet verified use_device list on 2026-09-09 shows q-the-brain [endpoint/q-the-brain], url https://q.cagatay.my, capabilities telemetry chat led mcu shell, online: null until invoked
q-tiny.service active, uno-q in use_device list, invoke round-trip verified BOARD b09e456, SUPERVISOR 19:32Z; again NIGHT 21:06Z: uno-q online, a shell prompt through the fleet returned uno-q, uptime 3491 s, three units active
endpoint invoke through the fleet (use_device invoke q-the-brain/api/chat on the board) verified NIGHT 21:06Z: "Host: uno-q, IP: 192.168.1.210, CPU: 47.6 C, Doctor: 17/18 ok." answered from the grounded prompt without tools
LAN zenoh mesh from the board not possible today no linux-arm64 prebuilt, stubbed
owner session on the board renewed before ~2026-10-31 needs owner expires in about 52 days
iOS panel built and deployed to the phone in progress IOS lane