# EnAccess <> NFE Checkin - June 2nd 2026 ## Attendees - Aaron T. - Vivien B. - Obinna I. - Daniel M. ## Overview The call focused on whether MPM should evolve to better support grid-connected mini-grids, especially postpaid billing, meter integrations, and monitoring of batteries/solar assets. The team agreed the current direction is promising for the Nigerian mini-grid use case, but emphasized that new capabilities should be integrated carefully so the platform remains technically coherent and maintainable. ## Why the conversation happened Aaron raised a strategic question: whether the current MPM product is being pushed beyond its original design by supporting grid-connected mini-grids, or whether a new system should be built instead. Vivien and Daniel clarified that MPM was historically built as a mini-grid CRM and later adapted by solar home system companies by the newest work in Mozambique. However, new conversations with REI in Nigeria is increasingly steering it toward mini-grid needs again. ## Product positioning and strategic direction Vivien explained that MPM’s roots are in mini-grid operations and CRM workflows, not solar home systems, even though solar home system companies adopted it over time. He noted that recent demand from Mozambique and a larger contract in Nigeria are driving more mini-grid-specific work, including OEM integrations, dashboard hardening, and other adaptations. The team also discussed the upcoming PayGo Ops community edition, which may better serve some solar home system users. Vivien’s view was that this does not undermine MPM’s mini-grid identity; rather, it highlights that MPM should keep focusing on the mini-grid segment while remaining open to adjacent use cases where appropriate. ## Postpaid vs. prepaid metering A major topic was Aaron’s observation that the pilot became easier when the team moved away from a proprietary prepaid meter setup and adopted postpaid billing. Aaron had originally feared that MPM might be too biased toward prepaid workflows, and wondered whether postpaid mini-grid support would require an entirely new system. Daniel responded that prepaid metering is easier to support technically because the abstraction is straightforward: a customer pays, a tariff applies, and energy is delivered. Postpaid introduces more complexity because it requires tracking usage over a billing period, calculating debt/amount owed, and handling billing logic in a less linear way. Daniel said MPM already has some related concepts, but postpaid still requires careful design so the abstractions remain coherent. ## Metering and data acquisition lessons from the pilot Aaron described the operational problems they faced with a Chinese vendor, Kalin: the meters claimed to support both prepaid and postpaid, but the vendor did not expose meter data directly. Instead, the team had to use proprietary middleware APIs hosted by the vendor, which caused reliability issues, token-lockout problems, slow support response times, and pressure to place larger orders before the pilot was stable. To solve this, the team switched in March 2026 to locally sourced meters that are postpaid-only and expose data via RS-45/Modbus into a Raspberry Pi, which is then connected to the internet through a modem. This setup gave them direct access to meter data, reduced dependency on the vendor, and eliminated the operational risk of needing tokens from overseas just to unlock a customer meter. Aaron also noted that the meters are physically clustered in a single PDU, which makes wired connectivity practical in this pilot. Vivien pointed out that this works for dense apartment-complex style deployments, but would not translate well to rural, dispersed mini-grids where wireless communication is usually more appropriate. ## Open-source monitoring and OpenEMS integration Aaron said the pilot team had already contributed a plugin to OpenEMS so that usage data from the new meters can be read in real time. He suggested a future model where OpenEMS handles monitoring of meters, batteries, and solar assets, while MPM handles business functions such as billing, invoicing, and customer communication. Daniel and Vivien were receptive to this division of labor. Vivien emphasized that the goal should be integration rather than rebuilding existing open-source tools. He referenced the existing Prospect integration as a model: ideally, MPM should connect with external monitoring systems in a way that lets users move seamlessly between tools rather than duplicating functionality. ## Battery and solar support Aaron asked whether MPM was originally intended to handle batteries and solar generation data as part of mini-grid operations. Daniel clarified that this was not part of the original core focus. MPM’s main scope has been customer transaction management and business workflows, not system monitoring. That said, Daniel acknowledged that there is a gray area where battery or solar data affects billing, and therefore may need to be integrated into MPM workflows. He stressed that system monitoring should not simply be bolted on as a disconnected feature. Instead, the team should think carefully about where such data belongs, how it is modeled, and how it can be integrated without making the product overly complicated. ## Billing, customer visibility, and invoicing features Aaron demonstrated the pilot’s customer-facing web app, which lets customers see their usage, estimated bill, and end-of-month projection. The app refreshes automatically every six hours, with manual refresh available. This was intended to reduce uncertainty for customers and let them see charges before the monthly billing cycle closes. He also showed the microgrid manager billing interface, where customer data is imported, billing cycles are created monthly, invoices are generated, and payment links are attached through a payment service. Aaron highlighted this as one of the strongest parts of the pilot and argued that MPM should gain similar invoicing capability, alongside an integrated payment-provider flow and an OpenEMS data source. The group agreed that these were the most concrete candidate features to pursue. Aaron said his team could likely push the payment integration and invoicing work, while also helping define the OpenEMS plugin approach and continuing conversations with Nigerian partners. ## Nigeria and regulatory relevance Vivien stressed that Nigeria is especially relevant because it has an active mini-grid market, including grid-connected mini-grids, structured regulation, and tariff systems that resemble the use case Aaron is working on. Aaron agreed, noting that Uganda’s regulator is increasingly looking to Nigeria as an example for policy development, and that his team is preparing a paper to make the case for adopting elements of Nigeria’s regulatory framework. The discussion made clear that Nigeria is both a strong market for the problem and a promising source of practical solutions. Vivien also suggested Aaron could observe some conversations EnAccess has with other community members who are focussing on Mini-grids. ## Managing codebase complexity and simplification Later in the call, Aaron asked whether there should be a roadmap for removing or disabling legacy features from MPM, since long-running applications tend to accumulate unused functionality. Daniel said the team had spent much of 2025 removing things, but had recently shifted toward adding new capabilities. He agreed that managing complexity is an ongoing concern. Daniel distinguished between two kinds of simplification: - user-facing simplification, such as hiding advanced options by default or using more sensible defaults; - backend simplification, which is harder because core abstractions like “mini-grid” are deeply embedded in the codebase. Obinna added that from his experience, the team usually receives feature requests rather than removal requests. He suggested that if the roadmap included clearer visibility into unused functionality, he could help identify features that no one appears to use and also warn when something that looks unused is actually used by someone else. ## Key takeaways - MPM is still seen by the team as a mini-grid CRM, not just a solar home system platform. - Postpaid support is viable, but it needs deliberate abstraction design. - Direct meter integration and open data access are critical for reliable mini-grid operations. - OpenEMS is a strong candidate for handling monitoring, while MPM should focus on billing, customer/account management, and payment workflows. - The strongest near-term product opportunities are invoicing, payment-link generation, and an OpenEMS data-source integration. - The team should continue exploring simplification opportunities, but removal of legacy code or features needs a more explicit process and roadmap.