Our own IoT,
from cloud to valve.

Open any zone’s pH chart full size

Click a pH chart on the Zones page and it opens full size, as the moisture curve does. The larger view has a time window of its own and breaks the readings down by node.

• Full size, on click. Click a zone’s pH chart, or its expand link, or press Enter on it, to see it at full size. The scale is marked every half pH, and a legend says what each line is.
• Its own window. Change the period in the larger view without changing the page behind it.
• By node. A table lists each node’s readings, mean, spread and range, in order of pH. Hover or tap a node and its readings stand out on the chart, so you can see which node makes which peak. The orchard-wide view does the same by zone.

Nothing changes in the readings or the figures. This is a closer look at them.

pH on every zone, as a bell curve

The Zones page now shows each zone’s soil pH as a distribution: every reading from every pH probe in the zone, in the colours of a pH test strip, under the normal curve for the period. Set the range you aim for and see how much of the zone sits inside it. A new orchard-wide box puts the zones together.

• A bell curve per zone. The actual readings as bars, each in the colour a pH strip turns at that pH, under the normal curve for the period with its mean and ±2σ marked. Its shape shows whether a zone is steady, drifting or split between probes.
• The figures beside it. The mean, the standard deviation, the range of mean ± 2σ, and the share of readings inside that range (a normal curve holds 95.4%).
• Your target range. Mark the pH range you aim for, for one zone or the whole orchard. The chart shades it and shows the share of readings inside it. A zone without a range of its own uses the orchard’s.
• Any window. From one day up to as many as you like, or Max for every reading on record. One control sets every chart, so the orchard figures always match the zones on screen.
• Orchard-wide. A new box averages the zones, each zone counting the same however many nodes it has.
• Only real readings. A reading below pH 3 or above 10, which is what a probe out of the soil reports, is counted and left out. A node that moved counts in the zone it was in when it took each reading.

Nothing changes on the controller or in the irrigation recommendations. This is a new way to read the readings already there.

Bring your own relay board, free

Anyone who signs in with Google can now control their own pumps and valves from the dashboard, free. Buy a supported ESP32-S3 relay board, plug it into your computer, and the dashboard flashes it, puts it on your Wi-Fi and adds it to your account. And the controller firmware learns to get itself back online without anyone pulling the plug.

• Commission an IoT relay. The same USB-C flow we use for our sensor nodes: hold BOOT, plug in, click. Then click each relay to hear which is which, name it, give it a zone, and mark the pump.
• Two boards to start. The Waveshare ESP32-S3-Relay-6CH, and the SmartElex Industrial 6-Channel ESP32-S3 WiFi Relay Module (the same board under another name): six relays, 10 A at 250 V AC, powered from 7–36 V DC.
• The same controls as our orchard. Turn on for a set time, daily schedules to the second, a run log you can download, and the pump rule: a pump never runs with every valve shut.
• Yours alone. Each account gets its own hub. A board signs in with its own key, made at commissioning; nobody else's dashboard can see or switch it, and removing it signs it out.
• Your time zone. Schedules run in your farm's local time, set from your computer when you commission and changeable from the page.
• Firmware 2.1.0: back online on its own. A board that stayed on Wi-Fi but couldn't reach us used to wait for a power cycle. Now it rejoins Wi-Fi after three minutes and restarts after fifteen (never while something is running). Each board reports its Wi-Fi drops and why, so a flaky connection shows on its card.
• Updates without PSRAM. Over-the-air updates now stream straight to flash, so boards without extra memory update too, with every safety check still made before the new firmware can start.

For our own orchard nothing changes but the firmware: the schedules, the safety rules and the AI approvals are as they were. You buy and own the hardware; the firmware and the dashboard are free.

Uptake for every tree, and a demo that says what’s real

The Uptake Index now covers every tree with a sensor node, not just the two oldest. And the demo orchard says up front that its controls are real and its money is not, with terms and a privacy policy written for listing in MCP directories.

• Uptake Index for every tree. Nodes commissioned since v74 report to a newer data store that the index never read, so only the two oldest trees ever had a score. Each tree’s index now draws on every node that has been on it, counting each reading on the tree the node was on when it was taken.
• Each reading in the right window. Readings near midnight could be counted with the wrong day’s window. They now count with their own, so some scores will move a little.
• The LIVE light counts every node. The Overview’s indicator now includes the newer nodes; it could read offline while they were reporting.
• A demo, plainly labelled. The demo orchard and its MCP server now say first that the pump, valves, schedules, interlock and Approve step are production code, and only the orchard around them is simulated.
• Money in S$. Demo prices are in S$ (Sankhya dollars), a made-up game currency: not Singapore dollars or any real money.
• Ready for MCP directories. Terms for the demo and the MCP server (Section 9 of our Terms), a privacy policy that covers them, questions and troubleshooting on the MCP page, and new share images.
• Tighter public views. The dashboard’s public demo login shows stock and use but not costs, suppliers, invoices or attached files, and photos are served without any location a camera stored in them.
• Fixes. “+ Add entry” on the Orchard Log opens its form again, and the Pumps page no longer stalls when a pump timer has run out.

Nothing changes on the controller: the safety rules and the schedules are as they were.

Irrigation to the second, and Accept all

Pumps and valves can now be scheduled to switch on and off on any second of the day, not only on the minute. And when the AI audit leaves several proposals, they are all on one screen, to approve one by one or all at once.

• Start times to the second. A schedule can open a valve at 18:02:30 and close it at 18:05:05. In an irrigation sequence with one pump start, each zone can get exactly the time it needs (two and a half minutes, say) instead of being rounded to whole minutes.
• No firmware update needed. Our hub has run the schedules since v109 and tells the controller how long each output stays on, so the boards already in the field get this as they are.
• Every proposal on one screen. The Pumps & Valves page lists everything the audit has left for a decision, each with what it would change on the controller, worked out from exactly what would be applied. Approve or reject each one, or accept them all.
• Accept all, with care. It applies only the proposals on the screen, in the order they were made, and each one once, even if the button is pressed twice. If one can’t be applied it says why, and the rest still go ahead. A newer proposal for the same schedule replaces the older one.

The safety rules are unchanged: the pump still can’t run against shut valves, and a schedule still changes only when a person approves it.

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.