Live Console
The Live Console is a page in the R1-MCP dashboard that keeps updating while you talk to Claude. A conversation is turn-based; a client’s signal is not. The console covers that gap — you watch a client’s events and metrics tick continuously in one window while you work the problem in another.
This is an Early Access feature: unlock Early
Access, then turn it on in the Early Access card of the
dashboard. Its toggles appear once the password
is accepted; the Features card holds only the generally available features. Open it at
https://r1-mcp.lanpulse.com/console.
It’s driven by watches
Section titled “It’s driven by watches”The console shows watches — the same watches the webhooks feature uses. There are two ways to start one:
- Ask Claude.
watch_clientarms a watch on a client MAC. It belongs to the Webhooks feature, so that must be on too — with only the console enabled, Claude has no way to start a watch. With the console feature enabled, that call also returns aconsoleUrl— a deep link straight to the live window for that watch, which Claude will hand you. - Add it on the page. Enter a client MAC in the console itself.
There is deliberately no separate “console” tool. watch_client is the single
registration point; enabling the feature is what makes it hand back the link.
A watch Claude starts while the page is already open is pulled into the list without a refresh.
A watch added on the page lasts 2 hours; one Claude starts with
watch_client lasts 24 hours by default. You can have up to 100 active
watches; past that, a new one is refused with watch_limit_reached. Because the
page and Claude share one set of watches, Stop on a card cancels the watch
everywhere — including the in-chat notices Claude was relying on for it.
What each watch shows
Section titled “What each watch shows”An event feed, newest first, of the webhook events mentioning that client, pushed the moment they’re ingested. This is the near-realtime half.
Three sparklines — RSSI in dBm, SNR in dB, and Tx in Mbps — built from polled R1 metrics. These are labelled as roughly three minutes delayed, because that’s the API’s own latency, not the page’s.
The page stops polling R1 while the browser tab is hidden, so leaving it open in a background tab doesn’t keep generating API calls. Metric polling also pauses altogether 15 minutes after the page opens, hidden time included — the sparklines freeze and a banner offers Resume. Events keep streaming regardless.
What it needs to show anything
Section titled “What it needs to show anything”The event feed is fed by the webhooks receiver. If you haven’t configured RUCKUS One to deliver events to your receiver URL, the sparklines will still fill in from the API but the feed stays empty.
Using it with Claude
Section titled “Using it with Claude”The pattern this exists for:
- Ask Claude to arm a watch on the client you’re investigating.
- Open the
consoleUrlit gives you. - Go reproduce the fault, watching the feed and the signal charts live.
- Come back to Claude and ask what was caught — the same watch data is available to the analytics tools.
Who sees the AI chat panel?
Section titled “Who sees the AI chat panel?”Some accounts also see an AI chat panel near the top of the console. It drives the same tools through a Cloudflare Workers AI model and shows each tool call as it runs.
The panel appears only when the console feature is on and an administrator has granted AI chat to your account. You can’t turn it on from the dashboard; to ask for it, contact support. Without the grant the panel simply isn’t there — no message, no error.
See also
Section titled “See also”- Webhooks and analytics — the watch tools and the event receiver
- Workflow prompts — Live reproduce-and-catch does this as a guided workflow
- Features and feature flags — unlocking Early Access