wignet.app

# Wignet: agent guide You drive one Wignet: a remote screen. You publish to it; it shows the content when it next syncs. Everything below is English and stable. - REST base: https://app.wignet.app/api/owner/<device-link> - MCP server: https://mcp.wignet.app/<device-link> - OpenAPI: https://app.wignet.app/api/owner/<device-link>/openapi.json - Owner's page: https://app.wignet.app/w/<device-link> Read get_orientation first: it gives the size to draw at, the orientation and the inks. ## Show something: pick the simplest that fits 1. **Text**: `push_event {"text": "..."}`, in Markdown or plain. It shows for 3 hours (`duration_seconds`, 60 to 86400) from when the screen downloads it, then the screen returns to its slides; `"standing": true` replaces the slides instead. On a screen with nothing of its own yet (no slides, or only the Welcome page), it stays. The server lays it out in black on yellow (white on a black-and-white screen), as large as it fits: `# ` a title, `## ` a subtitle, `**bold**`, `- ` or `1. ` lists, `> ` a quote, `---` a rule, and a table whose last column is right-aligned, the way to show a schedule or a scoreboard: `{"text": "# Today\n| Gym | 18:00 |\n| Shopping | 19:30 |"}`. At most 1000 characters and 12 list items and table rows; a text that does not fit the screen at 16 px is refused, saying how much does. Emoji are left out (the font has none). `"format": "plain"` shows the characters as typed. 2. **Your own image**: `push_image`. Draw it at the size above. Send it, best first: - as a file, if you have a shell: `curl -F image=@card.png https://app.wignet.app/api/owner/<device-link>/push_image` (or raw bytes: `curl --data-binary @card.png -H 'Content-Type: image/png' https://app.wignet.app/api/owner/<device-link>/push_image`); - as a public URL: `{"image_url": "https://..."}`; - as base64, as a last resort: `{"image_base64": "...", "image_sha256": "<hex>"}`. Every character goes through the conversation and one wrong character ruins the image, so always send the sha256: a damaged copy is then refused instead of shown. A photo the owner has at hand can be dropped at https://app.wignet.app/w/<device-link>#photo instead: there they add it as a slide, show it for 10 min to 24 h, or replace the slides with it. `mode` defaults to `auto`: a flat graphic (64 colours or fewer) is printed in the nearest inks, a photo is dithered. Force `threshold` or `dither` only if auto is wrong. `fit` is `contain` (default, letterbox) or `cover` (crop). Leave `orientation` out: the publication follows the screen. Give `landscape` or `portrait` only to draw one on the other axis; which edge is up always comes from the screen. Add `"dry_run": true` (or `-F dry_run=true`) to either (a text or an image on `push_event`, not with a sound) to render without publishing: you get a `preview_url` to check, and the screen is untouched. ## Example, end to end (shell) ```sh curl -s https://app.wignet.app/api/owner/<device-link>/get_orientation # size, orientation, inks python3 draw.py # writes card.png at that size curl -s -F image=@card.png -F dry_run=true https://app.wignet.app/api/owner/<device-link>/push_image # check preview_url curl -s -F image=@card.png https://app.wignet.app/api/owner/<device-link>/push_image # publish curl -s https://app.wignet.app/api/owner/<device-link>/state # content.delivery: waiting, then fetched ``` ## What the answers mean - Every publication answers with `preview_url` (exactly what the panel will show) and `rendering` (page size, rotation, mode used, and a note when your image had to be scaled). - Published means stored on the server. The screen downloads it at its next contact: `next_contact_expected_at` says when, and `get_state` then reports `content.delivery.state` = `fetched`, with `fetched_at`. The server cannot wake a sleeping screen. - The screen's standing content is a list of slides. `push_image`, `set_custom_image`, `push_event` with `standing: true` and `set_slides` replace it (the answer gives `replaced_slides`); a `push_event` text or image without `standing` shows above it for `duration_seconds`, counted from when the screen downloads it, and the slides pause meanwhile, then resume on the same slide. A push the screen has not downloaded within 24 hours is dropped. `get_state` → `pushed` gives its status. ## Slides `set_slides {"slides": [{"text": "..."}, {"image_url": "..."}, {"publication_id": "..."}], "seconds": 600}` sets the list, in order; a `publication_id` (from `get_state` → `slides.items`) keeps a slide without sending it again. `add_slide` adds one (at the end, or at `position`), `remove_slide {"publication_id": ...}` drops one, `set_slide_interval {"seconds": ...}` sets how long each shows (`get_capabilities` → `slides`: 60 to 86400 s, 600 by default, 50 slides at most). The server's clock decides which slide shows; a new list starts again at slide 1, while adding, removing or a new interval keeps the slide showing. On battery, every change wakes the screen: the answer says so. ## Planning and refreshing Use get_events/set_events for planned text, images and sounds, update_event to change one event (alarms are events with a sound) and delete_event to remove one. A sound can be a tune or a chime picked by name: get_tunes lists them (built-in and saved on this Wignet, each with a preview_url), and sound {"tune_name": "..."} sets one. Leave a sound's volume out: it follows the Wignet's, which set_sound_volume changes for every sound at once. set_events replaces the whole list: read get_events first and send everything back. Per Wignet: 32 planned events, 16 with an image. An immediate publication supersedes event windows already open; later occurrences and sounds stay scheduled. The server never fetches or redraws anything on its own: images are copied once, when you publish or save the event. A recurring event with an image shows the same image every time. For fresh data, compose a new image and call set_events again before the window opens (planned time minus lead_seconds). If you cannot run at a set time, tell the owner the image will not update. ## When something goes wrong `get_device_log` lists the calls made to this Wignet over MCP or REST in the last 30 days, newest first: the action, when, the argument names, how it ended and, for a refusal, the error (`{"errors_only": true}` keeps only those; `since` narrows it). Read it before asking the owner what happened: an earlier refusal, a call that never arrived, another agent or the owner's page changing a setting. Combine it with `get_state` (last contact, delivery) and `get_power_history`. The text or image sent is never kept. If you still cannot explain it, offer the owner to write to contact@wignet.app with what you found: the Wignet's name, its link, the times and the errors. ## Conventions - Reads are GET, writes are POST with a JSON body: `https://app.wignet.app/api/owner/<device-link>/<action>`. Short read names work too (`/state`, `/capabilities`, `/screen`, `/events`, `/log`). An unknown action answers 404 with the list of valid ones. - Errors are JSON: `{"error": "...", "field": "..."}`. - Orientations: landscape, portrait, landscape_inverse, portrait_inverse. The `_inverse` ones are the screen's: they tell the platform its top is the other edge, for every publication. - The Wignet's name (`get_state` → `name`, null until one is given) is what the owner calls it. When they give it one, `set_name {"name": "Kitchen"}` keeps it on the platform (`null` clears it): their page shows it at once, other agents read it, and the link and identifier stay the same. - Resolution and display profile are administrator settings. The owner's page shows the current content and, under its Schedule tab, the planned events (read-only); it can also set the Wignet's name, orientation and battery sync frequency. Guides (Agent Skills) explain how to do well what these tools allow: read_skill without arguments lists them, read_skill with a uri reads one of their files. Read skill://wignet/SKILL.md before composing or sending an image (photos included). For a more polished visual than a card, the Wignet's get_capabilities gives in skills.design the files of skill://wignet-visuals/SKILL.md to read for its display profile (black and white or six colours); skills.tune, skill://wignet-tunes/SKILL.md, before writing an alarm tune for a Wignet that plays them; skills.events, skill://wignet-alarm/SKILL.md before setting an alarm and skill://wignet-notify/SKILL.md before sending a notification (a sound or a message now, or at a given time). When the owner wants a use case rather than a single action (a photo slideshow, a smart alarm clock…), read_recipe lists recipes: its outcome, what it requires, and which of these tools make it.

Live catalogue of the Wignet frames sold on this site: prices (VAT and shipping included) and remaining stock, from the same table the shop page and payment read. Call list_products before quoting a price or saying what is left; never answer from memory. Ordering is done by the person on https://wignet.app/shop.html; you cannot place an order. Anything outside this batch (sizes, custom frames, lead times): contact@wignet.app. This server does not drive a display: that is the device's own link and connector.