Our own IoT,
from cloud to valve.

Play the orchard, then hand it to your AI

A farm game in the browser, built on the real thing: every demo farm runs the production code of our irrigation hub, with a virtual controller board in its pump house. Pick a crop, take it through a season, and connect your own AI to the same farm.

• Any tree crop. Fruit, berries, nuts or timber, in one of four climates. Start with a bearing block for a season from bloom to harvest, or plant saplings and skip ahead a year at a time. Field crops aren’t offered: Sankhya works plant by plant.
• Everything we do, as gameplay. Morning irrigation chains with one pump start; soil sensors that report hourly and move between trees; fertiliser ordered, delivered, carried to the tank by a farmhand and mixed; a picking crew in the harvest window; a report card at the end of the season.
• The same safety rules. The pump won’t run against shut valves, in the game as on our farm, and a schedule change your AI proposes waits for your Approve click, right in the game.
• A page for the MCP server, with the safety pattern beneath it, every tool the demo exposes, how to connect Claude, Claude Code, ChatGPT and other clients, and the demo’s privacy notice.

Play the demo orchard · About the MCP server

A demo server that runs the real controller

A public MCP server for anyone’s AI, with a simulated orchard behind every sign-in. It isn’t a mock: the tools, the pump interlock and the approval step are our production code.

• Any MCP client. Claude, ChatGPT, Claude Code, Cursor and others connect at one address. A one-click connect page starts a new farm, picks the one you’re playing, or opens a farm by its code.
• The production code inside. Each farm runs our irrigation hub and a virtual board that speaks our firmware’s protocol, so a pump run your AI asks for meets the same checks — and the same four-minute cap — as on our orchard.
• 25 tools, each labelled. Every tool says whether it only reads, changes the farm, or can’t be undone, so your client can ask before it acts.
• Kept apart. The demo runs on its own servers, with no connection to our orchard’s hub, databases or files. A farm is deleted after 14 days without a visit.

Release notes in the open

This page: what we ship, release by release, starting with the last release before our own IoT — and the story of how irrigation control moved from third-party switches to a controller and hub of our own.

One pump start per irrigation run

The pump now stays on through a whole irrigation sequence while the valves hand the flow from one zone to the next — so the motor starts once, not once per zone. Every start is an inrush at the contactor; fewer starts are kinder to the pump and the supply.

• One rule, stated plainly: the pump may never run while every valve is shut. If the last open valve closes, the pump stops with it, and the run log says so — so a scheduling mistake shows up instead of hiding.
• The rule holds on the board too. The controller is always given a pump deadline no later than the last valve it knows about, so if the connection drops mid-sequence the board stops the pump on its own.
• Edit the record. Orchard journal entries and fertiliser stock movements can be corrected or deleted, under the same rules whether a person does it on the dashboard or Claude does it through MCP.
• Files on records. Photos, scans and PDFs can be attached to journal entries, products, stock movements and invoices, and open in a viewer on the page. Claude can attach files too, or make a one-time upload link to open on a phone.

Replaces v111’s timing rule, which ended the pump early when a sequence moved on to its next valve.

Sensor readings that survive outages

Node firmware 4.5 writes every reading to flash before it tries to send it, and uploads the backlog when the connection comes back. A Wi-Fi drop or a dead router no longer means a gap in a tree’s history.

• Store and forward. A node holds roughly four months of readings and sends them oldest first, in batches, once it’s online.
• Dated when taken, not when received. Each buffered reading carries the node’s own clock, corrected against known time points, so a reading that arrives a day late still lands at the hour it was measured — on the tree the node was on at the time.
• Stored once. A reading sent twice, because a reply was lost, is recognised and kept once.

The MCP server on its own address

A follow-up to v111: the MCP server moved to an address of its own on our domain, and its tools were exercised end to end against the real hub code.

• Only Claude can connect, and every connection needs the orchard operator’s approval on a sign-in page that shows which app is asking and where the access will go.
• Sign-ins lapse after 30 days unused and 90 days at most, and can all be revoked at once.
• One set of rules for proposals. An AI proposal is checked with exactly the same function as one entered on the dashboard, so nothing can be queued that the Approve button couldn’t apply.

Pump interlock, AI approvals, fertiliser ledger and MCP

Four changes that only make sense because the controller and the hub are ours.

• The pump interlock. One output is marked as the pump, and it won’t run unless a zone valve is open — whoever asks: the dashboard, a schedule or an AI. A centrifugal pump pushing against closed valves has no flow to carry its heat away and can wreck its seal within minutes. The rule lives in the hub, beneath every caller.
• Approve AI recommendation. A scheduled AI audit never changes a schedule itself. It leaves a proposal with its reasoning and evidence, and the change reaches the orchard only when a person clicks Approve. A newer proposal replaces an older one, so a stale number is never applied.
• The fertiliser ledger. Stock by product and by nutrient (N-P-K), always computed from deliveries and applications rather than a number someone types in, so it can’t drift from its own history. Dry products are measured in g/kg and liquids in ml/L, never converted into each other. Invoices are uploaded as scans and stay drafts until a person confirms the figures.
• Our MCP server. A Model Context Protocol server gives Claude read access to the devices, the run log, soil readings, the journal and stock — and limited write access. There is no tool that changes a schedule, and a pump run that no person asked for is capped at four minutes, in code.

Firmware updates over the air

Sankhya IoT firmware 2.0.0 updates itself. Flash it over USB once; after that, new versions arrive over the air — with the care an irrigation controller needs.

• Weekly, or on request. The board checks for a new version once a week, and an admin can ask it to check now from the dashboard.
• Never while irrigating. With any output on, the update waits. A run that comes due during the two-minute install waits too, then runs for the time left.
• On trial until proven. A new version must reach the hub within 15 minutes of starting. If it doesn’t, or crashes before then, the board goes back to the version it had and skips the bad one.
• Checked before it’s written. An image built for a different board or a different setup is refused, and the board says why.

The hub runs the schedules

Scheduling moved from the board into the hub, and every run became a record you can line up against the soil.

• Named outputs and daily schedules. Each controller has its outputs — the pump, a valve per zone — and any number of daily schedules, run by the hub. Turn an output on for a set time, or off, from the dashboard.
• Several outputs at once, each with its own deadline. Firmware 1.1.0 keeps a timer per output, so a run still ends on time if the connection drops halfway.
• Every run is logged — planned and actual times, and how it ended: completed, stopped, missed or interrupted — beside the soil readings for the same zone and time, so irrigation can be read against moisture, EC and pH.
• Restarts are recorded honestly. A board that restarts mid-run is recognised, the run is recorded as interrupted with the best estimate of when water stopped, and it isn’t silently resumed.

Sankhya IoT: our own controller and hub

The release that changed the architecture. Pumps and valves can now be switched by an ESP32-S3 board running our own firmware, connected straight to our own hub — no gateway computer and no third-party protocol in between.

• A live connection. The board opens an encrypted WebSocket to the hub, a Cloudflare Durable Object, and keeps it open with a heartbeat every 20 seconds.
• Live status on the dashboard. Each board shows as online or offline within about a minute, with its signal strength and what it’s doing.
• Side by side with Tuya. Sankhya IoT boards appear on the same Pumps & Valves page as the existing Tuya devices, which keep working.

QR labels and scan-to-bind

The last release before our own IoT, and a field-work one: sensor nodes and trees get printed labels, and binding a node to a tree takes a phone.

• Print labels for nodes and trees from the dashboard, laid out for any label sheet, as a PDF built in the browser.
• Scan to bind. In the field, scan a tree’s label and a node’s label, take a photo, and the node is bound to that tree from that minute — so each tree keeps its own soil history as nodes move around the orchard.