Dashboards by conversation

A dashboard in Charyl’s world isn’t something you have to build from a blank canvas — you can describe what you want, and she drafts it. Building and editing happens in the web app; on the mobile app, the dashboards you’ve built render live, but creating or restructuring one is still a web app task.

Grounded before she drafts

Before Charyl proposes anything, she checks what’s actually true about your home: the dashboards you already have, the full registry of card types available, and a scoped list of the devices and sensors that could actually go on one. That’s why her first draft usually looks close to right from the start — she isn’t guessing at a generic dashboard from a generic list of possibilities, she’s working from your specific home and what’s really in it.

1. Ask for one

   “Build me a dashboard for the garage” is enough to start. She checks what exists, then proposes a layout using devices that are actually in that space.

2. Review the draft

   She shows you the cards she’s proposing before anything is created — what each one is bound to, and what it’ll show.

3. Confirm to create it

   A tap creates the dashboard. From there, you can keep going in the same conversation — “add a toggle for the porch light to this dashboard” appends a card the same way.

What needs a confirm, and what doesn’t

Every structural change to a dashboard — creating one, adding or removing a card, renaming it, or rolling it back to an earlier version — waits for a tap, the same as a device action does. You see exactly what’s about to happen before it does.

Deleting a dashboard asks for more than a tap. Because that one can’t be undone, she asks you to type the dashboard’s name to confirm — a small extra step reserved for the one action here that’s genuinely irreversible.

Cosmetic changes are the exception. “Change that sensor card’s color to blue,” or adjusting a unit or a sparkline’s thresholds, applies right away, with no confirm — those edits can’t change what a card actually shows or controls, only how it looks. The moment an edit would rebind a card to a different device, change what kind of card it is, or touch the label or icon on a card that’s tied to a specific device, it’s back to a confirm. That last one is deliberate: changing a card’s label without changing what it’s actually bound to is exactly how a card could end up quietly showing something other than what it claims to, so it gets treated as structural even though it sounds cosmetic.

A few things people ask her to do

• “Build me a dashboard for the garage.”
• “Add a toggle for the porch light to this dashboard.”
• “Change that sensor card’s color to blue.”
• “Delete my old dashboard.”

Each of those is a real, working request, not a simplified example — what you ask for is what gets checked against your home before anything is proposed.

Where sensor trends actually live

If you’ve asked Charyl about a sensor’s history and wanted more than a summary, a dashboard is the answer. A card showing a sparkline or a chart for a sensor’s readings over time is something you build once and then just glance at, rather than asking about in every conversation — trend charts live on dashboard cards, never inline in a chat reply.

Where dashboards live

Building and editing a dashboard — through conversation or by hand — happens on the web app. On your phone, the dashboards you’ve built render live and update in real time, but a new one, or a real restructuring of an old one, is still a web app task.

For the device actions dashboards can trigger, see what Charyl can control. For sensors themselves, see what sensors does Charyl understand.