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, editing and viewing all happen in the web app; the mobile app doesn’t show dashboards yet.

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, and that is where you view them too. The mobile app doesn’t show dashboards yet.

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