Model the whole project
Devices, variables, bindings, programs, operator views, history and deployment evidence stay in one engineering model.
Building systems,engineeredend to end.
Model, review and deploy building automation in one workspace. Keep execution local with Site Runtime.
Ask project
1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
def execute(inputs):
supply = float(inputs["supply_temp"
])
setpoint = float(inputs["setpoint"
])
demand = max(0.0, setpoint - supply)
return {"heating_demand": demand} Interactive demoProject savedRevision r18 · typed model
Agents at work 197
One platform for the complete automation workflow.
Build the project as connected engineering objects, review every change and carry the same model from simulation to site operation.
Work with an agent. Approve every change.
The project agent prepares an inspectable proposal. An engineer approves mutations before they reach a revision or Runtime.
Bind signals with context
Type, unit, quality and physical source remain visible through every connection.
Build logic your way
Graphical blocks and restricted Python work against the same object and signal model.
Publish operator views
Approved graphics, 3D scenes, alarms and history reach only the intended operators.
Carry one revision from Studio to site
Review and sign the project once, then activate it as a complete unit on the site-local Runtime.
Trace every value from field source to physical response.
Source, quality, unit, transformation and device readback remain attached to one trace. A fallback never pretends to be physical feedback.
Engineer in the cloud. Execute on site.
Studio delivers a reviewed, signed revision. Site Runtime validates and activates it as one unit, then keeps the building loop on the local network.
- Controlled deploymentMutations and releases stay behind explicit approval.
- Local continuityPolling, logic, schedules, alarms and history continue without cloud access.
- Focused operationWeb Station exposes only the views and commands published for operators.
What engineers usually ask first.
The current product boundary, stated without hiding what is implemented and what still needs site-level proof.
01What can I build in Nodectra today?
You can model an automation project, bind typed signals, create block or restricted-Python programs, configure Modbus TCP and RTU points, build operator graphics and 3D scenes, record history, define alarms and deploy a signed bundle to Site Runtime.
02Does the agent make changes on its own?
No. The project agent works inside a bounded project context and prepares an inspectable proposal. A person reviews and approves mutations before they become part of a revision or reach a Runtime.
03What happens when the cloud connection is unavailable?
Site Runtime is a separate, always-on local service. Approved control logic, polling, schedules, alarms and local history continue at the site; the cloud Studio remains the engineering and approval environment.
04Can I commission a project before connecting hardware?
Yes. Commissioning bundles may include Sensor Simulators for functional acceptance. Production bundles reject simulators, so a simulated source cannot silently ship as a physical control signal.
05Which field protocols execute today?
Modbus TCP and Modbus RTU are the executable protocol paths today. The logical project and signal model is independent of one controller vendor, while additional adapters remain explicit implementation work.
06Is this already a finished production control product?
Nodectra is currently an engineering and commissioning preview. The software flow is substantial, but production use still requires target-site validation, deployment operations and native hardware acceptance for the intended installation.
Build the project once. Keep control from Studio to site.
Start with simulation, review every change and move to site hardware without rebuilding the engineering model.