A prepaid energy meter has one job at the moment of truth: decide whether to dispense. Everything else — reporting, analytics, reconciliation — can wait. The decision cannot.
That sounds obvious until you look at how these systems are usually built. The meter reads a tag, calls the server, the server checks the balance, the server answers. It works beautifully in an office. It fails at a site connected over a 10 kbps link that drops for hours at a time, because the person standing at the meter is now waiting on a round trip that may never complete.
Move the decision, not the data
The fix is to stop treating the server as the authority for that one question. On EnergyOS, each site runs a Raspberry Pi that holds the remaining quota for every RFID tag it knows about. When a tag is presented, the node answers locally and immediately. No network involved.
The server's role changes from arbiter to eventual reconciler. Readings queue on the node as compact JSON and drain whenever the link permits. Bandwidth stops being a correctness problem and becomes a latency problem — the dashboard is a few minutes behind, which nobody minds, instead of the meter being unavailable, which everybody does.
What this costs you
This is not free, and it is worth being clear about the bill:
- Quota becomes distributed state, so you need a deliberate answer for what happens when the same tag is used at two sites during a partition.
- The node is now something you have to deploy to, update and monitor — fleet management is real work.
- Reconciliation logic has to be written and tested against out-of-order arrivals, because that is what an unreliable link produces.
- Your dashboard needs to show data freshness honestly, or operators will trust a stale number.
That last one matters more than it sounds. Every view in the operator dashboard carries a last-sync time per node. A number without a timestamp is a guess wearing a suit.
When not to do this
If your sites have reliable connectivity, do not build this. Distributed state is a real cost and you should only pay it when the alternative is a system that stops. The test is simple: write down what happens to the business during a four-hour outage. If the answer is 'nothing much', keep the server as the authority and go home.
Design for the worst link you will actually see, not the average one. The average is not what wakes people up.