Product

Book on product development. Metering, Microgrid OS, Batteries, Invertors, Solar panels

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

Monitoring and Steering assets on the microgrid

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. 

Microgrid OS

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. 

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

Next Steps 

Continue deployment to digital ocean VM

 Steps to Determine Required Packages

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:

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.

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:

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

Microgrid OS

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)


Phoenix Finance (domestic payment plans)


Smart Ease (commercial payment plans)


Scaffolding Integration

🎥 PVF Scaffolding Training


API Integrations

Learn more and view documentation

Microgrid OS

Target Architecture

Metering

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. 

The meter sample fee: 10pcs*600USD/pc; the DCU will need 7500USD/pc; the PC software for testing is 5000USD/pc; the optical head is 300USD/pc; the pilot system will need 30000USD; the technical assistance fee is 1500USD; DHL shipping cost is around 5500USD.

Metering

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

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

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 ✅

📌 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:

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

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

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

Chatgpt detailed thread

Metering

CalinMeter

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

User Manuals 

⚡ 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

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

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

Examples

Example #1

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

Screenshot 2025-09-04 at 14.21.36.png

Answer 

Meter operating status = 1008

Step 1: Interpret the Code

Step 2: What This Means in Postpaid Setup

Step 3: Field Action (from Quick Action Guide)

✅ 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 

Screenshot 2025-09-04 at 14.36.50.png

Answer

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

Case: Meter operating status = 1000

Step 1: Interpret the Code

Step 2: What This Means in Postpaid Setup

Step 3: Field Action (from Quick Action Guide)

✅ Summary for your case:

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

👉 Everything is normal; no technician action required.

⚡ So together:

Metering

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

Metering

NFE metering strategy + Glen Street-EMS

Authoritative page for NFE's role in the IEEE Smart Village meshEMS / Street-EMS initiative. Compiled 2026-08-10 from the Element room "Smart Village Energy Interest Group" (full history back to 2026-04-24), the ISV Dev Kit BOM sheet, isv.wiki, and the Rev B/C line diagrams. No customer PII or financial ledgers on this page by policy.

What it is

Not a standalone NFE product. It is NFE's seat in an IEEE Smart Village (ISV) open-source initiative called meshEMS, hardware-branded Street-EMS, started at an IEEE / NESL hackathon in April 2026. Hardware and firmware are led by Glenn Algie (10power.com / NESL); the software and standards side is led by Adam Sauer (ISV Tech Committee chair). The working venue is the Element/Matrix room "Smart Village Energy Interest Group".

meshEMS is open-source firmware on an ESP32-S3 / ESP32-P4 module doing OpenAMI two-way metering and control over secure MQTT into OpenEMS. Deployed as a street-pole or pedestal low-voltage feeder cabinet that meters AND controls every tenant, it is designed to replace the per-tenant DIN-rail meters and the OpenEMS Raspberry Pi with a single integrated 9x15 cm EMS board.

How it fits NFE

The cabinet (Rev C, 9-tenant, 3-phase LV feeder)

Signal flow left to right:

Legend (Rev B with legend): QF circuit breaker, CT current transformer, K contactor, UKK80 distribution terminal block, RCM residual current monitor, SSR solid-state relay, PCB printed circuit board, EVSE EV charger. 1P+N one phase plus neutral. RS485 / Modbus UART / I2C communications.

Decisions ratified in the room (2026-07-25):

Still open: the make-before-break 80A neutral / phase-transfer balancer ("neutral rebalancer transfer method and apparatus") and the EVSE port are marked spare-room / in-progress.

Firmware and energy-policy vision (Glenn)

Local, IFTTT-style per-tenant automation in C/C++ on the ESP32, not just remote on/off:

Cloudless village

An ESP32-P4 with its own Ethernet NIC acts as a per-feeder aggregation node. Street-EMS units LAN-hop along the feeder ("feeder hops") to run an in-village pay-go portal and full UX with no broadband. Optional LoRa / Meshtastic mesh and power-line communication on top; optional low-cost village camera / audio snapshots.

Standards and interoperability (OpenAMI)

OpenAMI is the "actionable energy telemetry" layer, the utility-facing layer above a village feeder. Built on DLMS/COSEM (IEC 62056), SunSpec Modbus/JSON, MQTT, IEEE 1547-2018 (DER interconnection) and IEEE 2030.5 (Smart Energy Profile). Village Metering goals: billing, remote disconnect, theft detection. EnAccess Foundation is extending the OpenAMI codeset. Reference: isv.wiki (repo github.com/overview-solutions/isv-ai-wiki, MIT).

The workshop (immediate driver of the ISV Dev Kit BOM)

IEEE ISV awarded Glenn and Adam a 4-session, 9-hour hands-on workshop (assemble an EMS in about 15 minutes each, assemble a cabinet, run code challenges). IEEE funds the parts BOM. Plan: build 15-20 EMS units and 3-5 multitenant cabinets for participants to take home (about USD 50 each). Parts pre-ship to Albert, the ISV lead in Nairobi (AliExpress China to Nairobi direct; small PCB parts hand-carried, PSUs prebuilt on site). BOM total about USD 2,377 per batch (see the ISV Dev Kit BOM sheet).

Venues: PAC2026 Nairobi (September) and OSEAS Kigali, Rwanda (October, about EUR 50).

NFE attendance (as of 2026-08-10): Dansturn and Dismas are going to Kenya (Nairobi). Aaron, now back in Uganda, could join them. Kigali remains a possibility. Glenn asked NFE to co-lead the cabinet builds.

People and orgs

Glenn Algie (10power.com / NESL / IEEE ISV, hardware + firmware; also WMAC.CLOUD New Zealand, REI Cameroon). Adam Sauer (ISV Tech Committee chair, meshems software + OpenAMI, runs isv.wiki). Aaron Tushabe, Hillary Arinda, Dansturn, Dismas (NFE). Albert (ISV Nairobi lead). Abiodun Okunola (ISV Africa regional lead). EnAccess Foundation, EPRI Open Source, NESL.

Sources

Open items

Metering

Phase Balancing Recommendation (Sezibwa)

Recommendation for re-assigning Sezibwa's single-phase customers across the three phases of the SRNE three-phase inverter, to fix a severe load imbalance. Uses meter IDs; the site operator maps these to customers.

Implementation status (2026-08-24)

The two minimal phase-balancing moves were completed on the morning of 2026-08-24:

The expected post-change distribution is L1 5.9 / L2 7.3 / L3 7.6 kWh/day (28 / 35 / 37 percent), based on the historical load profile. Live measurements should be reviewed after sufficient post-change data has accumulated to confirm the achieved balance.

Baseline before the change (the problem)

Before the 2026-08-24 reconnections, meter_100's per-phase energy and per-customer voltage matching (all high-confidence), the current assignment and daily load is:

Phase Load (kWh/day) Share Customer meters (kWh/day)
L1 10.4 50 percent 002 (5.7), 003 (4.5), 008 (0.1), 011 (0.1)
L2 5.1 25 percent 009 (2.3), 007 (1.6), 010 (1.2)
L3 5.3 25 percent 006 (2.7), 005 (2.1), 004 (0.5)

Total site load about 20.7 kWh/day, so the ideal is about 6.9 kWh/day per phase. L1 carries half the site while L2 and L3 carry a quarter each.

Root cause: the two largest consumers, meter 002 (5.7) and meter 003 (4.5), are both on L1. Together they are 10.2 kWh/day, which already exceeds a balanced phase on its own.

Updated meter reference (after 2026-08-24 phase balancing)

This table records the wiring after the two completed moves. Initials only (no full names, per the customer-data rule). Modbus address is the meter's slave address; serial is the physical meter serial. Energy figures are historical averages used for the recommendation, not post-change measurements.

Meter Modbus addr Serial Customer (initials) Previous phase Current phase Change status Historical kWh/day
meter_002 2 200326019929 NP L1 L1 Unchanged 5.7
meter_003 3 200326020101 KFH L1 L2 Moved 2026-08-24 4.5
meter_004 4 200326020199 AB L3 L3 Optional L3→L1 move outstanding 0.5
meter_005 5 200326020128 KFH L3 L3 Unchanged 2.1
meter_006 6 200326020209 WS L3 L3 Unchanged 2.7
meter_007 7 210302003356 JN L2 L2 Unchanged 1.6
meter_008 8 200326019807 PO L1 L1 Unchanged 0.1
meter_009 9 250902040373 DK L2 L3 Moved 2026-08-24 2.3
meter_010 10 250902040216 SN L2 L2 Unchanged 1.2
meter_011 11 250902040311 (unmapped) L1 L1 Unchanged 0.1

KFH holds two meters (003 and 005), now split across L2 and L3. Names are looked up live from the customer database by serial; the logical-to-service-ID map in the logger configuration had 009/010 transposed, so the physical serial remains authoritative.

Why phase balance matters

  1. Voltage quality. L1 carries roughly twice the current of L2/L3, so it has the largest voltage drop. Customers on L1 see the lowest voltage (dimmer lights, more appliance stress) while L2/L3 sit high. Balancing evens the voltage across customers.
  2. Backup capacity. The SRNE is a three-phase inverter with a per-phase output limit. During a grid outage (battery backup), an overloaded L1 can hit its per-phase limit and trip or brown out even though L2 and L3 have spare capacity and the total is within the inverter rating. Balancing maximises the backup the site can actually deliver.
  3. Losses. Imbalance drives neutral current and extra I2R losses in the distribution.

Note: this does not affect the battery arbitrage or solar economics. The three-phase inverter time-shifts the site's total energy across all phases, so the savings analysis is unchanged. Phase balancing is a separate power-quality and backup-reliability issue.

Implemented recommendation (minimal moves)

The following two reconnections were completed on 2026-08-24:

  1. Completed: meter 003 (4.5 kWh/day) moved from L1 to L2 — the key move, separating the two big loads (002 and 003).
  2. Completed: meter 009 (2.3 kWh/day) moved from L2 to L3 — rebalances L2 after taking on 003.

Expected result based on the historical load profile:

Phase Before After 2 moves
L1 10.4 (50 percent) 5.9 (28 percent)
L2 5.1 (25 percent) 7.3 (35 percent)
L3 5.3 (25 percent) 7.6 (37 percent)

The max-minus-min spread drops from 5.3 to 1.7 kWh/day.

Outstanding optional third move for near-perfect balance: meter 004 (0.5) remains on L3. Moving it from L3 to L1 would give L1 6.4 / L2 7.3 / L3 7.1 (31 / 35 / 34 percent), spread 0.9.

The calculation

Loads are from the same meter data used across the Sezibwa economic analysis (meter_100 aggregate plus per-customer meters, over the March to August 2026 window). Note that meters 003 and 005 belong to the same customer (two service points); moving 003 to L2 leaves that customer with one meter on L2 and one on L3, which is fine.

Data provenance

Underlying data: the aggregate meter meter_100 plus the 10 customer sub-meters, over 2026-03-19 to 2026-08-10, from the modbus energy-logger archive (sources: pi-direct and nextcloud-import), i.e. the pre- and early-OpenEMS period. Load basis is a conservative 21.3 kWh/day.

Note (2026-08-20): the site has since migrated to OpenEMS, which is now the live source. OpenEMS-sourced daily figures from mid-August show inconsistencies (the aggregate roughly doubled exactly at the source switchover, and on some days the customer-meter sum exceeds the aggregate), so they are treated as a data-quality issue to resolve before use; this analysis stays on the validated archive. The baseline phase assignments reflect wiring observed up to about May 2026. The meter reference and implementation status above were updated for the reconnections completed on 2026-08-24; OpenEMS measurements should be used to verify the resulting live balance.

Metering

Sezibwa meter replacement log

Sezibwa meter replacement log

One entry per customer meter swap at Sezibwa (gateway gw-pi2). Record every system that points at a meter serial, because each one must be switched separately: the OpenEMS gateway config, the customer app (meter_sources) and the billing engine (MBE device + household link). Customers are identified here by Modbus address and serial only.

Summary

Date Modbus address Old serial New serial Status
2026-09-14 7 210302003356 200326020197 All systems switched 2026-09-24; closing 244.54 kWh, opening 0.31 kWh

2026-09-14: address 7, 210302003356 to 200326020197

Why it was replaced. The old meter stopped answering on the meters bus on 2026-08-29 at 23:07 UTC (logger issue #82). It was later found physically absent. Its last register value seen on the backend was 229.35 kWh on 2026-09-04.

New meter. CHINT DDSU666 serial 200326020197, on Modbus address 7. The first backend data is from 2026-09-14; the register read 16.16 kWh on 2026-09-24.

Systems switched:

System Change Date Reference
OpenEMS gateway (gw-pi2) New meter component meter200326020197 on unit 7 2026-09-14 microgrid-gateway PR #68
Customer app meter_sources row repointed to meter200326020197/ActiveConsumptionEnergy, history start 2026-09-14; daily usage backfilled 14 to 24 Sep with the production backfill script (11 days, sums match the register) 2026-09-24 this page
Billing engine (MBE) New device "(new meter)" added on edge sezibwa-rentals-gw-pi2 as a Consumption meter 2026-09-24 this page
Billing engine (MBE) Household billing device changed to the new device (Change billing device); old device now unlinked; invoice meter serial field set to 200326020197 by hand 2026-09-24 MBE UI gap reported: serial does not follow a device change

Closing and opening readings (from the swap thread, Element product room, 2026-09-14). Old meter 210302003356 read 244.54 kWh just before removal. New meter 200326020197 read 0.31 kWh at installation (about 12:15 EAT), on Modbus address 19. The old meter's register kept counting while it was off the bus, so there is no unmetered gap: its closing reading covers 30 Aug to 14 Sep.

September bill. The billing engine takes one meter per household per period, so bill this customer with one manual reading (manualReadings in the generate call) that joins the two meters:

Start End kWh
Old meter 223.52 (August end, when it went silent) 244.54 21.02
New meter 0.31 reading at September close end minus 0.31
Manual reading to enter 223.52 244.54 + (new end - 0.31) sum of both

Check first that the August bill really ended this customer at 223.52 kWh.

Watch. A stray 0.35 kWh value appears on 2026-09-14 under the old channel name. That was the new meter answering on address 7 before its component was renamed, not the old meter.

Storage

Batteries and invertor

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.1 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.1 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.4 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.6 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.4 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.4

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.16 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 12 and the higher end at approximately $70/kWh 4, 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.16 Several specific companies have been identified as offering BYD battery products.16 Additionally, BYD itself operates an energy storage division, which could be a direct point of contact for procurement.25 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.37 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.37 The typical transit time for sea freight from China to Uganda ranges from 5 to 8 weeks.38

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.38 However, this speed comes at a considerably higher cost compared to sea freight.37

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 40 to over 700kg for a Delong battery pack.41

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 37, 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.37 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.37

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.37 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.48 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.50 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%.50 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.52 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.50 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.50 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.48 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:

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.

Storage

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. 

 

 

Storage

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

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

Storage

FENECon - Germany

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

Storage

Solei Power - Uganda

https://www.soleilpower.ug/

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

They quoted: 

$1350 after a 10% discount for 5.12 kWh 
If we want to do 25kwh, they can supply with rack and parallel/terminal cables for $6630. That's about 15% off
Storage

Arbitrage Tracker (gw-pi2, Sezibwa)

Cumulative record of the TOU battery arbitrage on gw-pi2 (Sezibwa). Each night the inverter discharges the battery during a peak-tariff window and recharges it from the grid at the off-peak rate from 00:00. Daily progress goes to the Element business room; this page is the running record. It is rebuilt from the OpenEMS backend by scripts/arbitrage_tracker.py in the nfe-modbus-energy-logger repo.

Settings and why they were chosen: Arbitrage Window and Thresholds (decision record).

Last updated: 2026-10-15 06:32 EAT.

Totals

Measure Value
Nights armed 15
Energy shifted to peak 65.6 kWh
Estimated net saving 12,400 UGX
Average per armed night 4.37 kWh, 827 UGX
Projected per month at that rate 24,800 UGX

Night by night

Night Config Window Start SoC start SoC end Shifted (kWh) Peak (kW) Lowest pack (V) Saving (UGX) Recharge 00-06 (kWh) Notes
2026-09-26 v12 22:00-23:59 22:03 78% 48% 3.08 6.1 50.96 582 5.9 first armed night
2026-09-27 v13 off 0 0 4.5 disarmed: SoC 65% after the 27 Sep overload outage
2026-09-28 v14 21:30-23:30 21:33 87% 64% 2.28 4.6 51.45 432 4.1 window moved to 21:30-23:30
2026-09-29 v15 off 0 0 5.5 disarmed: SoC 61% after the 05:15-07:51 grid outage
2026-09-30 v17 21:00-23:00 21:03 87% 60% 2.75 6.3 50.94 519 4.5 window 21:00-23:00, no more manual disarms
2026-10-01 v18 off 0 0 5.7 skipped: two outages left SoC at 51% before the window
2026-10-02 v18 off 0 0 1.7 still disarmed (re-arm missed)
2026-10-03 v19 21:00-23:00 21:03 64% 38% 2.64 4.4 51.10 499 7.0 re-armed with the v17 profile
2026-10-04 v19 21:00-23:00 21:03 84% 63% 2.17 2.2 52.17 410 4.3
2026-10-05 v21 18:00-23:59 19:22 15% 9% 0.08 1.9 49.32 15 10.8 driver rules live: start at 30% or above, floor 15%; 0.9 kWh of the discharge was during an outage (backup, not counted)
2026-10-06 v21 18:00-23:59 18:04 89% 25% 5.04 4.0 51.14 953 8.4 1.5 kWh of the discharge was during an outage (backup, not counted)
2026-10-07 v21 18:00-23:59 18:04 89% 25% 6.56 5.0 51.00 1,239 8.3
2026-10-08 v21 18:00-23:59 18:04 89% 21% 6.88 5.5 50.22 1,300 8.7
2026-10-09 v21 18:00-23:59 18:04 79% 28% 5.18 4.3 50.88 980 8.0
2026-10-10 v21 18:00-23:59 18:04 65% 15% 4.96 4.1 51.10 938 9.4
2026-10-11 v21 18:00-23:59 18:04 54% 15% 3.59 4.3 50.26 679 9.2
2026-10-12 v21 18:00-23:59 18:00 77% 15% 6.12 4.4 50.52 1,157 9.0
2026-10-13 v21 18:00-23:59 18:03 89% 15% 7.51 5.1 50.34 1,419 9.3
2026-10-14 v21 18:00-23:59 18:04 89% 23% 6.76 4.1 50.82 1,277 8.5

Outages and reliability

Every grid outage, with how the battery carried it and how much of the reserve that night's arbitrage had already used. This is the record for judging what the deeper discharge costs in backup.

Measure Value
Outages 16 (27.4 h)
Outages where the site went dark 1
Outages that started after an arbitrage night, before the recharge 0
Of those, site went dark 0
Date Start End Duration SoC at start Lowest SoC Lowest pack (V) Battery supplied (kWh) Site dark Arbitrage use before (kWh) Notes
2026-10-01 10:45 14:12 3h27 93% 60% 52.16 3.4 no
2026-10-01 20:20 20:42 0h22 56% 52% 51.92 0.5 no
2026-10-03 15:10 16:49 1h39 90% 66% 52.10 2.5 no
2026-10-04 16:35 16:52 0h17 90% 87% 52.60 0.3 no
2026-10-05 06:40 09:27 2h47 96% 68% 52.07 3.0 no
2026-10-05 10:35 13:44 3h09 66% 37% 51.70 2.9 no
2026-10-05 13:50 14:42 0h52 37% 31% 51.91 0.5 no
2026-10-05 15:25 17:17 1h52 30% 15% 50.91 1.6 no
2026-10-05 19:25 20:55 1h30 15% 9% 49.32 1.0 yes, 48 min no data
2026-10-06 19:20 20:06 0h46 81% 64% 52.00 1.7 no
2026-10-09 16:50 17:55 1h05 90% 79% 52.62 1.1 no
2026-10-10 10:45 10:47 0h02 93% 93% 52.92 0.0 no
2026-10-10 12:30 12:54 0h24 92% 89% 52.80 0.3 no
2026-10-10 15:15 17:39 2h24 88% 65% 52.32 2.4 no
2026-10-11 02:15 08:20 6h05 100% 60% 52.28 4.0 no 0.0
2026-10-12 17:20 18:04 0h44 89% 77% 51.99 1.3 no

Where to tweak

Method

Storage

Arbitrage Window and Thresholds (decision record)

This page records how the nightly TOU arbitrage window and battery thresholds at Sezibwa (gw-pi2) were chosen and changed. For the running night-by-night results see the Arbitrage Tracker. The engineering record is ADR-016 in the microgrid-gateway repository.

Current settings (from 30 Sep 2026)

Setting Value
Discharge window 21:00 to 23:00 (config v17, microgrid-gateway PR #77)
Start threshold 75% battery at window start, otherwise skip the night
Floor 45%, stop discharging when reached
Recharge from the grid at the off-peak rate from 00:00 (unchanged)

How the thresholds are enforced. Until now, the 75% start rule and the 45% floor were enforced by hand, by deploying a "disarm" config and later a "re-arm" config. That meant a change and a deploy after every outage day. It stops now:

Why 21:00 to 23:00

Site load inside each candidate window, over 75 to 77 nights (1 Jul to 28 Sep 2026). Battery use is corrected for the two real nights, which used about 20% less charge than the load alone predicts.

Window Average load Heavy night (1 in 10) Ends at, from a typical 86% start Heavy nights ending below 45% Ends at, from a 75% start
21:30 to 23:30 (previous) 3.5 kWh 4.5 kWh 59% 0% 48%
21:00 to 23:00 (chosen) 3.8 kWh 4.8 kWh 57% 4% 46%
21:00 to 23:30 4.4 kWh 5.3 kWh 53% 9% 42%
22:00 to 23:59 2.9 kWh 4.0 kWh about 64% 0% about 53%

21:00 to 23:00 shifts slightly more energy than the previous window and stays clear of the floor on normal nights. 21:00 to 23:30 adds little energy, and from a 75% start it would end below the floor on most nights.

Typical start level. On normal evenings the battery is at about 86% at 21:00. It is lower only after a daytime outage (27 and 29 Sep started at 65% and 61%).

Outage timing. Of 14 outages seen from 25 Aug to 30 Sep (grid absent at least 30 minutes), 2 started between 21:00 and 06:00. The battery is refilled by about 01:30 after each night's discharge.

Value

Each kWh shifted from the peak rate (666.5 UGX) to the off-peak rate (429.7 UGX, at 90% round trip) saves about 189 UGX. Across the options above, arbitrage is worth roughly 15,000 to 20,000 UGX a month. The larger saving is solar (see "Solar Sizing Re-run, Sept 2026").

History

Date Config Change
26 Sep v12 First armed night, 22:00 to 23:59
27 Sep v13 Off after the overload outage (battery 65%)
28 Sep v14 Window 21:30 to 23:30
29 Sep v15 Off after the morning outage (battery 61%)
30 Sep v16 Re-armed 21:30 to 23:30
30 Sep v17 Window 21:00 to 23:00, start 75%, no more manual switch-offs
Storage

NFE Daily Brief (gw-pi2, Sezibwa)

NFE daily brief

Written each morning by Claude Haiku from the day's data. Newest first, last 30 days.

2026-10-14

Daily brief: Sezibwa Rentals, 14 October 2026

Arbitrage window (18:00–23:59): The battery started at 89% and ended at 24%, discharging 6.7 kWh. Its lowest level for the day was 15%.

Grid outages: None. Power was off for 0 minutes.

Evening L3 voltage: The lowest L3 reading was 193.5 V. L3 spent 233 minutes below 207 V. This matches the known grid-side sag pattern.

Modbus errors: 275 for the day. Normal is about 100 plus the nightly burst from midnight to 2 AM, roughly 260 in total, so this is slightly higher than expected.

Needs attention: Modbus read errors were slightly above expected (275 vs. about 260). Check whether this repeats tomorrow.

2026-10-13

Daily brief, Sezibwa Rentals battery, 13 October 2026

The evening arbitrage window ran from 89% to 15% battery charge, discharging 7.5 kWh. The battery held the 15% floor.

There was no grid outage today (0 minutes).

Evening voltage on phase L3 was below 207 V for 189 minutes. The lowest L3 reading was 197.6 V. This matches the known evening pattern.

Modbus read errors totalled 230. That is within the normal range, which allows about 100 per day plus the nightly burst from midnight to 2 AM while the battery charges.

Needs attention: nothing.

Storage

Macro outlook: shilling, rates and NFE (15 Oct 2026)

Macro outlook: shilling, interest rates and NFE (15 Oct 2026)

Asked by Aaron in the NFE leads chat. Facts are from public reporting found on 15 Oct 2026 (links at the end). Where sources disagree or I could not confirm, it is marked UNVERIFIED. NFE's own cost and funding numbers are not all known to this note; the "what we need" list at the end says which.

What happened

How it reaches NFE

Channel Direction Why
Hardware (inverters, batteries, panels, meters, Pis) Cost up Priced off the dollar. Local quotes follow the shilling within weeks.
Solar quote (Mudde, UGX 4,426,000 materials) Cost up About USD 1,067 at 4,150. See table below.
Customer tariff in MGM Lagged support MGM bands mirror ERA's domestic tariff (250 / 779.4 / 412 / 779.4 UGX/kWh, UGX 7,320 service charge, 18% VAT). ERA reviews quarterly and has named the exchange rate as an input, so retail prices follow the dollar with about one quarter of delay.
Arbitrage (peak 666.5 vs off-peak 429.7 UGX/kWh, Code 10.2) Mild support The saving is set in shillings, so it grows only if ERA raises tariffs. Today about 189 UGX per shifted kWh, roughly UGX 35,000 a month on one site at 6 kWh a night. Small against hardware costs.
Borrowing Cost up CBR at 12% points to higher shilling loan rates (assumption: not yet seen). Dollar loans look cheaper (7.5%) but turn expensive if the shilling keeps falling.
Customers (Sezibwa households) Risk Fuel and food inflation cuts what households can spend; September's pilot bill was UGX 552,197 for 8 households, so a few late payers matter.
Cloud and SaaS (Hetzner in EUR, Claude Team, API credits) Cost up, small Charged in foreign currency. The Claude credits (USD 1,000) and any USD grant gain value in shillings.
Grid reliability Possible risk Fuel cost and import pressure can strain UEDCL. Our 20:00 to 22:30 L3 sag pattern is already grid-side.

Sensitivity: the Mudde solar materials quote (UGX 4,426,000 at 4,150/USD)

UGX per USD Materials cost (UGX) Change
3,950 4,212,700 -5%
4,150 4,426,000 base
4,500 4,799,300 +8%
4,800 5,119,200 +16%
5,000 5,332,500 +20%

The quote is valid to about 22 Oct. Labour is extra and local (Green Volta).

What I would do

  1. Decide the solar order before the quote lapses (about 22 Oct) or ask Mudde to hold the price in writing. Every 5% shilling move is about UGX 220,000 on materials.
  2. Buy hardware earlier rather than later for anything already planned (spare meters, Pis, a second inverter), while the shilling is firmer after the hike.
  3. Keep any USD funding in USD (grant, credits) until a shilling cost needs paying.
  4. Keep customer tariffs on the ERA bands and re-read the ERA schedule every quarter (next: the Q1 2027 schedule, due about the end of December).
  5. Avoid new shilling debt at the current rates unless the project pays back well inside a year; compare with a dollar-linked option only if income is dollar-linked.
  6. Watch the cash side of billing: track unpaid bills in MGM monthly, because households are the first to feel inflation.

What we need to finish this properly

Sources

Billing


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

Billing

Pesapal

In Brief: Pesapal is a Payment Service Provider that enables various forms of Payment options for business in one platform. Through our Online and Point of Sale Payments services, we ensure customers have a variety of options, and your team can monitor all transactions coming through in one web-based merchant dashboard.

ONLINE PRODUCTS:


 We provide a personalised payments page link that enables your clients to pay you both on and off the website. It accepts Visa, Mastercard, AMEX and mobile money payments. For example, https://payments.pesapal.com/wildwaterslodge


Benefits:
Find Below examples of some of the properties and the links that we have Integrated the online booking engine.

B)Point of sale machine
cid:b75f8c5e-18fd-4b37-bd97-65a8b3c42067

Distinct features
 We provide a personalised payments page link that enables your clients to pay you both on and off the website. It accepts Visa, Mastercard, AMEX and mobile money payments. For example, https://payments.pesapal.com/wildwaterslodge

Rates and costs
Documents required to be submitted

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

The Microgrid OS capability model describes what the platform enables people, devices and software to do. Capabilities are therefore named as behaviours — using verbs or object–verb phrases — rather than as domain nouns such as Assets, Alerts, Payments or Storage.

This keeps capability boundaries stable even as implementations change. For example, Measure Energy Use can be implemented by OpenEMS today and by other metering providers later; Collect Payments can be implemented by MTN MoMo, Airtel Money, bank integrations or manual reconciliation.

Important: the capability map and the Generation 1 / 2 / 3 model describe different things.
The capability map defines what the Microgrid OS does. The generation model describes how open, locally maintainable and community-controlled the current implementation of a capability is.

Capability map

nfe_microgrid_capability_map_v2.png

How this changes the previous map

Previous noun-oriented area Capability-oriented framing
Metering Measure Energy Use
Storage Dispatch Stored Energy, Observe Energy Flows, Monitor Equipment Health
Solar Generation Observe Energy Flows, Forecast Generation, Control Equipment
Billing Configure Tariffs, Calculate Charges, Issue Invoices
Payments Collect Payments, Vend Energy Credit
Customer Relationship Management Manage Customer Accounts, Notify Customers & Operators
Alerts Detect Grid Outages, Diagnose Device Faults, Notify Customers & Operators
Assets Register Devices, Provision Devices, Commission Devices, Configure Devices

Generation model

Generation should be tracked per implementation of a capability, not baked into the capability name itself.

This lets NFE move a capability from one implementation generation to another without changing the capability contract itself.

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

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;

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


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:

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"
  1. Copy your public key:
cat ~/.ssh/id_ed25519.pub
  1. 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
  1. 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:

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
  1. Verify both devices are on the same network:
sudo zerotier-cli listnetworks
# Both should show network 2873fd00f2d70904 with status OK

  1. 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.

  2. Check for RELAY connection:

sudo zerotier-cli peers

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

  1. 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
  1. 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

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

  2. 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

Installation Steps

  1. Install ZeroTier on the Raspberry Pi:
curl -s https://install.zerotier.com | sudo bash
  1. Join the network:
sudo zerotier-cli join 2873fd00f2d70904
  1. Verify the Pi joined:
sudo zerotier-cli listnetworks

You'll see status as "ACCESS_DENIED" initially.

  1. Authorize the Pi:
  1. Verify connection:
sudo zerotier-cli listnetworks

Should now show:

200 listnetworks 2873fd00f2d70904 my-first-network ... OK PRIVATE ztxxxxxx 10.135.127.xxx/24
  1. Enable SSH (if not already enabled):
sudo systemctl enable ssh
sudo systemctl start ssh
  1. Make ZeroTier start on boot:
sudo systemctl enable zerotier-one
  1. Test connection from another device:
# From your computer (already on ZeroTier network)
ping <new-pi-ip>
ssh <username>@<new-pi-ip>
  1. 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

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

  2. Connect using the ZeroTier IP:

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

Last updated: 2026-03-28

OpenEMS

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

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

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)

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

1. Raspberry Pi OS Setup (Headless)

Use Raspberry Pi Imager:

Boot the Pi and connect via:

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:

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:

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:

If UI shows "disconnected":

Why UI Runs on macOS and Edge Runs on Pi

Troubleshooting

Security Notes

You now have:

OpenEMS

DTSU666 3‑Phase + mbpoll Command Reference

🔌 Standard Communication Settings (DTSU666)

Most DTSU666 meters use:

Protocol : Modbus RTU
Baud Rate : 9600
Data Bits : 8
Parity : None
Stop Bits : 2
Mode : Big‑endian
Table : Input Registers (FC04)

Base communication block used in all commands:

-m rtu -b 9600 -P none -s 2

🧠 Critical Flags (Important)

Flag Meaning Required?
-t 3 Input Registers (Function 04) ✅ Yes
:float 32‑bit floating point ✅ Yes
-B Big‑endian word order ✅ Yes
-0 Zero‑based addressing ✅ Yes
-a <id> Slave address ✅ Yes
-1 Poll once Optional
-l 5000 Poll every 5 seconds Optional

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

Register: 0x2006

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

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

Register: 0x2000

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

🔹 Phase Currents (L1, L2, L3)

Register: 0x200C

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

🔹 Total Active Power (kW)

Register: 0x2012

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

🔹 Frequency (Hz)

Register: 0x2044

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

🔹 Total Active Energy (kWh)

Register: 0x4000

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

🔁 Continuous Polling Example (Every 5 Seconds)

mbpoll -m rtu -b 9600 -P none -s 2 \
-t 3:float -B -0 \
-r 0x2006 -c 1 \
-l 5000 \
/dev/ttyUSB0 -a 1

🔢 Change Slave Address (Only One Meter Connected)

⚠ Use Holding Registers (Function 03) for configuration.

Register: 0x002E

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

Changes slave ID from 1 → 5.

🧪 Quick Communication Test

Fastest health check:

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

If you see ~230V → communication confirmed.

🚨 Troubleshooting Quick Guide

Symptom Likely Cause
Timeout Wrong address or wiring
4200+ volts Reading wrong register
-8192 values Wrong data type
Nonsense numbers Missing -B
No /dev/ttyUSB0 USB‑RS485 not detected
OpenEMS

SRNE ASP48120SH3 (Direct Hybrid Inverter) + mbpoll Command Reference

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

1. Purpose

Complete reference for the SRNE ASP48120SH3 three-phase hybrid inverter over Modbus RTU: what can be READ, what can be WRITTEN, and the tested limits. Validated against the live unit at Nansana on 2026-07-21 (slave address 1).

2. Hardware & Software Requirements

3. Serial parameters and function codes

4. Reading values (exhaustive, all ranges respond)

Every documented range answers FC03. Ranges (SRNE V1.7 segment map, confirmed on this unit):

Product info (P00), 0x0000 to 0x0049

Controller / battery (P01), 0x0100 to 0x0122

Inverter (P02), 0x0200 to 0x0237 (the main live telemetry, see the register-map page)

Settings / parameters, 0xE001 to 0xE02D (writable, see section 5). Raw values present; battery voltage thresholds around 0xE006 to 0xE00E appear as 48V-system values (register/10 x 4), e.g. 144 = 57.6 V. Exact per-register meaning is TBD from the ASP settings doc.

Settings F, 0xF000 to 0xF01F: additional parameters (raw values present).

Control commands, 0xDF00 to 0xDF09: write-only, read back as 0.

Example reads (mbpoll):

# battery block 0x0100 (dec 256), 4 regs
mbpoll -m rtu -b 9600 -P none -s 1 -t 4 -0 -r 256 -c 4 -a 1 -1 <port>
# inverter block 0x0210 (dec 528), 32 regs
mbpoll -m rtu -b 9600 -P none -s 1 -t 4 -0 -r 528 -c 32 -a 1 -1 <port>
# settings 0xE001 (dec 57345), 45 regs
mbpoll -m rtu -b 9600 -P none -s 1 -t 4 -0 -r 57345 -c 45 -a 1 -1 <port>

5. Writing values (tested 2026-07-21)

The inverter accepts BOTH FC06 and FC16 and enforces a permission model:

Exception code table (SRNE V1.7): 1 illegal function, 2 illegal data address, 3 illegal data value, 4 operation failed, 5 password error, 7 read only, 8 cannot change while running, 9 password protection, 10 length error, 11 permission denied.

Control command registers (DANGEROUS on a live system, documented only):

How to write:

# mbpoll FC06 (write single): value as the last argument
mbpoll -m rtu -b 9600 -P none -s 1 -t 4 -0 -r <dec_addr> -a 1 <port> <value>

# pymodbus
client.write_register(address=REG, value=V, device_id=1)     # FC06
client.write_registers(address=REG, values=[V], device_id=1) # FC16

6. Tested limits summary

7. Preparing for OpenEMS integration

The validated telemetry map is a declarative table in src/inverter/registers.py (nfe-modbus-energy-logger), grouped by OpenEMS nature (ElectricityMeter grid/backup, SymmetricEss battery, OffGridBatteryInverter state). It maps 1:1 to a GoodWe-style defineModbusProtocol (FC3ReadRegistersTask + word elements + SCALE_FACTOR). Control writes map to FC16WriteRegistersTask on the 0xDF00 area and 0xE0xx settings.

OpenEMS

SRNE ASP48120SH3 Modbus Register Map (validated)

Validated Modbus register map for the SRNE ASP48120SH3 three-phase hybrid inverter, verified register-by-register against the live Nansana unit, including a grid-off / grid-on transition test on 2026-07-27 that resolved the previously-unknown registers and corrected the battery-current sign.

Bus: RS485, 9600 8N1, function code 03 (read holding registers), slave address 1. Source of truth (code): src/inverter/registers.py in nfe-modbus-energy-logger.

Valid register ranges (probed live)

Live telemetry, full per-phase - VERIFIED

quantity phase A phase B phase C notes
grid voltage 0x0213 0x022A 0x022B x0.1 V (all go to 0 when grid is off)
grid current 0x0214 0x0238 0x0239 x0.1 A. B/C live in the extended block, CONFIRMED grid-side by the transition test
grid frequency 0x0215 - - x0.01 Hz
grid active power 0x023A 0x023B 0x023C W (extended block, grid-side)
inverter voltage 0x0216 0x022C 0x022D x0.1 V
inverter current 0x0217 0x022E 0x022F x0.1 A (rises when off-grid, inverter sources the load)
inverter frequency 0x0218 - - x0.01 Hz
load current 0x0219 0x0230 0x0231 x0.1 A (load-side, holds through the transition)
load active power 0x021B 0x0232 0x0233 W. No total register: sum the three phases
load reactive power (derive) 0x0234 0x0235 var. Phase A: S=sqrt(P^2+Q^2) not given, derive
load apparent power 0x021C (derive) (derive) VA. B/C: derive S = sqrt(P^2 + Q^2)
load ratio 0x021F 0x0236 0x0237 %

Other P02: state 0x0210, password status 0x0211, bus V 0x0212 (x0.1) = PBus 0x0228 + NBus 0x0229, inverter DC component 0x021D (mV), mains charge current 0x021E (x0.1 A), heat-sink temps 0x0220/0x0221/0x0222 (x0.1 C, 0x0223 bogus), PV charge current 0x0224 (0, no PV), inverter fault 0x0226, charge status 0x0227. Extended grid block tail 0x023D/0x023E/0x023F (0/221/245/309 on grid) is grid-side reactive/apparent, exact split still to confirm.

Battery / DC (P01) - VERIFIED

SOC 0x0100 (%), battery V 0x0101 (x0.1 V), battery current 0x0102 (x0.1 A, signed), device temp 0x0103 (reads 0, dead), DC load 0x0104-0x0106 (0), PV1 0x0107-0x0109 (0, no PV), charge state 0x010B, charge power 0x010E, PV2 0x010F-0x0111 (0).

IMPORTANT - battery current sign is POSITIVE = DISCHARGE on this unit (the OPPOSITE of the generic SRNE V1.7 doc). Proven by the 2026-07-27 off-grid test: with grid and PV both at 0, the battery is the only source, and while it was unambiguously discharging ~750 W to the loads it read +14.2 A; when the grid returned, discharge collapsed to +0.4 A (idle). So positive current = discharge, negative = charge.

Grid-off / grid-on transition test (2026-07-27) - what died vs held

Corrections vs the generic SRNE V1.7 doc (do NOT trust the generic enums/signs)

For the OpenEMS driver (important)

Writes

Both FC06 and FC16 supported. Read-only registers reject with exception code 7. Settings 0xE0xx writable. Control 0xDF00 area (power/reset/restore) is dangerous on the live unit: documented, not fired.

OpenEMS

SRNE ASP48120SH3 Safe Settings Write: design, registers, and commissioning (#53)

Purpose and scope

This page documents the SRNE ASP48120SH3 safe settings write feature (story #53): the ability to remotely change a bounded set of inverter parameters over Modbus, with every write guarded, verified by read back, and never retried. It records the design, the exact registers, the commissioning procedure, and, importantly, the current verification status so the work stays traceable and defendable.

Read this alongside the validated register map (page 126) and the mbpoll command reference (page 125).

What can and cannot be written

The feature can change eight settings only. Each is disabled by default (sentinel -1), bounded, applied only when the configured target differs from the live reading, and verified by a fresh read back.

# Setting Register (FC16) Bounds Units / raw multiplier
0 Discharge cutoff SoC 0xE00F 0 to 100 percent, x1
1 Stop charge current 0xE01C 0 to 100 A amps, x10 (deci-amp raw)
2 Stop charge SoC 0xE01D 0 to 100 percent, x1
3 Low SoC alarm 0xE01E 0 to 100 percent, x1
4 Switch to line (grid) SoC 0xE01F 0 to 100 percent, x1
5 Switch to battery SoC 0xE020 0 to 100 percent, x1
6 AC charge current limit 0xE205 0 to 100 A amps, x10
7 Max total charge current limit 0xE20A 0 to 100 A amps, x10

The current ceiling is MAX_BATTERY_CURRENT_A = 100 A, the continuous rating. The datasheet peak is 120 A for 3 seconds, so the continuous value is the correct, conservative cap.

It explicitly cannot: change charge or discharge time windows, command a specific charge or discharge power, change operating or source priority modes, start or stop the inverter, or reset or clear data.

Safety design

Every write passes through the same defended path (component SrneBatteryInverterImpl, helper SafeWriteHandler in the io.openems.edge.ess.srne bundle):

  1. Default off. Nothing writes unless the operator sets controlEnabled true in the gateway config. Default is false.
  2. Machine state gate. A write is only queued when the inverter reports a verified stable state. Register 0x0210 value 2 (on-grid, mains bypass) is the only verified state; every other state, including off-grid (3), transitioning, fault, and undefined, blocks all writes.
  3. Bounds. Each setting is range checked against the table above. An out of range target is rejected before any Modbus write and marked failed (terminal).
  4. One shot per activation. The write state machine is IDLE, then QUEUED, then AWAITING_READBACK, then VERIFIED or FAILED. A setting is queued at most once per component activation; VERIFIED and FAILED are terminal, so there is no re-write and no storm even though reconciliation now runs every cycle.
  5. Read back verification. After the FC16 write executes, a fresh read of the same register must equal the target to reach VERIFIED. A mismatch goes to FAILED.
  6. Bounded wait, no retry. The read back is allowed up to 30 Edge cycles; on timeout the state is FAILED. A failed or mismatched write is never retried automatically.
  7. Thread safe. The handler methods are synchronized so the cycle thread (reconcile) and the Modbus worker thread (execute and read back) transition state atomically.

The aggregate SAFE_WRITE_STATE channel surfaces the highest severity handler state so an operator can watch commissioning progress.

The standalone topology fix (openems PR #23)

During #53 commissioning, gateway config v18 enabled control and targeted Low SoC alarm 15 to 16, but no FC16 write occurred and the read back stayed at 15. Root cause: gw-aaron runs a standalone Srne.Ess topology, so the generic ManagedSymmetricBatteryInverter run() path was never invoked, and reconciliation was hung off run(). The gateway was restored to the healthy v17 read only profile; the inverter setting did not change.

The fix moves the reconcile trigger to the Edge TOPIC_CYCLE_AFTER_PROCESS_IMAGE event, which fires every cycle in all topologies. It drives both the read back timeout advance and the queue, so the failure path works too. All guards above are unchanged; only the trigger moved.

Commissioning procedure (staged)

The commissioning is deliberately low risk and staged, with a pre staged rollback:

  1. v17: read only baseline, control disabled.
  2. v18: enable control, target exactly one setting (Low SoC alarm 15 to 16), leave the other seven at -1 (disabled). Verify a fresh read back of 16 and SAFE_WRITE_STATE VERIFIED, with stable telemetry and no other writes.
  3. v19: restore Low SoC alarm 16 to 15, keep control enabled, all other targets at -1.
  4. Rollback profile (microgrid PR #33): a break glass config that targets only Low SoC alarm 15, used if v18 changes the inverter but verification fails.

Gate: the v19 enable step (microgrid PR #34) must not be deployed until v18 has been deployed and verified with SAFE_WRITE_STATE VERIFIED on the real inverter.

Verification status (as of 2026-08-08)

Be precise here, because the live unit has not yet confirmed a write.

Traceability

Live read test results (2026-08-08)

First live read of the eight settings on the pilot inverter (gw-aaron), via direct Modbus (mbpoll, FC03) with the OpenEMS edge and the nfe-monitor process stopped to free the RS485 bus. Read only, no writes. Accessed over Raspberry Pi Connect plus ZeroTier (nfetestpiaaron, 10.135.127.37).

Setting Register Raw Decoded
Discharge cutoff SoC 0xE00F 5 5 percent
Stop charge current 0xE01C 30 3.0 A
Stop charge SoC 0xE01D 100 100 percent
Low SoC alarm 0xE01E 15 15 percent
Switch to line (grid) SoC 0xE01F 10 10 percent
Switch to battery SoC 0xE020 90 90 percent
AC charge current limit 0xE205 1200 120.0 A
Max total charge current limit 0xE20A 1000 100.0 A

Context registers: machine state 0x0210 = 3 (off-grid, inverter-powered), SoC 0x0100 = 92 percent.

Findings:

  1. Low SoC alarm reads 15, matching the gateway config. This confirms the v18 15 to 16 commissioning write did not change the inverter (the standalone topology bug fixed in openems #23); the live value is still 15. This is the live evidence behind that finding.
  2. Machine state is 3 (off-grid). The write feature only permits writes in the verified state (2, on-grid mains bypass), so a write attempted right now would be correctly blocked by the machine-state gate. A live write test must wait for the inverter to be on-grid.
  3. Current scaling is x0.1 (deci-amp): AC charge limit 120.0 A, max charge 100.0 A, stop-charge current 3.0 A. SoC and percent settings are x1.
  4. Bus collision confirmed live: both the OpenEMS edge and the nfe-monitor (F3) process were found mastering /dev/ttyUSB0 at the same time. The bus only freed after stopping both. F3 must not run a second Modbus master on this Pi.
  5. The block read of 0xE001 to 0xE02D (count 45) returns Modbus exception 0x0A (gateway path unavailable) on this unit even with the bus free; read the settings individually or in small blocks.

Raw mbpoll output:

[57359]  5      (0xE00F discharge cutoff SoC)
[57372]  30     (0xE01C stop charge current)
[57373]  100    (0xE01D stop charge SoC)
[57374]  15     (0xE01E low SoC alarm)
[57375]  10     (0xE01F switch to line SoC)
[57376]  90     (0xE020 switch to battery SoC)
[57861]  1200   (0xE205 AC charge current limit)
[57866]  1000   (0xE20A max charge current limit)
[528]    3      (0x0210 machine state)
[256]    92     (0x0100 SoC)

Status: reads are now live-verified as above. The live WRITE test (Low SoC alarm 15 to 16, verify by fresh readback, restore to 15) is still pending, and requires both openems #23 deployed and the inverter in the verified on-grid state (it was off-grid at read time).

Commissioning results — live on gw-aaron (2026-08-10)

The guarded settings-write path was commissioned end to end on the live Aaron pilot inverter (SRNE ASP48120SH3), using the low-risk representative setting LowSocAlarm 15 -> 16 -> 15.

Sequence:

Evidence (edge logs):

Queued one-shot settings write [LOW_SOC_ALARM] from [15] to [16]
Settings write [LOW_SOC_ALARM] state [VERIFIED] after readback [16]

Two operational lessons banked:

Process note: settings changes must go through git -> deploy-gateway.sh, never hand-edited on the box. A read-only resting config (v21) is the safe default between commissioning windows.

OpenEMS

SRNE charge/discharge scheduling registers (self-decoded, #67)

Summary

We self-decoded the SRNE ASP48120SH3 settings registers (V1.7 protocol PDF + a live read-scan of the pilot inverter, firmware v925, 2026-08-09). The key result: time-of-use charge/discharge scheduling is implemented and writable, even though real-time active-power dispatch is not. This is the arbitrage lever, and it is not firmware-blocked.

Aaron's SRNE email (2026-08-03) reported that 0xE047-0xE04D (timed charge/discharge MAX POWER) and 0xE400/E401/E402 (grid active/PF/reactive power) return Modbus "Illegal data address" on our firmware. That is confirmed. But those are a different feature (instantaneous power dispatch). The actual time-window schedule registers 0xE026-0xE032 are RW and implemented.

Charge / discharge schedule registers (RW, hour*256 + minute)

Register Function Live value Decoded
0xE026 1-section charge start 0 00:00
0xE027 1-section charge stop 1536 06:00
0xE028 / 0xE029 2-section charge start / stop 0 / 0 unused
0xE02A / 0xE02B 3-section charge start / stop 0 / 0 unused
0xE02D / 0xE02E 1-section discharge start / stop 0 / 0 unused
0xE02F / 0xE030 2-section discharge start / stop 0 / 0 unused
0xE031 / 0xE032 3-section discharge start / stop 0 / 0 unused

Encoding: value = hour * 256 + minute. Max 5947 (23*256 + 59 = 23:59). So 1536 = 6*256 + 0 = 06:00.

Current live config: charge window 1 = 00:00 to 06:00 (off-peak), no scheduled discharge. To do TOU arbitrage, set a discharge window over the peak (18:00 to 24:00 = start 4608, stop 6144-ish, i.e. 24:00 as 23:59 = 6143 or 0).

RTC / current time: 0xE034 (year+month) 0xE035 (day+hour) 0xE036 (minute+second) RW; read via 0x020C/020D. The inverter's clock must be correct for the schedule to fire at the right wall-clock time - verify it.

Mode / priority registers (RW)

Register Function Live Notes
0xE204 Output priority 3 0/1/2 documented (2 = hybrid, mains+PV, PV preferred); reads 3 on this unit
0xE20F Charge priority (def 2) 0-3
0xE216 Start charge time (hour) 1 01:00, "valid for some custom model"
0xE217 Start discharge time (hour) 12 12:00, "valid for some custom model"
0xE205 Mains charge current limit 80 x0.1 A? doc says A; range 0-100
0xE20A Maximum charge current 80 0-150

Full settings decode (0xE001-0xE039, from V1.7 + live)

Voltage/battery: E002 nominal capacity, E003 system voltage (48), E004 battery type, E005 over-voltage (15.0V), E006 limited-charge (14.4V), E007 equalize, E008 boost/overcharge, E00A boost-return (13.2V-ish), E00B over-discharge-return, E00C under-voltage warn, E00D over-discharge (load cut), E00E limited-discharge, E00F discharge-cutoff SoC (5%), E01B mains-switching voltage, E022 inverter-switching voltage. Times: E010 over-discharge delay (s), E011 equalize time, E012 boost time (min), E023 equalize timeout. The 8 settings the OpenEMS write feature (#53) uses are a subset: E00F, E01C, E01D, E01E, E01F, E020, E205, E20A.

NOT implemented on this firmware (Illegal data address, confirmed live)

0xE047-0xE049 timed discharge max power, 0xE04A-0xE04C timed charge max power, 0xE04D timed charge source, 0xE400 grid active-power set, 0xE401 PF, 0xE402 reactive, 0xE42A battery grid participation, 0xE42C zero-export. So OpenEMS-style instantaneous power dispatch is not available; TOU scheduling is the achievable control.

What this unlocks for NFE

TOU arbitrage via scheduling: set the charge window to off-peak (already 00:00-06:00) and add a discharge window over the peak tariff, using 0xE026-0xE032. All RW, all validated readable live. Next: a careful readback-verified live write test of one discharge window (write, verify, restore), then integrate scheduled writes (guarded, like #53) so NFE can shift the battery by tariff without a site visit.

Method / traceability

Live read-scan via mbpoll (edge + nfe-monitor stopped to free the RS485 bus), firmware v925, 2026-08-09. Decoded against SRNE_Hybrid_Inverter_MODBUS_protocol_V1.7.pdf (repo: NFE/CUSTOM_CODE/srne-products). Related: register map (page 126), mbpoll reference (page 125), safe settings write (page 128, #53). Issue logger #67.

OpenEMS

SRNE phase balancing: big consumers on one phase trip the inverter on battery

Problem

When the site runs on battery (grid outage, typically evening or night), switching on a large single-phase load such as a heater or fan trips the inverter off until the load is removed. This causes an outage for the whole site.

Evidence (2026-08-11)

Per-phase active power read directly off the SRNE ASP48120SH3 (bus-quiet mbpoll on gw-aaron):

Phase On mains (state 2) On battery (state 3)
L1 102 W 145 W
L2 230 W 327 W
L3 212 W 291 W
Total 544 W 763 W

L1 consistently carries about half of L2 and L3. Total load is small (under 1 kW against the inverter rating of 12 kW / 24 kVA, roughly 4 kW / 8 kVA per phase), so the trip is not a total-capacity overload. It points to the big consumers being concentrated on one phase: a large load landing on an already heavier phase, plus its switch-on inrush, can overload that single phase or trip protection while the other phases sit nearly idle.

Action

  1. Rebalance customer phase assignments toward an even split. Prefer balancing by measured load rather than by simple 4-3-3 count.
  2. Identify the big consumers and move them off the loaded phases (L2 and L3) onto the lighter phase (L1).
  3. Re-measure per-phase load after rebalancing to confirm the spread has narrowed.

Use the backup-phase-dashboard phase-balance analysis (reads the customer meter CSVs) to plan the reassignment.

Also check (a separate, compounding cause)

Protection and power-save settings may make the trip worse on battery. Read (read-only) the power-save level E207, eco mode E20C, overload auto-restart E20D, and overload bypass E212. Off-grid there is no mains to bypass to, so an overload just shuts the inverter down.

Tracking

GitHub issue: Nearly-Free-Energy/nfe-modbus-energy-logger #70

OpenEMS

OpenEMS Backend InfluxDB Data Model and Edge-ID Collision

[!warning] Verification status
The storage-key collision vulnerability is confirmed in source code, and the repository contains a real configured collision. However, the vulnerability alone does not prove that Hillary data contaminated the current Sezibwa Pi2 history. Historical causation must be established from production InfluxDB data, connection periods, and gateway logs before any records are rewritten or deleted.

Executive conclusion

Confirmed backend data model

The relevant implementation is:

io.openems.backend.timedata.influx/src/io/openems/backend/timedata/influx/TimedataInfluxDb.java

For every accepted data timestamp, the backend constructs an InfluxDB point using:

Point.measurement(this.config.measurement())
    .addTag(this.oem.getInfluxdbTag(), String.valueOf(influxEdgeId))
    .time(timestamp, WritePrecision.MS);

The deployment configuration sets measurement="data". “Measurement” is the correct InfluxDB term; it is analogous to, but not identical with, a relational database table. All edges handled by this configured timedata provider share that measurement unless another Timedata.InfluxDB instance or measurement is configured.

Channel addresses such as meter0/ActivePower and _sum/EssSoc are written as fields. History queries parse the requested edge ID through the same numeric function and filter using the resulting numeric tag.

Confirmed edge-ID parser behavior

InfluxConnector.parseNumberFromName(edgeId) uses:

\D++(\d++)$

This extracts the trailing numeric run rather than preserving the full edge ID:

Configured valueRole in this repositoryInflux tag valueFinding
hillary-test-pi-1Hillary test edge ID1Collides with aaron-pi-1
aaron-pi-1Aaron edge ID1Collides with hillary-test-pi-1
sezibwa-rentals-gw-pi2Current Sezibwa Pi2 edge definition2No suffix collision with Hillary
nfetestpi1Hostname/deployment userNot applicable as currently configuredNot the backend edge ID

If an edge ID contains no parseable trailing number, the timedata write is not stored. This is not completely silent: TimedataInfluxDb.writeData() logs a warning stating that it could not parse the numeric Influx Edge-ID, then returns without writing the notification.

What a collision does

InfluxDB identifies a point by measurement, tag set, and timestamp. Once two gateways share the same numeric edge tag:

The resulting history may therefore be mixed, overwritten, or both; “merge” should not be interpreted as guaranteed preservation of every value from both sources.

What is and is not proven about the incident

Proven: the implementation is collision-prone, and two repository edge configurations currently resolve to edge=1.

Not yet proven: that this caused the reported Hillary-to-Sezibwa contamination. If the affected Sezibwa history was requested under aaron-pi-1, the collision is a strong causal candidate. If it was requested under sezibwa-rentals-gw-pi2, the 1-versus-2 mapping means this specific mechanism does not explain it.

Confirm the affected edge ID and examine production edge=1 data before finalizing the root-cause statement.

Immediate containment

  1. Inventory every edge registered with or connecting to the production backend.
  2. Compute the parsed numeric ID for each and identify duplicates before making changes.
  3. Disconnect colliding test rigs from production or assign a globally unique temporary numeric suffix.
  4. Back up InfluxDB and the backend/metadata configuration before renaming an edge.
  5. Update all coupled references together: metadata, API keys, gateway configuration, monitoring, dashboards, automation, and operational documentation.
  6. After each change, verify websocket connectivity, live channels, new timedata writes, history queries, and monitoring alerts.

[!note] Unique numeric suffixes are containment, not the permanent design
A naming convention reduces immediate risk but remains brittle and easy to violate as the fleet grows.

Permanent backend correction

  1. Use the complete immutable edge ID as the InfluxDB discriminator, or resolve the edge to another stable, globally unique identifier maintained by backend metadata.
  2. Validate uniqueness at edge registration and backend startup. Reject duplicate storage identifiers instead of accepting ambiguous writes.
  3. Fail visibly for invalid identifiers, with actionable logs and operational alerts.
  4. Add automated tests covering identical suffixes, multi-digit suffixes, IDs without numbers, reconnects, resends, and history-query isolation.
  5. Review other structures keyed by the parsed integer, including timestamped-channel tracking and aggregated timedata, so the fix covers more than the point tag.

Migration requirements

Changing the tag key or value can make existing history unreachable to current queries. The implementation therefore needs an explicit migration plan, such as:

Historical-data audit before cleanup

  1. Identify exactly which logical Sezibwa edge displayed Hillary channels.
  2. Determine when hillary-test-pi-1 and aaron-pi-1 were simultaneously connected to the same production backend and bucket.
  3. Inspect edge=1 by time range, unique channel inventory, device serial numbers, meter topology, and gateway connection logs.
  4. Classify records as confidently Hillary, confidently Aaron/Sezibwa, or ambiguous.
  5. Quarantine ambiguous records. Do not delete or rewrite them merely from channel-name assumptions.
  6. Document any irrecoverable overlap where the same field and timestamp may have been overwritten.

Approval boundary

Approved direction: immediate containment, a reviewable backend fix, collision tests, and a documented migration design.

Requires separate approval: irreversible deletion, reassignment, or rewriting of production historical data. That work must follow the backup and attribution audit above.

Pre-Commissioning Process for CHINT Meters

Document Information

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:

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:

Tools Used:

Field Operations Team

Responsibilities:

Tools Used:

Training Required:

Field Installation Team

Responsibilities:

Tools Used:

Training Required:

Remote Commissioning Team

Responsibilities:

Tools Used:

Training Required:

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:

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:

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:

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:

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:

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:

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:

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:

Escalation Information to Provide:

Safety and Best Practices

General Safety

⚠️ Electrical Safety:

⚠️ RS485 Bus Safety:

Conversion Best Practices

✅ One Meter at a Time:

✅ Document Before Converting:

✅ Test Before Shipping:

✅ Never Reuse Addresses on Same Site:

✅ Physical Labeling is Mandatory:

✅ Keep Conversion Logs:

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:

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:

Retention:

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:

Appendix

Glossary

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:

Document Version History:

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 is worth a thousand words 

Microgrid Capability Framework.png

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:

Each capability may operate at a different level of autonomy.

A microgrid could therefore simultaneously contain:

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:

2. Digital Assets

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

Examples include:

3. Economic and Contractual Assets

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

Examples include:

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:

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:

3. Intelligence

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

Intelligence forms the reasoning layer of the microgrid.

Examples:

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:

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:

Examples:

Optimization

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

Optimization typically combines:

Examples:

Commercial Operations

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

Commercial operations typically combine:

Examples:

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:

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:

An autonomous system manages outcomes.

Levels of Operational Autonomy

This framework distinguishes between:

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:

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

Relevant Standards

Relevant standards may include:

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:

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

Relevant Standards

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

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:

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

Key Requirements

Level 3 systems should include:

Relevant Standards

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

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:

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:

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:

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:

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:

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:

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

Metering protocols: DLMS/COSEM, OBIS, Modbus, MQTT (and NFE CHINT register map)

Traceable explainer: how metering data actually moves, where DLMS/COSEM, OBIS, Modbus, MQTT and HTTP each sit, and how NFE's live CHINT registers map to the OBIS standard vocabulary. Compiled 2026-08-10. Companion to "NFE metering strategy + Glen Street-EMS".

The layer cake (mental model)

Networking is layers. Each solves one problem and talks only to the layer above and below.

Layer Job Examples
Link move bits over one physical medium RS485, Ethernet, WiFi
Network (IP) address and route between any machines IP
Transport (TCP) reliable, ordered byte-stream between two programs TCP, UDP
Application what the two programs actually say HTTP, MQTT, Modbus, DLMS

Key point: MQTT, HTTPS and DLMS/COSEM are all application-layer. MQTT and HTTPS run on top of TCP (transport) on top of IP (network). MQTT is NOT a transport or network protocol.

One clean way to hold it all: IP gets you to the right building. TCP is registered mail that guarantees the whole message. Modbus/DLMS is the local interview with one meter (DLMS adds a shared vocabulary and an ID badge). OBIS/COSEM/SunSpec is that shared vocabulary. MQTT is the courier network carrying notes across the village and orders back. HTTP is a different courier that only does "go fetch one thing and return".

Three separate jobs, often confused

You put COSEM-modelled data inside an MQTT message. They are not competitors: MQTT is the envelope, COSEM is the language on the page.

MQTT vs HTTPS

MQTT over the internet? Yes, it is just TCP. Devices make an outbound connection to a broker, so no inbound port-forwarding through the site modem, ideal for field gear on cellular.

Why not DLMS/COSEM over HTTPS? It buys nothing: DLMS already has its own TCP transport and its own message-level crypto (AES-128-GCM). And DLMS is a point-to-point session with one meter, not a fan-in/out telemetry bus. So the natural split is DLMS or Modbus to talk to the meter locally, MQTT to move the results around.

DLMS/COSEM, unpacked

The distinction: Modbus register vs COSEM "register"

A meter does NOT contain Modbus registers and COSEM registers side by side. They are two alternative languages for the same physical measurements. A given meter speaks one (or, on high-end dual-interface meters, both via separate ports).

NFE's CHINT DDSU666 / DTSU666 are Modbus-only meters: inside them there are only Modbus registers, no COSEM, no OBIS. The OBIS column below is a translation NFE applies in software (in the logger / EMS / OpenAMI layer); the meter itself never knows about OBIS. The value of doing it: the meaning stops living in the CHINT manual and becomes the industry-standard, self-describing vocabulary.

NFE CHINT register to OBIS map

Single-phase DDSU666 (tenant meters, one phase). Source: nfe-modbus-energy-logger/src/meter_reader.py and the OpenEMS Meter.Chint.DDSU666 driver.

Quantity Modbus register (float) OBIS code Meaning
Voltage 0x2000 1-0:32.7.0 Instantaneous voltage L1
Current 0x2002 1-0:31.7.0 Instantaneous current L1
Active power 0x2004 1-0:1.7.0 Instantaneous active power (import +)
Power factor 0x200A 1-0:13.7.0 Power factor
Frequency 0x200E 1-0:14.7.0 Frequency
Import energy 0x4000 1-0:1.8.0 Total active energy imported (billing)
Export energy (invert cfg) 0x4000 1-0:2.8.0 Total active energy exported

Three-phase DTSU666 (aggregate meter_100):

Quantity Modbus register(s) (float) OBIS code(s) Meaning
Voltage L1/L2/L3 0x2006 (x3) 32.7.0 / 52.7.0 / 72.7.0 Instantaneous phase voltages
Current L1/L2/L3 0x200C (x3) 31.7.0 / 51.7.0 / 71.7.0 Instantaneous phase currents
Active power total + L1/L2/L3 0x2012 (x4) 1.7.0 / 21.7.0 / 41.7.0 / 61.7.0 Instantaneous active power
Power factor 0x202A 13.7.0 Power factor total
Frequency 0x2044 14.7.0 Frequency
Import energy 0x4000 1-0:1.8.0 Total active energy imported

Note: the DDSU666 driver reads active power as already scaled kW; the DTSU666 needs per-manual scaling (Table 11: V/10, I x0.001, P x0.0001, PF x0.001, F x0.01). Minor code note: the logger's DTSU REGISTERS dict lists PF at 0x2020 but read() polls 0x202A; 0x202A is the one in use.

Why two OpenEMS drivers (meter and inverter)

Two physical devices with different proprietary Modbus maps means two drivers:

OpenEMS "Natures" (ElectricityMeter, SymmetricEss) are abstract interfaces both drivers map into, so the rest of OpenEMS sees a uniform API regardless of vendor. That is the local equivalent of what OBIS/COSEM and SunSpec do industry-wide.

The real prize of the standards is not one driver for meter plus inverter. It is one driver per device TYPE that works across every compliant vendor: any DLMS meter uses the same meter driver, any SunSpec inverter the same inverter driver. That removes the per-vendor Modbus-map work NFE did for both the CHINT and the SRNE. OpenEMS Natures give that uniformity on the edge (after the driver); DLMS and SunSpec give it at the wire (removing the driver work).

OBIS vs profiles (IDIS / OpenAMI): naming is not interoperability

OBIS names things, it does not force a meter to implement or behave the same way. DLMS/COSEM is a large, flexible toolkit and leaves most choices to the manufacturer: which OBIS objects are actually present, which data types and scalers, which security suite, which communication profile, which optional events. So two meters can both be DLMS/COSEM compliant and both use OBIS and still not interoperate out of the box. Compliant is not the same as interoperable.

IDIS (Interoperable Device Interface Specifications) is an industry association profile that sits on top of DLMS/COSEM/OBIS and removes the optionality: it mandates exactly which OBIS objects must be present and how they behave, the data types, security and events, a fixed communication profile, and an interoperability certification (conformance plus multi-vendor testing). Packages by transport: Package 1 (basic, local/optical + core residential objects), Package 2 (power-line comms PRIME/G3 + data concentrators), Package 3 (cellular/IP). Any two IDIS-certified devices genuinely interchange.

Mental model: DLMS/COSEM is the grammar and a giant dictionary with optional dialects; OBIS gives every word one fixed meaning; IDIS is a mandated phrasebook plus accent everyone certifies to, so a whole conversation is portable, not just the words.

Why it matters here: even if two meters both spoke OBIS, if they exposed different object sets over different links you would still write per-vendor glue (the same thing that produced two OpenEMS drivers). A profile is what makes "buy any certified meter, one driver, plug and play" real. IDIS is the heavyweight, utility-grade version of exactly what OpenAMI aims to be for off-grid villages: a mandated, open, lightweight village-metering profile on top of the vocabulary. NFE does not need full IDIS, but it does need a profile, and that is OpenAMI's whole purpose.

How OpenAMI sits on top

OpenAMI (IEEE Smart Village) is the actionable, utility-facing telemetry layer above a village feeder. It does not reinvent meter semantics: it composes OBIS/DLMS/COSEM (meters), SunSpec (inverters/DER), MQTT (transport), IEEE 2030.5 and 1547 (DER control). Its value-add is two-way, village-edge, policy-driven control and a billing cache, run cloudlessly and cheaply.

Sources

Element room "Smart Village Energy Interest Group"; isv.wiki; nfe-modbus-energy-logger/src/meter_reader.py; OpenEMS drivers io.openems.edge.meter.chint.ddsu666 and io.openems.edge.ess.srne; IEC 62056 (DLMS/COSEM); DLMS User Association Blue Book (OBIS).

Inverter-monitor notifications: hardening + tuning (ADR-012)

How the NFE inverter-monitor decides what to alert on, and the 2026-08-10 hardening pass that killed the nightly "Battery low" noise and closed several alert-integrity gaps. Source of truth is the code + ADR-012 in nfe-modbus-energy-logger; this is the team-facing summary.

What triggered it

A "[NFE Nansana] Battery low - below 80 percent" email fired at 79% while the battery was doing normal peak-window arbitrage. 79% is not low; 80% was simply in the alert threshold set, which a normally-cycling battery crosses every evening. An end-to-end review found that plus several real gaps.

What changed (all live on the VM)

The alert ladder (unchanged rungs)

Deploy + rollback

Built from merged main and deployed to the NFE OpenEMS VM as nfe-monitor:local + nfe-notifier:local (local build; the GHCR pipeline path unlocks once the nfe-monitor package is public). Previous images tagged :prev for rollback (docker tag nfe-monitor:prev nfe-monitor:local && docker compose up -d). Verified live: both containers stable (0 restarts), notifier listening + auth enforced (bad token -> 401), monitor heart-beating.

Traceable in repo

ADR-012-notification-hardening, docs/inverter-monitor.dsl (C4 model), docs/notification-severity-standard.md, PR #69. 255 tests, 99% coverage.

SRNE TOU arbitrage: plan (#67)

The plan to turn on time-of-use battery arbitrage on the Sezibwa/Nansana SRNE inverter (logger issue #67): charge the battery from the grid off-peak, discharge it to the load at peak, using the SRNE charge/discharge SCHEDULE registers written through the guarded write path we proved with #53. Compiled 2026-08-11.

The gap (why we are leaving money on the table)

The inverter already CHARGES off-peak (charge window is set to 00:00-06:00) but it does NOT discharge at peak - the discharge time-windows are all 0 (off). Live-confirmed 2026-08-10: at peak the battery sat idle on grid at ~79% while ~1.3 kW of load was served straight from the grid. So we pay the peak grid rate for load we could have covered with cheap off-peak energy already sitting in the battery. Turning on the discharge window closes that.

The economics (Code 10.2, what NFE pays the utility)

Period Window Rate (UGX/kWh)
Off-peak 00:00-06:00 343.20
Shoulder 06:00-18:00 577.11
Peak 18:00-24:00 666.50 (Q3 2026)

Arbitrage = buy at 343 off-peak, avoid ~666 at peak = ~320 UGX/kWh gross, minus battery wear. Usable battery ~10.49 kWh; discharging ~5-7 kWh at peak while holding a reserve gives a gross saving in the low thousands of UGX per day. The daily energy/cash summary (#26, already live) already computes charged kWh + buy cost, discharged kWh + value, wear, and net margin - so once this is on we MEASURE the real number, not guess.

The levers (SRNE registers, decoded firmware v925, RW)

Written through the same guarded path as #53 (SafeWriteHandler: default-off, verified-machine-state gate, one-shot FC16, readback-verified). Time encoding = hour*256 + minute (e.g. 18:00 = 4608, 06:00 = 1536).

Function Register(s) Live (2026-08-09) Target
Charge window 1 0xE026 / 0xE027 00:00-06:00 keep (off-peak)
Charge windows 2/3 0xE028/E029, 0xE02A/E02B unset optional
Discharge windows 1/2/3 0xE02D-0xE032 ALL 0 (off) window 1 = 18:00-24:00 (peak)
Output priority 0xE204 3 confirm = battery-first in-window
Charge priority 0xE20F tbd grid, off-peak
Switch-to-line SoC (reserve floor) 0xE01F 10 raise to protect reserve
Switch-to-battery SoC 0xE020 90 tune
Discharge cutoff SoC 0xE00F 5 hard floor
Inverter RTC set 0xE034-0xE036 / read 0x020C-0x020E must be correct verify, set if drifted

NOT available on this firmware (confirmed Illegal-data-address): real-time active-power dispatch (0xE047-0xE04D, 0xE400-0xE402). We do NOT need it - scheduling covers TOU arbitrage.

Safety framing: reserve vs savings (the core tension)

The site's PRIMARY mission is backup during grid outages. Discharging at peak spends reserve exactly in the evening window when outages are most likely. So arbitrage must never drain below a backup reserve. Policy: hold >= 50% reserve until 30 days of outage data are collected (per CUSTOM_CODE/CLAUDE.md), then revisit. The discharge must STOP at the reserve floor, not run down to the discharge-cutoff. Phase 1 confirms exactly which register enforces that floor on this firmware (the switch-to-line SoC band vs a per-window reserve). RTC accuracy is critical - a wrong clock means the windows fire at the wrong time.

The build (mirrors #53, which is proven)

Phase 1 - Prove the schedule-write path (DAYTIME, no customer disruption):

Phase 2 - Program the arbitrage schedule (DAYTIME, supervised):

Phase 3 - Measure + tune:

Guardrails (all carried from tonight's #53 discipline)

Live-test before commission. Daytime writes only. Guarded write path (default-off, verified-state gate, one-shot, readback-verified). git -> deploy, never hand-edit the box. Bus-quiet reads (stop edge + mbpoll + 5s). Reserve-first: backup mission beats savings.

Open questions Phase 1 must answer

  1. Which register actually enforces the reserve floor on v925 (switch-to-line SoC vs a per-window reserve field)?
  2. Is the inverter RTC accurate right now? (windows fail silently if not)
  3. Output-priority (0xE204=3) semantics on this firmware - does it put battery first inside a discharge window while grid is present?