OMS Workshop Nairobi · open server
Open Metering Strategy · 30 Sep–2 Oct 2026 · Nairobi · hosts A2EI and EnAccess · workshop page
← Back to Meeting Notes · Workshop page
One open head end the gateway can join, in the cloud and on site. Meter, radio, and keypad stay outside it.
Inhe Meters was the first OEM to vocally support this. They were in attendance.
One open management system. A pluggable driver per meter type. Gateways that can hold more than one driver. Connectors for known OEMs, and room for third parties to add more. Near-term baseline: open connectors for SparkMeter and SteamaCo fleets already in the ground. Keep the work already done. Other meters in urgent need can be added. In the room, open core meant not full open source: OMS is the metering minimum, and companies sell what sits on top. The organizers’ October summary describes the same build as an open-source metering infrastructure, a modular application layer, operated at cost as a Digital Public Good. Roadmap Phase 1 is that installed base. Phase 2 is the open mini-grid core. An IEEE village standard is a later milestone.
Organizer summary
A2EI and EnAccess, Workshop Summary, October 2026. Counts below are theirs, not an ISV census. The contact list, expert-pool names, and workshop photos are not on this page.
The summary ties the workshop to the financial collapse of SparkMeter and severe financial strain on SteamaCo. It states about 249,000 mini-grid meter connections, serving more than 1 million people, mostly in deep rural places across 30+ countries, are at risk of lost electricity if the meters stop. Operator revenue depends on those meters. A2EI and EnAccess, supported by NRECA International, AMDA, and OpenAMI, are building that open-source layer. Scoping mixed remote requirement collection, this workshop, and a later async design review. People in the room: developers, industry associations, funders, and technology providers.
- Day 1. Shared history, pain points, and a common vocabulary. Edge capability versus cloud capability was opened, not closed.
- Day 2. An ideal feature set was cut to a realistic MVP. A joint list of existing tools against those features was started and finished over the next two days.
- Day 3. The MVP list became a draft solution design, so each feature had a system and an operating cost. Ideal timing named in the summary: MVP version 1 operational for a pilot in January/February 2027. Initial governance ideas for OpenCore 1. Support and technical assistance for operators on metering onboarding and offboarding. An expert pool was mapped onto parts of the design.
Questions that ran through all three days:
- What interaction with the meter, and what control, is required — local or cloud, and at what latency?
- How much edge operation belongs in the MVP, and what role do proprietary OEM protocols keep at the edge?
- Where are the functional boundaries of Open Core?
- What governance and incentives fit OpenCore 1 and an open-source ecosystem around it?
- What support do the mini-grid companies need?
Immediate outcomes named: a draft architecture, an MVP feature list with tools mapped onto it, a contact list, and a folder of pictures and visual notes.
Next steps in that summary
| Activity | When |
|---|---|
| Escrow key transfer, batch 1 | In the coming days |
| WhatsApp group for informal exchange | 9 Oct 2026 |
| Receive, approve, and bundle eligible costs | 13 Oct 2026 |
| Verify, process, and refund eligible travel costs | 6–18 Oct 2026 |
| Share consolidated architecture and roadmap with participants (request for non-objection) | 15–16 Oct 2026 |
| Feedback from participants and experts | 20 Oct 2026 |
| Include feedback and finalize | 21 Oct 2026 |
| Share with the funders group | 22 Oct 2026 |
| Development work on OpenCore | 1 Nov 2026 onward |
Thanks in the summary: Global Energy Alliance for People and Planet for the Nairobi venue, Good Energies for support to invite a wide group, NEFCO for support of the work that follows, NRECA for advice, OpenAMI and AMDA for convening members and technical experts, and EarthSpark and SteamaCo representatives for open participation.
One stack
Violet is the head end the group is building. It runs in the cloud and again on site, so service continues when the link is down. The group needs that head end to speak to the gateway. Amber and gray are the field hardware: gateway, radio, meter, keypad.
When the cloud link is down
The headend holds a local mirror of the server. The site keeps operating while the link is down. The question was how operations continue when the internet is down. The room did not treat the two approaches as a permanent either/or. The lean was to make offline capability an option. One company can have sites with a link and sites without one at the same time. Start with a stage that works, and do not design the next stage out.
| What it does | Cost named in the room | |
|---|---|---|
| Edge computing on the grid | An on-site system keeps operating while the link is down. TC 2.0 already draws that for GroundBolt: the uplink can fail while local prepaid continues. | Higher complexity and cost. |
| Split continuity from live data | Accept gaps in the data. Sync when the link returns. Vending continues with STS tokens, typed in by hand if needed. Token path, including SMS: 28 May topology. | Narrower than a full edge system. Still needs the grid to be designed for that gap. |
Where the headend sits is the same split. SparkMeter runs the command center on site: wallets, credit countdown, time-of-use, customer list. Offline, then sync when the link returns. SteamaCo runs it in the cloud: the meter waits for a remote command, and an outage blocks that. Cloud-first design was called a known failure for this sector. An outage stops vending, and it also stops onboarding, tariff changes, and other work that waits on the link. One Madagascar case was operators connecting about once a month to sync. Energy used without payment, or payment taken without energy, lands on the developer.
Keep the two offline stacks apart. GroundBolt keeps local prepaid when the uplink fails, and those SM meters do not decode STS. STS-through-the-gap is the other path. Both can sit in one company. Neither is monitoring. A control loop cannot use that gap. Service can continue while history waits.
Talks to OEM gateways and DCUs
Mini-grid platforms bundle this into one product. Open Core is the head end and the hop up from the gateway. The picture is one stack above. Village Metering draws the same split for SteamaCo, SparkMeter, EnAccess, and an OpenAMI path.
Comms the server has to carry, from the priority-1 list on the Features MVP shortlist:
- OEM-agnostic infrastructure.
- Robust communication: standards for hardware-OEM comms, a head-end sized for the loads, MDMS necessary for the head-end, and comms right-sized to the use case.
On this wiki, DLMS/COSEM sits at the meter and the DCU. The DCU is client to the meter and server toward the head-end. North of the gateway the payload is the register checklist, not a second object model. One northbound shape: the gateway publishes the same keys so a head-end survives a meter OEM change. VMRS is the draft of that shape. This work should not mint a second register standard. Ask for a short list, not a utility ICD. Tier A names are already settled. 1.8.0 is import kWh. Tier B is where makers still diverge inside “DLMS”: credit, tamper bitmap, disconnect, serial. Ask for the companion-profile certificate, or one ICD excerpt per model. A brochure logo is not the certificate. VMRS is a draft shortlist, not a published standard. 96.1.0 is the billing-period counter, not the serial.
Another team read frequency, voltage, and consumption from 5 meters through an off-the-shelf gateway and a normal cloud path. Azure and MQTT were the example. Readable registers mean the data can move.
Lock-in the server is answering
Hardware lock-in and software lock-in were split on purpose. A phone analogy used in the room: a vendor can keep proprietary hardware if the interface above it is open. Hidden registers make the meter a brick when the vendor stops. That gap is what the register checklist is for.
| Level | What fails | Matching response |
|---|---|---|
| 1 — blackout | Vendor system down. Operators see errors. Meters unreachable. | Escrow is the fallback when a vendor stops operating. |
| 2 — stranded hardware | Operator wants to leave. Meters stay tied to the old platform. | Migration means new software, same meters. Possible in theory for some stacks. Not proven at scale. |
| 3 — mixed fleet | Operator wants another brand under one platform. | Universal headend, or one management system with a driver per meter type. This is the server. |
A vendor switch uses a Key Change Token sequence, applied in order. It can go out remotely or be typed on the customer keypad. Provision that access when the meter is made, so the switch does not need a site visit. Each meter holds encryption keys tied to a Supply Group Code. The 28 May note already separates STS keys from OEM keys and from DLMS keys. ThunderCloud 2.0 and GroundBolt are open. SteamaCo’s migration path is still being built. DLMS register codes come from the manufacturer on request, and they are not always right.
Where the work can be cut
| Cut | What it builds | Limit named in the room |
|---|---|---|
| Above the headend | Open MDMS, CRM, outage and revenue management on an existing headend. | Still locked at the hardware and gateway. |
| The headend | One headend that can speak SparkMeter, Calin, and others. Both are in the vendor study. | Called boiling the ocean. DLMS named as the possible lever. |
| Below the headend | Free meter-to-gateway comms: registers, a SparkNet equivalent (TC 2.0), LoRaWAN. | High complexity. Needs operator skill or a strong open effort. |
Tests proposed for any cut: which lock-in it addresses, whether it reinvents a commercial-scale standard, and how much burden lands on the operator.
One framing: write the standard for new meters. Priority hop is gateway to cloud. Start with DLMS, upgraded for this ecosystem.
The other: open connectors for SparkMeter and SteamaCo fleets already in the ground. DLMS as leverage for a universal headend, and as manufacturer register codes.
The near-term baseline that landed is the second one. KPLC, at about 8 million meters, can impose interoperability on manufacturers. A mini-grid operator does that only together with others.
What sits above the server
The open core does not hold all of the business logic. Tariffs, CRM, and payment rules sit above it. The core stays extensible so an operator can plug in their own modules. The infrastructure has to be able to carry the business model. How that model is built is the operator’s choice. After SteamaCo stopped mini-grid development in 2021, Nimbus became a pass-through. Customers, PowerGen among them, built their own layers above it. Nimbus in the vendor study is SteamaCo’s AMI head-end. Company filings and the product claims: ISV-TRD-002.
About ten tariff schemes have been built. About three are actually used. Requests for more elaborate tariffs came from developers and rarely ran at scale. The staged path that was endorsed: a tight first version, built so it can grow, then revisit.
Operator path, in order: vending (STS, collect revenue), then monitoring (usage and events), then control (run the grid). STS is a vending standard, not a comms standard. It does not give remote monitoring or control. The interoperability gain named for standard STS: one system vends tokens for more than one meter brand.
2030 exercise. NRECA International was named as technical advisor and validator in the consortium, with A2EI and EnAccess. Silent write, then affinity clustering. Prompt: mini-grid operations in 2030. Roadmap Phase 3 is a later grid-arrival path, not this feature list. Clusters on that sheet:
- Vending & Tokens (tariff)
- Billing/Accounting
- Data/Monitoring/Analytics
- Transparency/Reporting — who the story is for. A dashboard is not a reading.
- Operational Control
- User interface, customer awareness
Data/Monitoring/Analytics and Operational Control are the server. Vending, billing, transparency, and the customer interface sit above it or beside it.
On this wiki
- Workshop page · Open Core stack SVG · Village Metering · solutions map · vendor study
- 8 Oct · gateway vs requirement · TC 2.0 review · roadmap · 11 Aug SparkMeter / Nimbus · ISV-TRD-002
- DLMS/COSEM · register checklist · 28 May STS topology · wireless telecom
- OpenAMI · village standards · Village GeoJSON · village scope · grid cybersecurity layers