ISV IEEE Smart Village
← ISV Knowledge Base · Home

OMS Workshop · Nairobi

Open Metering Strategy · 30 Sep–2 Oct 2026 · Nairobi · A2EI and EnAccess · results

← Back to In-Person Events · Home

3
Days ran
30 Sep–2 Oct · vocabulary, MVP, draft design
2027
MVP v1 pilot aim
January / February · organizer summary
What ran

Three days in Nairobi, the week after the ISV OpenAMI EMS Workshop. Hosts: A2EI and EnAccess, with NRECA International, AMDA, and OpenAMI. The organizer summary names about 249,000 mini-grid meter connections at risk if those meters stop. Public note: open server — cloud head end inside Open Core, a local mirror of that head end, gateways outside the core. MVP version 1 aimed at a pilot in January/February 2027. Contact list and photos stay off this site.

Who

The October summary records an expert pool mapped onto parts of the design. Names, the contact list, and the participant spreadsheet stay off this site.

Pre-session record

The agenda, the 22 Sep online votes, and the resource list below are the prep pack. Room results are on the open server note.

Pre-read agenda

Times from the 25 Sep pre-read. The October summary says Day 3 turned the MVP list into a draft solution design. The clock below is that pre-read.

TimeDurationSession
Day 1 · Wednesday 30 September · Plenary — looking back, diagnosing, sketching forward
09:30–10:301 hOpening & warm-up. Welcome and framing (Chatham House · no-blame). Icebreaker and introductions.
10:30–12:302 hLooking back: history of (smart) metering issues and efforts (OpenAMI, Prospect, ISV Open Street-EMS, MPM, others). Data in practice: what funders, developers, and metering software actually collected vs what they used. Surface the cost of unused high-resolution data.
12:30–13:301 hLunch
13:30–14:0030 minBreak
14:00–15:001 hWhat went wrong in 2025 — facilitated root-cause discussion of the SparkMeter / SteamaCo crisis (operators, platforms, funders, technical partners).
15:00–16:301.5 hSketching the OMS strategy. Map existing building blocks. Needs going forward: hardware layer, DLMS meters, incumbent/legacy meters. Feeds Day 2 working-group topics.
16:30–17:000.5 hOnline Day 1 recap summary
Day 2 · Thursday 1 October · Working groups
09:00–09:300.5 hWarm-up and Day 1 recap
09:30–11:302 hWorking Groups I — frame · silent write · affinity cluster · 3–5 propositions · canvas
11:30–11:5020 minBreak
11:50–12:3040 minPlenary: first findings
12:30–13:301 hLunch
13:30–16:002.5 hWorking Groups II — same method
16:00–16:3030 minPlenary: afternoon findings
16:30–17:000.5 hOnline Day 2 recap summary
Day 3 · Friday 2 October · Alignment & sign-off
09:00–09:300.5 hDay 2 recap
09:30–10:45~1.25 hAlign working-group results into an OMS development strategy
10:45–11:0015 minBreak
11:00–12:301.5 hDraft strategy: capture & comment. Flag open issues.
12:30–13:301 hLunch
13:30–14:301 hStrategy sign-off. Group confirms direction.
Draft agenda clock

Minutes from the 25 Sep pre-read table. Lunch/break vs session. Not attendance. Scale = 8 h (longest day).

Day 1 · Wed6 h session · 1 h 30 min break · 7 h 30 min
Day 2 · Thu6 h 40 min session · 1 h 20 min break · 8 h
Day 3 · Fri4 h 15 min session · 1 h 15 min break · 5 h 30 min
SessionLunch / break

Online pre-session (already ran)

Tuesday 22 September 2026, 11:00–12:30 CEST. Hosted by AMDA, A2EI, and EnAccess so more voices than the Nairobi room could be heard. Pre-read says 50+ attendees on that call. Themes recorded in the outcomes pack (no chat names copied here):

Live polls (22 Sep)

Six Pollol screenshots sit under Polls in the outcomes pack. Bars use the printed answer counts. “% of Attended” is Pollol’s own line — not a published headcount, and not the 50+ call note. No country split in those screenshots.

What metering platform are you running today?

28 answers · 50% of Attended

Koios10 · 36%
Own platform5 · 18%
Other third-party platform5 · 18%
Thundercloud4 · 14%
Nimbus4 · 14%
What’s your realistic migration timeline, if any?

23 answers · 41% of Attended

No migration planned as of now8 · 35%
Want to migrate in one month7 · 30%
Sometime next 6 months5 · 22%
Want to migrate next week2 · 9%
Sometime next 12 months1 · 4%
What breaks first for you if the platform goes away?

23 answers · 41% of Attended

No vending8 · 35%
Free energy7 · 30%
No energy available to customers6 · 26%
Data monitoring2 · 9%
What’s your biggest concern about a new custodian holding your credentials?

18 answers · 32% of Attended

Other concern7 · 39%
Escrow agent doesn’t safeguard well the keys5 · 28%
No big concern actually4 · 22%
Escrow agent fails to exist2 · 11%
How many meters are you operating today?

18 answers · 32% of Attended

>5,000 meters8 · 44%
500–2,000 meters4 · 22%
<500 meters3 · 17%
2,000–5,000 meters3 · 17%
None as of today0 · 0%
How would you want to operate your metering in the future?

13 answers · 23% of Attended

Manage metering hardware on our own6 · 46%
Basic hosted layer + own added features4 · 31%
Fully hosted and serviced platform3 · 23%

EarthSpark key options (pre-read PDF)

Developer note in the pack, after ThunderCloud 2.0 / SparkNet-HTTP open-source: three paths — (1) EarthSpark keeps holding keys, (2) copy into A2EI escrow, (3) request keys (or a chosen custodian) from EarthSpark. Options 2 and 3 can run together. Process URLs stay on EarthSpark’s own channels — not duplicated here.

Feature prioritisation (online votes)

Pre-read 1.2: 119 votes across 27 features. Each person had 12 votes, max 3 on one feature. Connectability was the strongest theme. Hosted OMS / operator takeover of the old head-end almost empty. Voter headcount not published — do not back-solve from 119 ÷ 12.

Votes by block

119 total. Share as printed in the results sheet.

Data, monitoring and reporting32 · 27%
Meter communication and control27 · 23%
Vending and tokens23 · 19%
Integration and ecosystem interface19 · 16%
Hosting, takeover and independence18 · 15%
BlockVotesShare
Data, monitoring and reporting3227%
Meter communication and control2723%
Vending and tokens2319%
Integration and ecosystem interface1916%
Hosting, takeover and independence1815%
All 27 features, ranked

Bar scale = 9 votes (top row). Amber = 6+ · red = 0–1 — same cut as the results sheet.

Documented integration with an open-source CRM9
Provision and commission meters yourself, without vendor support tickets7
Bulk export of historical consumption, payments and meter configuration7
Open API covering all data and commands7
Multi-site and multi-operator support with role-based access7
Management tokens — clear tamper, clear credit, set power limit6
Remote disconnect and reconnect; read meter status6
Open data schema so any platform can integrate without bespoke work6
Self-hosting: containerised, documented, one-command deployment6
Operate the SparkMeter legacy fleet (SparkNet & TC 2.0)5
Interval data — hourly or 15-minute5
Aggregated monitoring and reporting export for funders5
Vendor-independent STS token generation4
Top-up in currency units as well as kWh4
Time of use + different load limits per tariff and time frame4
Integrate DLMS meters directly4
Convert meters to STS-only operation and drop the comms layer4
Event push / webhooks for meter and payment events4
Data export and portability — leave any platform with your data intact4
Key Change Tokens — move a meter to your own supply group code3
Event data3
Daily aggregates3
Set tariff rate on the meter2
High-resolution — 1-minute or finer2
Operate legacy SteamaCo meters via Nimbus-equivalent head-end1
Hosted OMS service for operators without in-house IT capacity1
Operator takeover of the existing head-end — run ThunderCloud 2.0 or Nimbus yourself0
6+ votes2–50–1
Data resolution (same vote sheet)

Pack text: hourly / 15-min outscored event, daily, and 1-minute. Not a separate poll — four rows from the 27.

Interval data — hourly or 15-minute5
Event data3
Daily aggregates3
High-resolution — 1-minute or finer2

Top cluster (6+ votes)

FeatureVotesBlock
Documented integration with an open-source CRM9Integration
Provision and commission meters yourself, without vendor tickets7Meter comms
Bulk export of historical consumption, payments, configuration7Data
Open API covering all data and commands7Data
Multi-site / multi-operator role-based access7Hosting
Management tokens — clear tamper, clear credit, set power limit6Vending
Remote disconnect / reconnect; read meter status6Meter comms
Open data schema (no bespoke integration)6Integration
Self-hosting: containerised, documented, one-command deploy6Hosting

Mid-table that still registered: SparkMeter legacy fleet (SparkNet & TC 2.0) 5 · hourly/15-min interval data 5 · funder reporting export 5 · vendor-independent STS 4 · DLMS direct 4 · time-of-use + load limits (added live) 4. Bottom: hosted OMS service 1 · legacy SteamaCo via Nimbus-equivalent HES 1 · operator takeover of ThunderCloud 2.0 / Nimbus 0. High-resolution 1-minute data 2 — operators asked for load profiles, not per-minute telemetry.

Resource map (pre-read 2)

Stacks named in the resource list — wiki links where this site already tracks them. No unpublished pricing.

Attendance

Not listed. Prep file 3.OMS Workshop_participants.xlsx exists in the organizer pack. This public wiki does not publish names, visas, or roles from it. The public result is the open server note. Working roster is ISV-internal — access on request.

Training demand (catalog, not a course)

Named operator interest from this pre-session (CRM, commission meters, data/API/export, multi-site, management tokens, remote ops, self-hosting, monitoring/reporting, and others) is catalogued as work that needs training — not taught here. Lifecycle timeline + skillsets: OMS / village training skills · #events/oms-training-skills. Modules TBD. No hours, certificates, or sign-up.

Related on this wiki