Guided tour¶
On a new install, once you have signed in and joined or created an organization, Zelos offers a tour. You can also start it at any time from the command palette (Start the guided tour) or from Settings › App › Guided tour.
It is twelve steps. A simulated battery site comes online, misses a dispatch target, and you work out why, keep the layout and the run as a trace, ask the assistant, and publish its write-up. Everything you do is the real app. The Marketplace, the panels, the timeline, the chat surface and the Share dialog are all real.
What is behind them is not. For the length of the tour the app talks to a simulated site instead of to your agent and your account: the bus, the extension, the assistant's reply, the write-up and the team you publish to are all made up on this machine. Nothing is written to disk, nothing reaches your agent, and nothing leaves for the cloud. Leaving removes all of it. So does a crash or a reload: the tour ends there, and the next launch puts your sidebars and lists back the way it found them. If you had not yet answered the offer, it comes round again.
The story¶
A grid-connected battery site is asked for a fast ramp to 248 kW and delivers 206. Its battery management system (BMS) reports a comms fault and cuts the pack's power limit.
The pack is fine. What actually happened is that the DC bus sagged under the ramp. The heartbeat between the power conversion system and the BMS missed three frames 300 ms later. The BMS read that silence as a pack fault. The evidence that clears the battery is on a different bus from the component that got blamed. Finding it means having every source on one timeline.
The twelve steps¶
Explorer, the extension's page, the AI view and the write-up are opened for you; the tour asks you for the actions worth learning, and for one click on the rail, so you have opened a view yourself. The steps come in four chapters: connect, investigate, keep, answer.
| Step | What you do | What it shows you |
|---|---|---|
| 1 | Connect the localhost agent |
The Data view lists agents, which read your hardware, and recorded traces, which open here too. The app bundles an agent; remote agents connect the same way. Then Explorer, which lists what an agent has, and is empty |
| 2 | Open the Extensions view from the rail | The rail icons switch between views. An extension connects an agent to an interface: CAN, Modbus, OPC UA, serial |
| 3 | Install CAN Bench from its page | A battery site simulated on a CAN bus: a pack and its BMS, a DC/DC converter, an inverter, and a site controller |
| 4 | Open its settings, pick a channel and a bitrate, then Save & start | Settings tell an extension what to read. Both reach the data |
| 5 | Command a dispatch | Actions drive hardware from Zelos and come back with a result. Here that is a time range, and the timeline pauses on it |
| 6 | Right-click the log's ERROR line and choose Set cursor here | The site log is on the same timeline as the signals. Every panel reads at the cursor: the link is already lost, the bus is already down, and the limit has just been cut |
| 7 | Open the sidebar search and drag input_voltage onto the plot |
Every signal the agent knows is in the tree. The tour writes the search term; you build the panel by dragging |
| 8 | Turn on the ruler | Two cursors on the sag, and each legend chip shows that signal's change between them: the bus fell before the BMS cut the limit |
| 9 | Save the layout | A layout is your tabs and panels without the data. Load it on any agent or trace, or share it with your team. Your team has saved some already. The form opens with the name Dispatch view in it; you press Save |
| 10 | Open Save trace on the timeline and press Upload | A trace is a recording of a time window across every source. Save trace captures the window you are looking at; Upload puts it in your team's cloud, where the Cloud view lists it. The tour names and tags it for you |
| 11 | Send the prefilled question | Zelos AI has its own view. It reads the same signals you did, builds a layout, and writes the finding up as a notebook |
| 12 | Open Share on the write-up and press Publish | A notebook keeps the write-up, the queries behind it and their charts in one file. A published notebook is one your team can open. Here it publishes to the tour's own team, Demo, and never leaves the machine |
A step moves on when the thing it asked for actually happened, not when something was clicked. The dispatch counts when the site returns a window that holds the failure. The measurement counts when the ruler spans the drop. An instruction card has no way to skip past it. The cards that report what just happened carry Continue, which is you saying you have read them.
While it runs¶
Only the control the current step asks for responds. Everything else is dimmed and inert. A click there does nothing, on purpose. ++escape++ asks whether you want to leave rather than dropping you out.
Keyboard shortcuts are held back for the same reason, with one exception: quitting the app always works. The close-window shortcut does not, because a window closing under a running tour leaves it pointing at furniture that is gone. The title bar's own close button is not a shortcut and still closes the window; the next launch cleans up after it.
The tour ends on one last screen, the way it began. Done is the only way out, and it ends the tour.
While it runs, the Data view, the Layouts section and the Cloud view show the tour's own agents, traces and layouts in place of yours, so nothing of yours is on screen or at risk. Leaving removes the site, its workspace, the layout it saved, the trace it uploaded, its write-up and the publish. CAN Bench goes with them. It is a prop the tour builds its story out of, not an extension you keep, and it appears in the Marketplace only while a tour is running. Start the tour again from Settings.
What the settings do¶
The settings dialog has two, and both reach the data.
- Channel is the interface the bus publishes on. It names the source in the site's log and in the write-up.
- Bitrate is how fast the bus runs, and so how many frames a second arrive. The faster one makes every trace denser. Both are fixed when you press Save & start.
The write-up¶
The assistant writes it as part of answering, the tour opens it, and step 12 publishes it. It is a read-only notebook holding the run. It lists what moved and in what order, the pack checks (three of which pass), the cause, and the queries behind all of it. It opens instantly because it is a document rather than a computation. No Python is needed to read it.
It lives in the tour's own notebook library for as long as the tour does. There is no file on disk, and publishing it puts nothing in your team's cloud.
The queries it lists are the part worth keeping. Point the same four at your own capture and they answer the same question about it.
The trace¶
Step 10 saves the run the way you would keep a real one: Save trace on the timeline
captures the window you are looking at, across every source, and Upload puts it in
your team's cloud. Export, which writes a .trz file to this computer, is held during the
tour so nothing is written to disk. The upload is answered on this machine and lands in the
tour's own Cloud view, beside two recordings a colleague made up for the occasion.
Then your own hardware¶
Real hardware works the same way you just watched, and by the same steps: connect an agent, install its extension, configure it, start it. CAN Bench simulates a site rather than reading one, but it is installed and run exactly like an extension that does.
The agent is the process that owns the connection, collects the data and answers
queries. The tour used the one this app bundles, called localhost, which is why step 1
connects to it. An agent can also run on a bench machine, or on the vehicle itself:
connect that one from the Data view, and install the extension onto it instead. The
rest is what you have already done.
See Installing the agent for getting one running, and Extensions for what is there to install.