Product

• Capability Evaluation Criteria
• Microgrid OS
• Microgrid OS Evaluation
• GxF Platform Evaluation
• Microgrid Design with OpenSolar
• Target Architecture
• Metering
• Metering Evalutation
• Wired vs Wireless meters
• CalinMeter
• A2EI Data
• Storage
• Cost Analysis: Procurement and Shipment of 60kWh LFP BYD Batteries from China to Uganda
• Battery as a service Provider
• SRNE
• FENECon - Germany
• Solei Power - Uganda
• Billing
• Billing and Payment System evalutation
• Pesapal
• Microgrid Capability Map
• Microgrids 101
• OpenEMS
• Getting Started
• DDSU666 (Direct chint meter ) + mbpoll Command Reference
• Running OpenEMS Edge on a Raspberry PI
• DTSU666 3‑Phase + mbpoll Command Reference
• Pre-Commissioning Process for CHINT Meters
• Towards a Framework for Autonomous Microgrids

Capability Evaluation Criteria

Attribute	Cost	Interoperability	Long term relationship	Deployment readiness	Build Quality
1	over market price	proprietary standards, risk of vendor lock-in	cannot reliably communicate, needs aggressive follow up and management	timeline unclear or unknown	Questionable may need replacement anytime or unknown durability
3	close to or exactly at market price	use some open and proprietary standards	can communicate reliably but needs incentives to do so	timeline is known but is volatile or longer than what is needed	Acceptable could last 2 to 3 years
5	under market price	fully using open standards	communicates reliably and incentives are already aligned	timeline is known and predictable or within acceptable duration	Durable can last 3 years or more

Microgrid OS

Microgrid OS Evaluation

OS	Cost (money)	Interoperability	long term relationship	Deployment Readiness	Quality	Features
NewSunRoad Stellar
Remot by Innovex
Inhemeter
GxF by LF Energy
MicroPower Manager
Hyphae by LF Energy
OpenEMS
Sunalyzer

New Sun Road Stellar 

Stellar seems to have all the capabilities we want from their website but Michael (CTO) confirms that he is not sure that the meters are are using are supported 100%. They can likely monitor usage data but may not be able to remote on/off. It is proprietary. 

Remot by Innovex

The Innovex team has not been responsive to our email requests for more information about this. Also, their website seems to be frequently down. 

Inhemeter

We were not about to get a demo or even an order for meters out of this company. Their meters are known to be good quality but I think they are not interested in working with us because we are a small new company. 

GxF by LF energy 

This project is actually a macrogrid OS that currently still being open sourced. A number of key components like the GUI for smart metering is not yet open sourced. It is worth watching because it has potential to run for a microgrid because it has smart metering and public lighting capabilities. 

MicroPowerManager 

This is one looks very promising. Open source and field tested. I think it's ripe for us to take to production and prove it out. It also has an associated battery management capability which makes this community seem like a good fit for NFE. 

Hyphae by LF Energy

I think Hyphae has a bold vision for an autonomous microgrid. It currently only has peer to peer battery power interchange capabilities and no metering. Also not get field tested but has some simulation capabilities. 

GxF Platform Evaluation

Overview

GxF is an opensource platform (set of capabilities; metering, public lighting) for distribution of power on a grid. It is currently being used by and was donated to the open source community by a Dutch utility company called Alliander. 

Links

Here's some useful links from my discovery work on GxF

• Understanding it's capabilities
• Official docs
• Video Overview
• GxF on M1 Mac
• Microgrid Management Software 
  

Next Steps 

Continue deployment to digital ocean VM

• Start by reviewing all these packages and understanding which ones you want to deploy or explore whether it makes more sense to rebuild the latest release and deploy packages from that. 
• To run the GXF (Grid eXchange Fabric) platform, you generally need only a subset of the packages published in the OSGP GitHub organization—specifically, those that are direct dependencies for the platform's core services and adapters.
• GXF is a modular system, and the required packages depend on your deployment goals. Commonly, the following package types are used:
• Core Platform Packages – These include the main server components, messaging infrastructure, shared libraries, and authentication modules.
  • Protocol Adapters – Depending on your use case, you’ll need the adapters that communicate with your field devices (e.g., OSLP, DLMS, IEC61850).
  • Domain and WS Adapters – These provide domain-specific logic and web service endpoints (e.g., smart metering, microgrids, public lighting).
  • Shared Utilities – Supporting packages shared between multiple modules.

 Steps to Determine Required Packages

• Review the GXF Deployment Documentation: The official [GXF deployment guide](https://github.com/OSGP/open-smart-grid-platformdocumentation) lists the core components and adapters you need to deploy for a standard platform.
• Match Packages to Components: Identify which packages correspond to those components (e.g., "osgp-adapter-domain-smart-metering", "osgp-adapter-ws-publiclighting", etc.).

Focus on Smart metering Use Case: One of the maintainers tells the application’s current design allows you to deploy only the smart metering components, along with some core GxF components. You’ll need the following components for smart metering:

• core GxF components:
  • osgp-adapter-domain-admin
  • osgp-adapter-domain-core
  • osgp-adapter-ws-admin
  • osgp-adapter-ws-core
  • osgp-core
  • osgp-logging
• Smart metering specific components
  • osgp-adapter-domain-smartmetering
  • osgp-adapter-ws-smartmetering
  • osgp-protocol-adapter-dlms
  • osgp-throttling-service
  • osgp-secret-management
• Smart metering simulator
  • osgp-simulator-dlms-triggered
  • dlms-device-simulator-starter

These components do not contain any user interface but provide a SOAP interface for communication with the GxF platform. The user interface is currently not part of the open-source implementation.

• We could set up RESTful APIs and build a GUI we can use and contribute back to the community or we can also try to build a UI from the SOAP API available. Open to either, I don't know how much we can do with API only if we don't have a GUI.
  

Historical Context 

From Sander (Maintainer). I recommend you join the project mailing list, introduce yourself (I already did) and use it to ask questions along the way.. I have found it very useful and Sander is very helpful in responding there. 

We are currently in the process of creating an open-source containerized solution for deploying and testing GxF. With this solution it will be possible to run GxF locally in k3d - a lightweight wrapper to run k3s (a minimal Kubernetes distribution) in docker - and to run automated tests using cucumber. For this you will need at least 32 GB of RAM, 64 GB is preferable. The solution can be found here: https://github.com/OSGP/gxf-gitops. Container images can be found in https://github.com/orgs/OSGP/packages?repo_name=open-smart-grid-platform. Currently the gxf-gitops repository only contains the charts to deploy and test our flexible public lighting solution. The deployment of our smart metering solution is still work in progress.

As a side note, I would like to mention that the current smart metering implementation is specifically tailored to the Dutch market, so it would probably need several changes to make it operable outside of the Netherlands.

 

In the past we also used to have a distinct microgrids solution available, but as it was no longer used, we removed it from our codebase. However, the old microgrids components can still be found in the GitHub history:

• https://github.com/OSGP/open-smart-grid-platform/tree/release-5.28.0/osgp/platform/osgp-adapter-domain-microgrids
• https://github.com/OSGP/open-smart-grid-platform/tree/release-5.28.0/osgp/platform/osgp-adapter-ws-microgrids
• https://github.com/OSGP/open-smart-grid-platform/tree/release-5.28.0/osgp/protocol-adapter-iec61850
• https://github.com/OSGP/open-smart-grid-platform/tree/release-5.28.0/integration-tests/cucumber-tests-platform-microgrids

but they will require some serious dusting off to make them usable again.

Microgrid Design with OpenSolar

We have an OpenSolar NFE account, reach out to aaron.tushabe@nearlyfreeenergy.com for an invite. 

⚙️ View and Bookmark all Training & Support Links

Webinar Recordings

🎥 Design Training

🎥 Account Setup

🎥 MCS

🎥 Battery Control Schemes

Webinars

☀️ Weekly Training Sessions

View availability and book our dedicated UK training sessions.

Purchasing & Supplier Integrations

🎥 Segen

🎥 City Plumbing

Support

☀️ AI Chatbot Assistant

Get real-time live answers to your questions with our digital assistance

☀️ General Support Contact Form

Send enquiries, feedback and supporting information directly to our global 24 hour Mon - Fri support team. Tickets are the quickest most efficient way to receive support and guidance. Unfortunately, we can only offer very limited low-priority support via email.

☀️ 1-2-1 Support

Installers looking for 1-2-1 support can view our availability and book sessions directly. Click "Book a time" at the bottom of the page.

☀️ Online Resource Centre

An extensive online library of videos and tutorials.

Finance Integrations

🎥 Finance Training

Selina (domestic payment plans)

• Email: tom.watson@selinafinance.co.uk
• Call: 020 4525 8044
• Register here

Phoenix Finance (domestic payment plans)

• Email: jono@phoenix-fc.co.uk
• Book meetings: https://calendly.com/jono-9
• Call: 01923 333 256
• Register here

Smart Ease (commercial payment plans)

• Email: enquiries@smartease.uk
• Call: 033 3404 0695
• Register here

Scaffolding Integration

🎥 PVF Scaffolding Training

API Integrations

Learn more and view documentation

Target Architecture

Metering

Metering Evalutation

Attribute	Cost (money)	Interoperability	long term relationship	Deployment Readiness	Build Quality
Inhemeter	3	5	3	3	5
Gomelong Meter (no PLC meter with built-in relay)
Sagewood Meters
Calin Meter	?	5	5	?	5
Spark Meter	3	1	3	1	5
China Brandless Meter	5	1	3	3	1
iSmart Meter	1	5	3	1	3
Hoptele Meter	3	5	5	5	3

Inhemeter

China/UG based OEM. Edwin Cho is our contact. 0 774 667667, +86 135 3210 1631. 1way Meter boxed FOB 46Usd
Cloud Vending System 100 USD per month up to 1000 meters

Free On Board (FOB)
Which means not including shipping and inland transport and any clearance fees

Sagewood 

Sagewood is a UK based logistics supplier. +44 7831 135528 - Manoj

Got some feedback on this one . Here goes…
Hi Hilary, all good am still in china snd heading back tomrrow to uk.
China was on national holidays from 30 April to today May 5.
Now working on it.
I have discussed with the team - Due to small number of meters for the system, we suggest a cloud version so you don’t have to invest in hardware. Many endusers are doing this.
Meters we can handle but MOQ is around 2000 metres.
Or we can manufacture them to very with other orders. So you don’t have to worry about MOQ.
Allow me few days and I revert back. 

Hoptele 

China supplier / OEM. Single phase PLC meter. Wall mount with PLC support and inbuilt relay. DIN rail mount with PLC support but no inbuilt relay. 70 US per meter. No vending system. 

Gomelong 

China based supplier, has a local distributor in Uganda. Gomelong Meter (no PLC meter with built-in relay). May have none PLC option. Pricing for "digital meter" (probably with no relay) 127k UGX per unit. 

Spark Meter 

Kenya based. Proprietary system (Meters + AMI). 70 USD per meter. Comes with a DTU that requires line of sight to meters. 1 DTU per 2000 meters max. 600 USD per year per DTU. 

Calinmeter 

Have a DIN rail PLC with built-in relay. Waiting on quote. May also have AMI

iSmart 

Found these ones online. They also have a PLC with built-in relay. 

Wired vs Wireless meters

Wireless open standards 

Comparison

Protocol	Frequency	Range	Data Rate	Topology	Power Usage
Zigbee	2.4 GHz, 915/868 MHz	Short	Up to 250 kbps	Mesh, Star	Very Low
LoRaWAN	868/915 MHz	Long	0.3–50 kbps	Star	Extremely Low
Wi-SUN	868/915 MHz	Medium to Long	50–300 kbps	Mesh	Low to Medium
Bluetooth LE	2.4 GHz	Short	125 kbps–2 Mbps	Star, Mesh	Very Low
IEEE 802.11ah	Sub-GHz (~900 MHz)	Medium	Up to Mbps	Star, Tree	Low
IEEE 802.15.4	Various	Short–Medium	20–250 kbps	Mesh, Star	Very Low
Thread	2.4 GHz	Short	250 kbps	Mesh	Very Low

Recommended for Residential Microgrid Applications in Uganda:

• LoRaWAN: If covering a large geographical area (kilometers), due to its excellent range, penetration, and low power use.

• Wi-SUN: For robust, medium-to-large-scale smart metering networks, especially if a mesh topology is desirable.

• Zigbee/Thread: Ideal for dense residential areas where devices (meters) are closer together, benefiting from low power and reliable mesh networking.

Wired Open standards 

Comparison

Protocol	Standard	OSI Layers	Medium	Topology	Range	Data Rate	Typical Application Areas	Remarks
G3-PLC	ITU-T G.9903	Layers 1-2	Power Lines	Mesh, Star	Up to several km	2.4–35 kbps	Smart grids, AMI, smart meters	Robust, designed for noisy environments; supports IPv6, strong security
PRIME	ITU-T G.9904	Layers 1-2	Power Lines	Mesh, Star	Up to several km	21–128 kbps	Smart metering, distribution automation	Optimized for higher-speed PLC, widely used in European smart meter rollouts
IEEE 1901.2 PLC	IEEE 1901.2	Layers 1-2	Power Lines	Mesh, Star	Up to several km	2.4–500 kbps	Smart grids, smart cities	High interoperability, IPv6 support; ideal for utility and smart city deployments
M-Bus (Meter-Bus)	EN 13757	Layers 1-2	Twisted pair cable	Bus	Up to ~1 km	0.3–38.4 kbps	Meter reading (water, heat, gas)	Widely used in Europe; reliable, low-cost wired solution
KNX	ISO/IEC 14543-3	Layers 1-2	Twisted pair cable	Bus, Star, Tree	Up to ~1 km	9.6 kbps	Building automation, home control	Open standard for building automation, popular in Europe
BACnet MS/TP	ASHRAE 135	Layers 1-2	RS-485 twisted pair	Bus	Up to ~1.2 km	9.6–115.2 kbps	Building automation, HVAC controls	Common in building and industrial automation; robust, scalable
Ethernet	IEEE 802.3	Layers 1-2	CAT5/CAT6 cable	Star, Tree	Up to ~100 m	10 Mbps–100 Gbps	Networking backbone, smart buildings	High-speed, standard networking; widely supported across industries
RS-485 (EIA-485)	EIA-485	Layers 1-2	Twisted pair cable	Bus	Up to ~1.2 km	Up to 10 Mbps	Metering, industrial control systems	Simple, robust, widely used for serial data transmission
CAN Bus	ISO 11898	Layers 1-2	Twisted pair cable	Bus	Up to ~1 km	Up to 1 Mbps	Automotive, industrial automation	High reliability, robust error detection, common in harsh environments

Recommended Wired Protocols for Residential Microgrid Metering (Uganda)

• PLC-based (e.g., G3-PLC or IEEE 1901.2):

  • Ideal due to existing infrastructure (power lines).

  • Good for scalable, reliable deployments.

• RS-485:

  • Robust, simple wiring suitable for smaller clusters.

  • Common for direct-wired connections (local clusters).

• M-Bus:

  • Suitable if integrating gas, water, or heat metering alongside electricity

Comparison between wired and wireless 

Aspect	Wireless Option (Wi-SUN/LoRaWAN)	Wired Option (G3-PLC, RS-485)	Recommendation
Installation Cost	🟢 Lower	🔴 Higher (cabling, labor)	Wireless ✅
Maintenance Cost	🟡 Moderate (battery replacements)	🟢 Low (no batteries required)	Wired ✅
Reliability	🟡 Medium (environment dependent)	🟢 High (consistent, stable)	Wired ✅
Scalability	🟢 High (easy additions)	🔴 Moderate to low (harder additions)	Wireless ✅
Range/ Coverage	🟢 Good (with repeaters)	🟢 Excellent (using PLC)	Wired (PLC) ✅
Security	🟡 Good (depends on setup)	🟢 Very Good	Wired ✅
Installation Time	🟢 Short	🔴 Longer	Wireless ✅
Physical disruption	🟢 Minimal	🔴 High (trenching, wiring)	Wireless ✅

💡 Recommended Choice: Hybrid or G3-PLC

📌 Primary Recommendation: G3-PLC (Wired)

Given your scenario (dense apartment blocks with existing electrical infrastructure and meters located closely on the ground floor), G3-PLC offers significant advantages:

• Low Ongoing Maintenance: No batteries to manage.

• High Reliability: Stable signal leveraging existing wiring.

• Cost-effective (long-term): Minimal ongoing costs after initial installation.

• Robust & secure: Highly suited for apartment complexes.

📌 Alternate Recommendation: Hybrid (PLC Backbone + Wireless Endpoints)

If flexibility or future expansions matter, consider a hybrid setup:

• Use G3-PLC within each block to connect meters reliably to a local gateway.

• Connect block gateways to a central system via wireless (Wi-SUN or LoRaWAN). This reduces physical disruption between buildings while maintaining the reliability within each block.

This hybrid method provides the best of both worlds—flexibility and low maintenance.

Links

Chatgpt detailed thread

CalinMeter

We got the API docs here: Calin_API_for_NFE.postman_collection.json

User Manuals 

• User instructions for the CA168-S Single-phase electricity meter (1).pdf
• CA168 Din Rail Meter- Technical Specification (1).pdf
• Installation Guide - Calin LoraWAN Smart Meters.pdf

⚡ CalinMeter Status Codes – Postpaid Quick Reference & Action Guide

---

📑 Common Meter Status / Short Codes (Postpaid Use)

Code	Meaning	Action
01	Cumulative total active kWh consumption	Record/check usage trend
14	Load threshold	Compare with customer load, adjust if configured too low
31	Current total active power	Check load at moment of query
35	Current total power factor	If persistently low, investigate load/PF correction
40	Number of meter cover open events	Check tamper log; reseal if necessary
41–45	Last 1st–5th cover open times	Verify tamper history
46	Number of overload trip events	Review load demand; advise upgrade if frequent
47–51	Last 1st–5th overload trip times	Identify when overloads occurred
52	Number of power down events	Check supply reliability
53–57	Last 1st–5th power down times	Cross-check with outage records
58	Number of phase down events	Investigate supply-side issues
87	Reason for relay disconnecting	Use table below for action

(Codes related to credit/tokens are ignored in postpaid setups.)

Perfect — let’s build a lookup table that maps your AMI responses (1000–1025) directly to the Code 87 disconnect sub-codes, with meaning and field action tailored for postpaid deployments.

⚡ AMI Operating Status Code Lookup (Postpaid Mode)

AMI Code	Code 87 Sub-Code	Meaning	Field Action
1000	00	Relay Closed (normal supply)	✅ No action, meter supplying load.
1001	1	No Credit	(Ignore in postpaid) — not applicable.
1003	3	Over Power (load exceeded threshold)	Check load vs. configured trip limit; advise reduction or adjust threshold.
1004	4	Relay Test	No action needed — relay was tested.
1005	5	Open Upper Cover (tamper)	Reseal cover + enter clear tamper token.
1006	6	Open Terminal Cover (tamper)	Reseal cover + enter clear tamper token.
1007	7	Remote Disconnect	Confirm backend/HES instruction; reconnect if not intentional.
1008	8	Not-active (meter not commissioned)	Commission meter (default code: 12345).
1009	9	Over Current	Inspect load for surges; advise customer or adjust protection.
1011	11	Over Voltage	Supply voltage too high; report to utility/feeder operator.
1012	12	Under Voltage	Supply voltage too low; report to utility/feeder operator.
1013	13	Current Reverse (possible tamper/wiring issue)	Inspect wiring; correct polarity; clear tamper if needed.
1014	14	Open Enclosure Cover (tamper)	Reseal + enter clear tamper token.
1015	15	Magnetic Field Interference (tamper)	Investigate possible magnet tampering; clear tamper.
1016	16	Current Imbalance	Check for abnormal phase imbalance; troubleshoot load.
1017	17	Neutral Line Interference	Inspect neutral wiring/tamper.
1018	18	Bypass (illegal connection)	Investigate and escalate if confirmed.
1021	21	Voltage Imbalance	Investigate feeder phase imbalance.
1022	22	Thermal Overload	Meter overheating; check ventilation/load; allow cooling.
1023	23	Low Power Factor	Check load PF; recommend correction (capacitors).
1024	24	Tariff Error	Backend tariff configuration issue; escalate to AMI admin.
1025	25	Remote Reconnect + Local Trip	Local condition (e.g., overload/tamper) persists; troubleshoot before reconnection.

---

✅ Key Notes for Postpaid Teams

• Ignore credit-related codes (1001, and codes tied to tokens/residual amounts).

• Focus on tamper (1005, 1006, 1014, 1015, 1018), load/power quality (1003, 1009, 1011–1013, 1016–1023), and backend issues (1007, 1024, 1025).

• Always check AMI Code → Action before deciding if a site visit is required.

---

Would you like me to now regenerate the PDF reference card with this full 1000–1025 lookup table included, so your team doesn’t need to flip between guides?

✅ Quick Action Guide Summary

• Tamper-related (5, 6, 14, 15, 18) → Reseal + enter clear tamper token.

• Load/power issues (3, 9, 11, 12, 16, 21, 22, 23) → Inspect loads and supply conditions; report or advise customer.

• Backend-related (7, 24, 25) → Confirm with HES/AMI admin.

• Commissioning (8) → Activate with code 12345.

Examples

Example #1

You query the meter for meter operating status and you get back this 

Answer 

Meter operating status = 1008

Step 1: Interpret the Code

• In many AMI/CalinMeter integrations, codes like 1000 and 1008 map directly to relay/disconnect statuses (Code 87 sub-codes).

• 1008 = Sub-code 8 under Code 87.

• From the guide:

   

  • 8 → “Not-active” → Meter not commissioned.

   

Step 2: What This Means in Postpaid Setup

• The meter is physically installed, but it hasn’t been commissioned.

• In this state, the meter will not supply power, regardless of load or tariff configuration.

Step 3: Field Action (from Quick Action Guide)

• Action: Commission the meter using the commissioning token/code.

   

  • Default commissioning code is 12345.

  • Enter this via the CIU (Customer Interface Unit) or backend if supported.

   

• Once successfully commissioned:

   

  • Tamper detection is activated.

  • Relay will close and supply will start flowing.

   

✅ Summary:

Your AMI response of 1008 means “Meter not commissioned.”

👉 To resolve: Enter 12345 (or your site-specific commissioning token) on the CIU/backend to activate the meter.

---

Example #2 

Answer

Great — let’s now map 1000 through the same guide.

Case: Meter operating status = 1000

Step 1: Interpret the Code

• In the AMI integration, 1000 corresponds to Code 87 sub-code 00.

• 00 → “Relay Closed”.

Step 2: What This Means in Postpaid Setup

• The meter is active and commissioned.

• The relay is closed, meaning the meter is supplying electricity normally.

• No tamper or abnormal condition is blocking supply.

Step 3: Field Action (from Quick Action Guide)

• Action: No intervention needed.

• Record this status if troubleshooting, since it confirms the meter is healthy and delivering power.

✅ Summary for your case:

Your AMI response of 1000 means “Relay Closed – supply ON.”

👉 Everything is normal; no technician action required.

⚡ So together:

• 1000 = Relay Closed (meter supplying power)

• 1008 = Not-active (meter not commissioned; activate with commissioning code)

A2EI Data

Thank you for showing interest in our data and our efforts here at the A2EI!

We are happy to provide you with our latest data releases from our Solar Killed the Generator Star Project in Nigeria, our clean cooking pilots, and our research into productive-use appliances in East Africa. Please find a detailed summary of each dataset and latest release below.

Please drop us a line via datadatadata@a2ei.org if you have any comments or questions, or in case you would like to unsubscribe from receiving updates.

Most recent data releases SKGS

06.04.2022 The A2EI set out to provide the sector with an open-source hardware
solar business system. Two years later, we have not only made the solar
generator available, but sold over 1,000 systems. Every solar
generator is sending real time data on consumption and system state,
which allows the A2EI to share millions of data points with the sector
as open-source data.

Please download our SKGS Project Update and Data Release Report here.

Download the associated data and readme here.

29.04.2020 To
date, we have over 215 smart meters (and counting) connected to small
scale generators and grids in Nigeria, located within multiple markets
across several regions.
You can download the raw data, the meter list as well as the README here.
Find some brief release notes here.
Please find the Executive Summary here.

02.06.2020 Please find our analysis of generator usage during COVID-19 here.

Latest data releases Clean Cooking

15.11.2021 In a new comprehensive data release report, the A2EI analyses the entire data collected by our smart meters monitoring the usage of electric pressure cookers (EPCs) by 100 pilot users in rural Tanzania from March 2020 to May 2021.
Please download the data release report here.
Download the data frames here.
Download the Readme here.

16.07.2021 The A2EI has been part of a feasibility study to pave the way for mass distribution of electric hotplates to rural households in Malawi. Please download the Study of Hotplate & Grid Use in Rural Malawi here and access the associated data here.

Latest data releases Productive Use

14.07.2021 We are sharing our learnings of successful ventures in the agricultural productive use appliance sector by our first "Entrepreneur in Residence", Imara Tech, and are proposing a way forward that we believe could increase the likelihood for successful product development. Download the summary of learnings here.

21.09.2020 The Access to Energy Institute has developed a systematic methodology and published a report to jointly discuss the question what makes or breaks a successful solar-powered productive-use appliance - and to help find solutions for successful adoption and scaling.
Download the report here.
Please find the associated data and materials here.

Your feedback is very warmly welcomed. We believe that sharing our data is paramount to unlocking further entrepreneurship and engineering, which in turn will help us crack the many nuts of providing a reliable, clean and affordable universal energy supply. In our efforts to deliver meaningful data, we need your feedback in order to collect further data points and to make adjustments to our current measuring practices.

For now, we wish you a wonderful day...and cheerful data crunching!

All the best,
your A2EI Team

Storage

Cost Analysis: Procurement and Shipment of 60kWh LFP BYD Batteries from China to Uganda

1. Executive Summary:

This report provides a comprehensive cost estimate for purchasing and shipping a 60kWh Lithium Iron Phosphate (LFP) battery pack manufactured by BYD from China to Uganda. The analysis encompasses the estimated purchase price in China, various shipping options and their associated costs, and the import duties and taxes applicable in Uganda. The total estimated cost is subject to considerable variation depending on factors such as the prevailing market price of batteries, the chosen shipping method (sea or air freight), and the specific import duties levied by the Ugandan authorities at the time of import. This report outlines a potential cost range to aid businesses in Uganda in their procurement planning and financial forecasting for such a significant component.

2. Introduction:

BYD (Build Your Dreams) stands as a prominent global manufacturer of rechargeable batteries, including Lithium-ion and LFP chemistries, with a significant presence in the electric vehicle and energy storage sectors.¹ The company's LFP batteries are particularly recognized for their enhanced safety features and cost-effectiveness, making them a preferred choice for a wide array of applications, from electric vehicles to stationary energy storage systems.¹ Given BYD's established position in the battery market, this report aims to provide a detailed cost analysis for an entity in Uganda seeking to procure a 60kWh LFP battery pack from this leading Chinese manufacturer. This analysis will delve into the primary cost drivers, including the initial purchase price of the batteries in China, the logistical expenses associated with shipping to Uganda, and the governmental levies in the form of taxes and duties imposed by both countries. Understanding these components is crucial for accurate budgeting and informed decision-making for any organization undertaking such an international procurement.

3. Estimated Purchase Cost of 60kWh BYD LFP Batteries in China:

The landscape of lithium-ion battery pricing in China has been characterized by a notable downward trend, primarily influenced by decreasing raw material costs and heightened competition among manufacturers.⁴ This trend is particularly evident in the pricing of LFP batteries, which generally exhibit a more competitive cost structure compared to Nickel Cobalt Manganese (NCM) batteries.⁶ Recent industry reports suggest that the price of LFP battery cells in China, which stood at approximately $70 per kilowatt-hour (kWh) in the near past, was anticipated to undergo substantial reductions throughout 2024, with further potential decreases projected for 2025.⁴ Some forecasts even indicated the possibility of LFP cell prices falling below $56/kWh by mid-2024 and potentially reaching as low as $36/kWh by 2025.⁴

Examining online marketplaces such as Alibaba and Made-in-China reveals a variety of BYD LFP battery products listed by different suppliers, with prices varying based on factors like capacity and the specific vendor.¹⁶ Given these fluctuating market conditions and supplier-specific pricing, it becomes apparent that a precise, fixed purchase price is difficult to ascertain. Instead, a more realistic approach involves considering a price range based on the available data.

Based on the per kWh price ranges identified in the research, the estimated purchase cost for a 60kWh BYD LFP battery pack in 2024 can be projected. Utilizing the lower end of the price spectrum at around $49/kWh ¹² and the higher end at approximately $70/kWh ⁴, the following cost range can be estimated:

Table 1: Estimated Purchase Cost Range of 60kWh BYD LFP Batteries in China (2024)

Price per kWh (USD)	Estimated Cost for 60kWh Pack (USD)
Low Estimate: 49	2,940
Mid Estimate: 60	3,600
High Estimate: 70	4,200

This suggests that the purchase cost for a 60kWh BYD LFP battery pack could range from approximately $2,940 to $4,200 based on 2024 price levels. It is important to note that potential price reductions anticipated for 2025 could further lower these estimates.

For sourcing these batteries, platforms like Alibaba and Made-in-China serve as potential avenues, hosting numerous suppliers and distributors of BYD batteries.¹⁶ Several specific companies have been identified as offering BYD battery products.¹⁶ Additionally, BYD itself operates an energy storage division, which could be a direct point of contact for procurement.²⁵ While online platforms offer a broad selection of suppliers, engaging directly with BYD or their officially recognized distributors might provide enhanced assurance regarding product quality and potentially more favorable pricing terms, especially for substantial orders like a 60kWh battery pack.

4. Shipping Cost Analysis: China to Uganda:

Transporting a large and heavy item like a 60kWh battery pack from China to Uganda necessitates careful consideration of the available shipping methods, each with its own implications for cost and transit time. Sea freight generally emerges as the more economical option for such substantial cargo.³⁷ Within sea freight, two primary options exist: Less than Container Load (LCL) for smaller shipments that don't fill an entire container, and Full Container Load (FCL) for larger volumes.³⁷ The typical transit time for sea freight from China to Uganda ranges from 5 to 8 weeks.³⁸

Conversely, air freight offers a significantly faster transit time, typically between 7 to 10 days for standard air freight and 2 to 4 days for express services.³⁸ However, this speed comes at a considerably higher cost compared to sea freight.³⁷

Estimating the precise shipping costs requires considering the weight and volume of the 60kWh LFP battery pack. Research suggests that a battery pack of this capacity can vary in weight depending on the manufacturer and design, ranging from approximately 438kg for a Tesla Model 3 battery ⁴⁰ to over 700kg for a Delong battery pack.⁴¹

Based on these weight figures, the estimated cost for air freight, which is typically calculated per kilogram, can be projected. Using a cost range of $7.5 to $10 per kg ³⁷, the air freight cost for a 60kWh battery pack could range from $3,285 (438kg * $7.5/kg) to $7,120 (712kg * $10/kg).

For sea freight, the cost is often determined by volume, particularly for LCL shipments, with rates ranging from $150 to $190 per cubic meter.³⁷ While the exact volume of a 60kWh battery pack was not explicitly available in the research, its substantial size likely makes an FCL shipment (using a 20-foot container) a more practical approach. The cost for an FCL 20-foot container from China to Uganda is estimated to be between $4,000 and $6,000.³⁷

Table 2: Estimated Shipping Cost Comparison (Sea vs. Air Freight)

Shipping Method	Cost Metric	Estimated Cost (USD)	Transit Time
Sea Freight (LCL)	$150 - $190 / m³	Requires Volume Data	5 - 8 weeks
Sea Freight (FCL 20ft)	Per Container	$4,000 - $6,000	5 - 8 weeks
Air Freight	$7.5 - $10 / kg	$3,285 - $7,120	7 - 10 days (Std)

The selection of the shipping method will have a significant impact on the total cost. Sea freight offers substantial cost savings but necessitates a longer lead time, while air freight provides speed at a considerable premium.

Engaging a freight forwarder is a common practice for international shipments to manage the complexities of logistics and customs procedures.³⁷ These services typically involve additional fees covering documentation, customs clearance in China, and overall shipment coordination. Furthermore, it is important to anticipate potential surcharges such as fuel adjustments, port handling fees, and other miscellaneous charges that can add to the base shipping costs. Therefore, when budgeting for the shipment, an allowance for freight forwarder fees and these potential unforeseen surcharges should be included to ensure a more accurate overall cost estimation.

5. Tax and Duty Implications:

Navigating the tax and duty implications in both China and Uganda is a critical aspect of the overall cost analysis.

In China, the research material does not explicitly mention specific export taxes levied on batteries. While standard export procedures and minor administrative fees might be applicable, significant export duties on this commodity appear unlikely based on the provided information. Nevertheless, it is prudent to verify this with the chosen supplier or a freight forwarder based in China to preempt any unexpected charges at the point of export.

Uganda, on the other hand, has specific import duties and taxes that will apply to the incoming battery pack. Notably, Uganda recently imposed a 25% import duty on electric vehicles, hybrid vehicles, and electric motorcycles.⁴⁸ While batteries are not explicitly listed in this category, their fundamental role as a core component in both electric vehicles and energy storage systems strongly suggests that they are highly likely to be subject to this new import duty. Under the East Africa Customs Union (EACU) common external tariff, most finished products attract a 25% duty, further supporting the likelihood of this tariff applying to the battery pack.⁵⁰ This import duty is expected to be a significant contributor to the overall cost of importing the 60kWh LFP battery pack.

In addition to import duties, Uganda levies a Value Added Tax (VAT) at a standard rate of 18%.⁵⁰ This VAT is typically calculated on the Cost, Insurance, and Freight (CIF) value of the imported goods, which includes the purchase price, shipping costs, and the import duty itself.⁵² Therefore, the 18% VAT will be applied on top of the combined cost of the battery, its shipment, and the 25% import duty, leading to a further increase in the total expenditure.

Other relevant taxes in Uganda include a 1.5% infrastructure tax on imports, designed to fund railway infrastructure development.⁵⁰ Additionally, a 15% withholding tax may be applicable to imported goods and services, although the specific applicability to batteries warrants confirmation with the Ugandan tax authorities.⁵⁰ While these taxes are individually lower than the import duty and VAT, they will collectively contribute to the overall tax burden associated with the import.

It is important to highlight that the Ugandan government offers potential tax exemptions and incentives for local manufacturers involved in the electric vehicle sector. Entities manufacturing electric vehicles, electric batteries, or charging equipment, and meeting specific criteria such as employing at least 80% Ugandan citizens, utilizing at least 80% locally sourced raw materials (where available), and meeting minimum investment thresholds, might be exempt from the 25% import duty and stamp duty.⁴⁸ If the importing entity qualifies under these provisions, they could potentially realize significant reductions in the final cost.

To provide an estimated range for the import duties and taxes in Uganda, the following table illustrates the potential breakdown based on the low and high estimates for the purchase cost and shipping (using sea freight as the lower shipping cost):

Table 3: Breakdown of Estimated Ugandan Import Duties and Taxes (Based on Sea Freight)

Item	Low Estimate (USD)	High Estimate (USD)
Estimated Value of Goods (Purchase + Shipping)	6,940	10,200
Import Duty (25% of Estimated Value)	1,735	2,550
VAT (18% of (Estimated Value + Import Duty))	1,561.20	2,295
Infrastructure Tax (1.5% of Estimated Value)	104.10	153
Potential Withholding Tax (15% of Estimated Value)	1,041	1,530
Total Estimated Taxes and Duties	4,441.30	6,528

Note: The "Estimated Value of Goods" in the Low Estimate scenario uses the low purchase cost ($2,940) + the low end of the FCL sea freight cost ($4,000). The High Estimate uses the high purchase cost ($4,200) + the high end of the FCL sea freight cost ($6,000).

6. Total Estimated Cost and Breakdown:

Consolidating the estimated purchase cost, shipping cost (considering both sea and air freight for a comprehensive range), and the total estimated taxes and duties, we can arrive at an overall cost projection:

Table 4: Consolidated Total Estimated Cost Range

Cost Component	Low Estimate (USD)	High Estimate (USD)
Estimated Purchase Cost	2,940	4,200
Estimated Shipping Cost (Sea Freight)	4,000	6,000
Estimated Shipping Cost (Air Freight)	3,285	7,120
Estimated Taxes and Duties	4,441.30	6,528
Total Estimated Cost (Sea Freight)	11,381.30	16,728
Total Estimated Cost (Air Freight)	10,666.30	17,848

The total estimated cost for purchasing and shipping a 60kWh LFP BYD battery pack from China to Uganda could range significantly, potentially from approximately $10,666.30 (low purchase cost + low air freight + low taxes/duties) to $17,848 (high purchase cost + high air freight + high taxes/duties). If sea freight is chosen, the range would be approximately $11,381.30 to $16,728.

7. Key Considerations and Recommendations:

For any entity in Uganda looking to undertake this procurement, several key considerations and recommendations should be taken into account:

• Supplier Negotiation: Actively engage in negotiations with potential battery suppliers in China to secure the most competitive purchase price, especially when dealing with larger order volumes.
• Incoterms: Clearly define and agree upon the Incoterms with the chosen supplier. These terms dictate the responsibilities and costs associated with transportation and delivery, including who bears the risk at different stages of the shipping process.
• Shipping Insurance: Secure adequate shipping insurance to protect against potential damage or loss of the valuable cargo during its transit from China to Uganda.
• Quality Control: Implement stringent quality control measures in China, preferably through on-site inspections before shipment, to ensure the battery pack meets the required technical specifications and quality standards.
• Customs Clearance in Uganda: Partner with a reputable and experienced customs broker in Uganda. Their expertise will be invaluable in navigating the import clearance procedures, ensuring compliance with all Ugandan regulations, and potentially expediting the process.
• Verification of Import Duties and Taxes: It is strongly recommended to directly contact the Uganda Revenue Authority (URA) or consult with a qualified tax professional in Uganda. This step is crucial to obtain the most up-to-date and accurate information regarding import duties, VAT rates, and the applicability of any potential exemptions for battery imports. The information provided in this report is based on currently available data but is subject to change.
• Exploring Local Suppliers: While the focus of this report is on importing from China, it might be worthwhile to briefly explore the possibility of sourcing similar batteries from local suppliers within Uganda or the broader East African region. However, the availability and cost-effectiveness of BYD LFP batteries through these channels may be limited.
• Long-Term Cost Analysis: When evaluating the overall cost, consider the long-term benefits associated with LFP batteries, such as their extended lifespan, high cycle life, and potentially lower maintenance requirements compared to other battery chemistries. These factors can contribute to a more favorable total cost of ownership over the operational life of the battery pack.

By carefully considering these recommendations and conducting thorough due diligence, the procuring entity in Uganda can better navigate the complexities and costs associated with importing a 60kWh LFP BYD battery pack from China.

Battery as a service Provider

SLS energy based in Rwanda 

 

Cost: USD 4.40-6.48 kwh of system capacity available per month. Also depends on the duration of the lease. 

 

 

SRNE

See product catalog here: https://www.srnesolar.com/

They have a factory showroom in Naguru. 

Pricing from the factory showroom below. Full price list here:Uganda SRNE item price list.pdf

• 5.12 KW battery - 3.22m UGX
• 6kw inverter - 3.74m UGX
• 10kw inverter - 4.611m UGX
• 12kw inverter - 7.673m UGX

Quote from a thirrdparty local supplier is attached here. Quote-105 (1).pdf. 

Datasheet here: SRNE_HESP series_EU_48V_3.6_6kW_230V_Single-Phase_Hybrid_Solar Storage Inverter_Datasheet_V1.2[20250618] (1).pdf

Modbus Protocol: SRNE Solar Charge Inverter MODBUS Protocol1.96 (1).pdf

FENECon - Germany

They shared their quote here Fenecon quote.pdf. It's a detailed plug and play system at about 10k USD for 20kWh. 

Solei Power - Uganda

https://www.soleilpower.ug/

They are offering LFP batteries (locally manufactured) with BMS. 

They quoted: 

Billing

Billing and Payment System evalutation

Attribute	Cost (money)	Interoperability	long term relationship	Deployment Readiness	Quality
Pesapal	1	3	5	5	5
Jumia Pay
Pegasus
Kitegateway	3	3	5	3	3
Stripe Atlas
Flutterwave
Stanbic	3	3	5	3	3

Pesapal

• Saves Time & Cost: Rids off the time and resources of having to register orders & bookings manually.
• Drive Sales 24/7: Push for sales all day as long as you are open without fear of overbookings
• Reduce risk on Fraud: All payments are posted in real-time reducing risk of handling payments manually
•  You can run promotions on social media pages using links that will direct guests to place direct bookings to any property as well as to complete payment. i.e.https://payments.pesapal.com/wildwaterslodge

• Arcadia Lodges -https://arcadialodges.reserveport.com/
• Imperial Hotels -https://imperialhotels.reserveport.com/
• BMK House - https://bmkhouse.reserveport.com/

• Fast set up and training in 24 hours  
• Accept VISA , MasterCard & Mobile Money payments
• Process MTN Mobile Money payments
• Customer receives physical receipts for Mobile Money and card payments, you also retain the merchant copies to help in reconciliations.
• Stable connection with both 4G + Wi-Fi
• Virtual Cards from Booking.com & Expedia can be charged  
• Tap and Go feature
• Next day settlement
• Settlement to any Bank in Uganda
• Very competitive transaction fees .
• Access real-time reports
• Branded receipt with your company logo
• Integrate with any 3rd party POS system
• Mitigate fraud and human error during reconciliation

• Card rate   per transaction- 2.5%
• mobile money per transaction is 2%
• Online Rate per transaction- 3.5%
• Payment page set up-No cost
  
  

• Certificate of incorporation
• Form 20 
• Form 1
• TIN certificate
• IDs for the directors as per the form 20
• Cancelled cheque leaf or Bank statement/ Bank letter confirming bank details
• Completed signup form Pesapal Sign Up Form new.pdf

Questions from Aaron

Rates and Costs: In your current workflow, are these costs paid by customers (transparently) or charged to the merchant (hidden from the customer)? I pay my Yaka bill with MTN mobile money and when I pay for a token of 200k UGX, I am charged a 4150 UGX. I would like an approach where fees are transparent to the customer and not hidden. Customers are charged for every transaction they make see attached tariff Tarrif .png. In addition, merchant is charged commission of 3.5% per transaction

Payment links/Page: There's two options I would like to discuss here. There examples you shared for the lodges are one option. I would like to know if I can have the option of NFE appearing among the Pay Utility options on this page. Is that option available to us? This is not an available option, we can engage our developers on this.

Timelines for payment settlement: I would like to understand what your current average timelines are for settling funds to Merchants and Customers in the following cases

- Depositing funds on Merchant accounts after completion of a customer transaction. Let me know if these differ depending on the payment method the customer uses. Understanding these will help my team plan what our cashflow expectations if we decide to work with Pesapal. Settlement to merchant accounts takes 24hrs,we have developed this to have real time settlements to any bank or mobile money 

- Refunding customers for transactions done in error or overpayment. How long before a customer receives their fund on their orginal form of payment when NFE initiates are refund through PesaPal. Reversals to customers take effect from the time we are notified 

Documents required to be submitted: We are able to provide all these documents. I think you forgot to attach the sign-up form. See attached the sign up form

Lastly, in full transparency, this decision for our payments partner is still pending. We are currently evaluating other providers like Jumia Pay, Pegasus and setting up direct integrations with Telcos and Banks. We are aiming to make a decision on this by end of this week. Can we run a test account as you evaluate on the providers, this will give us the real feel.

Microgrid Capability Map

Microgrid Capabilities

This diagram shows the distinct capabilities the microgrid will have and the level of freedom each capabilities for each capability's current implementation offers the community the microgrid is serving. The diagram also show Aaron's understanding of the level of risk to the model associated with each capability given what we know about it. The capabilities without a risk profile assigned are not targeted to go live yet. 

Our capabilities are currently evolving across 3 generations. See our roadmap for progress updates. 

Generation 1 

• Hardware and or software propritary but accessible to small microgrid developers
• Hardware needs to be sourced from out of country 
• Cost of hardware purchase is high and so is cost of repair 
• Software licenses may be prohibitively expensive for small developers/communities because they are meant to target larger scale buyers 

Generation 2 

• Hardware still proprietary but can be locally sourced
• The software is open source and can be run by small developers or several SaaS providers giving developers options 
• Cost of hardware purchase is comparatively lower than Gen 1 and cost of repair is similar to Gen 1 since hardware is still proprietary 

Generation 3 

• Hardware is open, can be assembled in country or locally sourced
• The software is open source and so is the hardware firmware 
• Cost of purchase and repair of hardware is optimal 

 

Microgrids 101

This page and Wikipedia go into great detail to describe the concept of a microgrid. I would like to expand on that. During one of the weekly LF Energy Hyphae community checkin calls. When I explained that the initial phase for NFE's pilot microgrid will only include sub-metering a handful of homes. My colleague commented that "Oh, so it won't really be a microgrid yet". That statement stuck with me because I infant think it would be a microgrid. Which brings us to the question I would like to address in this article. What do I mean when I say "microgrid". 

Why definitions matter

Definitions generally matter because they help us communicate more clearly about the problem and how we are solving it. If we can agree on what we when when we say "microgrid" or "battery" then it makes it simpler to have conversations about which use-cases make sense for Hyphae's autonomous microgrid idea to address. 

First principles 

The term microgrid is a compound term. It consists of two terms micro and grid. I will start with the assertion that a microgrid is first a grid. If we are agreed there (pun not intended), then let's move on to define what we mean by grid. 

A grid, in it's most primitive form, is really a set of at least two energy assets, connected, usually by physical energy conducting medium like a wire for a purpose. Let's look at the picture below. 

The energy asset on the left (battery) is producing energy and the asset to the right is consuming energy. The two assets have been connected for a purpose and I think that's actually an a very simple example of a grid. Now this grid can include more than 2 assets and in the real world, there's often 100s of assets connected to a grid but for the sake of defining the term, I think this example will serve us well. 

If you are still with me, let's move on to the preceding term, the micro term. This term adds a layer of meaning to the Grid term. I propose that the distiction between Micro and Macro is really about scope of monitoring and steering for the "owner(s)" of the grid. If the scope is considered small by the owner and exists within the context of a larger grid, then we have ourselves a microgrid. 

Energy Assets 

These exist in various forms but here's an oversimplified list Energy_Asset_Taxonomy.csv. I share it here to example one's imagination on the kind of things that can exist on a microgrid. 

Supply-Side Assets (Energy Producers)

These generate or inject energy into the system.

Subtype	Example Assets	Notes
Renewable Generators	Solar panels, wind turbines	Often variable in output
Non-renewable Generators	Diesel gensets, gas turbines	Firm or dispatchable supply
Co-generation Units	CHP systems	Produce electricity + heat

Demand-Side Assets (Energy Consumers)

These draw energy from the system.

Subtype	Example Assets	Notes
Residential Loads	Lighting, HVAC, appliances	Often flexible for DR programs
Industrial Loads	Motors, manufacturing equipment	Usually larger and more steady
Electric Vehicles	While charging	Can also act as supply (see V2G)

Storage Assets (Bidirectional)

These can both store (consume) and release (supply) energy.

Subtype	Example Assets	Notes
Battery Storage	Lithium-ion, lead-acid	Fast response, scalable
Mechanical Storage	Flywheels, pumped hydro	Used in larger systems
Thermal Storage	Ice storage, molten salt	Stores heat, not electricity

Hybrid/Prosumer Assets

Assets that both consume and produce energy as part of normal operation.

Subtype	Example Assets	Notes
Solar + Battery Systems	Rooftop PV with integrated battery	Common in homes & businesses
EVs with V2G	Electric Vehicles (bi-directional)	Vehicle-to-grid capable
Smart Appliances	Can adjust operation dynamically	May support DR/load shifting

Monitoring & Steering Assets (Support Infrastructure)

These don’t directly consume or produce energy, but enable management.

Subtype	Example Assets	Notes
Smart Meters	Energy meters with comms	Enable billing, monitoring
IoT Sensors	Voltage, temperature, fault sensors	Support system diagnostics
Controllers/EMS	Inverters, EMS, SCADA systems	Coordinate and control flow

Monitoring and Steering the microgrid

This capabilities represent what the purpose for a microgrid can be. In the example of NFE's first phase of microgrid deployment. The purpose can be thought of as 3 part;

• for the owner (of the microgrid) to monitor energy consumptions patterns to inform additions of supply side assets like batteries in future so that energy can be more reliable for the community
• for the owner and consumers to bulk purchase electricity there by making it more affordable. 
• for the owner and consumers to evolve the their experience of transacting on the grid. Prepaid vs postpaid vs credits to consumers. 

The point here being that these capabilities of monitoring and steering (the assets) on the grid are a means to achieve a variety of purposes for the grid owner and other grid stakeholders. 

The Autonomous Microgrid 

This is what I think can be the vision for project Hyphae, to be able to simply define a start and end state for grid attributes we care about and have Hyphae monitor and steer the grid to the end state. For example, the end state could be 90% reliability for all demand side assets on the grid. Hyphae can then make sure that energy is being drawn or stored or cut off from some assets so that we can maintain a reliability of 90%. 

That's what I imagine an autonomous microgrid should be capable of doing. There may be aspects of grid operations that will require manual human intervention like replacing a malfunctioning asset or making a payment for a bill but the more you think about it, the more you recorgnize that almost every aspect has potential to be automated to make the grid completely autonomous. 

Levels of Microgrid Autonomy 

I am thinking about how we can borrow from the 6 levels for Self driving cars to define levels for Microgrids.. 

TBD

OpenEMS

Getting Started

ZeroTier Remote Access Guide

This guide explains how to connect to the NFE Raspberry Pi from anywhere in the world using ZeroTier. It covers both SSH access and troubleshooting common issues.

---

Table of Contents

1. Prerequisites
2. Network Information
3. Installing ZeroTier on Your Computer
4. Joining the Network
5. SSH Access to Raspberry Pi
6. Troubleshooting
7. Setting Up ZeroTier on a New Raspberry Pi

---

Prerequisites

Before starting, you need:

• A Mac or Windows laptop
• A ZeroTier account (free at https://my.zerotier.com)
• ZeroTier One installed on your computer
• Network authorization from the network administrator

---

Network Information

Network ID: 2873fd00f2d70904 Network Name: my-first-network Raspberry Pi ZeroTier IP: 10.135.127.86 Raspberry Pi Username: nfetestpi2

---

Installing ZeroTier on Your Computer

Mac:

1. Download ZeroTier One: https://www.zerotier.com/download/
2. Install it normally
3. After installation, the ZeroTier icon will appear in the top-right menu bar

Windows:

1. Download ZeroTier from https://www.zerotier.com/download/
2. Install and launch it
3. ZeroTier icon will appear in the system tray

---

Joining the Network

Method 1: Using the ZeroTier Menu (Mac - Recommended)

1. Click the ZeroTier icon in your menu bar
2. You'll see "My Address:" with your device ID
3. Click on the network ID 2873fd00f2d70904 if it's already listed
4. Or select "Join New Network..." and enter: 2873fd00f2d70904
5. The status will show "REQUESTING_CONFIGURATION"

Method 2: Using Command Line

Mac/Linux:

sudo zerotier-cli join 2873fd00f2d70904

Windows (run as Administrator):

zerotier-cli join 2873fd00f2d70904

Authorization

After joining, you need to be authorized:

1. Contact the network administrator
2. Provide them with your device's MAC address or Device ID
3. They will authorize your device at https://my.zerotier.com
4. Once authorized, your device will receive an IP address like 10.135.127.xxx

Verify Connection

Mac/Linux:

sudo zerotier-cli listnetworks

You should see:

200 listnetworks 2873fd00f2d70904 my-first-network ... OK PRIVATE ... 10.135.127.xxx/24

The status should show OK and you should have an IP address assigned.

---

SSH Access to Raspberry Pi

Once connected to the ZeroTier network, you can SSH to the Raspberry Pi:

ssh nfetestpi2@10.135.127.86

Enter the password when prompted.

Note: If you get a password prompt but it keeps failing, try using the -v flag for verbose output:

ssh -v nfetestpi2@10.135.127.86

Optional: Set Up SSH Keys (Recommended)

To avoid entering passwords every time:

1. Generate SSH key on your computer (if you don't have one):

ssh-keygen -t ed25519 -C "your-email@example.com"

2. Copy your public key:

cat ~/.ssh/id_ed25519.pub

3. Add it to the Pi's authorized keys (via SSH or Raspberry Pi Connect):

mkdir -p ~/.ssh
nano ~/.ssh/authorized_keys
# Paste your public key, save and exit

# Set correct permissions
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

4. Now you can SSH without a password:

ssh nfetestpi2@10.135.127.86

---

Troubleshooting

Issue: ZeroTier shows "REQUESTING_CONFIGURATION"

Cause: Your device hasn't been authorized on the network yet.

Solution:

1. Go to https://my.zerotier.com
2. Log in and navigate to network 2873fd00f2d70904
3. Click "Member Devices" tab
4. Find your device and check the "Auth" checkbox

Issue: ZeroTier shows "OFFLINE"

Cause: ZeroTier service isn't running properly.

Solution for Mac:

# Restart ZeroTier service
sudo launchctl unload /Library/LaunchDaemons/com.zerotier.one.plist
sudo launchctl load /Library/LaunchDaemons/com.zerotier.one.plist

# Verify it's online
sudo zerotier-cli info

You should see:

200 info <device-id> 1.16.0 ONLINE

Solution for Windows:

• Restart the ZeroTier service from Services (services.msc)
• Or restart the ZeroTier One application

Issue: Can't ping or SSH to Raspberry Pi

Symptoms:

ping 10.135.127.86
# Shows: "No route to host" or "Request timeout"

Solutions:

1. Check if ZeroTier is running on both devices:

sudo zerotier-cli info
# Should show: ONLINE

2. Verify both devices are on the same network:

sudo zerotier-cli listnetworks
# Both should show network 2873fd00f2d70904 with status OK

3. Try changing WiFi networks: Sometimes the initial WiFi network blocks ZeroTier's peer-to-peer connections. Try connecting to a different WiFi network or mobile hotspot.

4. Check for RELAY connection:

sudo zerotier-cli peers

If the Pi shows as "RELAY" instead of "DIRECT", there's a NAT traversal issue. Try:

• Restarting ZeroTier on both devices
• Leaving and rejoining the network
• Changing WiFi networks

5. Restart ZeroTier on both devices:

Mac:

sudo launchctl unload /Library/LaunchDaemons/com.zerotier.one.plist
sudo launchctl load /Library/LaunchDaemons/com.zerotier.one.plist

Raspberry Pi (via Raspberry Pi Connect):

sudo systemctl restart zerotier-one

6. Leave old networks: If you have multiple networks joined, leave unused ones:

# List networks
sudo zerotier-cli listnetworks

# Leave old network
sudo zerotier-cli leave <old-network-id>

Issue: SSH password keeps failing

Solutions:

1. Try verbose SSH to see what's happening:

ssh -v nfetestpi2@10.135.127.86

2. Make sure you're using the correct username (nfetestpi2, not pi)

3. Set up SSH keys instead (see SSH Keys section above)

---

Setting Up ZeroTier on a New Raspberry Pi

If you need to set up ZeroTier on a new Raspberry Pi, follow these steps:

Prerequisites

• Raspberry Pi with Raspberry Pi OS installed
• Internet connection
• Access to the Pi (via Raspberry Pi Connect, monitor/keyboard, or local SSH)

Installation Steps

1. Install ZeroTier on the Raspberry Pi:

curl -s https://install.zerotier.com | sudo bash

2. Join the network:

sudo zerotier-cli join 2873fd00f2d70904

3. Verify the Pi joined:

sudo zerotier-cli listnetworks

You'll see status as "ACCESS_DENIED" initially.

4. Authorize the Pi:

• Go to https://my.zerotier.com
• Log in and navigate to network 2873fd00f2d70904
• Click "Member Devices" tab
• Find the new Pi device (you can identify it by the MAC address or hostname)
• Check the "Auth" checkbox
• Note the "Managed IP" assigned to the Pi (e.g., 10.135.127.xxx)

5. Verify connection:

sudo zerotier-cli listnetworks

Should now show:

200 listnetworks 2873fd00f2d70904 my-first-network ... OK PRIVATE ztxxxxxx 10.135.127.xxx/24

6. Enable SSH (if not already enabled):

sudo systemctl enable ssh
sudo systemctl start ssh

7. Make ZeroTier start on boot:

sudo systemctl enable zerotier-one

8. Test connection from another device:

# From your computer (already on ZeroTier network)
ping <new-pi-ip>
ssh <username>@<new-pi-ip>

9. Update this documentation with the new Pi's IP address!

---

Advanced: VNC Access (Remote Desktop)

If you need graphical access to the Raspberry Pi:

1. Enable VNC on the Pi:

sudo raspi-config
# Navigate to: Interface Options → VNC → Enable

2. Install VNC Viewer on your computer: https://www.realvnc.com/en/connect/download/viewer/

3. Connect using the ZeroTier IP:

• Open VNC Viewer
• Enter: 10.135.127.86
• Enter Pi username and password

---

Quick Reference

Useful Commands

# Check ZeroTier status
sudo zerotier-cli info

# List joined networks
sudo zerotier-cli listnetworks

# Join a network
sudo zerotier-cli join <network-id>

# Leave a network
sudo zerotier-cli leave <network-id>

# Check peer connections
sudo zerotier-cli peers

# SSH to Raspberry Pi
ssh nfetestpi2@10.135.127.86

Network Details

• Network ID: 2873fd00f2d70904
• Network Name: my-first-network
• Pi IP: 10.135.127.86
• Pi Username: nfetestpi2

---

Last updated: 2026-03-28

DDSU666 (Direct chint meter ) + mbpoll Command Reference

Version: 1.0
Prepared For: Field & Deployment Teams
Platform: Raspberry Pi / Linux
Tool: mbpoll

1. Purpose

This document explains how to communicate with the CHINT DDSU666 Direct Smart Meter using Modbus RTU and the mbpoll tool.

It covers:
• Reading electrical parameters
• Setting meter addresses
• Verifying communication
• Preparing for OpenEMS integration

2. Hardware & Software Requirements

Hardware
• DDSU666 (Direct Version)
• RS485 → USB Converter
• Raspberry Pi / Linux PC
• Correct RS485 wiring (A(converter)↔24(meter com-port terminal), B(converter)↔25(meter com-port terminal), GND recommended)

Software
Install mbpoll:

sudo apt update
sudo apt install mbpoll

Check serial port:

ls /dev/ttyUSB*

Example output:

/dev/ttyUSB0

3. Communication Parameters (Confirmed)

Parameter	Value
Protocol	Modbus RTU
Baud Rate	9600
Data Bits	8
Parity	None
Stop Bits	2
Format	8N2
Float Order	Big Endian
Addressing	0-Based

These parameters must always be used.

4. Standard mbpoll Format

All commands follow this format:

mbpoll -m rtu -b 9600 -P none -s 2 -t 4:float -B -0 -r <register> -c <count> /dev/ttyUSB0 -a <id> -1

Where:
•    <register> = Modbus register
•    <count> = Number of values
•    <id> = Meter address (NO.)

5. Electrical Parameters

Summary:

Voltage: 0x2000
Current: 0x2002
Active Power: 0x2004
Power Factor: 0x200A
Frequency: 0x200E
Energy: 0x4000

5.1 Voltage (V) — Register 0x2000

Meter ID = 1
mbpoll -m rtu -b 9600 -P none -s 2 -t 4:float -B -0 \
-r 0x2000 -c 1 /dev/ttyUSB0 -a 1 -1
Meter ID = 2
mbpoll -m rtu -b 9600 -P none -s 2 -t 4:float -B -0 \
-r 0x2000 -c 1 /dev/ttyUSB0 -a 2 -1

5.2 Current (A) — Register 0x2002

Meter ID = 1
mbpoll -m rtu -b 9600 -P none -s 2 -t 4:float -B -0 \
-r 0x2002 -c 1 /dev/ttyUSB0 -a 1 -1
Meter ID = 2
mbpoll -m rtu -b 9600 -P none -s 2 -t 4:float -B -0 \
-r 0x2002 -c 1 /dev/ttyUSB0 -a 2 -1

5.3 Active Power — Register 0x2004

Meter ID = 1
mbpoll -m rtu -b 9600 -P none -s 2 -t 4:float -B -0 \
-r 0x2004 -c 1 /dev/ttyUSB0 -a 1 -1

Meter ID = 2
mbpoll -m rtu -b 9600 -P none -s 2 -t 4:float -B -0 \
-r 0x2004 -c 1 /dev/ttyUSB0 -a 2 -1

5.4 Power Factor — Register 0x200A

Meter ID = 1
mbpoll -m rtu -b 9600 -P none -s 2 -t 4:float -B -0 \
-r 0x200A -c 1 /dev/ttyUSB0 -a 1 -1
Meter ID = 2
mbpoll -m rtu -b 9600 -P none -s 2 -t 4:float -B -0 \
-r 0x200A -c 1 /dev/ttyUSB0 -a 2 -1

5.5 Frequency (Hz) — Register 0x200E

Meter ID = 1
mbpoll -m rtu -b 9600 -P none -s 2 -t 4:float -B -0 \
-r 0x200E -c 1 /dev/ttyUSB0 -a 1 -1
Meter ID = 2
mbpoll -m rtu -b 9600 -P none -s 2 -t 4:float -B -0 \
-r 0x200E -c 1 /dev/ttyUSB0 -a 2 -1

5.6 Energy (kWh) — Register 0x4000

Meter ID = 1
mbpoll -m rtu -b 9600 -P none -s 2 -t 4:float -B -0 \
-r 0x4000 -c 1 /dev/ttyUSB0 -a 1 -1
Meter ID = 2
mbpoll -m rtu -b 9600 -P none -s 2 -t 4:float -B -0 \
-r 0x4000 -c 1 /dev/ttyUSB0 -a 2 -1

6. Reading Multiple Values

Use -c option to read multiple registers.

Example ( Voltage + Current Together)

mbpoll -m rtu -b 9600 -P none -s 2 -t 4:float -B -0 \
-r 0x2000 -c 2 /dev/ttyUSB0 -a 1 -1

7. Meter Address

Register: 0x0006

mbpoll -m rtu -b 9600 -P none -s 2 -t 4:int16 -0 \
-r 0x0006 -c 1 /dev/ttyUSB0 -a 2 -1

Example Output:
[6]: 2

8. Changing Address

• Only one meter connected.
• Power cycle after change.

Change Address (2 → 1)
mbpoll -m rtu -b 9600 -P none -s 2 -t 4:int16 -0 \
-r 0x0006 /dev/ttyUSB0 -a 2 -W -- 1
Power Cycle
Turn OFF → ON the meter.
Verify
mbpoll -m rtu -b 9600 -P none -s 2 -t 4:int16 -0 \
-r 0x0006 -c 1 /dev/ttyUSB0 -a 1 -1

9. Health Check

Voltage should be 220–240V.

mbpoll -m rtu -b 9600 -P none -s 2 -t 4:float -B -0 \
-r 0x2000 -c 1 /dev/ttyUSB0 -a 1 -1

10. Common Issues

Timeout Errors
•    Duplicate IDs
•    Wrong wiring
•    Wrong stop bits
•    Multiple meters during setup

Incorrect Float Values
Use -B option.

Current / Power = 0

Normal when:
•    No load
•    Bench testing

11. Deployment Workflow

For large installations:
•    Connect one meter
•    Convert to Modbus
•    Set address
•    Test voltage
•    Install
•    Repeat
•    Never deploy duplicate addresses.

Connect → Configure → Test → Install

12. System Status

✔ Modbus Enabled
✔ 9600 8N2 Confirmed
✔ Big-Endian Floats
✔ Multi-meter Bus Working
✔ Ready for OpenEMS

Running OpenEMS Edge on a Raspberry PI

This guide explains how to:

1. Install and run OpenEMS Edge on a Raspberry Pi

2. Configure WebSocket + simulation

3. Run OpenEMS UI on a macOS machine (not on the Pi)

4. Connect the UI to the Edge over the internet

The structure is intentionally split into two clear parts:

• PART A — Raspberry Pi (Edge)

• PART B — macOS Machine (OpenEMS UI)

---

============================

PART A — Raspberry Pi (Edge)

============================

1. Raspberry Pi OS Setup (Headless)

Use Raspberry Pi Imager:

• Device: Raspberry Pi 4

• OS: Raspberry Pi OS Lite (64‑bit)

• Configure:

  • Hostname

  • Username & password

  • Enable SSH

  • Configure Wi‑Fi

  • Enable Raspberry Pi Connect

Boot the Pi and connect via:

• SSH

• OR Raspberry Pi Connect

---

2. Install Java 21 (Temurin ARM64)

On the Pi:

sudo apt update
sudo apt install -y wget apt-transport-https gpg

wget -qO - https://packages.adoptium.net/artifactory/api/gpg/key/public \
 | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/adoptium.gpg > /dev/null

echo "deb https://packages.adoptium.net/artifactory/deb \
$(awk -F= '/^VERSION_CODENAME/{print $2}' /etc/os-release) main" \
 | sudo tee /etc/apt/sources.list.d/adoptium.list

sudo apt update
sudo apt install -y temurin-21-jdk

Verify:

java -version

---

3. Install OpenEMS Edge

mkdir -p ~/downloads
cd ~/downloads
wget https://github.com/OpenEMS/openems/releases/download/2025.11.0/openems-edge.jar
sudo chmod +x openems-edge.jar

sudo mkdir -p /usr/lib/openems
sudo mv openems-edge.jar /usr/lib/openems/
sudo mkdir -p /etc/openems.d

---

4. Configure systemd Service

Create:

sudo nano /etc/systemd/system/openems.service

Paste:

[Unit]
Description=OpenEMS Edge
After=network.target

[Service]
User=root
Group=root
Type=notify
WorkingDirectory=/usr/lib/openems
ExecStart=/usr/bin/java -Dfelix.cm.dir=/etc/openems.d/ \
  -jar /usr/lib/openems/openems-edge.jar
SuccessExitStatus=143
Restart=always
RestartSec=10
WatchdogSec=60

[Install]
WantedBy=multi-user.target

Enable & start:

sudo systemctl daemon-reload
sudo systemctl enable openems
sudo systemctl start openems

Check:

systemctl status openems

---

5. Access OpenEMS Config Manager

On the Pi, open:

http://localhost:8080/system/console/configMgr

---

6. Add Required Components

In Config Manager:

1. Add a Scheduler (any default scheduler)

2. Add Controller.Api.Websocket

   • Port: 8085

   • Enabled: true

Restart Edge:

sudo systemctl restart openems

Verify WebSocket is listening:

sudo ss -lntp | grep 8085

You should see Java listening on port 8085.

---

7. (Optional) Add Simulation Components

In Config Manager, add:

• Simulator ESS

• Simulator Grid Meter

• Simulator PV

Save and restart OpenEMS.

---

=====================================

PART B — macOS Machine (OpenEMS UI)

=====================================

1. Install Docker Desktop

brew install --cask docker
open -a Docker

Wait until Docker reports "Docker is running".

Verify:

docker version

You must see both Client and Server.

---

2. Clone OpenEMS Source

git clone -b 2025.11.0 https://github.com/OpenEMS/openems
cd openems

---

3. Build OpenEMS UI Image

docker build . \
  -t openems_ui \
  -f tools/docker/ui/Dockerfile.edge

---

4. Run OpenEMS UI

Replace YOUR_PI_IP with:

• Public IP

• OR VPN IP

• OR Public DNS

Example:

docker container run \
  -e WEBSOCKET_HOST=YOUR_PI_IP \
  -p 80:80 \
  -p 443:443 \
  --restart unless-stopped \
  --name openems_ui_container \
  openems_ui

---

5. Open the UI

On your Mac:

http://localhost/login

Default login:

• Username: admin

• Password: admin

If UI shows "disconnected":

• Confirm port 8085 is listening on the Pi

• Confirm WebSocket controller exists

• Confirm WEBSOCKET_HOST is correct

---

Why UI Runs on macOS and Edge Runs on Pi

• Edge interacts with hardware and benefits from native systemd management

• UI behaves like a stateless web application and is ideal for containerization

• Separating them improves stability and flexibility

---

Troubleshooting

• UI loads but no connection → check port 8085

• Nothing listening on 8085 → WebSocket not configured

• Docker errors on Mac → ensure Docker Desktop is running

---

Security Notes

• Prefer VPN/tunnel (Tailscale/WireGuard) over port forwarding

• Use SSH key-based authentication

• Do not expose ConfigMgr (8080) publicly

---

You now have:

• OpenEMS Edge running on Raspberry Pi

• WebSocket enabled

• Optional simulation components

• OpenEMS UI running on macOS

• UI connected over internet

DTSU666 3‑Phase + mbpoll Command Reference

---

🔌 Standard Communication Settings (DTSU666)

Most DTSU666 meters use:

Base communication block used in all commands:

---

🧠 Critical Flags (Important)

---

---

🔹 Phase‑to‑Neutral Voltages (L1‑N, L2‑N, L3‑N)

Register: 0x2006

---

🔹 Line‑to‑Line Voltages (L1‑L2, L2‑L3, L3‑L1)

Register: 0x2000

---

🔹 Phase Currents (L1, L2, L3)

Register: 0x200C

---

🔹 Total Active Power (kW)

Register: 0x2012

---

🔹 Frequency (Hz)

Register: 0x2044

---

🔹 Total Active Energy (kWh)

Register: 0x4000

---

🔁 Continuous Polling Example (Every 5 Seconds)

---

🔢 Change Slave Address (Only One Meter Connected)

⚠ Use Holding Registers (Function 03) for configuration.

Register: 0x002E

Changes slave ID from 1 → 5.

---

🧪 Quick Communication Test

Fastest health check:

If you see ~230V → communication confirmed.

---

🚨 Troubleshooting Quick Guide

Pre-Commissioning Process for CHINT Meters

Document Information

• Version: 1.0
• Last Updated: 2026-04-04
• Target Audience: Field Operations Team, Development Team, Remote Commissioning Team

---

Table of Contents

1. Introduction
2. Team Roles and Responsibilities
3. Equipment and Software Requirements
4. Pre-Commissioning Workflow
5. Converter Tool Guide
6. Troubleshooting Guide
7. Safety and Best Practices
8. Inventory Management
9. Future Enhancements

---

Introduction

Purpose of Pre-Commissioning

Pre-commissioning is the process of converting CHINT DDSU666/DTSU666 meters from their native DL/T645 protocol to Modbus RTU protocol and assigning unique Modbus addresses before the meters are installed at customer sites.

Why Pre-Commissioning Matters

Problem: Fresh CHINT meters operate on the Chinese DL/T645 protocol and default to Modbus address 1 after conversion. If meters are converted on-site:

• Address collisions occur when multiple meters default to address 1
• Production disruption happens when using the production USB-RS485 adapter for conversion (interrupts live meters)
• Field complexity increases with protocol conversion and addressing at customer locations

Solution: Pre-commission all meters in a controlled lab environment before field deployment.

Benefits

✅ Zero Downtime: Field installation becomes plug-and-play (physical connection only) ✅ No Address Conflicts: Each meter arrives with unique, pre-assigned Modbus address ✅ Quality Control: Test meter communication before shipping ✅ Simplified Installation: Field team doesn't need protocol conversion tools ✅ Audit Trail: Complete inventory tracking from procurement to commissioning

---

Team Roles and Responsibilities

Development Team

Responsibilities:

• Assign Modbus addresses based on site requirements and numbering scheme
• Maintain master meter inventory spreadsheet
• Build and distribute converter.exe updates
• Provide escalation support for complex technical issues
• Plan and design system upgrades

Tools Used:

• Master Inventory Spreadsheet (Nextcloud Sheets)
• PyInstaller (for building Windows executable)

---

Field Operations Team

Responsibilities:

• Execute lab conversion of meters from DL/T645 → Modbus RTU
• Assign Modbus addresses per Development Team's mapping
• Test meter responses after conversion
• Update inventory status (Assigned → Converted → Shipped)
• Label meters physically with assigned Modbus address
• Package and ship pre-configured meters to sites

Tools Used:

• converter.exe (Windows GUI application)
• USB-RS485 adapter (dedicated lab adapter, NOT production)
• Meter Inventory Spreadsheet (Nextcloud Sheets)
• Physical label maker/stickers

Training Required:

• Converter tool operation (see Converter Tool Guide)
• Inventory management workflow
• Basic RS485 wiring (A+/B- terminals)

---

Field Installation Team

Responsibilities:

• Mount meter at customer location
• Wire power connections (L1/L2/L3/N)
• Wire current transformers (if three-phase meter)
• Connect to existing Modbus RS485 bus (A+/B- terminals)
• Verify meter powers up and displays readings
• Notify Remote Commissioning Team when installation complete

Tools Used:

• Standard electrical installation tools
• Multimeter for continuity checks

Training Required:

• Meter mounting procedures
• RS485 bus connection (parallel wiring to existing meters)
• Safety protocols for live electrical work

---

Remote Commissioning Team

Responsibilities:

• Connect to Raspberry Pi remotely via ZeroTier + SSH
• Add meter entry to production config file (config.prod.yaml)
• Deploy configuration changes using automated script
• Monitor service restart and verify meter logging
• Update inventory status (Installed → Commissioned)
• Notify stakeholders when meter is live

Tools Used:

• ZeroTier VPN client
• SSH client (Terminal, PuTTY, etc.)
• Text editor (nano, vim)
• add_meter.sh CLI helper script (recommended)

Training Required:

• SSH basics and remote access
• YAML syntax for meter configuration
• Deployment script usage
• Log monitoring with systemctl/journalctl

---

Equipment and Software Requirements

Hardware (Field Operations Team)

Item	Specification	Purpose	Notes
USB-RS485 Adapter	CH340, FTDI, or PL2303 chipset	Connect Windows PC to meter	CRITICAL: Use dedicated lab adapter, NOT production adapter
Windows PC/Laptop	Windows 7/10/11	Run converter.exe GUI	Must have USB port
Power Supply	230V AC (single-phase) or 3-phase	Power meter during conversion	Match meter type
RS485 Wiring	2-wire twisted pair	Connect adapter to meter A+/B- terminals	Keep wiring short (<2 meters)
Label Maker	Any type	Create Modbus address labels	Physical labels prevent confusion

Software (Field Operations Team)

Item	Location	Version	Purpose
converter.exe	Nextcloud: /Field_Operations/Tools/converter_v1.0.exe	v1.0	Protocol conversion and address assignment
USB Driver	Manufacturer website	Latest	CH340/FTDI/PL2303 driver for Windows
Meter Inventory	Nextcloud Sheets (shared link) + Excel backup on Nextcloud	Current	Track meter status

Download Links:

• CH340 Driver: http://www.wch.cn/downloads/CH341SER_EXE.html
• FTDI Driver: https://ftdichip.com/drivers/vcp-drivers/
• PL2303 Driver: http://www.prolific.com.tw/US/ShowProduct.aspx?p_id=225

---

Pre-Commissioning Workflow

Overview: 5-Phase Process

Phase 1: Address Assignment (Development Team)
   ↓
Phase 2: Lab Conversion (Field Operations Team)
   ↓
Phase 3: Pre-Dispatch Testing (Field Operations Team)
   ↓
Phase 4: Field Installation (Field Installation Team)
   ↓
Phase 5: Remote Commissioning (Remote Commissioning Team)

---

Phase 1: Address Assignment (Development Team)

Duration: 15-30 minutes per batch

Steps:

1. Receive Procurement List

   • New meters arrive from supplier
   • Record 12-digit serial numbers from meter labels
   • Note meter types (DDSU666 single-phase or DTSU666 three-phase)

2. Assign Modbus Addresses

   • Follow numbering scheme:
     • Single-phase (DDSU666): IDs 02 to 99 (90 meters max per site)
     • Three-phase (DTSU666): IDs 100 and above (unlimited)
   • CRITICAL RULE: Never use address 1 (factory default, causes conflicts)

   Example Assignment:

   Site: Office Building A
   - Meter Serial 200322016690 → Address 02 (Floor 1 Reception)
   - Meter Serial 200322016691 → Address 03 (Floor 1 Office)
   - Meter Serial 200322016692 → Address 04 (Floor 2 Office)
   - Meter Serial 200415023456 → Address 100 (Main 3-Phase Supply)
   

3. Update Master Inventory Spreadsheet

   • Open Nextcloud Sheets inventory (link in team resources)
   • Add new rows for each meter:
     • Meter Serial Number (12 digits)
     • Meter Type (DDSU666 or DTSU666)
     • Site Name
     • Building/Customer Name
     • Assigned Modbus Address
     • Status: "Assigned"
     • Date Assigned: Today's date
     • Assigned By: Your name

4. Send Assignment List to Field Operations Team

   • Export assignment list as PDF or share Nextcloud Sheets link
   • Include any special instructions (e.g., priority meters, site notes)

---

Phase 2: Lab Conversion (Field Operations Team)

Duration: 5-10 minutes per meter Location: Lab/Office environment Tools: Windows PC, converter.exe, USB-RS485 adapter

Steps:

2.1 Physical Setup

1. Connect Meter to Power

   • Single-phase: Connect L (live) and N (neutral)
   • Three-phase: Connect L1, L2, L3, and N
   • Verify meter LCD powers on and displays readings

2. Connect USB-RS485 Adapter

   • Locate meter's RS485 terminals (usually labeled A+/B- or 485A/485B)
   • Connect adapter's A+ wire to meter's A+ terminal
   • Connect adapter's B- wire to meter's B- terminal
   • Polarity matters! Incorrect wiring causes "No response" errors

3. Connect Adapter to Windows PC

   • Plug USB end into PC USB port
   • Windows should detect and install driver automatically
   • If not, install driver manually (see Equipment section)

2.2 Launch Converter Tool

1. Run converter.exe
   • Double-click converter_v1.0.exe from Nextcloud download
   • GUI window opens with title "DLT645 to Modbus Converter"
   • Initial status shows red "● Disconnected"

2.3 Configure Connection

1. Detect Serial Port

   • Click "⟳ Refresh" button
   • Dropdown populates with available ports (e.g., COM3, COM4)
   • If no ports appear:
     • Check USB cable connection
     • Verify driver installed (Windows Device Manager → Ports)
     • Try different USB port

2. Select Port and Baud Rate

   • Select detected port from dropdown (e.g., COM3)
   • Baud rate: Keep default 2400 (DLT645 standard)

3. Connect to Port

   • Click "Connect" button
   • Status changes to green "● Connected"
   • All action buttons become enabled
   • Log shows: [HH:MM:SS] Connected → COM3 @ 2400 baud

2.4 Enter Meter Details

1. DLT645 Station Address (12 digits)

   • Find on meter label or LCD display
   • Example: 200322016690
   • Must be exactly 12 digits (tool validates)

2. Target Modbus Address (from assignment list)

   • Refer to Master Inventory for assigned address
   • Example: Address 02 for first single-phase meter
   • Valid range: 1-247 (but avoid address 1)

3. Reverse Address Bytes (checkbox)

   • Keep checked by default
   • Tool will auto-retry with this toggled if conversion fails

2.5 Execute Conversion (Recommended: Use "Full Process")

Option A: Full Process (Recommended for Field Operations)

1. Click "▶ Full Process" button
2. Tool automatically performs:
   • Step 1/2: Convert protocol (DLT645 → Modbus RTU)
   • Step 2/2: Change Modbus address to target value
3. Watch log panel for progress:

   [14:23:15] ═══ Full Process Started ═══
   [14:23:15] [1/2] Converting protocol — station=200322016690
   [14:23:15] TX: FE FE FE FE 68 02 03 20 01 66 90...
   [14:23:27] ✓ Protocol conversion done.
   [14:23:27] [2/2] Changing Modbus address: 1 → 10
   [14:23:30] ✓ Address set to 10.
   [14:23:30] ═══ Full Process Complete ═══
   

4. Success indicators:
   • ✓ checkmarks for both steps
   • No ✗ errors in log
   • "Full Process Complete" message

Option B: Manual Step-by-Step (for troubleshooting)

If Full Process fails, try manual steps:

1. Convert Protocol First

   • Click "Convert Protocol" button
   • Tool sends DLT645 protocol-switch command
   • Wait 2-5 minutes for meter to respond
   • Log shows: ✓ Protocol conversion done.

2. Scan for Current Address (optional)

   • Click "🔍 Scan" button
   • Tool tests all 247 Modbus addresses (takes ~90 seconds)
   • Log shows: ✓ Meter found at Modbus address 1
   • "Current Modbus Address" field auto-updates

3. Change Address

   • Ensure "Current Modbus Address" is correct (usually 1 after conversion)
   • Enter "Target Modbus Address" (from assignment list)
   • Click "Change Modbus Addr" button
   • Log shows: ✓ Address changed to 10.

2.6 Update Inventory

1. Open Nextcloud Sheets Inventory
2. Find meter row (search by serial number)
3. Update fields:
   • Status: Change "Assigned" → "Converted"
   • Date Converted: Today's date
   • Converted By: Your name
   • Notes: Add any issues encountered (e.g., "Required reverse byte toggle")

2.7 Label Meter Physically

1. Create Label (using label maker or sticker)
   • Text: Modbus Address: 02 (use actual assigned address)
   • Include site name if space permits
2. Affix Label to Meter
   • Place on front panel or top cover
   • Ensure visible after installation
   • Prevents confusion during field installation

2.8 Disconnect and Repeat

1. Disconnect from Meter

   • Click "Disconnect" button in converter tool
   • Status returns to red "● Disconnected"
   • Unplug USB-RS485 adapter from PC
   • Disconnect adapter from meter terminals
   • Power off meter

2. Repeat for Next Meter

   • Proceed to next meter in batch
   • Follow steps 2.1-2.7 for each meter

---

Phase 3: Pre-Dispatch Testing (Field Operations Team)

Duration: 5 minutes per meter Purpose: Verify meter responds at assigned Modbus address before shipping

Steps:

1. Setup Test Bus

   • Connect 2-3 converted meters to same RS485 bus
   • Use twisted pair wiring (parallel connection)
   • Ensure meters have different addresses (e.g., 10, 11, 12)

2. Test Communication (Manual Method)

   • Connect USB-RS485 adapter to test bus
   • Open converter tool
   • Change baud rate to 9600 (Modbus standard)
   • Use "Scan" function to detect meters
   • Verify each meter responds at its assigned address

3. Alternative: Use NFE Test Script

   • If Raspberry Pi available for testing
   • Copy test_modbus_read.py script to test Pi
   • Edit script to test specific meter ID
   • Run: python3 test_modbus_read.py
   • Verify readings returned (voltage, current, power)

4. Record Test Results

   • Update inventory spreadsheet:
     • Add checkmark or "Tested OK" in Notes column
     • If test fails, mark as "Retest Required" and escalate to Development Team

5. Package for Shipping

   • Power off meter
   • Ensure address label is visible
   • Package securely with protective materials
   • Include shipping label with site name

---

Phase 4: Field Installation (Field Installation Team)

Duration: 30-60 minutes per meter (excluding electrical prep) Location: Customer site Safety: Follow all electrical safety protocols

Steps:

4.1 Pre-Installation Checks

1. Verify Meter Received

   • Confirm meter serial number matches work order
   • Verify Modbus address label matches site plan
   • Inspect for shipping damage

2. Review Site Plan

   • Identify installation location
   • Locate existing Modbus RS485 bus terminals
   • Note power source (single-phase or three-phase)

4.2 Physical Installation

1. Mount Meter (per manufacturer instructions)

   • Use DIN rail mounting or wall mount bracket
   • Ensure meter is accessible for reading and maintenance
   • Keep away from excessive heat and moisture

2. Wire Power Connections

   Single-Phase (DDSU666):

   • Connect Line (L) from customer's circuit breaker
   • Connect Neutral (N) from customer's neutral bar
   • Verify polarity with multimeter

   Three-Phase (DTSU666):

   • Connect L1, L2, L3 from customer's supply
   • Connect Neutral (N) from neutral bar
   • If using current transformers (CTs):
     • Install CTs on each phase conductor
     • Connect CT secondaries to meter CT terminals (K1/L1, K2/L2, K3/L3)
     • Ensure CT orientation matches current flow direction

3. Wire Modbus RS485 Bus

   • CRITICAL: This step must NOT interrupt existing meters
   • Locate existing RS485 bus terminals (A+/B- or 485A/485B)
   • Connect new meter's A+ terminal to bus A+ (parallel)
   • Connect new meter's B- terminal to bus B- (parallel)
   • Use twisted pair cable (CAT5 or dedicated RS485 cable)
   • Keep total bus length under 1200 meters
   • Use 120Ω termination resistor if meter is at end of bus

4.3 Power-Up and Verify

1. Energize Meter

   • Turn on customer circuit breaker
   • Meter LCD should illuminate and display readings
   • Verify voltage readings match expected values (230V ±10% single-phase, 400V ±10% three-phase)

2. Quick Communication Test (Optional)

   • If laptop with converter tool available:
     • Connect USB-RS485 adapter to bus (parallel, don't disconnect existing)
     • Set baud rate to 9600
     • Use "Scan" to verify meter responds at assigned address
     • Disconnect adapter when done
   • If no laptop: Skip this step (Remote Commissioning Team will verify)

3. Notify Remote Commissioning Team

   • Send message: "Meter [Serial Number] installed at [Site Name], ready for commissioning"
   • Include photo of meter with label visible (for audit trail)
   • Update inventory:
     • Status: "Converted" → "Installed"
     • Date Installed: Today's date
     • Installed By: Your name

---

Phase 5: Remote Commissioning (Remote Commissioning Team)

Duration: 10-15 minutes per meter Location: Remote (via ZeroTier VPN + SSH)

Prerequisites:

• Receive notification from Field Installation Team
• ZeroTier VPN client installed and connected to network ID: 2873fd00f2d70904
• SSH access to production Raspberry Pi: nfetestpi2@10.135.127.86

Steps:

5.1 Connect to Raspberry Pi

1. Start ZeroTier VPN

   • Ensure ZeroTier client is running
   • Verify connected to "my-first-network" (ID: 2873fd00f2d70904)
   • Check ZeroTier shows "ONLINE" status

2. SSH to Production Pi

   ssh nfetestpi2@10.135.127.86
   

   • Enter password when prompted
   • Or use SSH key if configured (passwordless)

5.2 Add Meter to Configuration (Option A: Manual Edit)

For users comfortable with YAML editing:

1. Edit Staging Config

   nano ~/nfe-modbus-energy-logger/config/config.prod.yaml
   

2. Add Meter Entry

   Scroll to the meters: section and add new entry:

   Single-Phase Meter Example:

   meters:
     # ... existing meters ...
   
     - id: 2                      # Assigned Modbus address
       name: "floor1_reception"    # Descriptive name (lowercase, underscores)
       type: "1phase"              # Meter type
       enabled: true               # Enable logging
   

   Three-Phase Meter Example:

   meters:
     # ... existing meters ...
   
     - id: 100                     # Assigned Modbus address
       name: "main_supply"         # Descriptive name
       type: "3phase"              # Meter type
       enabled: true               # Enable logging
   

   Naming Conventions:

   • Use lowercase letters
   • Use underscores instead of spaces
   • Make names descriptive but concise
   • Examples: floor2_office, hvac_panel, server_room

3. Save and Exit

   • Press Ctrl+O to save
   • Press Enter to confirm filename
   • Press Ctrl+X to exit nano

5.2 Add Meter to Configuration (Option B: CLI Helper Script - RECOMMENDED)

For automated validation and safety:

1. Run Helper Script

   ~/nfe-modbus-energy-logger-prod/scripts/add_meter.sh
   

2. Answer Interactive Prompts

   Enter Meter ID (2-247): 2
   Enter Meter Name: floor1_reception
   Enter Meter Type (1phase/3phase): 1phase
   Enable meter? (yes/no): yes
   
   About to add:
     ID: 2
     Name: floor1_reception
     Type: 1phase
     Enabled: true
   
   Proceed? (yes/no): yes
   

3. Script Automatically:

   • Validates input (address range, type, duplicate ID check)
   • Backs up current config
   • Appends meter to YAML
   • Runs deployment script
   • Monitors service restart
   • Verifies meter logging
   • Reports success or failure

4. Review Output

   ✅ Meter 2 (floor1_reception) successfully added and logging
   📁 Data directory: ~/nfe-modbus-energy-logger-prod/data/meter_010/
   📊 CSV file: meter_010_2026-04-04.csv
   

5.3 Deploy to Production (Manual Method Only)

Skip this if you used add_meter.sh script (already done)

1. Run Deployment Script

   ~/nfe-modbus-energy-logger/scripts/deploy.sh
   

2. Script Actions:

   • Backs up production directory
   • Syncs staging code to production
   • Runs pre-flight test (30-second dry run)
   • Restarts meter.service
   • Verifies service started successfully
   • Auto-rollback if service fails

3. Monitor Deployment

   • Watch for "Deployment complete" message
   • Check for any error messages
   • If errors occur, script auto-rolls back

5.4 Monitor Service Restart

1. Watch Service Logs

   sudo journalctl -u meter.service -f
   

2. Look for Meter Initialization

   [timestamp] ✅ Initialized meter 10 (floor1_reception, 1phase)
   [timestamp] 🚀 Starting multi-meter logger
   [timestamp]    Poll interval: 10s
   [timestamp]    Log interval: 900s (15 minutes)
   [timestamp]    Active meters: 3
   

3. Press Ctrl+C to stop watching logs

5.5 Verify Meter Logging

1. Check Data Directory Created

   ls -lh ~/nfe-modbus-energy-logger-prod/data/
   

   • Should show new directory: meter_010/ (or corresponding ID)

2. Check CSV File Started

   ls -lh ~/nfe-modbus-energy-logger-prod/data/meter_010/
   

   • Should show CSV file: meter_010_2026-04-04.csv (today's date)

3. View Recent Log Entries

   tail -20 ~/nfe-modbus-energy-logger-prod/data/meter_010/meter_010_2026-04-04.csv
   

   • Should show recent readings with timestamps
   • Verify data fields populated (not all zeros or empty)

4. Sample Output:

   timestamp,meter_id,V_L1_V,I_L1_A,P_total_kW,E_total_kWh,...
   2026-04-04 15:15:00,10,234.5,2.1,0.49,12345.6,...
   2026-04-04 15:30:00,10,235.1,2.3,0.53,12345.8,...
   

5.6 Update Inventory and Notify

1. Update Inventory Spreadsheet

   • Status: "Installed" → "Commissioned"
   • Date Commissioned: Today's date
   • Commissioned By: Your name
   • Notes: Add any observations (e.g., "All readings nominal")

2. Verify Backup Enabled (if configured)

   • Check backup service runs successfully:

     sudo journalctl -u backup.service -n 50
     

   • Verify meter CSV files being backed up to Nextcloud

3. Notify Stakeholders

   • Send confirmation message: "Meter [Serial Number] commissioned at [Site Name] - logging active"
   • Include link to meter data directory or dashboard (if available)

---

Converter Tool Guide

GUI Overview

┌─────────────────────────────────────────────────────────┐
│  DLT645 to Modbus Converter                             │
├─────────────────────────────────────────────────────────┤
│  Serial Port: [COM3         ▼] [⟳ Refresh]  [Connect]  │
│  Baud Rate:   [2400         ▼]                          │
│  Status: ● Connected                                     │
├─────────────────────────────────────────────────────────┤
│  DLT645 Station Address (12 digits):                    │
│  [200322016690                                       ]  │
│                                                           │
│  Current Modbus Address: [1   ]  [🔍 Scan]              │
│  Target Modbus Address:  [10  ]                         │
│                                                           │
│  ☑ Reverse address bytes                                │
├─────────────────────────────────────────────────────────┤
│  [Convert Protocol] [Change Modbus Addr] [▶ Full Process]│
├─────────────────────────────────────────────────────────┤
│  Log Panel (scrollable):                                │
│  [14:23:15] Connected → COM3 @ 2400 baud                │
│  [14:23:25] Converting protocol — station=200322016690  │
│  [14:23:27] ✓ Protocol conversion done.                 │
│  [14:23:30] ✓ Address changed to 10.                    │
│                                                           │
└─────────────────────────────────────────────────────────┘

Input Field Descriptions

Field	Description	Valid Values	Example
Serial Port	USB-RS485 adapter COM port	Auto-detected ports	COM3
Baud Rate	Communication speed	1200, 2400, 4800, 9600, 19200	2400 (DLT645 default)
DLT645 Station Address	Meter's 12-digit serial number	000000000000 - 999999999999	200322016690
Current Modbus Address	Address meter currently responds to	1-247	1 (factory default)
Target Modbus Address	New address to assign	1-247	10 (from assignment list)
Reverse Address Bytes	Toggle byte order for firmware compatibility	Checked/Unchecked	☑ Checked (recommended)

Button Functions

Button	Function	When to Use	Duration
⟳ Refresh	Re-scan for serial ports	USB adapter just connected	Instant
Connect	Open selected serial port	Before any conversion operations	Instant
Disconnect	Close serial port	After conversion complete	Instant
Convert Protocol	Send DLT645 protocol-switch command	Standalone protocol conversion	2-5 minutes
🔍 Scan	Search all 247 Modbus addresses	Find current meter address	~90 seconds
Change Modbus Addr	Write new address to meter	After protocol conversion	5-10 seconds
▶ Full Process	Automated conversion + address change	RECOMMENDED for Field Operations	5-10 minutes

Success Indicators

Look for these in the log panel:

✅ Protocol Conversion Success:

[14:23:27] ✓ Protocol conversion done.

✅ Address Change Success:

[14:23:30] ✓ Address set to 10.

✅ Full Process Success:

[14:23:30] ═══ Full Process Complete ═══

✅ Meter Discovery Success:

[14:23:45] ✓ Meter found at Modbus address 1. 'Current Modbus Address' updated.

Error Indicators

❌ Communication Errors:

[14:23:27] ✗ No response — check wiring / address / baud rate.

❌ Validation Errors:

Validation Error: Station address must be exactly 12 digits.
Validation Error: Modbus address must be an integer 1–247.

❌ Port Errors:

Error: No port selected. Click ⟳ Refresh first.
Connection Error: [SerialException message]

---

Troubleshooting Guide

Problem: No Serial Ports Detected

Symptoms:

• Dropdown shows "No ports found" or is empty
• "⟳ Refresh" button doesn't populate ports

Causes and Solutions:

1. USB Adapter Not Connected

   • ✅ Solution: Plug USB adapter into PC USB port
   • Click "⟳ Refresh" again

2. Driver Not Installed

   • ✅ Solution: Install USB-RS485 driver for your adapter chipset
   • Check Windows Device Manager → Ports (COM & LPT)
   • If device shows yellow warning icon, driver missing
   • Download and install correct driver (see Equipment section)
   • Restart PC if required
   • Click "⟳ Refresh" after driver installed

3. Faulty USB Cable or Adapter

   • ✅ Solution: Try different USB port
   • Try different USB cable
   • Test adapter on another PC
   • Replace adapter if confirmed faulty

4. Windows Security Blocking

   • ✅ Solution: Run converter.exe as Administrator
   • Right-click → "Run as administrator"

---

Problem: "No Response" During Protocol Conversion

Symptoms:

• Log shows: [HH:MM:SS] ✗ No response.
• Tool retries with reverse byte toggle automatically

Causes and Solutions:

1. Incorrect Station Address

   • ✅ Solution: Double-check 12-digit serial number on meter label
   • Ensure no typos (easy to confuse 0/O, 1/I, 6/8)
   • Verify number matches meter (not packaging)

2. Wiring Problem (Most Common)

   • ✅ Solution: Check RS485 connections
   • Verify A+ to A+, B- to B- (not swapped)
   • Tighten terminal screws (loose connections cause intermittent failures)
   • Use twisted pair cable (not individual wires)
   • Keep wiring short (<2 meters)

3. Incorrect Baud Rate

   • ✅ Solution: Confirm baud rate is 2400 for DLT645 meters
   • Some meters may use different rates (try 1200, 4800)

4. Meter Not Powered

   • ✅ Solution: Verify meter LCD is illuminated
   • Check power connections (L/N for single-phase, L1/L2/L3/N for three-phase)
   • Use multimeter to verify voltage at terminals

5. RS485 Bus Termination Issue

   • ✅ Solution: If multiple meters on same bus, add 120Ω termination resistor across A+/B- at each end

6. Reverse Byte Order Required

   • ✅ Solution: Tool auto-retries with reverse toggle
   • Manually toggle "Reverse address bytes" checkbox and retry

7. Meter Already in Modbus Mode

   • ✅ Solution: Meter may already be converted (from previous attempt)
   • Change baud rate to 9600
   • Use "Scan" function to find current address
   • Skip to "Change Modbus Addr" step if needed

---

Problem: Scan Finds No Modbus Address

Symptoms:

• After protocol conversion, scan completes but finds no meter
• Log shows: ⚠ No meter responded on Modbus addresses 1-247.

Causes and Solutions:

1. Protocol Conversion Failed

   • ✅ Solution: Meter still in DLT645 mode
   • Return to "Convert Protocol" step
   • Try manual conversion with longer timeout
   • Power cycle meter (turn off, wait 10 seconds, turn on)
   • Retry conversion

2. Incorrect Baud Rate for Modbus

   • ✅ Solution: After conversion, meter uses 9600 baud for Modbus
   • Change baud rate dropdown to 9600
   • Retry scan

3. Meter Needs Time to Restart

   • ✅ Solution: Wait 5 minutes after protocol conversion
   • Power cycle meter
   • Retry scan

---

Problem: Address Change Fails

Symptoms:

• Log shows: ✗ Address change failed.
• Meter doesn't respond at new address

Causes and Solutions:

1. Wrong Register Address for Meter Type

   • ✅ Solution:
   • DDSU666 (single-phase) uses register 0x0006
   • DTSU666 (three-phase) uses register 0x002E
   • Converter GUI currently supports single-phase only
   • For three-phase, use CLI version:

     python3 converter_cli.py change --port COM3 --current 1 --target 10 --type 3phase
     

2. Meter Not in Modbus Mode

   • ✅ Solution: Ensure protocol conversion succeeded first
   • Use "Scan" to verify meter responds in Modbus mode

3. Current Address Incorrect

   • ✅ Solution: Use "Scan" function to discover actual current address
   • Update "Current Modbus Address" field with scanned value
   • Retry address change

---

Problem: Meter Doesn't Respond After Conversion

Symptoms:

• Conversion appears successful in log
• But meter doesn't respond in Modbus mode later

Causes and Solutions:

1. Conversion Incomplete (False Positive)

   • ✅ Solution: Some meters acknowledge command but don't actually switch
   • Power cycle meter (off for 30 seconds, then on)
   • Wait 5 minutes after power-on
   • Retry scan

2. Firmware Requires Extended Timing

   • ✅ Solution: Use CLI version with extended timeout:

     python3 converter_cli.py convert --port COM3 --station 200322016690 --reverse --extended
     

3. Meter Reverted to DLT645 Mode

   • ✅ Solution: Some meters revert to factory default after power loss
   • This is rare but possible
   • Repeat full conversion process
   • Test immediately after conversion before power cycling

---

Escalation: When to Contact Development Team

Contact Development Team if:

• Meter doesn't respond after 3 conversion attempts
• Error messages not covered in this guide
• Physical damage suspected (meter LCD dead, RS485 terminals broken)
• Firmware version incompatibility suspected
• Need CLI script for three-phase meter address change
• converter.exe crashes or freezes

Escalation Information to Provide:

• Meter serial number
• Meter type (DDSU666 or DTSU666)
• Complete log output from converter tool (screenshot)
• Steps already attempted
• Observations (LCD displays, unusual behavior)

---

Safety and Best Practices

General Safety

⚠️ Electrical Safety:

• Only qualified electricians perform power wiring (Phase 4)
• De-energize circuits before connecting meter to live power
• Use lockout/tagout (LOTO) procedures
• Verify voltage with multimeter before assuming power is off
• Wear appropriate personal protective equipment (PPE)

⚠️ RS485 Bus Safety:

• Never connect/disconnect RS485 wiring with power applied (can damage meter)
• Use ESD (electrostatic discharge) precautions when handling meter electronics
• Keep RS485 bus wiring away from high-voltage conductors (>50V)

Conversion Best Practices

✅ One Meter at a Time:

• Convert meters individually (don't connect multiple unconverted meters to same bus)
• This prevents address conflicts during conversion

✅ Document Before Converting:

• Update inventory BEFORE starting conversion
• Record meter serial number, type, and assigned address
• This prevents confusion if interrupted mid-process

✅ Test Before Shipping:

• Always perform Phase 3 Pre-Dispatch Testing
• Catch issues in lab, not at customer site
• Reduces field failures and rework

✅ Never Reuse Addresses on Same Site:

• Each meter must have unique address
• Keep site-specific address map
• Even if meter replaced, don't reuse old address immediately (wait until removed from config)

✅ Physical Labeling is Mandatory:

• Label prevents installation errors
• Field Installation Team relies on label (may not have inventory access)
• Use durable labels (water-resistant, doesn't fade)

✅ Keep Conversion Logs:

• Take screenshot of successful conversion log
• Store in Nextcloud or local folder
• Useful for audit trail and troubleshooting
• Include meter serial number in filename (e.g., conversion_200322016690_success.png)

---

Inventory Management

Master Inventory Spreadsheet

Primary Location: Nextcloud Sheets (shared link - request from Development Team) Backup Location: Nextcloud /Field_Operations/Templates/METER_INVENTORY_TEMPLATE.xlsx

Required Columns

Column Name	Data Type	Purpose	Example
Meter Serial Number	Text (12 digits)	Unique meter identifier	200322016690
Meter Type	Text	Single or three-phase	DDSU666 or DTSU666
Site Name	Text	Customer site	Office Building A
Building/Customer	Text	Specific location or customer name	Floor 1 Reception
Assigned Modbus Address	Number (1-247)	Pre-assigned unique address	10
Status	Dropdown	Current workflow stage	Assigned, Converted, Shipped, Installed, Commissioned
Date Assigned	Date	When address assigned	2026-04-01
Date Converted	Date	When protocol conversion completed	2026-04-02
Date Installed	Date	When physically installed at site	2026-04-03
Date Commissioned	Date	When added to NFE config and logging	2026-04-04
Converted By	Text	Field Ops team member name	Jane Doe
Installed By	Text	Field Installation team member	John Smith
Commissioned By	Text	Remote Commissioning team member	Alice Johnson
Notes	Text	Issues, observations, special instructions	Required reverse byte toggle

Status Workflow

Unassigned → Assigned → Converted → Shipped → Installed → Commissioned
     ↓          ↓           ↓           ↓          ↓            ↓
   (New)   (Dev Team)  (Field Ops) (Field Ops) (Field Inst) (Remote Comm)

Status Definitions:

• Unassigned: New meter received from supplier, no address assigned yet
• Assigned: Development Team assigned Modbus address, ready for conversion
• Converted: Field Operations Team completed protocol conversion and address assignment
• Shipped: Meter packaged and sent to customer site
• Installed: Field Installation Team physically installed meter and wired to bus
• Commissioned: Remote Commissioning Team added to NFE config and verified logging

Conditional Formatting (Nextcloud Sheets)

Setup in Nextcloud Sheets:

1. Status Column Color Coding:

   • Unassigned: Gray background
   • Assigned: Yellow background (action required by Field Ops)
   • Converted: Light blue (ready to ship)
   • Shipped: Blue (in transit)
   • Installed: Orange (action required by Remote Comm)
   • Commissioned: Green (complete)

2. Overdue Highlighting:

   • If "Status = Assigned" and "Date Assigned" > 7 days ago → Red text (conversion overdue)
   • If "Status = Installed" and "Date Installed" > 2 days ago → Red text (commissioning overdue)

3. Address Range Validation:

   • If "Meter Type = DDSU666" and "Assigned Modbus Address" < 10 or > 99 → Red background (invalid)
   • If "Meter Type = DTSU666" and "Assigned Modbus Address" < 100 → Red background (invalid)

Data Validation (Nextcloud Sheets)

Setup in Nextcloud Sheets:

1. Status Dropdown:

   • Column: Status
   • Criteria: List from a range: Unassigned, Assigned, Converted, Shipped, Installed, Commissioned
   • Reject invalid input

2. Meter Type Dropdown:

   • Column: Meter Type
   • Criteria: List from a range: DDSU666, DTSU666
   • Reject invalid input

3. Address Range Validation:

   • Column: Assigned Modbus Address
   • Criteria: Number between 1 and 247
   • Warning on invalid input (not rejection, to allow temporary placeholders)

Audit Trail Requirements

What to Track:

• Every status change must include date and operator name
• Notes column should capture any deviations from standard process
• Conversion logs (screenshots) stored in Nextcloud with meter serial in filename

Retention:

• Keep inventory records for lifetime of deployment
• Archive old entries when meters decommissioned
• Export monthly backup to Excel and store in Nextcloud

---

Future Enhancements

Planned for Phase 2:

1. Web-Based Commissioning Portal

   • Browser-based UI for adding meters to NFE config
   • No SSH required for Remote Commissioning Team
   • Authentication and audit logging
   • Real-time dashboard showing meter status

2. Automated Meter Discovery on Modbus Bus

   • Raspberry Pi scans bus for new meters automatically
   • Suggests config entries for detected meters
   • Reduces manual configuration errors

3. Inventory Management Database

   • Centralized database replacing Nextcloud Sheets
   • API integration between converter tool and inventory
   • Auto-update status on successful conversions
   • Real-time sync across all teams

4. Converter Tool Enhancements:

   • Batch operations (convert multiple meters in sequence)
   • Save/load meter assignment lists
   • Auto-populate from inventory database
   • Persistent configuration (remember last settings)
   • Auto-generated conversion reports (PDF)

5. Mobile App for Field Installation

   • Scan meter barcode/QR code
   • Verify address label matches inventory
   • Guided installation checklist
   • Photo documentation for audit trail

6. Automated Alerting:

   • Notify Remote Commissioning when meter installed
   • Alert if meter stops logging after commissioning
   • Daily summary of meters pending action

7. Fleet Management Dashboard:

   • Web dashboard showing all meters across all sites
   • Real-time status (online/offline)
   • Energy consumption graphs
   • Maintenance scheduling

How to Request Features:

• Contact Development Team (CTO)
• Describe use case and priority
• Features prioritized based on team feedback and ROI

---

Appendix

Glossary

• DL/T645: Chinese national standard for electrical meter communication protocol
• Modbus RTU: Industry-standard serial communication protocol for industrial devices
• RS485: Differential serial communication standard (A+/B- or Data+/Data-)
• Station Address: 12-digit unique identifier for DL/T645 meters (meter serial number)
• Modbus Slave Address: 1-byte address (1-247) for Modbus devices on same bus
• USB-RS485 Adapter: Device converting USB to RS485 differential signals
• Baud Rate: Communication speed in bits per second (bps)
• Protocol Conversion: One-time operation switching meter from DL/T645 to Modbus mode
• ZeroTier: Virtual private network (VPN) software for secure remote access
• SSH: Secure Shell protocol for remote command-line access

Quick Reference Card

Converter Tool Quick Steps:

1. Connect meter power and USB-RS485 adapter
2. Run converter.exe → Refresh → Select port → Connect
3. Enter 12-digit station address (from meter label)
4. Enter target Modbus address (from inventory)
5. Click "▶ Full Process"
6. Wait for "✓ Full Process Complete"
7. Update inventory status to "Converted"
8. Label meter with address sticker

Common Mistakes to Avoid:

• ❌ Using address 1 (always use 10+ for single-phase, 100+ for three-phase)
• ❌ Swapping A+/B- wiring (causes "No response" errors)
• ❌ Forgetting to change baud rate to 9600 after conversion (for Modbus scan)
• ❌ Skipping physical label (causes installation errors)
• ❌ Not updating inventory (breaks audit trail)

---

Document Version History:

• v1.0 (2026-04-04): Initial release - Complete pre-commissioning workflow

Document Owner: Development Team Review Cycle: Quarterly or as needed for process updates

Towards a Framework for Autonomous Microgrids

Table of Contents

1. Introduction

2. Core Concepts

   • Assets

   • Foundational Capabilities

   • Application Capabilities

3. Automation vs Autonomy

4. Levels of Operational Autonomy

   • Level 1 — Manual Local Operation

   • Level 2 — Automated Supervisory Control

   • Level 3 — Autonomous Supervisory Control

5. Operational Criticality

   • Safety-Critical Capabilities

   • Business-Critical Capabilities

   • Optimization Capabilities

6. Applying the Framework

7. Implications for a Microgrid OS

A picture with worth a thousand words 

Introduction

As distributed energy resources become increasingly software-defined, microgrids are evolving from manually operated electrical systems into digitally coordinated energy platforms. This evolution creates a need for a clear framework describing the degree of operational autonomy assigned to different microgrid functions.

This document proposes a simple three-level autonomy model for microgrids inspired by concepts from industrial automation, supervisory control systems, and autonomous systems engineering.

Unlike autonomous vehicle frameworks that classify an entire vehicle into a single automation level, this framework applies autonomy levels to specific operational capabilities operating on specific assets.

For example:

• Observing smart meter consumption

• Steering battery dispatch

• Observing EV charger utilization

• Steering flexible loads

• Forecasting solar production

Each capability may operate at a different level of autonomy.

A microgrid could therefore simultaneously contain:

• Level 3 autonomous battery steering

• Level 2 remote EV charger steering

• Level 1 manual generator operation

This capability-oriented approach allows microgrids to evolve incrementally toward higher levels of operational autonomy.

---

Core Concepts

Assets

Assets are physical, digital, or economic components participating in the operation of the microgrid.

This framework groups assets into three primary categories.

1. Physical Assets

Physical assets are hardware systems that generate, store, distribute, consume, or protect electrical energy.

Examples include:

• Smart meters

• Battery energy storage systems (BESS)

• Solar PV inverters

• EV chargers

• Diesel generators

• Protection relays

• Flexible loads

• Distribution transformers

• Remote disconnect relays

2. Digital Assets

Digital assets are software systems, communications systems, and computational services used to monitor, coordinate, optimize, and operate the microgrid.

Examples include:

• Billing systems

• Tariff engines

• Payment systems

• Forecasting systems

• Customer identity systems

• AI orchestration systems

• SCADA platforms

• DERMS platforms

• Telemetry databases

• Mobile applications

• Notification systems

3. Economic and Contractual Assets

Economic and contractual assets represent the financial, commercial, and policy relationships governing the microgrid.

Examples include:

• Customer accounts

• Energy credits

• Tariff structures

• Power purchase agreements (PPAs)

• Service tiers

• Demand response agreements

• Payment obligations

• Credit limits

• Utility interconnection agreements

These asset categories recognize that modern microgrids are not purely electrical systems. They are virtual-physical-economic systems integrating energy infrastructure, software platforms, and operational business logic into a unified operational environment.

---

Foundational Capabilities

Foundational capability domains are the core operational primitives from which higher-order microgrid behaviors and applications are constructed.

Rather than treating every operational function as a separate foundational capability, this framework identifies a small set of core capabilities that can be composed together to create more advanced orchestration, optimization, commercial, and autonomous behaviors.

These foundational domains operate across physical, digital, and economic assets.

1. Observability

Observability capabilities measure, record, analyze, and communicate system state.

Observability forms the awareness layer of the microgrid.

Examples:

• Reading smart meter consumption

• Monitoring battery state of charge

• Detecting inverter faults

• Measuring feeder voltage and frequency

• Monitoring EV charging sessions

• Customer usage analytics

• Payment status monitoring

• Event logging and telemetry collection

2. Steering

Steering capabilities execute operational actions intended to guide system behavior toward desired operational outcomes.

Unlike traditional low-level control systems, steering emphasizes adaptive orchestration, policy-driven operation, and outcome-oriented system management across distributed assets.

Steering forms the action layer of the microgrid.

Examples:

• Disconnecting a load

• Dispatching battery storage

• Curtailing solar generation

• Starting a backup generator

• Setting EV charging limits

• Executing demand response actions

• Remote relay switching

• Service disconnection and reconnection

3. Intelligence

Intelligence capabilities generate predictions, recommendations, classifications, reasoning, and adaptive operational decisions.

Intelligence forms the reasoning layer of the microgrid.

Examples:

• Solar production forecasting

• Load forecasting

• Predictive maintenance

• Fault prediction

• Fraud detection

• Adaptive operational policy selection

• AI-driven energy management

• Anomaly detection

• Optimization modeling

4. Governance

Governance capabilities define and enforce operational rules, permissions, priorities, compliance requirements, and safety boundaries.

Governance forms the constitutional layer of the microgrid.

Examples:

• Access control

• Human override policies

• Safety constraints

• Regulatory compliance

• Escalation policies

• Operational audit logging

• Cybersecurity enforcement

• Service disconnection policies

• Critical load protections

---

Application Capabilities

Operational application domains are higher-order business and operational functions constructed from combinations of the foundational capabilities.

These applications are not themselves foundational primitives. Rather, they emerge from orchestrating observability, steering, intelligence, and governance capabilities together.

Coordination

Coordination capabilities orchestrate workflows across systems, users, assets, and operational processes.

Coordination typically combines:

• Observability

• Steering

• Governance

Examples:

• Human escalation workflows

• Multi-device orchestration

• Customer notification systems

• Utility coordination

• Maintenance scheduling

• Service provisioning workflows

• Incident response coordination

Optimization

Optimization capabilities improve operational efficiency, economics, reliability, or customer experience.

Optimization typically combines:

• Intelligence

• Steering

Examples:

• Energy arbitrage optimization

• EV charging optimization

• Demand response coordination

• Forecast-driven battery dispatch

• Load balancing

• Power quality optimization

• Asset utilization optimization

Commercial Operations

Commercial operations capabilities manage the economic and business functions of the microgrid.

Commercial operations typically combine:

• Observability

• Steering

• Intelligence

• Governance

Examples:

• Customer billing

• Tariff management

• Payment processing

• Credit management

• Revenue collection

• Energy credit accounting

• Invoice generation

• Service eligibility evaluation

• Automated service disconnection and reconnection

---

Automation vs Autonomy

The distinction between automation and autonomy is foundational to this framework.

Automation

Automation refers to systems that execute predefined instructions or workflows under human-defined logic.

Examples:

• Fixed battery charging schedules

• Rule-based generator startup

• Threshold-based load shedding

• Remote switching by operators

• Scheduled EV charger limits

An automated system follows instructions.

Autonomy

Autonomy refers to systems capable of independently managing operational objectives under changing conditions while operating within defined technical, economic, and safety constraints.

Examples:

• Optimizing battery dispatch based on tariffs, weather forecasts, and outage probability

• Dynamically prioritizing critical loads during constrained operation

• Coordinating EV charging across multiple users to minimize peak demand

• Predictive fault response and recovery

• Adaptive energy management based on real-time conditions

An autonomous system manages outcomes.

---

Levels of Operational Autonomy

This framework distinguishes between:

• Manual local operation

• Automated supervisory control

• Autonomous supervisory control

---

Level 1 — Manual Local Operation

At Level 1, foundational capabilities are operated directly by humans physically present at the asset location.

The asset itself provides the operational interface.

Examples:

• Reading values directly from a smart meter display

• Manually operating breakers or disconnects

• Physically starting a generator

• Local inverter configuration

• On-site battery inspection

Operational Characteristics

Question	Answer
Who monitors the system?	Human operators on-site
Who makes decisions?	Human operators on-site
Who executes actions?	Human operators on-site
Who handles failures?	Human operators on-site

Characteristics

• No remote supervisory capability

• Human-driven operational awareness

• Minimal software orchestration

• Typically isolated or standalone systems

Relevant Standards

Relevant standards may include:

• IEEE 1547 for DER interconnection behavior

• IEEE 2030.7 for microgrid controller functional specification

• IEC 61850 for power system communication models

At Level 1, however, most operational authority remains local and manual.

---

Level 2 — Automated Supervisory Control

At Level 2, foundational capabilities are supervised remotely through software platforms and communications networks.

Humans remain responsible for operational decisions, while software automates telemetry collection, visualization, alarms, workflows, and execution of predefined control logic.

Examples:

• Remote smart meter monitoring

• SCADA-based microgrid supervision

• Rule-based battery dispatch

• Remote EV charger management

• Automated threshold alarms

• Scheduled load control

Operational Characteristics

Question	Answer
Who monitors the system?	Human operators remotely
Who makes decisions?	Human operators remotely
Who executes actions?	Automated systems under human-defined logic
Who handles failures?	Human operators with software assistance

Characteristics

• Remote visibility and control

• Centralized supervisory software

• Deterministic rule-based workflows

• Human approval remains central

• Software improves operational efficiency but does not independently manage system objectives

Relevant Standards

This level aligns closely with existing industrial automation and microgrid supervisory standards including:

• IEEE 2030.7 — Specification of Microgrid Controllers

• IEEE 2030.8 — Testing of Microgrid Controllers

• IEC 61850 — Power system communication models

• DNP3 and Modbus — Telemetry and control protocols

• OpenADR — Demand response coordination

Level 2 corresponds closely to modern SCADA and DERMS architectures.

---

Level 3 — Autonomous Supervisory Control

At Level 3, foundational capabilities are operated autonomously by software systems capable of independently managing operational objectives within defined technical, economic, and safety constraints.

Humans define policies, operating boundaries, escalation procedures, and override authority, but the system continuously makes operational decisions without requiring constant human supervision.

Examples:

• AI-driven battery optimization

• Autonomous load orchestration

• Dynamic outage response

• Self-optimizing EV charging coordination

• Predictive maintenance actions

• Autonomous islanding and reconnection

• Adaptive tariff-aware energy management

Operational Characteristics

Question	Answer
Who monitors the system?	Autonomous software systems with human oversight
Who makes decisions?	Autonomous systems operating within defined policies
Who executes actions?	Autonomous software systems
Who handles failures?	Autonomous systems first, humans upon escalation

Characteristics

• Goal-oriented operational behavior

• Context-aware decision making

• Forecast-driven optimization

• Dynamic adaptation to changing conditions

• Human escalation rather than continuous supervision

• Continuous optimization across multiple objectives

Key Requirements

Level 3 systems should include:

• Human override capability

• Policy enforcement mechanisms

• Audit logging

• Cybersecurity protections

• Fallback operational modes

• Confidence scoring and escalation logic

• Safety envelopes and operational constraints

Relevant Standards

Existing standards partially address autonomous operation today. Relevant references include:

• IEEE 2030.7 and 2030.8

• IEC 62351 — Power system cybersecurity

• NIST Cybersecurity Framework

• Emerging AI governance and operational safety standards

Further industry standardization may be required to fully define autonomous microgrid operation.

---

Operational Criticality

Not all microgrid capabilities carry the same operational importance or risk.

This framework distinguishes between different classes of operational criticality.

Safety-Critical Capabilities

Capabilities whose failure or misuse could threaten human safety, equipment safety, or grid stability.

Examples:

• Protection relay operation

• Islanding and reconnection

• Overcurrent protection

• Emergency load shedding

• Battery thermal protection

• Voltage and frequency stabilization

These capabilities typically require strict operational constraints, auditability, and human override mechanisms.

Business-Critical Capabilities

Capabilities necessary for the commercial and operational sustainability of the microgrid business.

Examples:

• Customer billing

• Payment processing

• Remote service disconnection

• Tariff enforcement

• Revenue collection

• Customer account management

These capabilities are operationally important but must remain subordinate to safety-critical protections.

Optimization Capabilities

Capabilities intended to improve efficiency, economics, customer experience, or asset utilization.

Examples:

• Energy arbitrage optimization

• EV charging optimization

• Demand response coordination

• Forecast-driven battery dispatch

• Predictive maintenance

• Customer energy recommendations

Optimization capabilities should degrade gracefully without compromising safety or core operations.

Supporting Capabilities

Capabilities that support operational continuity, efficiency, maintenance, coordination, or administrative workflows, but whose temporary failure does not immediately compromise safety or core service delivery.

Examples:

• Maintenance scheduling

• Reporting systems

• Asset inventory management

• Customer notifications

• Workforce coordination

• Historical analytics

• Non-critical integrations

Supporting capabilities improve operational effectiveness and resilience but are generally lower priority during constrained or degraded operations.

Informational Capabilities

Capabilities whose primary purpose is visibility, insights, diagnostics, learning, or reporting without direct operational authority over the system.

Examples:

• Dashboards

• Historical reporting

• Data visualization

• Energy usage insights

• Community analytics

• Educational interfaces

• Public transparency portals

Informational capabilities provide situational awareness and decision support but typically do not directly influence operational behavior.

---

Applying the Framework

The framework is intended to classify autonomy at the capability level rather than the whole microgrid level.

Example:

Asset	Foundational Capability Domain	Operational Function	Autonomy Level
Smart Meter	Observability	Usage telemetry	Level 2
Battery Storage	Steering	Battery dispatch	Level 3
Diesel Generator	Steering	Generator operation	Level 1
EV Chargers	Observability	Charger monitoring	Level 2
EV Chargers	Steering	Charging orchestration	Level 3
Billing System	Commercial Operations	Automated billing	Level 2
Smart Relay	Steering	Service disconnection	Level 3

This allows gradual evolution toward autonomy without requiring the entire microgrid to transition simultaneously.

---

Implications for a Microgrid OS

A Microgrid OS designed around this framework should:

• Treat foundational capabilities as modular services

• Support mixed autonomy levels simultaneously

• Allow policy-driven escalation to humans

• Maintain secure telemetry and control channels

• Provide auditability and operational transparency

• Support standards-based interoperability

• Maintain operational safety boundaries

• Support both edge and cloud orchestration architectures

The Microgrid OS becomes the orchestration layer coordinating assets, capabilities, policies, and autonomy levels across the energy system.