AI Chat
An assistant embedded in the screen itself, so an operator can ask a question about what is in front of them without opening another tool. It answers from the tags you scope it to, the alarm history, and any manuals you have uploaded — and it reads only. It can point at a problem and suggest a next step; it cannot change a setpoint, acknowledge an alarm or write a tag.
Reach for it when you need:
- A "why did this line stop?" box beside a line overview
- Putting the equipment manual within reach of the screen that shows the equipment
- Letting a shift lead ask for yesterday's downtime without learning the trend tool
Component name: AIAssistant · Category: Input
In the palette: An AI assistant on this screen. Tick the skills it may use and the part of the plant it covers; operators can then ask about tags, alarms and your uploaded manuals without leaving the screen. It can read and suggest — it never changes anything on its own.
Properties
Any property can be bound to a tag, another component's property, or a query.
| Property | Type | Default | Description |
|---|---|---|---|
title | string | Assistant | Heading above the conversation, e.g. "Ask about Line 1". |
limitToRole | boolean | false | Let each operator's ROLES decide what this assistant may reach, set once in Settings → Identity & Access → Roles → AI Access. Off (the default) the boxes below are the answer; on, they are hidden and not used, and one screen serves a plant where an operator and a maintenance engineer should see different things. Ask about something a role does not cover and the assistant simply says it cannot see it. Three things to know before turning it on: what an operator ends up with is still limited by their own account (an HMI never gets authoring or writes, and an administrator can switch any capability off for everyone); roles come from the project's bound User Database, so a screen copied to a project bound elsewhere resolves differently; and a role nobody has given AI access permits NOTHING, which reads as a broken assistant rather than an unconfigured one. |
playbooks | aiPlaybooks | [] | START HERE, and usually the ONLY thing you need to set. Saved answer PROCEDURES for the questions operators actually ask — "for pump condition: read these tags, check these alarms, trend this, answer as a dashboard" — so the same question gets the same complete answer however it is phrased, instead of the assistant deciding for itself each time. Authored in Project Browser → AI Playbook and shared by every screen that picks them. Each one BRINGS THE SKILLS ITS STEPS NEED and MAKES THE TAGS IT NAMES READABLE, so you do not tick skills or set a scope for it: a Read-tags step brings Tags and the two tags it lists, a Trend step brings History. Because an engineer picked those paths they are also used verbatim, skipping the search a guessed path would need. A procedure can name the roles it is FOR, so one screen serves an operator and a maintenance engineer with different procedures. Picking none is not a restriction — the assistant works it out as before. A playbook GUIDES; the only reach it adds is the exact tags it lists, never a folder, and never past the operator's own role when limitToRole is on. A step it cannot take is skipped silently; the picker tells you at design time when that will happen, per role. |
skills | skills | [{"id":"tags"},{"id":"alarms"},{"id":"knowledge"}] | Capabilities for questions your playbooks do NOT cover. Whatever a selected playbook needs is already on — you will see those rows ticked and locked, marked "from playbook" — so tick here only for the unscripted questions: "what is the temperature on Line 3?" has no playbook and still needs Tags. Fewer skills means fewer tools competing for the assistant's attention and a measurably better chance it picks the right one. Authoring and writes are refused on an HMI whatever is ticked — they change the product or the plant, and no amount of ticking should reach them from an operating screen. READS are not refused by the surface: free-form SQL and the file library can be ticked here, and what an operator actually gets is then decided by the admin switchboard and their own account (the file library needs Manage Library, which an operator does not normally hold). Worth knowing before ticking Database Explorer on a panel: the tag scope does not fence SQL — which connections are AI-enabled is the only fence, and it is set in Settings. When limitToRole is on this list is hidden and NOT used — each operator's roles decide instead — but it is kept, so unticking the box restores it. |
specialists | aiSpecialists | [] | Which saved SPECIALISTS this screen's assistant may call. A specialist is a focused assistant of its own — its own instructions, its own narrower set of tools — that hands back one finished answer, so a question needing four capabilities costs this assistant a single tool instead of four. Authored in Project Browser → AI ▸ Specialists and shared by every screen that picks them. Each one BRINGS THE SKILLS IT NEEDS, so you do not tick those separately; it can never reach further than the person asking, and it changes nothing on its own — anything it recommends becomes a proposal a person approves. Picking none is not a restriction — the assistant simply answers the way it did before. Requires the Specialists skill above: ticking one here without it does nothing. |
scope | tag | [] | EXTRA tag data, for freehand questions your playbooks do not cover — the tags a playbook lists are already readable without setting anything here. Nothing (the default), Everything, or the folders you tick, e.g. Line1/, which keeps covering Line 1 as tags are added to it. It starts closed on purpose: a playbook says exactly which tags it reads, whereas this opens the assistant up to browse, so that should be deliberate. NEEDED BY A PLAYBOOK TOO: a "Check alarms" step sweeps a FOLDER, and folders are never opened automatically — tick it here, or that sweep only sees the tags the playbook already made readable. Enforced by the SERVER against the saved screen, so editing it in the browser changes nothing. When limitToRole is on this is hidden and NOT used — each operator's roles supply the scope instead. |
databases | aiDatabases | "" | Databases this assistant may query, as a comma-separated list of connection ids — or * for every AI-enabled database. Empty (the default) means none. NEEDED BY A PLAYBOOK TOO: a "Run saved query" step is refused unless its connection is listed here — unlike tags, a playbook does not open a database for you. Named databases rather than connections because that is all the AI can ever reach: SQL, QuestDB and MongoDB, never an OPC-UA server or a mailer. Bindable, so a tag or param can supply it. Only databases an admin marked AI-enabled in Settings are reachable at all, and the SERVER enforces this against the saved screen. |
externalSystems | aiExternalSystems | "" | External systems this assistant may call, as a comma-separated list of endpoint ids — or * for every one an administrator has opened. Empty (the default) means none. NEEDED BY A PLAYBOOK TOO: a "Call external system" step is refused unless its endpoint is listed here. It can only run the operations an administrator defined on them: it cannot compose a URL or reach anything unlisted. Bindable. Enforced by the SERVER against the saved screen. |
prompt | string | "" | A standing instruction added to every question this assistant is asked — e.g. "You cover Pump 2. Answer in Bahasa Indonesia. If asked about another line, say you do not cover it." Use it to narrow a general assistant to one job: a focused one answers better than a broad one. The operator never sees it and cannot argue with it. Applied by the SERVER from the saved screen, so editing it in the browser changes nothing. |
security | object | {} | Who may USE this assistant. Leave roles empty = everyone. The server reads this same gate from the saved screen and refuses an unauthorized turn, so it holds even if the widget is reached directly. |
showTitle | boolean | true | Draw the heading above the conversation. Off keeps the title text, so turning it back on does not mean retyping it. |
titleStyle | textStyle | {} | Typography for the heading alone. Anything set here wins over textStyle; anything left unset falls through to it, so setting only a colour keeps the inherited size. |
textStyle | textStyle | {} | Typography for the conversation (font, size, colour, spacing). Sizes inside scale from this, so raising the size enlarges the whole chat. |
value | string | "" | The text in the message box — reflects what the operator types, and bindable both ways. Bind a tag or a param to seed a question ("Why did %{tag} alarm?") from a button or another widget. Seeding is all it does: the operator still presses Send, so plant data can never start a conversation on its own. |
placeholder | string | Ask a question… | Placeholder text in the message box. |
emptyText | string | Ask a question to get started. | Shown before the first question. |
style | style | {} | Custom CSS properties |
Events
Attach event actions to these in the Event Manager.
| Event | Label | Group | Payload |
|---|---|---|---|
click | Click | Mouse | The DOM event. |
dblclick | Double click | Mouse | The DOM event. |
contextmenu | Right click | Mouse | The DOM event. |
mouseenter | Mouse enter | Mouse | The DOM event. |
mouseleave | Mouse leave | Mouse | The DOM event. |
Right-click behaves differently in the Designer
contextmenu fires your configured actions at runtime only — in LiveView and in preview. On the Designer canvas the right-click is captured to open the Event Manager, so testing it there will not run your actions. Test right-click in preview.
Notes
Two settings decide what it can see, and both default to closed. scope is empty by default, which means no tag data — tick the folders this assistant may reach (Line1/) rather than granting everything, so a screen for one line cannot answer questions about another. skills decides what it may do at all: tags, history, alarms, knowledge and saved-queries. Untick a skill and the capability is gone, not merely discouraged.
security gates who may use the assistant. Leaving roles empty means everyone who can open the screen. This is enforced on the server against the saved screen, not in the browser, so it cannot be bypassed by a doctored client.
Answers are only as good as what you have given it. An assistant with knowledge ticked but nothing uploaded will say it does not know — which is the intended failure, and better than a confident guess.