Training tasks · village energy + OMS / metering

Integration with an open-source CRM

What it is. Connect metering / vending events to a customer-account system you can read and leave. Pre-session top row on the OMS page: “Documented integration with an open-source CRM” — 9 votes (cite that page; do not treat 9 as a headcount).

Typical tasks to train. Map customer / account / meter IDs. Push payment and consumption events. Avoid a one-way vendor CRM lock. Handover of the customer book when the operator or platform changes.

Self-paced later: documentary (API docs, field maps) can be self-paced. Custom later: site-specific CRM and ID scheme. Wiki already names MicroPowerManager (MPM) as an open mini-grid customer/asset OS (CRM + prepaid families). OpenAMI lists MPM as one backend. Shared customer/account id across stacks: unknown. Do not claim a finished MPM↔OMS integration as fact.

Provisioning and commissioning meters

What it is. Put a meter into service — identity, keys, tariff/credit start, NAN join — without waiting on a vendor ticket. OMS page: “Provision and commission meters yourself, without vendor support tickets” — 7 votes.

Typical tasks to train. Unbox → register → associate customer. Join RF / PLC / GSM path. Confirm a first read. Re-commission after swap. Re-key on handover. Layer stays at meter + DCU; do not score this as a cloud feature.

Self-paced later: checklists and OEM public docs. Custom later: feeder voltage, harmonic profile, OEM field tools. Related: field problems · vendor study · TC 2.0 / GroundBolt. Per-vendor ICD often NDA-gated — cite as ISV-internal; do not paste restricted text here.

Data management, API integrations, and bulk exporting

What it is. Own the data path: what is stored, who can call it, how you leave with it intact. OMS page top cluster: bulk export of historical consumption / payments / configuration — 7; open API covering data and commands — 7; open data schema — 6.

Typical tasks to train. Define export (CSV / JSON / API). Auth and scope for commands vs reads. Bulk pull for a site or a date range. Keep a copy that still loads after the head-end dies. Northbound contract is not the same as a meter register map.

Self-paced later: schema and API docs (good self-paced fit). Custom later: live credentials, rate limits, dirty historical tables. Wiki: northbound MQTT v0.1 · VMRS / OBIS checklist (draft, not a published standard). “REST (partner login)” ≠ public OpenAPI — that warning already lives on the vendor study.

Multi-site and multi-operator support

What it is. One person or org can see more than one village / concession, with role-based access — and a site can change operator without a full rebuild. OMS page: “Multi-site and multi-operator support with role-based access” — 7 votes.

Typical tasks to train. Tenant / site / role model. Who can vend, disconnect, or export. Handover of a single site out of a multi-site book. Audit trail: unknown per platform.

Self-paced later: role-matrix worksheets. Custom later: real org chart and concession contracts. How any one named platform implements RBAC is not verified here.

Management tokens

What it is. Privileged tokens that change meter state — not the same as a customer prepaid credit token. OMS page wording: “Management tokens — clear tamper, clear credit, set power limit” — 6 votes.

Typical tasks to train. Who may issue. Clear tamper / clear credit / set power limit. Store and rotate issuer keys. Offline path if WAN is down. Do not conflate with STS prepaid vending (IEC 62055) or OpenPAYGO credit tokens — those are a related but different skill (see and others).

Self-paced later: token-type list and who-can table (the OMS “WHO can generate and distribute tokens” row is still TBD). Custom later: live key ceremony, escrow, site SGC. Pre-session also recorded escrow-of-keys and EarthSpark key-option themes — process URLs stay on those orgs’ channels. Key-change tokens (move a meter to your own supply group) sat mid-table on the OMS sheet (3 votes) — related, not this row.

Remote operations

What it is. Act on a meter you are not standing next to: disconnect / reconnect, read status. OMS page: “Remote disconnect and reconnect; read meter status” — 6 votes.

Typical tasks to train. Confirm last-heard and relay state before a command. Fail safely when NAN/WAN is down (wiki: rural backhaul breaks cloud-first designs). Distinguish meter-level connect from DCU-level and cloud-level “online.” Log who sent the command.

Self-paced later: command list + failure modes. Custom later: that feeder’s radio and DCU. Related: metering topology note · wireless telecom map. Do not score IEEE 2030.5 / OpenADR here — those are Phase 3 grid-facing on the roadmap.

Self-hosting

What it is. Run the head-end / operator app on infrastructure you control. OMS page: “Self-hosting: containerised, documented, one-command deployment” — 6 votes. Pre-session outcomes also recorded a self-host burden: operators who take hardware/software/cloud still need a shared open customer-management codebase rather than each rebuilding a full platform.

Typical tasks to train. Choose hosted vs self-host vs hybrid. Stand up, back up, restore. Patch the host. Know what you still cannot do without keys. One-command deploy for which stack: unknown — do not treat the vote wording as a shipping product.

Self-paced later: public compose/docs once they exist. Custom later: that operator’s IT capacity (OMS hosted-OMS-service row had 1 vote; operator takeover of ThunderCloud 2.0 / Nimbus had 0 — cite the OMS page). Wiki: TC 2.0 describes a ThunderCloud self-host path; OpenAMI names MPM / OpenEMS / ThunderCloud as backends. OpenEMS on that page: no support yet for SparkNet aggregation, DLMS/COSEM, or STS.

Upgrading systems

What it is. Move firmware, head-end, or platform version without bricking revenue collection. Demand source: stated with this catalog request. Not a named row on the 22 Sep 27-feature sheet — no vote number invented here. The OMS page does have a separate live poll on migration timeline (already printed there).

Typical tasks to train. Backup before upgrade. Order of meter vs DCU vs cloud. Rollback. What breaks first if the old platform goes away (OMS poll themes: vending, free energy, no energy, data monitoring — counts stay on that page). Firmware update that needs encryption keys (pre-session EarthSpark / SparkNet-HTTP note).

Self-paced later: upgrade checklists once a stack publishes them. Custom later: that fleet’s mix (SparkNet / TC 2.0 / DLMS / STS-only). Do not invent a migration date or a certified upgrade path.

Monitoring and reporting

What it is. See the fleet and produce reports someone else will actually use. On the OMS page this is a vote block (“Data, monitoring and reporting” — 32 · 27%), not one feature. A named row inside that block: aggregated monitoring and reporting export for funders — 5 votes. Interval data (hourly or 15-minute) outscored 1-minute on that same sheet.

Typical tasks to train. Choose resolution you can backhaul. Build a site / feeder / customer roll-up. Export a funder pack. Alarm on last-heard and tamper — at the correct layer. Do not treat unused high-resolution data as free (OMS draft Day 1 theme).

Self-paced later: report templates + VMRS field list. Custom later: that funder’s columns. Wiki: VMRS · northbound MQTT · OpenAMI leakage / telemetry.

And others

What it is. Room for skillsets the named list did not cover. Not a fake complete survey. Add a row when someone names the work — do not fill from memory.

Already on the OMS mid-table (cite that page; not expanded into modules here): vendor-independent STS token generation · DLMS meters direct · SparkMeter legacy fleet (SparkNet & TC 2.0) · time-of-use + load limits · convert meters to STS-only and drop comms · event push / webhooks · key-change tokens.

Wiki-tracked work that may need training (not pre-session named rows):

• Architecture class / procurement shortlist — prepaid vs AMI vs proprietary mesh; industry $/connection bands only. Vendor study. Lives in conception / planning / procurement.
• STS prepaid vending and key management — different from management tokens above. Topology note · OpenPAYGO listed as an open alternative. Escrow-of-keys was a pre-session theme, not a mandate.
• Field problems — theft, bypass, flat tariffs, DCU/backhaul. Overview · Problems.
• OpenAMI EMS / MeshEMS / Village Simulator — Power Africa workshop asked for a training session in a few weeks (no date here). Workshop results · MeshEMS · Village Simulator.
• Decommissioning and recycling — later phases. Hardware reuse, meter retirement, data retention after teardown: not specified.

Self-paced later / custom later: open. Do not invent hours or a certificate track for this bucket.