Example prompt: an embedded Pixelblaze Charm for MBXHub

Rendered from pixelblaze-charm-prompt.md • back to worked examples

Use this single prompt to ask an LLM to create the integration described in the worked example. Replace <MBXHUB_BASE_URL> with the actual MBXHub HTTP origin, including its port. Replace <PIXELBLAZE_BASE_URL> with your controller's HTTP origin, such as http://<ipaddress>/. These are two different devices and addresses.

The output should contain the two installation files and documentation for their operation and design. It should not rebuild MBXHub. Read the worked example first for the LAN reachability and HTTP embedding requirements.

---

Copy-paste prompt

Build an embedded Pixelblaze controller Charm for MBXHub, reusing the Pixelblaze's existing webpage.

My inputs are:

• MBXHub base URL: <MBXHUB_BASE_URL>.
• MBXHub API/Charm contract: <MBXHUB_BASE_URL>/llms.txt.
• Pixelblaze device: <PIXELBLAZE_BASE_URL>.
• Optional controller implementation reference: https://github.com/halrad-com/PixelblazeDotNet.
• Optional local PixelblazeDotNet checkout: use it if I provide one; do not assume a checkout location or require theMatrix source access.

Read llms.txt first, especially Charms, manifest fields, display modes, framed pages, shared components, and Device Proxy. Use that published contract for the MBXHub integration; do not require MBXHub source access and do not invent endpoints. If you cannot access an input, say which one and request its contents instead of claiming to have read it. Follow this session's permissions for any network/tool access, file edits, or installation.

Architecture: a hub-hosted wrapper at /pages/pixelblaze.html embeds the actual device URL in an iframe. The device page retains its origin and owns its WebSocket connection. Do not fetch its HTML and inject it into the wrapper, bundle a copy of the firmware UI, or treat POST /api/proxy as a WebSocket/site reverse proxy. Do not add a bridge or dependencies without discussing a concrete need first.

Prior inspection on 26 September 2026 found HTTP 200, no X-Frame-Options or CSP response header, and inline code calling connectWebsocket(window.location.hostname) to open ws://<hostname>:81/. Treat this as dated evidence, not a guarantee about the current device or browser. If inspection is authorized, check the current root page and headers with a read-only GET. Do not invoke device control/update routes as part of inspection. If embedding is blocked, report the exact observed blocker and propose the smallest alternative before changing this architecture.

Produce these deliverables:

1. charms/pixelblaze.json: a page Charm named Pixelblaze, using the documented expand[] shape and an action of webapp /pages/pixelblaze.html with display: "both". Use example.pixelblaze as the example ID, a small local icon, and only documented fields. This is a locally placed manifest; do not manufacture a hub-owned registration record or request proxy:lan for an implementation that does not use that API. Explain any registration policy required by the actual target hub through its existing console workflow.
2. pages/pixelblaze.html: the complete wrapper, using plain HTML, CSS, and only the JavaScript needed for wrapper behavior. Load the hub's documented shared components and theme tokens. Give the iframe an accessible title and usable responsive height. Put the title, Reload device page and an Open device separately link (target="_blank", rel="noopener noreferrer") in a header the user can collapse — a native <details open> with the title as its <summary>, remembered per browser — so the device page can have the room. Use the device URL above; make its configuration point clear. Keep the device's own UI.
3. README.md: a user guide covering prerequisites, finding the active instance's data directory, installing the two files, opening inline/separately, using the device's own controls, changing the device address, troubleshooting, and removing just these files. Explain that removing/closing the Charm does not reset the LEDs.
4. IMPLEMENTATION.md: a worked explanation of how llms.txt informed the manifest and wrapper, why direct embedding preserves the controller's origin, what any controller references establish, the boundaries below, source locations, and a verification record. Include the input prompt or refer to a saved copy so the example is reproducible.

Required behavior and boundaries:

• Work on a local LAN without new cloud/CDN/runtime dependencies. The browser itself must reach the device; this is not remote access through the MBXHub server.
• Use Firefox as the first browser check, and cover Chrome, Edge, and Safari when available. Label unavailable checks, never infer a pass.
• An HTTPS hub page must not be promised an embedded HTTP device. Provide a clear fallback to opening the device separately; do not disable browser security or automatically downgrade the hub's connection.
• The cross-origin iframe is opaque to the wrapper. Do not read or manipulate its DOM, assume a postMessage API, add fake iframe-cmd controls, or report Connected merely because its load event fired. Direct users to Pixelblaze's own status.
• Theme the wrapper only. Pixelblaze retains its own UI/theme, including its full device-management surface. Do not claim the embedding restricts its capabilities.
• Log wrapper navigation requests and relevant decisions/errors through the documented MBXShared.clientLog, using appropriate levels. Distinguish a frame load event from a verified device connection. Do not log secrets or page contents.
• PixelblazeDotNet is an optional read-only development reference, not a runtime dependency. Do not port its protocol code for this embedding task. If a later custom controller is discussed, inspect the actual implementation and device responses; pattern listing can return binary frames.
• No music synchronization, discovery, MBXHub core changes, security-setting changes, device configuration, firmware changes, or process restarts are included.

Validate manifest JSON, endpoint/field names against llms.txt, HTML/JavaScript syntax, relative links, and the two files' consistency. When authorized and a running hub/browser is available, verify the served wrapper, inline display, separate display, controller connection, and narrow layout. Test hardware writes only with authorization, record the initial state, and restore it afterward. Explicitly list any checks not performed, including offline runtime checks.

Create the files in the agreed output directory for review. Do not install into the running instance, build MBXHub, push anything, or declare the project ready. Provide the file paths and a short, factual verification summary.