Skip to content

About

AoT puts your space on a map and links the records and devices that belong to it. It then lets AI look at that space together with people, make judgments, and get work done.

It is an open-source system for monitoring an environment with sensors and controlling devices remotely, not tied to any particular purpose or kind of site.

It runs natively on single-board computers such as the Raspberry Pi, and in Docker on ordinary servers and PCs.

What it offers:

  • a proven Input / Output / Function control model, inherited from the Mycodo project AoT started out from (see Origins);
  • a GIS map — devices, sensors, and structures can be placed at their real positions and viewed and operated from there;
  • an AI layer built on MCP (Model Context Protocol) — an assistant that can read the system, diagnose it, and act on it, with your approval for anything that moves hardware.

Which of these you use is up to you.

GIS — Map, Facility, and Information~

The map widget holds devices, sensors, structures, and areas at their real positions. Whether to use it is up to you; a setup without the map works the same way.

  • Spatial hierarchy — sites, zones, facilities, and planting areas form a real hierarchy, so a question like "what is happening in the east house" has a definite answer.
  • Facilities in 3D — facility outlines are defined as polygons and visualized in 3D; vents, curtains, and other components are bound to the geometry and controlled from there.
  • GIS data sources — weather, satellite, and soil layers are registered as Inputs, so external map data flows into the same time-series database as your sensors.
  • Devices on the map — sensor Inputs and Output devices (valves, relays, curtains, vents) are placed on the map and operated directly from the map or facility view.
  • Geometry drives control — facility-level environmental control uses the geometry itself: opening area, azimuth, and wind direction coordinate several actuators as a single feedback loop (for example, differential venting by wind side).

AI and MCP~

AoT exposes its whole system — devices, measurements, spatial tree, functions, schedules, notes — as MCP tools. Two paths use the same tool registry, so they never drift apart:

  • In-app assistant — the chat assistant on the dashboard. A single agent loop sees the full tool catalog and chooses tools itself.
  • External MCP server — aot/aot_mcp_server.py speaks standard MCP over stdio or HTTP, so an external client such as Claude Desktop can call AoT tools directly.

What the AI can do:

  • Observe and diagnose — read sensor history, summarize zone conditions, spot anomalies, and answer questions grounded in your own facility data rather than generic advice.
  • Operate — switch Outputs, schedule device control, and adjust setpoints. Every state-changing action passes an approval gate before it is applied: an approval card in the chat, or a pending queue for external MCP clients.
  • Build — create and edit Inputs, Outputs, Functions, GIS shapes, and plantings on request.

Model choice is yours: Claude, Gemini, GPT, Mistral, Groq, and local Ollama models are all supported. AoT does not require, bundle, or default to any single provider.

Control Model: Inputs, Outputs, and Functions~

Everything above rests on three controller types:

  • Input — acquires measurements and stores them in the InfluxDB time-series database. Measurements usually come from sensors, but can also be the return value of a Linux Bash / Python command, a math equation, or a GIS data source.
  • Output — produces a change: switching GPIO pins (HIGH/LOW), generating PWM signals, driving pumps, publishing to MQTT, running commands, and more.
  • Function — combines Inputs and Outputs into higher-level behavior: PID feedback loops, sequences, timers, conditionals, and Methods (a setpoint that changes over time).

A wide catalog of sensors, relays, and controllers is supported out of the box — see Supported Inputs and Supported Outputs.

Connectivity~

  • LoRaWAN — ChirpStack integration with a site-level Class A/C scheduler and downlink pacing for reliable valve commands.
  • Modbus TCP, MQTT, HTTP — network-attached devices work identically in the direct and Docker installations.
  • GPIO, I2C, 1-Wire — available in the direct install on Raspberry Pi pins.

User Interface~

  • Tab system — Input, Output, Function, and dashboard pages are organized into tabs, so large device lists and multi-screen dashboards stay manageable.
  • Custom colors and styles — brand colors, chart palettes, and light/dark themes are user-configurable and applied consistently across widgets and pages.

Runs on Raspberry Pi and Docker~

AoT can be installed natively on Raspberry Pi OS or Debian, or run in Docker on other platforms — the same application, whichever deployment fits your hardware.

Origins~

AoT began as a customized build of the open-source Mycodo project by Kyle T. Gabriel, which pairs sensor Inputs with device Outputs to sense and regulate an environment through a text- and graph-centered interface.

AoT kept that control model and rebuilt everything around it: a GIS digital twin in place of the device-list interface, an MCP-based AI layer, facility-scale environmental control, LoRaWAN device management, and a redesigned UI. Mycodo remains the foundation of the Input / Output / Function layer, and its contribution is gratefully acknowledged.