How Aliste Turns a Meter's Relay Back On the Instant a Recharge Clears, Over MQTT

The moment that matters: payment confirmed, power should follow

A tenant on a prepaid Aliste meter runs their balance to zero, the relay opens, and the room loses power. They open the app, recharge, and the transaction succeeds. What happens between that successful payment and the lights coming back on is where a prepaid metering system either feels instant or feels broken. Aliste's meters, EMS devices and automation controllers all stay connected to the backend over MQTT the same way described in our post on securing that channel - and it's that same persistent connection that makes instant reactivation possible, rather than something the tenant has to wait out.

Two lanes on one channel: readings up, commands down

Most of the traffic on a meter's MQTT connection flows in one direction: the device publishes usage and balance readings up to the broker, which routes them to the backend. But the same connection carries traffic the other way too. Every meter is also subscribed to a command topic scoped to itself, and the backend can publish directly into that topic at any time - to turn the relay on, turn it off, or push a configuration change. Because the meter is already connected and already listening on that topic, a command doesn't wait for the device to ask if anything's changed. It arrives the moment it's sent.

What happens in the seconds after a recharge

A recharge triggers a short, specific sequence rather than a general "re-check everything" cycle:

• The tenant completes a recharge in the app, and the payment gateway confirms it to Aliste's backend.
• The backend credits the balance and, because the balance moved from zero (or the meter's relay is currently open), immediately issues a turn_on command.
• The backend publishes that command to the meter's own command topic - not a broadcast, not a topic shared with any other device.
• The meter, already connected and subscribed, receives the command instantly and closes its relay.
• The meter publishes an acknowledgement back over its own topic, which the backend uses to confirm the state change and update the app.

Why this has to be push, not poll

An alternative design would have every meter periodically ask the backend, "has my balance changed?" That works, but it puts a floor under how fast reactivation can ever be: on average, a tenant waits half the polling interval, and in the worst case, a full interval, and that wait exists for every recharge on every device, all the time, whether or not anything actually changed. Polling also means constant outbound requests from potentially thousands of devices asking a question that's usually "no" - a real, ongoing cost that scales with the size of the fleet. Pushing the command the instant it's needed removes the wait and the wasted traffic in one move: nothing happens until there's something to say, and when there is, it arrives immediately.

Making sure the command actually lands

Speed doesn't mean firing a command and hoping. A dropped or duplicated command matters more here than a delayed reading would, because it directly controls whether power flows to a room. Three things keep that reliable:

• The broker delivers the command with a guarantee, not a best-effort attempt - if the meter is briefly unreachable, the message is held and delivered as soon as it reconnects, rather than silently dropped.
• The meter acknowledges the command back to the backend. If no acknowledgement arrives within a short window, the backend retries, so a lost message doesn't leave a paid tenant sitting without power.
• Each command carries a sequence number. If a retry or a network hiccup causes the same command to arrive twice, the meter recognizes the duplicate and doesn't toggle the relay a second time.

The same device authentication and topic-level authorization covered in the MQTT security post apply here without modification - a command topic is just as tightly scoped as a readings topic, so only the backend can issue a valid command to a given meter, and no other device can reach it.

The same channel, run in reverse: cutoff at zero balance

Instant activation is only half the design. The same mechanism runs symmetrically when a balance depletes: the backend detects the balance has reached zero and immediately publishes a turn_off command to that meter's topic, closing the loop the same way a recharge opens it. Neither direction depends on the meter noticing a threshold on its own - the backend, which holds the balance, is what decides and the meter simply carries out the instruction the moment it arrives.

Why instant matters more than it sounds

A few seconds might sound like a minor detail next to encryption, authentication or billing accuracy. In practice, it's the part of a prepaid system a tenant actually experiences directly - it's the difference between a recharge that visibly, immediately does what it promised and one that leaves someone standing in a dark room checking whether the payment actually went through. For an owner or operator, that reliability is also what prevents the support call that starts with "I recharged and the power's still off." Getting the seconds right is what makes prepaid billing feel like a utility rather than a workaround.

Frequently asked questions