Skip to content
Ali Ahmed
Power-control systemsLive production system

Switching a building between solar and the grid is easy. Proving it actually switched is the hard part.

A Pakistani building runs on two supplies — its own solar and the WAPDA grid — and someone usually decides between them by walking to a panel and pulling a lever. STS puts that changeover under software and, unlike a plain remote switch, reads the source back from the device’s own sensors before it calls the switch done. I built it.

Ali AhmedAli AhmedProduct · Data · EngineeringHead of Product & Platforms · BijliBachao.pkPrivate system · no customer is named on this page
  • Confirmedverified by sensor, not by command
  • Reconciledrecovered to desired state after an outage
  • Interlockedsingle-source enforced in hardware (Industrial)
  • Phone-firstinstallable PWA, no app store
STSSource control Live

Solar

standby

WAPDA

live now

One at a time, never both. On the industrial unit that is enforced in the equipment.

One switch, end to end

  1. RequestedWAPDAa tap, or the schedule
  2. Command sentto deviceover MQTT
  3. Awaiting sensorreading backthe step others skip
  4. Confirmed liveWAPDAthe source really changed
a plain remote switch stops at step twoillustrative
A control plane for a switch you can’t see, on a network you can’t trust.Confirmed switching · Desired-state recovery · Defined precedence · Hardware safety interlock

01The problem

Two supplies. One switch. Thrown by hand.

A building in Pakistan runs on two power sources — its own rooftop solar, and the WAPDA grid — and only one can safely carry the load at a time. Which one is a decision somebody makes all day, every day, usually by walking to a panel and pulling a heavy changeover lever.

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. During two-to-eight-hour load-shedding, that guess is made in the dark.

The honest state of most sites is a question, not an answer: “I think we’re on solar.”

What the hand-thrown switch costs

  • Solar left on the shelf

    The sun is up and free, but the building is still on the grid because nobody walked to the panel. You pay for power you are generating for nothing.

  • The grid bill nobody meant to run

    Left on WAPDA overnight, or through a whole weekend, because the switch back was forgotten. The most expensive units on the bill are the ones you did not decide to buy.

  • Two supplies, live at once

    The failure that is not an inconvenience. Bridge solar and the grid and you can back-feed a line that should be dead — a documented, sometimes fatal hazard to a line worker. A wrong switch here is a fault on your premises.

02The build

I put the changeover under software.

A controller sits on the changeover you already have. From there, the whole path — the link, the engine, the app — is the system I designed and built, end to end. A remote switch is the easy part; the judgement is everything after the tap.

Ali Ahmed

Head of Product & Platforms

Solar
WAPDA
01

The controller

On your existing changeover

Dingtian DT-R relay

industrial smart relay

02

The link

Device ↔ platform, live

MQTT

ISO/IEC 20922 · live state

03

The engine

Schedule · reconcile · confirm

Engine
  • Desired-state schedule

    a state to hold, not an event that fires once

  • Reconcile after outage

    back online → moved to where it should be now

  • Confirm from the sensor

    done only when the hardware reads it back

04

The app

Your phone, no app store

Next.js PWA

Android & iPhone · on AWS

Confirmed switch

From install to hands-off, in four steps

  1. 1

    Fit

    A small controller is wired onto your existing Solar/WAPDA changeover. Your wiring does not change.

  2. 2

    Connect

    The device comes online on its own; a one-time code in the app binds it to its owner.

  3. 3

    Control

    Tap to switch, see the live source, set daily switching times — from anywhere.

  4. 4

    Forget

    It runs the schedule every day, and catches up on its own after an outage.

Built on

  • Dingtian DT-R relay controllers

    Industrial smart relay hardware, the class used in commercial automation — not a prototyping board.

  • MQTT

    The device messaging protocol: lightweight, and built for many devices reporting live state and accepting commands.

  • Next.js, delivered as a PWA

    Installs to Android and iPhone from the browser and opens full-screen. No app store in the release path.

  • AWS

    Cloud infrastructure, so devices and dashboard are reachable around the clock.

03The control rules

Three rules, and each one is a failure that was designed out.

A remote switch sends a command. A control system holds a desired state, observes the actual state, and closes the gap between them — and keeps doing it when the network drops, when the power goes, and when a person overrules it. The difference is entirely in what happens after the tap.

Rule 01

Confirmed, not assumed

A switch is not reported as done when the command is sent. STS waits for the device’s own sensors to report that the source actually changed, and only then calls it. If the switch did not take, the user is told rather than left to find out.

The obvious behaviour

The command was accepted, so report success.

A relay can be commanded and still not move — a stuck contactor, a dropped message, a device that rebooted between receiving and acting. Reporting success from the command is reporting an intention as a fact.

What STS does

STS holds the switch open until the device reads its own sensors back and says which source is live. Success means measured, and a failure to move is surfaced instead of swallowed.

Rule 02

Reconciled after an outage

If a device loses power or connectivity it does not resume stuck in a stale state. The moment it is back, STS moves it to whatever the schedule says it should be on right now — including a transition it slept through.

The obvious behaviour

The device was offline at 5 PM, so it missed the switch. It will get the next one.

Load-shedding and connectivity gaps are the normal case here, not the exception. A scheduler that only fires at the instant of the transition leaves a device stranded on the wrong supply for the rest of the day, and nobody finds out until a bill or a blackout says so.

What STS does

The schedule describes a state, not an event. When a device comes back, STS asks what source it should be on right now and moves it there — including through a transition it slept through.

Rule 03

Manual intent wins, until it expires

A source changed by hand is honoured, and the automation does not fight it. The manual choice holds until the next scheduled transition, at which point the schedule resumes. Precedence is defined rather than raced.

The obvious behaviour

The schedule says solar, so put it back on solar.

Somebody switched by hand for a reason — maintenance, a fault, a load they know about and the system does not. Automation that immediately reverts a human is worse than no automation, because now the human cannot trust either.

What STS does

A manual change takes precedence and holds it until the next scheduled transition, when the schedule resumes. Precedence between human intent and automation is defined rather than left to whichever wrote last.

None of the three is specific to electricity. They are the rules any system needs when it drives a physical actuator it cannot see, over a network it cannot rely on, alongside a human who can overrule it.

04The hard part

The rule that must never break is not in the code.

On the industrial transfer switch, solar and the grid must never be live at the same time. Bridging two supplies is not a bug report — it can back-feed a line that should be dead, a documented and sometimes fatal hazard to a line worker. So that rule 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, where no command, no schedule, no race between two operators and no defect in this software can reach it.

A software check

Faster to build, demos identically, passes every test you would think to write — and is reachable by the next bug.

A hardware interlock

Accepts up front that the software will eventually be wrong, and puts the one rule that cannot fail where software cannot reach it.

That is the decision worth reading this page for — and it is the clearest example on the site of a judgement call rather than an implementation detail.

Where each guarantee lives

  • One source at a time

    In the equipment. A latching interlock.

    hardware
  • The source that is live

    In the device. Read from its own sensors.

  • The source that should be live

    In the platform. The schedule and the manual override.

  • Who may switch it

    In the platform. One-time claim code, then ownership.

The interlock is a property of the STS Industrial unit. The other two devices in the family are a single-changeover switch and a multi-circuit controller; the page does not claim the interlock for them.

A trustworthy control system knows which guarantees have to be physical.

Built to standard

Held to the standards that govern this class of device.

STS is transfer-switch equipment, so it has a real standards home — not a marketing badge, a category. It is aligned to the standards below; no unit is certified or Listed to them, and the page never claims otherwise.

UL 1008

Transfer Switch Equipment

The UL safety standard for the class of device STS is (Edition 9, 2022). STS is designed to its intent — the anchor for “safe by design”.

IEC 60947-6-1

Transfer switching equipment (ATSE)

The international standard for automatic transfer switching equipment, which by definition connects the load to one source at a time (classes PC / CB). The direct anchor for the single-source interlock.

ISO/IEC 20922

MQTT messaging

The telemetry runs on MQTT — an OASIS and ISO/IEC 20922 standard, ratified in 2016 — rather than a private protocol. A real international-standard IoT backbone.

The anti-islanding objective

The interlock serves the same objective the industry codifies in anti-islanding standards like IEEE 1547 — a local source must never back-feed a grid it should not — but STS meets it structurally, through a physical break-before-make interlock, rather than through inverter islanding detection.

Standards named are alignment targets, not certifications · UL 1008, IEC 60947-6-1, ISO/IEC 20922, IEEE 1547.

One control plane, three shapes of hardware

The same guarantees, whatever is on the wall.

A house wants per-circuit control. A shop wants one changeover it can trust. A plant wants a rule the equipment will not let anyone break. Three devices, one app, and one set of rules about confirmation, reconciliation and precedence that holds across all of them.

Multi-circuit

STS Controller

Four circuits switched 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.

Single changeover

STS Transfer Switch

A dedicated Solar/WAPDA changeover unit. One control, two sources, and the device’s own sensor confirming which supply is actually live.

Dual-source, interlocked

STS Industrial

A latching transfer switch with a hard safety interlock: one source at a time, never both, enforced in the equipment rather than in policy. Fully schedulable around that rule.

The only member of the family with the hardware interlock.

What it is built on

  • Dingtian DT-R relay controllers

    Industrial smart relay hardware, the class used in commercial automation — not a prototyping board.

  • MQTT

    The device messaging protocol: lightweight, and built for many devices reporting live state and accepting commands.

  • Next.js, delivered as a PWA

    Installs to Android and iPhone from the browser and opens full-screen. No app store in the release path.

  • AWS

    Cloud infrastructure, so devices and dashboard are reachable around the clock.

The app ships as an installable web app rather than through an app store, which 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 between a fault and its remedy.

Four shapes of the same problem

Who is actually standing at the panel.

The four situations the product was shaped around. They are archetypes written by the BijliBachao team, not accounts of identified sites — no customer is named anywhere on this chapter.

  • 01

    The house that never wastes daylight

    Solar from morning, grid from sunset, set once and running every day since. Nobody has touched the panel in months.

  • 02

    The shop owner already at home

    The sun is going down and the shop is still on solar. Opens the app, taps WAPDA, watches it confirm. Never gets up.

  • 03

    The plant that must never bridge

    Solar through the working day, grid overnight, automatically — and whatever anyone taps or schedules, the two supplies cannot be live together. The equipment will not allow it.

  • 04

    The installer with forty sites

    One dashboard: which devices are online, which switched today, which need attention. No site visit required to find out.

The opportunity

The market view

The hand-thrown switch is a global problem.

Anywhere a rooftop-solar boom meets an unreliable grid, someone is deciding between two supplies by hand — and only one can safely carry the load at a time. The category that automates it, the automatic transfer switch, is roughly a $0.9–1.8 billion market growing 5–10% a year (Allied Market Research, GMInsights, Technavio). STS builds the confirmed, safety-interlocked version of it.

A naming note for the technical reader: STS here is an automatic transfer switch. It is not the solid-state static transfer switch of the same acronym — that is a different, data-centre product.

$0.9–1.8B

automatic transfer switch market

Allied Market Research · GMInsights · Technavio

5–10%

annual growth, into the early 2030s

across the same firms

~17 GW

solar Pakistan imported in 2024

Ember · Renewables First

Where the same problem is most acute

An opportunity map · not deployment

The same three conditions that make the switch matter in Pakistan — a solar boom, an unreliable grid, and a switch thrown by hand — recur across the emerging world. STS is live in Pakistan today; everything below is where it could go, ranked by how acute the pain is now.

Acute now — solar boom meets a failing grid

Most acute

Nigeria

Grid + solar + generator is a three-source manual mess — the strongest fit for a confirmed, interlocked, hands-off switch.

Grid collapsed ~8× in 2024 · ~40% of power from generators

Extreme grid failure

Lebanon

Households already juggle solar, a private generator and an intermittent state grid by hand, every day.

State grid ~4 hrs/day in 2024 · solar rose ~10–13×

The scale prize

India

An enormous, policy-driven residential solar base; the grid is more reliable, so the pain is adoption-led rather than crisis-led.

7.1 GW rooftop installed in 2025 (+122%) · PM Surya Ghar

Large & emerging bases — the automation opportunity follows the solar

Large installed base

South Africa

Rooftop solar quintupled in two years — a vast base of solar-plus-backup that still needs orchestration, though load-shedding eased in late 2024.

Behind-the-meter PV ~1 GW → ~4.7 GW in ~2 years

Frequent outages

Philippines

Frequent supply interruptions and high tariffs make the case; rooftop adoption is still early, so the demand is ahead of the base.

~28 supply interruptions per household a year

Policy just turning

Bangladesh

New mandatory rooftop-solar rules on connections, and vast latent factory-roof potential — the boom is ahead, not yet realised.

Mandatory rooftop rules (Dec 2025) · ~5 GW of RMG-roof potential

Pakistan is the hard version of the problem — one of the world’s largest solar-import markets, a grid that sheds two to eight hours a day, and millions of sites switching by hand. A switch proven there is proven for the hard version of every market above. That is why the country is the proving ground, not the ceiling.

Source · Market sizing from Allied Market Research, GMInsights and Technavio; the Pakistan solar figures from Ember and Renewables First; per-country signals cited in docs/BB/STS/research/01-market-and-standards.md. STS is live in Pakistan only — the countries above are mapped opportunity, not reach.

What transfers

Strip out the supplies, and the skill isn’t electricity.

STS is a control plane for a physical actuator you cannot observe directly, over a network you cannot rely on, alongside a human who can overrule it — with one invariant important enough to sit below the software. Electricity is the domain detail. The judgement is knowing which guarantees have to be physical, and that transfers.

  • An actuator you can’t see

    the true state lives in the device, not the last command

  • A network you can’t trust

    outages are the normal case, so state must reconcile

  • A human who can overrule it

    manual intent needs defined precedence, not a race

  • One invariant that can’t fail

    the rule that matters most lives below the software

The same shape, in other domains

  • Robotics & fleet control

    commanding an actuator, confirming it moved, recovering after a dropout

  • Industrial process automation

    desired-state control with interlocks that must hold in hardware

  • IoT device management

    many devices, live state, ownership, and honest confirmation at scale

  • EV charging & energy control

    scheduling and switching physical loads a network can’t always reach

  • Orchestration systems

    reconciling a declared desired state against a messy real one

Why this one is on the page

A small product, and the clearest judgement on the site.

STS states no scale, because none is invented. What it states instead is a way of thinking: take a control plane from zero to production, treat the sensor as ground truth, recover cleanly from the outages that are the normal case here, and put the one rule that cannot fail where software cannot reach it. That is the judgement a serious technical evaluator is reading for — whether they want it built, or want it on their team.

If you’re hiring
This is the work sample for judgement under real-world constraints — control-plane engineering, desired-state recovery, and knowing which guarantee has to be physical.
If you’re building
You have a version of this: an actuator you can’t see, a network you can’t trust, an invariant that can’t fail. Ali has already shipped it.
If you want STS for your sites
STS is a BijliBachao product — the switch is theirs to fit and run. BijliBachao.pk is where that conversation goes.
Questions

What people ask about this build.

Six questions, answered the way the work was actually decided — including the guarantee that was deliberately kept out of the software.

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.

This chapter states no fleet 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. The same questions and answers are served as structured data and in this page’s plain-text and Markdown views.