The AetherEdge server provides a read-only API for managing and monitoring an IoT edge gateway, allowing you to inspect, monitor, and diagnose the runtime across the following areas:
Channels & Device I/O: List communication channels, check channel status, view point-to-instance mappings, list points (filtered by type: Telemetry/Status/Command/Analog), view a single point's mapping, and find unmapped points.
Alarms: List active alarms (filtered by channel, level, or keyword), get a specific active alert, list historical alarm events (filtered by rule, level, keyword, or event type), list/get alarm rules, and retrieve aggregate alarm statistics.
Historical Data: Query time-series historical data for a point over a configurable time range, and get the latest historical value for a specific point.
Device Models & Instances: List available product types and device instances (filtered by product type).
Business Rules: List all business/automation rules and get a specific rule by ID.
Network & Uplink: View MQTT uplink configuration, check MQTT connection status, and inspect installed TLS certificate info.
Routing: List all machine-to-cloud (M2C) and cloud-to-machine (C2M) routing entries.
Templates: List channel configuration templates, optionally filtered by protocol.
Note: This interface is intentionally read-only by default. Write access requires explicit, bounded authorization, consistent with AetherEdge's deny-by-default control philosophy.
Product site: aetheriot.ai · Developer site: aetheriot.dev
Documentation: docs.aetheriot.ai · Getting started · User journeys · Connect devices · Protocol adapters · Connect AI · 中文
Connect physical devices, prove the data path, and commission deterministic behavior—without making the cloud, a browser, or an AI model part of the control loop.
AetherEdge is an open-source, industry-neutral IoT edge kernel, six-service runtime, CLI, and Rust SDK for Linux gateways. Shared memory is authoritative for live point state; embedded SQLite stores desired state, history, audit, and a durable outbox. The default distribution needs no Redis, PostgreSQL, cloud service, browser, or LLM.
AI is a replaceable client behind the same typed, governed application boundary as every other client. Device control is deny-by-default, explicitly confirmed, and audited. Already commissioned acquisition, safety, rules, and alarms keep running deterministically when every external client is disconnected.
You want to… | Start with… |
Connect field devices and run local behavior on a Linux gateway | AetherEdge |
Deploy an energy-management solution and operator Console | |
Coordinate an edge fleet or cloud jobs | |
Implement or validate a shared protocol |
AetherEdge's direct users are device manufacturers, system integrators, solution builders, application developers, and edge operators. It deliberately does not pretend to be a finished application for every industry.
Related MCP server: MCP-Edge
The product journey is:
safe-empty install -> operator identity -> disabled device channel
-> physical/logical point mapping -> read-only data proof
-> reviewed behavior -> explicit commissioning -> audit and operationEvery consequential change follows:
inspect -> plan -> validate -> confirm -> apply -> audit -> observe -> reviseCreating configuration never silently enables hardware.
Download the matching .run package and checksum from
GitHub Releases, then verify and
run the fresh-install package on the target Linux host:
sha256sum -c AetherEdge-<arch>-<version>.run.sha256
chmod +x AetherEdge-<arch>-<version>.run
sudo ./AetherEdge-<arch>-<version>.runThe installer creates the six services, aether CLI, private bootstrap
credentials, embedded database, and an empty configuration. It does not add a
device, enable a rule, or install a domain solution.
Start with the local health gate:
aether doctorA healthy first boot has six healthy services and valid SHM. Sign in with the
private bootstrap credential, change that password immediately, create a
dedicated account for normal operation, and export its signed
AETHER_ACCESS_TOKEN. Then prove that nothing was commissioned implicitly:
aether channels list --json
aether models instances list --json
aether rules list --jsonThe channel, instance, and rule collections should all be empty. Getting Started covers the exact bootstrap and token flow.
Choose a protocol included in the installed IO build. A governed create command
requires authentication and confirmation, but the new channel remains disabled
unless --enabled true is explicitly requested:
AETHER_ACCESS_TOKEN='<signed access JWT>' aether channels create \
--name "PLC#1" \
--protocol modbus_tcp \
--params '{"host":"192.168.1.10","port":502}' \
--confirmedBefore enabling it, declare the physical points, map protocol addresses, bind the required points to a logical instance supplied by a Domain Pack, and review unresolved mappings. Follow Connect Devices for that complete workflow and the Protocol Adapter Reference for the exact feature, runtime ID, transport, and mapping matrix.
device -> aether-io -> authoritative SHM -> API and embedded history -> clientVerify channel health, timestamps, quality, freshness, topology generation, historical samples, and unmapped points. A connected socket without fresh data is not a healthy acquisition path, and a missing value is not zero.
Once the mapping is complete, enable the channel with the latest desired-state revision returned by the channel query:
AETHER_ACCESS_TOKEN='<signed access JWT>' aether channels enable <CHANNEL_ID> \
--expected-revision <REVISION> \
--confirmedThe first useful milestone is a read-only data path. Do not add physical commands merely to prove acquisition.
Add logical models, calculations, alarms, and local rules through a downstream Domain Pack or application composition. Draft rules and control paths stay disabled until their inputs, targets, permissions, failure behavior, and audit path have been reviewed.
review disabled behavior -> validate -> confirm -> enable
-> inspect audit evidence -> observe the physical outcomeA successful command acceptance is not proof that the physical device reached the requested state. Observe that outcome separately.
All clients enter through authenticated aether-api:6005:
Client | Use it for |
| Installation, commissioning, diagnostics, and operations |
HTTP/OpenAPI | Dedicated applications and generated clients |
Read-only MCP | AI-assisted inspection and explanation |
Temporary write-enabled MCP | One bounded, explicitly authorized maintenance task |
| A downstream solution or embedded composition |
Downstream Console | A domain-specific operator experience, such as AetherEMS |
The other five process APIs stay on loopback. Clients must not proxy them or write SHM or SQLite directly. AetherEdge ships no universal Web Console; a UI is a replaceable application client, never a second state authority.
To attach an existing runtime to Claude in the default read-only mode:
claude mcp add aether -- aether mcpSet AETHER_ACCESS_TOKEN for the session. Use SSH stdio or an HTTPS ingress for
a remote Edge—never expose an internal service port. See
Connect AI Assistants.
Run the industry-neutral SDK composition or a protocol verification simulator. Neither commissions a physical device:
cargo run -p aether-example-minimal-gateway
cargo run -p simulator -- \
--scenario tools/simulator/scenarios/modbus_protocol_verification.yaml \
--port 5020A source checkout is a developer path, not the normal operator installation flow. See Getting Started.
cargo add aether-edge-sdk --features local-runtimeaether-edge-sdk, imported as aether_sdk, is the supported Rust application
facade. A downstream product combines the SDK, a Domain Pack, and a dedicated
application or agent in its own repository. Domain processors, models, and
Consoles do not become dependencies of the AetherEdge kernel. AetherEMS is the
reference energy-domain implementation of this model.
Process | Responsibility |
| Protocol acquisition and sole telemetry/status writer |
| Instances, rules, and audited control dispatch |
| Alarm evaluation and lifecycle |
| Embedded history and optional history adapters |
| Authenticated remote application API and WebSocket |
| Durable legacy Cloud/MQTT delivery and experimental CloudLink foundation |
Devices -> aether-io -> authoritative SHM
|-> automation and alarms
|-> API and embedded history
`-> durable outbox -> optional cloud
domain <- ports <- application <- runtime/interfaces
^
`---- downstream static Rust adapters (out of tree)AetherEdge currently delivers the integrator-grade runtime, application contracts, governed commands, MCP foundations, Pack v1, and SDK facade. The complete conversational intent compiler, simulation, temporary behavior, and continuous outcome evaluation remain product direction. See the platform status for the exact delivery boundary.
Development setup and verification live in CONTRIBUTING.md. Repository rules for agents and contributors live in AGENTS.md.
Licensed under either MIT or Apache-2.0, at your option.
List active alarms, optionally filtered by channel/level/keyword
Inputs: page, size, level, channel, +1 more.
Get a specific alarm rule by ID
Inputs: id (required).
List alarm rules, optionally filtered by channel/enabled/level/keyword
Inputs: page, size, level, channel, +2 more.
Get aggregate alarm statistics
Inputs: no named parameters.
Show a channel's point-to-instance mappings
Inputs: channel_id (required).
List points on a channel, optionally filtered by type (T/S/C/A)
Inputs: channel_id (required), point_type.
Show the instance mapping for a single point
Inputs: point_id (required), channel_id (required), point_type (required).
Get the connection status of a specific channel
Inputs: channel_id (required).
List points on a channel that have no protocol address mapping (points not wired to a device register; instance routing is a separate concern)
Inputs: channel_id (required).
Get the latest historical value for a point
Inputs: point_id (required), series_key (required).
List device instances, optionally filtered by product type
Inputs: product.
List available product types
Inputs: no named parameters.
List all M2C/C2M routing entries
Inputs: no named parameters.
Get a specific business rule by ID
Inputs: rule_id (required).
List all business rules
Inputs: no named parameters.
List channel configuration templates, optionally filtered by protocol
Inputs: protocol.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 16 tools
Most tools are clearly separated by resource and granularity: alarms vs. rules, list vs. get, and channel-level vs. point-level mappings. The only mild risk is between channels_mappings, channels_points_mapping, and channels_unmapped_points, but their descriptions clarify the difference.
The naming generally follows a resource-first snake_case pattern with list/get/stats/status suffixes, which is predictable. Minor inconsistencies exist, such as history_latest not using a verb and alarm rules using alarms_rules vs. business rules using rules.
At 16 tools, the set is slightly over the ideal 3-15 range but still reasonable given the broad domain covering alarms, channels, rules, history, models, routing, and templates. Each tool has a distinct place in the overall surface.
The entire tool surface is read-only: there are no create, update, delete, acknowledge, map, or route configuration operations. This creates significant dead ends, such as listing unmapped points with no way to map them, or viewing alarm rules with no way to modify them.
Protocol-native energy infrastructure orchestration for AI data centers. Provides 46 MCP tools across 8 grid protocols (IEC-61850, DNP3, Modbus, OCPP, OpenADR, IEEE 2030.5, IEC 60870-5-104, ICCP) with 5 core API primitives: connect, dispatch, settle, comply, and intel. Enables AI agents to programmatically interact with substations, grid interfaces, and energy assets for real-time workload-grid coordination.
MCP server for your apps' tools and custom tools, plus hosted AI agents and approval-gated workflows
Context and control for any AI. Agent identity, scoped access, and proof across tools.
Zero-setup MCP gateway securely connecting AI to your tools with authentication and workflows
