--- title: "STS — Smart Transfer Switch" headline: "STS Smart Transfer Switch — Ali Ahmed, Head of Product & Platforms, BijliBachao.pk" description: "Ali Ahmed built STS: a control plane that switches a building between solar and the grid, confirms every switch from the device’s own sensors, and enforces safety in hardware." canonical_url: https://alioahmed.com/work/sts type: case-study role: "Head of Product & Platforms, BijliBachao.pk" date_label: "2026 – present" status: live date_modified: 2026-08-25 author: name: "Ali Ahmed" url: https://alioahmed.com/ orcid: https://orcid.org/0009-0007-4265-3295 key_figures: - "Confirmed switches verified by sensor, not by command" - "Reconciled devices recovered to desired state after an outage" - "Deferred manual override holds until the next transition" - "Interlocked single-source enforced in hardware (Industrial)" entities: - name: "STS — Smart Transfer Switch" type: SoftwareApplication - name: "BijliBachao.pk" type: Organization url: https://www.bijlibachao.pk/ same_as: - https://bijlibachao.pk/#organization - name: "STS control-plane rules" type: DefinedTermSet - name: "UL 1008 — Transfer Switch Equipment" type: DefinedTerm url: https://standardscatalog.ul.com/standards/en/standard_1008_8 - name: "IEC 60947-6-1 — Transfer Switching Equipment (ATSE)" type: DefinedTerm url: https://webstore.iec.ch/publication/63739 - name: "MQTT — ISO/IEC 20922" type: DefinedTerm url: https://www.iso.org/standard/69466.html same_as: - https://www.wikidata.org/wiki/Q10322548 - https://en.wikipedia.org/wiki/MQTT - name: "Next.js" type: SoftwareApplication url: https://nextjs.org/ same_as: - https://www.wikidata.org/wiki/Q56062435 - https://en.wikipedia.org/wiki/Next.js - name: "Amazon Web Services" type: Organization url: https://aws.amazon.com/ same_as: - https://www.wikidata.org/wiki/Q456157 - https://en.wikipedia.org/wiki/Amazon_Web_Services - name: "UN Sustainable Development Goal 7: Affordable and Clean Energy" type: DefinedTerm url: https://sdgs.un.org/goals/goal7 same_as: - http://metadata.un.org/sdg/7 - name: "UN Sustainable Development Goal 9: Industry, Innovation and Infrastructure" type: DefinedTerm url: https://sdgs.un.org/goals/goal9 same_as: - http://metadata.un.org/sdg/9 person_same_as: - https://www.linkedin.com/in/alioahmed/ - https://github.com/alioahmed - https://orcid.org/0009-0007-4265-3295 - https://x.com/Alioahmed_ - https://about.me/alioahmed - https://dev.to/alioahmed - https://medium.com/@alioahmed - https://hashnode.com/@alioahmed - https://substack.com/@alioahmed - https://huggingface.co/alioahmed - https://bsky.app/profile/alioahmed.bsky.social - https://mastodon.social/@alioahmed - https://www.kaggle.com/alioahmed - https://www.producthunt.com/@alioahmed - https://www.patreon.com/cw/alioahmed - https://www.goodreads.com/user/show/202106301-ali-ahmed - https://fueler.io/alioahmed - https://gitlab.com/alioahmed - https://linktr.ee/alioahmed - https://topmate.io/alioahmed related: - https://alioahmed.com/work/wattey - https://alioahmed.com/work/solar-performance-cloud - https://alioahmed.com/work/bijli-bachao full_corpus: https://alioahmed.com/llms-full.txt site_index: https://alioahmed.com/llms.txt --- # STS — Smart Transfer Switch > STS is a smart transfer switch platform built by Ali Ahmed, in the Wattey family at BijliBachao.pk. It moves a building between its solar supply and the WAPDA grid by phone, on a schedule, or automatically. What distinguishes it is what happens after the command: a switch is reported complete only once the device reads the new source back from its own sensors; a device that was offline is reconciled to the state the schedule says it should be in now; a manual override takes defined precedence until the next scheduled transition; and on the industrial unit, single-source operation is enforced by a hardware interlock rather than by software. **Canonical URL:** https://alioahmed.com/work/sts **Role:** Head of Product & Platforms, BijliBachao.pk — 2026 – present **Summary:** Ali Ahmed built STS: a control plane that switches a building between solar and the grid, confirms every switch from the device’s own sensors, and enforces safety in hardware. ## Key figures - **Confirmed** — switches verified by sensor, not by command - **Reconciled** — devices recovered to desired state after an outage - **Deferred** — manual override holds until the next transition - **Interlocked** — single-source enforced in hardware (Industrial) ### Sending the command is not the same as switching. A Pakistani building runs on two supplies: its own solar system, and the WAPDA grid. Somebody usually decides between them by walking to a panel and pulling a changeover lever — which means it gets forgotten, it gets done at the wrong time, and nobody who is not standing in front of the panel knows what the building is actually running on. STS puts that changeover under software: a controller fits onto the existing changeover hardware, and from then on the source can be switched from a phone, set to change on a daily schedule, or left to run itself. That much is a remote switch, and a remote switch is not a hard thing to build. The part that took judgement is everything after the tap. A relay can be commanded and still not move. A device can be offline at exactly the moment it was supposed to switch. A person can override the schedule for a reason the system knows nothing about. And on an industrial site, getting it wrong badly enough to bridge two live supplies is not a bug report — it is a fault on someone’s premises. ### Confirmation comes from the sensor, not from the command. The obvious behaviour is to report success when the command is accepted. It is what a plain remote switch does, it demonstrates identically, and it passes every test anyone would think to write. It is also reporting an intention as a fact. A contactor can stick. A message can be dropped. A device can reboot between receiving a command and acting on it. STS therefore holds the operation open until the device reads its own sensors back and reports which source is live, and only then calls the switch done. Success means measured — and when a switch does not take, the user is told rather than left to discover it later. ### A schedule is a state, not an event. Load-shedding and connectivity gaps are the normal case in this environment, not the exception. A scheduler that fires only at the instant of a transition will strand any device that happened to be offline at that moment on the wrong supply for the rest of the day — and nobody finds out until a bill arrives or the building goes dark. So the schedule in STS describes what source a site should be on at a given time, rather than an event that happens once and is lost if missed. When a device comes back, the platform asks what it should be on right now and moves it there, including through a transition it slept through. The same principle governs manual changes. Somebody who switches by hand has a reason — maintenance, a fault, a load the system does not know about — and automation that immediately reverts them is worse than no automation, because then neither the person nor the schedule can be trusted. A manual change therefore takes precedence and holds it until the next scheduled transition, when the schedule resumes. Precedence between human intent and automation is defined, rather than decided by whichever wrote last. ### The rule that must never break is not enforced in the code. On the industrial transfer switch, solar and the grid must never be live at the same time. That constraint is not a validation check, a guard clause, or a state the scheduler is careful to avoid. It is a latching interlock in the equipment itself, so no command, no schedule, no race between two operators and no defect in the software can reach it. This is the decision the chapter exists to show. Writing the check in software is faster, demonstrates identically, and passes every test you would think to write. Choosing to put it where software cannot reach it means accepting in advance that your own system will eventually be wrong, and building for the day that it is. The interlock is a property of the STS Industrial unit. The other two members of the family are a four-circuit controller and a single changeover switch, and neither is claimed to have it. ### One control plane, three shapes of hardware. The STS Controller switches up to four circuits independently, each one schedulable, with a cap on how many may run at once — for sites that want per-circuit control rather than one building-wide changeover. The STS Transfer Switch is a dedicated Solar/WAPDA changeover with its own sensor confirming which supply is live. STS Industrial is the latching, interlocked unit built for plants. Underneath, the devices run on Dingtian DT-R industrial relay controllers — the class of hardware used in commercial automation, not a prototyping board — and talk to the platform over MQTT. The application is a Next.js progressive web app hosted on AWS, installed to Android and iPhone straight from the browser rather than through an app store. That last one is a release-path decision as much as a platform one: a fix reaches every phone the moment it is deployed, with no review queue standing between a fault and its remedy. Each device is claimed at commissioning with a single-use code and bound to its owner, so nobody controls a device that is not theirs. One owner can hold many devices; one operator can manage many customers’ sites; and every switch, schedule run and configuration change is attributed and timestamped. ### Four shapes of the same problem. - The home that never wastes daylight — solar from morning, grid from sunset, set once and running every day since, untouched for months. - The shop owner already home for the weekend — realises the shop is still on solar as the sun sets, opens the app, taps WAPDA, watches it confirm, never gets up. - The plant that must never bridge — solar through the working day, grid overnight, automatically, and no tap, schedule or mistake can ever make the two supplies live together. - The installer managing forty sites — one dashboard showing which devices are online, which switched today, which need attention, with no site visit required. ### Built to the standards that govern this class of device. STS is transfer-switch equipment, and that category has a standards home. The physical device is designed to the intent of UL 1008, the safety standard for transfer switch equipment, and its single-source behaviour is aligned to the ATSE model of IEC 60947-6-1 — the international standard for automatic transfer switching equipment, which by definition connects the load to one source at a time. The telemetry runs on MQTT, an OASIS and ISO/IEC 20922 standard, rather than a private protocol. The safety objective the interlock serves is the one the industry codifies in anti-islanding standards such as IEEE 1547: a local source must never back-feed a grid it should not. STS meets that objective structurally — a physical break-before-make interlock makes two live sources impossible — rather than through inverter islanding detection. The distinction matters: back-feed is a documented, sometimes fatal hazard to line workers, and a rule that serious belongs in the equipment, not in a software check. STS is aligned to these standards; no unit is certified or Listed, and the page claims neither. ### The problem is bigger than one country. The manual solar-to-grid changeover is not a Pakistani quirk — it is what happens anywhere a rooftop-solar boom meets an unreliable grid. Pakistan is the proving ground: net-metering capacity rose from roughly 4 GW in 2024 to 5.3 GW by April 2025, and the country was one of the world’s largest solar-panel importers in 2024, at around 17 GW (Ember; Renewables First). Most of those installations are behind the meter, on homes and small businesses that switch between solar and the grid by hand, during load-shedding that runs from two to eight hours a day. The category STS sits in — the automatic transfer switch — is roughly a $0.9–1.8 billion market growing at 5–10% a year into the early 2030s (Allied Market Research, GMInsights, Technavio). That is the automatic transfer switch, an electromechanical device; it should not be confused with the solid-state static transfer switch of the same acronym, a different data-centre product. The same conditions that make the problem acute in Pakistan recur across the emerging world: Nigeria, where the grid collapsed roughly eight times in 2024 and about 40% of electricity is drawn from backup generators; Lebanon, where the state grid gave about four hours a day in 2024 and rooftop solar rose more than tenfold; and India, which installed 7.1 GW of rooftop solar in 2025. These are destinations to evaluate, not places STS operates. ### Strip out the supplies, and the skill is not electricity. STS is a control plane for a physical actuator that cannot be observed directly, over a network that cannot be relied on, alongside a human who can overrule it, with one invariant important enough to be enforced below the software. Electricity is the domain detail; the four properties are the engineering, and they are not specific to a solar switch. That exact shape recurs in robotics and fleet control, industrial process automation, IoT device management, EV-charging and load control, and any orchestration system that reconciles a declared desired state against a messy real one. The judgement that transfers is knowing which guarantees have to be physical — which is why STS belongs on a page about Ali, and why a team building device control of any kind is reading about their own problem. ### What this chapter does not claim. It states no device count, no install base and no uptime figure, because the source material contains none and estimating one would be the only dishonest thing on the page. It names no customer — the product brief instructs that twice, and the four situations described on the page are archetypes written by the BijliBachao team rather than accounts of identified sites. It states no price, no lead time and no installation duration. It does not claim the hardware interlock for any device other than the industrial unit. And it makes no reliability claim about the hardware beyond naming the class of controller it runs on. ## FAQ ### What did Ali Ahmed actually build in STS? The control plane and the product around it: the device model and claim-by-code ownership, the confirmation protocol that reads a source back from the hardware before calling a switch done, the desired-state scheduler and its reconciliation behaviour, the precedence rules between manual and automatic control, and the installable web application. He leads it as Head of Product & Platforms at BijliBachao.pk, in the Wattey product family. ### What is the hardest problem in a system like this? That you cannot see the thing you are controlling. Every other difficulty follows from it: you cannot trust that a command was executed, you cannot assume a device was awake when you needed it, and you cannot tell whether a state you did not expect came from a fault or from a person. The three rules on this page — confirm from the sensor, reconcile to desired state, give manual intent defined precedence — are each an answer to one of those. ### Why put the safety rule in hardware instead of in the software? Because the software can be wrong, and this particular rule cannot be. Bridging two live supplies is a fault on a customer’s premises, not a defect to fix in the next release. A software check is faster to build and demonstrates identically, so choosing the interlock means deciding up front that your own system will eventually fail and designing for that day. It is the clearest example on this page of a judgement call rather than an implementation detail. ### Why does this page have no numbers on it? Because the source material has none. The product brief this chapter is built from states no device count, no install base and no uptime figure, and no customer is named anywhere in it. Rather than estimate a figure to make the page look substantial, the chapter argues from the engineering — which is the stronger case for this product regardless. If a verified fleet figure arrives it will be added with a date attached. ### What standards is STS built to? STS is transfer-switch equipment, so it has a real standards home. The device is designed to the intent of UL 1008 (the safety standard for transfer switch equipment), and its single-source behaviour is aligned to the ATSE model of IEC 60947-6-1, which connects the load to one source at a time. The telemetry runs on MQTT, an ISO/IEC 20922 standard. The interlock serves the same objective as anti-islanding standards like IEEE 1547 — a local source must never back-feed the grid — but meets it structurally, through a physical break-before-make interlock. STS is aligned to these standards; it is not certified or Listed to them, and the page says so plainly. ### Why does automatic solar-to-grid switching matter at all? Because a building on rooftop solar has two supplies and can only safely use one at a time, and the decision is made all day, every day. Switch late and you burn expensive grid power while the sun is up; forget to switch back and you leave a dead load on solar at night; get it wrong badly enough to bridge both and you have a back-feed hazard. Pakistan added roughly 17 GW of solar imports in 2024 and runs two-to-eight-hour load-shedding, so millions of sites now make this switch by hand. STS makes it scheduled, confirmed, and safe — which is the same problem anywhere a solar boom meets an unreliable grid. ### How does STS relate to WattEY and Solar Performance Cloud? They are three parts of one account of a site’s electricity, and Ali built all three. WattEY measures what the site draws from the grid and what it costs under the tariff. Solar Performance Cloud inspects what the site’s own solar generates, string by string. STS controls which of the two sources is actually carrying the load — and until that switching is recorded, neither of the other measurements can be attributed to the right source. ### What transfers from this to a problem that is not about electricity? Nearly all of it. Strip out the supplies and this is a control plane driving a physical actuator it cannot observe directly, over a network it cannot rely on, alongside a human who can overrule it — with one invariant important enough to be enforced below the software. That is the same shape as fleet or robotics control, industrial process automation, and any orchestration system that reconciles a desired state against a real one. The judgement about which guarantees must be physical is the part that generalises. --- Rendered from the structured content at https://alioahmed.com/work/sts. Facts trace to the canonical bio; render, don't reword.