LoT Editor

Coreflux HUB LoT Editor showing digital-twin-energy-site badged LIVE with energy-site.lotnb, a markdown cell titled Solar energy site · Modbus TCP + BACnet/IP, a DEFINE ROUTE TwinEnergyModbusU1 cell badged DEPLOYED, BROKER RUNTIME with type counts, CONFIGURATION, LIBRARY, a Deployed chip, main branch, and Deploy All — The LoT Editor with the live project's notebook open: a markdown introduction above deployed connector cells, Projects lists the project badged LIVE, Broker runtime shows its entities, and the header shows Deployed plus Deploy All

Why Use the LoT Editor?

The LoT Editor brings the LoT Notebooks experience from VS Code into the Coreflux HUB. You author LoT and Python in notebook cells, deploy any cell on its own, and see per-cell whether your copy matches what the broker is running — with the broker’s live entity list right beside your code, without leaving the browser. This makes the HUB a single place to develop, manage, and operate your Coreflux solutions.

This is parity, not a replacement. Editing LoT from the VS Code LoT Notebooks extension remains fully supported, and you never have to choose between the two. The broker is the source of truth: either editor deploys to it, and both read the same project. Import .lotnb, Push to broker, and Pull from broker are what keep the two workflows one.

Like a lab notebook wired to the machine it describes. The prose, tables, and code live in one document — and each block of code is the thing that is actually running.

When to Use It

Deploying LoT without another tool installed — Any HUB install, Docker or desktop app, can author and deploy
Checking what is really on the broker — Broker runtime is the authoritative list, next to your code
Iterating on one definition — Run a single cell instead of redeploying a whole project
Auditing drift — Per-cell badges and a broker diff show exactly which definitions have moved out of sync
Documenting a solution where it lives — Markdown cells render inline, so the topic conventions and device maps sit beside the code that implements them
Putting live visuals next to the LoT that drives them — Drag Library components into a markdown cell and watch topics such as demo/sensor/value update in the notebook
Picking up someone else’s project — Open it from the broker and read the notebook top to bottom
Publishing or recovering a project — Push a local draft, Pull or Inspect one already on the broker, or restore an earlier commit
Removing without surprises — A local delete, an entity remove, and a project remove from the broker are three different operations

Opening the Editor

Select LoT Editor in the HUB dock — the notebook-and-pen icon, after Data Viewer and Connections. An orange dot under the icon marks the editor as the active app.

Animated walkthrough of clicking the LoT Editor icon in the Coreflux HUB dock to open the editor — Opening LoT Editor from the HUB dock: the notebook-and-pen icon is fourth from the left, and the editor opens above the dock

The window header carries the current project and notebook plus the controls that act on the whole notebook:

Coreflux HUB LoT Editor window above the dock, a template project's notebook.lotnb in the breadcrumb, 12 not running chip, orange Deploy All, Projects listing the project as local, Library Components 28, LoT Editor dock icon active — LoT Editor open on a template project with the dock still visible: breadcrumb project › notebook.lotnb, 12 not running, Deploy All, and the notebook-and-pen dock icon lit with an orange dot

Control	What it does
Breadcrumb (`project › notebook.lotnb`)	The open project and file. Click either part to rename it
`Deployed`	Every comparable cell in the open project matches the broker. Drift shows as an orange count such as `N differs` or `N not running` — on a live project, click it to Push
Branch chip (`main`)	Git branch of the open project on the broker. Missing git is silence — there is no `Local workspace` chip
`Deploy All`	Deploys every LoT and Python cell in the open notebook. The split control also offers Deploy project, which stores and loads the whole project
Action Console (pulse)	Opens the right-hand Action Console rail for running and tracing Actions — see Action Console
Remove entities	Removes the entities this notebook defines from the broker
Undo / Redo	Step cell changes back and forward
Attach notebook to AI chat	Hands the open notebook to the HUB’s AI assistant as context
`…`	`Import .lotnb file` and `Export open notebook as .lotnb`

A Notebook Is Both Document and Deployment

A notebook is an ordered list of cells, and the cell type dropdown decides what each one is:

Cell type	Contents	Deployed?
LoT	One complete definition — `DEFINE ACTION`, `DEFINE MODEL`, `DEFINE CONNECTOR`, `DEFINE RULE`	Yes, to the broker
Python	A Python script your Actions call, named in the cell’s Script name field	Yes, to the broker
Markdown	Headings, prose, lists, tables, live visual components, and links to project documents	Visuals are published as panels; prose is documentation

Markdown cells render in place between the executable ones. That is not documentation-only: you can drop a gauge, chart, or card from Library → Components into a markdown cell and it stays live, bound to MQTT. A project installed from a template can use this for a live document preview — widgets on a topic such as demo/sensor/value sit in the notebook itself, so you deploy the cells above and watch the gauge, status, and trend update without leaving the editor.

Adding visuals in the editor is a first-class authoring step, not a Dashboards-only feature. Drag from Library, or write the component in the markdown cell — the notebook is allowed to be the live view. See Library.

To add a cell, use the + Code and + Markdown buttons that appear in the gutter between cells — so a new cell always lands exactly where you point at it.

Working With Cells

Every cell has its own toolbar, left to right. Hover the cell to reveal the right-hand controls — Move up / Move down, Duplicate, and Delete stay hidden until then.

Coreflux HUB LoT Editor TwinEnergyProjectKpi cell hovered with the DEPLOYED badge and toolbar controls, DEFINE ACTION TwinEnergyProjectKpi ON EVERY 1 SECOND reading energy-site topics, and the strip TwinEnergyProjectKpi Not yet run with Open in Action Console — TwinEnergyProjectKpi hovered and deployed: drag handle, Run cell, LoT, DEPLOYED, then Run or trace, Move up, Move down, Duplicate, and Delete, with the run strip below

Control	What it does
Drag handle	Drag to reorder the cell
Run cell (`Shift`+`Enter`)	Deploys just this cell to the broker
Cell type	Switch between `LoT`, `Python`, and `Markdown`
Sync badge	This cell’s state against the broker — see below
Enabled switch (one ACTION, CONNECTOR, or AGENT per cell)	Turns the entity off or on without removing it — see Disable an entity
Run or trace (pulse, Action cells only)	Pin this Action in the Action Console. While a capture is armed it reads as tracing
Compare with broker	Shown when the cell is not `DEPLOYED` — see Comparing a cell with the broker. Appears on hover
Move up / Move down	Reorder without dragging. Appear on hover
Duplicate	Copy the cell and its contents. Appears on hover
Delete cell	Remove the cell from the notebook. Appears on hover

Action cells also carry a strip under the code. Here it reads SummarizeF2Hvac · Not yet run · Tracing — expand it for Traces and Run, or choose Open in Action Console to pin the same panel in the right-hand rail. Tracing (green) means a five-minute capture is already armed for that Action. Deleting a cell asks “Delete this cell?” and warns that the cell and its contents are removed from the notebook and that it cannot be undone. It changes the notebook only — the entity that cell deployed stays on the broker until you remove it there. See Removal.

Disable an entity

A cell that holds exactly one action, connector, or agent has an Enabled switch in its toolbar. Switch it off to write DISABLE true on the line after DEFINE. Switch it on to remove that line. The broker keeps a disabled entity defined and listed, but doesn’t run it.

Coreflux HUB LoT Editor with the acme-bottling project open on its Plant actions section: the Heartbeat cell, publishing acme/plant/heartbeat every 5 seconds, with its Enabled switch on, and the AlarmRelay cell with its switch off labelled Disabled, the line DISABLE true under DEFINE ACTION AlarmRelay, and the result Action AlarmRelay added successfully (disabled) — Two Action cells: Heartbeat with the Enabled switch on, and AlarmRelay switched off, which writes DISABLE true into its code

With a broker connected, the cell is redeployed right away, so the notebook and the broker stay in step.
Offline, the change stays in the cell and goes out with the next deploy.
Models, rules, and cells with several entities have no switch.
On a broker that doesn’t support DISABLE, the switch is locked and its tooltip says Requires a broker with DISABLE support.

See Disable and Enable for the matching broker commands.

Action Console: Traces and Run Once

Run cell deploys the definition. The console underneath — or pinned from the header pulse — is where you watch and trigger execution: Traces records every run for five minutes, and Run once fires the Action with a topic and payload you choose. Every Action cell has the same console in two places — expanded under the cell, or pinned in the header pulse rail. Both have Traces and Run.

Coreflux HUB LoT Editor SampleProcessor console on the Traces tab showing no messages yet, timeline playback controls, and copy that traces record every execution for five minutes — SampleProcessor Traces tab before a capture: timeline chrome and the note that traces last five minutes while a single run lives on the Run tab

Control	What it does
Traces tab	A five-minute capture of every execution, including runs triggered elsewhere. Playback sits on the timeline; a single run’s result stays on Run
Run tab	Topic and payload (or JSON parameters for callable Actions), then Run once
`Use`	Fill the payload from the last message on that topic, or from the last run
Run once	Live run — (re)deploys the version in the cell, then executes it. There is no sandbox: anything the Action publishes is published
Open in Action Console	Pin this Action in the right-hand rail so you can switch Actions without leaving the strip

Coreflux HUB LoT Editor SampleProcessor console on the Run tab with topic demo/sensor/value, payload 60, Use dropdown, and Run once play button — SampleProcessor Run tab: topic demo/sensor/value, payload 60, Use menu, and the orange Run once control

Run once is a live run. It (re)deploys the Action from the cell and executes it on the broker. Downstream topics, databases, and devices see the same publishes they would from a real trigger.

Is This Cell Running on the Broker?

Each LoT and Python cell reports its own state against the broker, which is the fastest way to tell whether the code you are reading is the code that is running:

Badge	Meaning	What to do
`DEPLOYED`	The cell matches an entity running on the broker	Nothing
`DIFFERS`	The entity is running but the source here has changed	Run the cell to update it
`NOT RUNNING`	Nothing of that name is running on the broker yet	Run the cell to deploy it
`RUNNING`	Something is running that this project does not declare	Adopt it, or remove it from Broker runtime

Coreflux HUB LoT Editor showing notebook cells badged NOT RUNNING with Compare with broker controls, and a header chip reading a not-running count — Cells that are not on the live project are badged NOT RUNNING — the header chip counts them, and Compare with broker is available on each toolbar

NOT RUNNING and DIFFERS are how the editor answers “why is my Action missing from LoT Flow?” — the graph is drawn from Broker runtime, so a cell that has never been deployed has nothing to draw.

Comparing a cell with the broker

Whenever a cell is not DEPLOYED, a Compare with broker (Diff) control appears on its toolbar. It replaces the editor with a line-by-line comparison of the running definition against your local copy, headed BROKER · <entity> ⟷ LOCAL with an added/removed line count:

Coreflux HUB LoT Editor showing SampleMqttBridge in diff mode, header BROKER · SampleMqttBridge vs LOCAL, CLIENT_ID changed from bridge-client to bridge, PROJECTS Sample LIVE, orange 1 differs chip and main branch — A cell in diff mode with the header 1 differs: BROKER · SampleMqttBridge ⟷ LOCAL, the removed CLIENT_ID bridge-client in red and the local CLIENT_ID bridge in green

For a NOT RUNNING cell the comparison is against nothing — every line shows as an addition, which is a quick way to review a whole definition before it goes live.

Deploying

Two granularities, and the difference matters when a project is large:

Run cell deploys that one definition. Use it while iterating — you get the broker’s response for that entity alone.
Deploy All deploys every LoT and Python cell in the open notebook. Use it while iterating.
Deploy project (the other half of the split button) stores the whole project and loads it, replacing the broker’s entity set. It always confirms first.

Either way the cell’s badge flips to DEPLOYED once the broker confirms it, and the entity appears under Broker runtime. Here is a complete Model as it appears in a cell — the fields the Action fills in are the ones worth reading first:

DEFINE MODEL SampleTableRow COLLAPSED
    ADD DOUBLE "value"
    ADD STRING "status"
    ADD STRING "timestamp"

Running a cell writes to the broker immediately. There is no staging step and no separate save — the definition in the cell replaces whatever the broker was running under that name.

Start from a template

A new project starts with an empty notebook.lotnb. Worked examples come from LoT Templates, which browses the library at templates.coreflux.org. The built-in Sample notebook is not part of the HUB. Open LoT Templates from Help → LoT Templates, or choose From a template… in the new-project dialog that ＋ New opens. Each template has three tabs:

Tab	What you see
Overview	What the template is for
Notebook	The notebook cells, read-only
Flow	How the LoT in the template fits together

Installing a template creates a LoT Editor project on this HUB. It does not deploy to the broker. Change the example values, then deploy the cells the same way you deploy any notebook.

Clone from git

＋ New → From git… copies a public git repository into a new LoT Editor project. The clone copies files only. It does not load the project, and it does not deploy any cell. Open the notebook and run the cells you want on the broker.

Limit	What it means
Public repositories	The HUB does not accept private credentials
30 seconds	The git clone stops if it has not finished
Whole repository	The repository root becomes the project root
64 MB	A project download larger than 64 MB is refused

There is one Projects list, and Broker runtime sits under it as its own section — always present, even when nothing is running.

Coreflux HUB LoT Editor sidebar with PROJECTS listing a template project LIVE, notebook.lotnb, Entities 12, and its models; BROKER RUNTIME listing that project with type counts; CONFIGURATION Variables Secrets Internal Rules 35; LIBRARY Components 28 Resources 0; header Deployed and main — The LoT Editor sidebar: PROJECTS lists a template project badged LIVE with notebook.lotnb and Entities 12, BROKER RUNTIME shows that project with Actions, Models, Rules, Connectors, Python, Themes, and Panels, then CONFIGURATION and LIBRARY

Section	What it holds
Projects	Every project you can open — on the broker, local-only drafts, and the one currently LIVE. `＋ New` creates a draft with an empty `notebook.lotnb`. From a template… opens LoT Templates. From git… clones a public repository (Clone from git). Hover a name for placement (`On broker · live`, `On broker · idle`, `Local draft`). The row plug is Activate or Deactivate
Broker runtime	What is actually running. The group reads `Project: {name}` for the live project, or `Standalone` when none is. Click the name to open the inspector table
Configuration	`Variables`, `Secrets`, and `Internal Rules` — the broker’s locked built-in permission rules
Library	Visual components, documents, and images — see Library

Editing a notebook changes your local copy. Only deploying, Push, Activate, or Deploy project writes to the broker. A colleague on another machine sees the same Broker runtime and the same on-broker projects, not your unpublished local edits — which is why you Push and Pull.

Broker runtime

Expanding Broker runtime groups everything running by type — Actions, Models, Rules, Connectors, Agents, Things, Python, Themes, Panels — each with a count and names beneath. Click Project: {name} or Standalone to open the inspector:

The inspector is where mixed ownership is obvious: rows that belong to the open project point at notebook.lotnb; a connector you added on its own, outside any project, leaves Project and Notebook blank. Select a row to read the running source and use Open notebook, Copy to project, or Remove. A project’s own Entities folder (under the project in Projects) is what that project’s notebooks declare. Broker runtime is what is running. Those counts can disagree — Connectors (1) under the project versus Connectors (2) on the broker — because a connector added from Connectors Manager is running but not declared in the notebook. An agent (DEFINE AGENT) is its own entity. The editor deploys that cell with -addAgent and removes it with -removeAgent. It does not appear as a connector. The LLM connector it uses does. See AI Assistant and AI Connectors and Agents.

Things in the editor

A cell with DEFINE THING blocks deploys as one Thing payload. The broker expands it; the HUB never does. See LoT THING.

Run cell first checks the cell with -addThing --dryRun, together with every template it references in the workspace. Problems show as markers in the code. If they pass, the same payload is applied. -addThing updates in place, so a Thing is never removed first.
When you change a template that other Things use, the editor asks Also redeploy N other Things? before it applies.
Broker runtime → Things lists each root Thing, its instances, and the entities they own. Owned entities are read-only and leave the per-type folders. The inspector table includes Things. A Templates subfolder shows which Things use each template. The project’s Entities folder has a Things group too.
On a broker without THING support, THING cells show a red chip, Requires a broker with THING support, and don’t deploy.
A THING cell in the older syntax offers an update. It previews the changes (TEMPLATE, and {p} to {{p}}) and applies them only when you confirm.

Flow preview in the editor toolbar opens a Flow pane with the Things view of the open notebook, from the same dry run. Click an entity to bring the cell that owns it into view.

Coreflux HUB LoT Editor on the acme-bottling notebook. Under Broker runtime, the Things folder lists Acme with 16 entities and its line1 and line2 BottlingLine instances, Utilities with 4, and Templates with 3. The notebook shows the cell with DEFINE THING Acme and DEFINE THING Utilities, and the read-only Flow preview pane, built from the broker's dry run, shows All Things with 2 root Things: MQTT clients feeding the Acme and Utilities cards, and the Acme alarms going to Not in a Thing — Broker runtime → Things with the Acme root expanded, and the Flow pane previewing the open notebook's Things

An idle project’s declarations can match the running set and still read NOT RUNNING on cells — Activate that project before treating those badges as a deploy to-do.

Connectors and Python scripts deploy from the editor too. Connectors still have their own Connectors Manager for connection status and templates.

Two counts are easy to misread:

Rules under a project counts rules that project owns. Locked built-ins live under Configuration → Internal Rules, not here.
Python counts scripts. LoT Flow’s Python group counts the individual functions those scripts expose.

Library: Visual Components and Documents

Library is the bottom of the LoT Editor sidebar. It is how you put views and files into a project — not a second editor.

Components

Components is the palette of live widgets you can drop onto a markdown cell. Each row is a type (Gauge, Chart, Button, Map, …) with its group on the right. Drag a row onto a markdown cell to embed a viewer bound to an MQTT topic. A template project’s live preview is this capability in use: a card of gauge, status, and trend sitting in the document.

Coreflux HUB LoT Editor markdown cell titled Live document preview with a Sensor overview card showing a gauge at 65.0, status normal, and a live trend chart — Live document preview in a template project: Sensor overview card with a gauge at 65.0, status normal, and a live trend on demo/sensor/value

Types you can drop today, by group:

Group	Components
Display	Gauge, Indicator, Value, Text, Header
Containers	Card, Frame
Data viz	Chart, Realtime Chart, Table, List
Input	Button, Switch, Toggle, Slider, Input, Text Field, Number Field, Select, Date Picker
Geo / spatial	Map, Markers, Trace
Media / graphics	SVG, Image, Video, Camera, Audio, Barcode

Widgets in the notebook publish as panels when the document is saved, so they are the same component types Dashboards uses — authored next to the LoT that feeds them.

Resources: documents and images

Resources nests Documents and Images. These are files in the project, not a separate scrapbook you have to remember to Push.

Coreflux HUB LoT Editor Library Resources with Documents expanded to site-notes.md and Add file, Images collapsed with count 1 — Library Resources: Documents lists site-notes.md with Add file…, Images shows a count of 1

Item	What it holds	How you add it	What drop onto markdown does
Documents	`.txt`, `.md`, and `.pdf` files in the open project	Add file…, or project / folder Import file…	Inserts a relative markdown link
Images	Project images (PNG, JPEG, SVG, GIF, WebP, and similar)	Add file… under Images, Import file…, or drag an image onto a project	Inserts a relative markdown image

Click a document or image in Library to open it in the main pane (it replaces the notebook until you go back). Hover Remove on a Library leaf to delete that file from the list. Right-click a project or folder for Import file… when you want the file to live under a specific folder rather than the Library picker. Dropping a Library image onto a project copies it into that project.

Standalone Deployments vs Projects

The broker can run LoT with a live project, or without one. Broker runtime tells you which:

Mode	Broker runtime label	What it means
Live project	`Project: {name}` (the live project’s name)	At most one project is LIVE. Deployments from that project auto-commit. Activate / Deactivate on the project row choose which stored project is active
Standalone	`Standalone`	No project is loaded. Entities can still be running — you deployed cells with nothing live, or leftovers that no project owns. Auto-commit is off

Standalone is a normal state: a scratchpad, the view after Deactivate, or entities deployed outside a project (another editor, an older session, or a cell run with nothing LIVE). How the two interact:

Run cell / Deploy All with nothing LIVE writes straight into standalone runtime. The toolbar stays a direct action.
Deploy All from an idle project on the broker asks you to Activate first — it does not silently load that project.
Deploy All from a local-only draft while another project is LIVE is refused (the toast points you at Push). Deploying those cells would write into the other live project.
Activate loads a stored project’s declarations. If the broker publishes entity ownership, only that project’s entities stop; standalone leftovers stay. Without ownership, the confirm says the current project’s entities are replaced.
Deactivate unloads the live project and removes its entities from running. Auto-commit stops until you Activate again. Broker runtime then reads Standalone (plus anything that was never owned by that project). The confirm is explicit: Deactivating BMS unloads it from the broker and removes its entities from running.
Adopt into project (Broker runtime context menu) writes selected running entities into a notebook and Pushes — that is how you turn a standalone set into a project.

Moving Work Between Projects and the Broker

Right-click a project under Projects for operations on that row. A LIVE project and an idle on-broker project do not offer the same items (idle has Inspect and Activate; live has Deactivate and the full create/import set).

Context menu for the digital-twin-energy-site project in the Coreflux HUB LoT Editor with New notebook, New folder, Import .lotnb, Import file, Push project to broker, Pull project from broker, Version history, Inspect, Activate, Deactivate, Rename, Delete local copy, and Remove project from broker in red — The project context menu: notebooks and import, Push and Pull, Version history, Inspect, Activate and Deactivate, then Rename, Delete local copy, and Remove project from broker

Item	What it does
`New notebook` / `New folder`	Add a `.lotnb` file or a folder inside the project
`Push to broker`	Send the whole project — every notebook and folder — to the broker. This is what links a local project to a broker project and puts it under version control
`Pull from broker`	Replace your local copy with the broker’s. If you have unsaved local changes, a “Pull from broker?” prompt warns you first
`Version history`	Open the broker’s git history for this project
`Import .lotnb` / `Import file…`	Bring a notebook or other file from outside into this project
`Inspect`	Download the broker’s copy of an idle on-broker project into the editor (does not Activate)
`Activate` / `Deactivate`	Load or unload the stored project as the live one — see Standalone vs projects
`Rename`	Rename the local project
`Delete local copy`	Delete the HUB notebooks only
`Remove project from broker`	Permanently delete the project from the broker

Click Project: {name} to open the inspector table (status, type, name, owning project, notebook). A row with empty Project / Notebook is a standalone leftover — see Standalone vs projects. Right-click Broker runtime for operations on the running set:

Context menu on the Broker runtime project in the Coreflux HUB LoT Editor with Adopt into project, Open in LoT Flow, Download all entities to notebook, and Remove all entities from broker in red — The Broker runtime context menu: Adopt into project, Open in LoT Flow, Download all entities to notebook, and Remove all entities from broker

Item	What it does
`Adopt into project`	Write the selected (or all) running entities into a notebook, then Push
`Open in LoT Flow`	Open the live graph of this runtime
`Download all entities to notebook…`	Copy running definitions into a `.lotnb` file
`Remove all entities from broker…`	Undeploy the running set. Internal Rules stay

Version History

Broker projects are git repositories, and the editor exposes enough of that to recover from mistakes without a terminal:

The dialog reports the project’s branch and current commit, lists recent commits with their messages, and shows any uncommitted changes on the broker. From here you can:

Restore a commit — checks that commit out on the broker and reloads the workspace if the project is active
Checkout a branch, tag, or commit — type a ref and check it out
Pull and Push — synchronise with the broker’s configured git remote

Entity changes auto-commit while the project is active. You do not commit by hand — deploying an entity produces a commit like Update connector: BacnetPortoHq, which is why the history reads as a log of deployments.

Restoring a commit can discard uncommitted changes on the broker. Check the Uncommitted changes list in the same dialog before restoring.

Pulling Entities Back Into a Notebook

Deployment is not one-way. Anything running on the broker can be brought back into a notebook, which is how you adopt LoT that was deployed by other means. Right-click an entity type group under Broker runtime:

Context menu on the Models entity type group in the Coreflux HUB LoT Editor Broker runtime showing Download all models to notebook… and Remove all models… in red — The context menu on the Models group offers Download all models to notebook… and a red Remove all models…

Every type group carries its own pair, and the Entities group itself carries Download all to notebook… and Remove all from broker… for the whole set. Right-clicking a single entity offers Open in code editor, Download to notebook…, and Remove from broker…. Any download asks “Choose notebook” — pick an existing .lotnb file in the project, or create a new one — and the definitions arrive as cells you can then edit and redeploy.

Removal: Four Different Operations

Deleting locally and removing from the broker are different operations with different consequences, and the HUB guards them differently on purpose. Read the dialog: it tells you which one you are in.

Trigger	Dialog	What it destroys	Guard
Workspace project → `Delete local copy`	”Delete project?” — local notebooks and folders only	Your local copy only	Plain confirm
Single entity → `Remove from broker…`	”Remove from broker?” — Remove action “SummarizeF2Hvac” from the broker. This cannot be undone.	One running entity	Plain confirm
`Entities` → `Remove all from broker…`	”Remove all from broker?” — Remove 3 action(s), 3 model(s), 1 connector(s), 1 python script(s), 0 theme(s), and 0 panel(s) from the broker. Project-owned rules are also cleared; built-in and operator custom rules are preserved.	Everything loaded on the broker	Plain confirm, but it enumerates live counts — read them
Broker project → `Remove from broker…`	”Remove project from broker” — This permanently deletes BMS* from the broker — all its files and its entire git history. This cannot be undone.*	The project, its files, and every commit	Type-to-confirm — the button stays disabled until you type the project name

Deleting a workspace project does not touch the broker, and removing a project from the broker does not touch your workspace. A local delete leaves every entity running and every commit intact; a broker removal leaves your notebooks on disk but destroys the project’s git history. Neither is a substitute for the other, and only the broker removal is guarded by type-to-confirm.

Coreflux HUB dialog titled Remove project from broker in red, warning that this permanently deletes BMS from the broker including all its files and its entire git history and cannot be undone, with a Type BMS to confirm field and a greyed-out Remove permanently button beside Cancel — The broker project removal dialog: the description spells out that the git history goes too, and Remove permanently stays disabled until the project name is typed into the field

The bulk-remove wording also settles a question the sidebar raises: project-owned rules are cleared, while built-in and operator custom rules are preserved. That is why the Rules count under Broker runtime can be small while Configuration → Internal Rules lists the broker’s locked built-ins separately.

A .lotnb file is the safety net worth having before any removal. Download all to notebook… on the Entities group captures everything currently deployed, and Export open notebook as .lotnb in the header … menu writes it out as a file.

Editing the Same Project From VS Code

The in-HUB editor and VS Code share the same broker-held project and git history: a project pushed from the HUB opens in the VS Code extension and vice versa, and .lotnb files move between them directly:

Import .lotnb on a project, or Import .lotnb file in the header … menu, brings a notebook from outside into that project
Export open notebook as .lotnb takes the open notebook back out
Push to broker and Pull from broker move the whole project, which is how two people using two editors stay on one project

Whichever tool deployed an entity, it appears the same way under Broker runtime and is drawn the same way in LoT Flow.

Next Steps

LoT Flow

See the entities you just deployed as a live dependency graph.

VS Code LoT Notebooks

Edit the same broker-held project from VS Code, then Push and Pull to stay in sync.

Quick Start

Coreflux MQTT Broker

LoT Language

Coreflux HUB

VS Code - LoT Notebooks

Coreflux Portal

Using AI with Coreflux

Product Updates

Why Use the LoT Editor?

When to Use It

Opening the Editor

A Notebook Is Both Document and Deployment