Open Source GSM prepaid Smart Energy Meter

Hi All

We have received a proposal for another potential Open Source innovation and would like to have feedback from the community : Open Source GSM prepaid smart energy meter with customizable API for easy web integration for online top up.
We want to understand if the proposed innovation is addressing the sector level need . We decide this based on your interest to adopt such solutions in your business operations, should this solution get funded and available as open source.

Share your feedback directly in the forum here for everyone to see and participate.
These are the questions we are trying to answer:

  1. Would the list of deliverables be sufficient for you to adopt this innovation?
  2. How disappointed would you be if we did NOT go ahead in developing and open sourcing this innovation?
    e.g. Very disappointed, Somewhat disappointed, Not disappointed
  3. Can you share potential scenarios when this innovation would NOT work for you?
    Anything else we should know?

Open source Innovation:
Open Source GSM prepaid smart energy meter with customizable API for easy web integration for online top up.

Proposed Deliverables
PCB

  • 2 layer PCB cad design on proteus( off the shelf available)
  • GERBER production file.
  • power board.
  • circuit layout.
  • GSM module connection to PCB.
  • RTC module connection to PCB.
  • (16x2) LCD connection to PCB.

Firmware/software

  • Firmware source code written on arduino uno platform.
  • libraries used in source code.
  • web template including database logging, graph history of energy used, credit topup using paystack, power consumption logging on internet every 12hours.
  • easy editable web source code.

Operational manual

  • specification sheet.
  • Troubleshooting manual.
  • production and specification manual.
  • ordering details with Moser and aliexpress link in tabular format.
1 Like

This sounds like an interesting project! Can you please provide details about the accuracy that can be achieved. I have some doubts as I see that you will “only” provide Arduino code for this.

Also: To what extend is this project based on the already open source project Learn | OpenEnergyMonitor

Dear @Hannes, many thanks for your comments. Our proposed design will be similar to referenced open source project in the following aspects:

  • Ac to Ac step Converter : PCB will contain a step converter with a variable resistor calibration method to set the voltage to desired RMS level, during calibration, the voltage level will be updated on LCD screen, the voltage measurement will be aligned to the true RMS value by taking multiple samples and averaging also proper protection will be incorporated to protect the maximum TTL voltage level of Atmega chip and also to prevent unnecessary spikes which fidget microcontrollers.

  • Current measurement using current sensor : The current sensor to be used will be an hall effect current sensor which is magnetically coupled together but electrically isolated from the circuit. Proper EMI interference protection circuit will be incorporated to enable proper measurement of RMS current, apparent power, real power and power factor, the current sensor will be capable of measuring continuous 200amps current and pulsed 1000amps current for 1sec).

In addition the the points listed above, our proposed project will implement the following innovations/addition:

Hardware

  • Proper power isolation between power switches and microcontroller to avoid spike and inductive kickbacks.
  • Components will be carefully selected to reduce EMI,

*Overload protection will be included to protect the meter from Overload.

  • Visual indication to notify use on low credit status prior to cutting off user when credit is exhausted.

*LCD display to show periodic energy consumption, Credit remaining and tariff.

  • True RMS meter and certified energy meters will be used in the calibration and firmware coding process to ensure industrial standards are met.

  • GSM module will be used to communicate with the internet, the gsm module that will be used is sim800l.

  • AC to DC smps power supply(220 to 12v) alongside other necessary voltage regulators will be used to power the board.

  • electromagnetic Relay will be used as the switching component to turn users on or off.

Software/Firmware

Software will implement the following functions:

*Remote monitoring of energy

  • Viewing historic data of energy.
  • Payment integration and energy meter topup via the web application.
  • Admin will be able to set tariff per kilowatt hour which will be changeable as desired.

The design will be developed on an 8bit Arduino microcontroller in other to foster easy development by other users and easy integration by hobbyist since many hobbyist are quite familiar with Arduino.

Dear @DanielK ,

Thanks a lot for your elaborations! What is the overall metering accuracy that you are (targeting) to achieve?

BR,
Hannes

Dear @Hannes we are targeting meter accuracy of 98% on a minimum, by taking true RMS reading of voltage, current, real power and other necessary measurement.

1 Like

An Open Source Smart Meter would be a really useful for the energy access community. Thanks for the proposal for the development!

As we are currently only dealing with DC (12V to 48V), we would probably not adopt this solution at the moment, but it could be helpful in the future. Thanks also for providing some accuracy figures.

Similar to @Hannes I’m a bit concerned about the Arduino aspect. The AVR 8-bit microcontrollers are damn simple to use, that’s true. But it will probably be impossible to implement features like over-the-air upgrade. So if possible, I’d suggest to choose a more powerful microcontroller like lower-end STM32 (if they ever get back into stock).

I’m not familiar with Proteus, but it seems to be quite expensive and Windows-only. So I’d really prefer a KiCad-based design. Open Source tools for Open Source projects :wink:

Dear @martinj thanks for your comments.
To reply martinj comment,

For the 12v to 48v system, the design will be done to take in input from 220v ac and convert to 12v DC via smps buck/boost converter.

The code written can be implemented on an stm32 based microcontroller easily as the code is written in ansi-c, however the person trying to implement the code on stm32 will have to read the data sheet of the microcontroller and address the right port and tris registers.

Kidcad could be considered if the majority of users request this. Let’s see.

@DanielK thanks for the quick feedback.

ANSI-C instead of Arduino (essentially C++) sounds like a good idea to make the firmware easier to port.

I didn’t completely understand the 12V conversion you mentioned. Will this 12V rail provide significant power so that it could be used for 12V appliances (i.e. existing SHS ecosystem) or is the 12V SMPS used for power supply of the internals of the meter (microcontroller, GSM module, etc.)?

1 Like

@martinj The 12V will be used to power the internal electronics of the meter.

Good morning community,

thank you very much for this proposal. We are looking for an open source prepaid energy meter for some while now and are happy to see this proposal. We are working with different stakeholders in the sector and are happy to share our experiences and requirements. I visualized all points in the graphic below to make it easier to follow:

Software

  • In my opinion, there are already open source software tools which fulfill this need. One open source tool is the Micro power manager from Inensus: https://micropowermanager.com/, which fulfills all the needs described in the proposal. If a company only needs a monitoring solution, I would recommend the open source software https://grafana.com/
  • Due to different requirements in the off-grid sector, I think it needs a focus on the hardware side for such a project (see points below). I like the idea about an easy-to-use API to interact with the smart meters. So I would love to see an energy meter that uses MQTT (since it is the Standard for IoT Messaging) in combination with an API that provides the following endpoints:
    • Get power consumption
    • Get remaining credit / balance
    • Set read interval
    • Reset credit
    • Add credit
    • Update credit
    • Update firmware (see point below)
    • Get system status (working properly / not working properly / system got disconnected / manipulation attempt detected…)
      Do you have something like this in mind for your proposal?

Electronic requirements

  • What we can see is that SIM900 or SIM800C are more commonly used in state of the art smart meters rather than SIM800L. Do you maybe know why they go for the more expensive ones?
  • Electronics should fit into a standard casing with IP65 and stable screw terminals. I think there are many nice looking standard casings out there which should fulfill this requirement. An individual, mechanical design would require own moulds and probably make it too expensive.
  • Communication Options / Interface (see graphic)
    • As proposed, GSM should be one possible communication interface
    • We also see the need for other communication interfaces. This might be out of scope for this project but in my opinion the core electronics must have the possibility to add other communication interfaces like LoRa and RS485, since those are also widely used in the industry, depending on the use case and country. So I would suggest:
      • A UART interface for GSM and RS485 modules
      • An SPI interface for LoRa modules
    • Each communication module might have its own DC/DC converter or can be be powered directly from the core electronics
  • User Interface Options (see graphic)
    • No user interface required if energy meter does have one of the mentioned communication interfaces
    • If someone wants to use the energy meter in an offline environment, it should have a user interface like
      • A keypad matrix to enter the activation code (STS token - see additional requirements below)
      • Or e.g. a NFC reader to read the activation code (STS token - see additional requirements below)
  • Measurement of power consumption via voltage meter and current sensor. It would be good to reach an accuracy of <1%. I am not sure if a hall sensor or shunt resistor does have the best price-/performance ratio. What do you think?
  • Usage of common, highly available components
  • Display: Ability for companies to display logo and other individual information, I would prefer e.g. an 0,96 inch (or larger) OLED Display I2C SSD1306 Chip 128 x 64 Pixel I2C
  • AC/DC converter. I assume you need 12V to power the relay right? Maybe, it might make sense to have 2 versions: 12V relay for high power applications and a 5V relay for lower power application (2kW) to ensure the best price/performance ratio, depending on the use case.
  • Short circuit protection

Additional function / firmware requirements

  • FOTA (Firmware - over - the - Air) - Can be updated via the API
  • Can accept STS tokens (Mandatory in many countries and becomes overall industry standard)
  • Data logger (SD card storage in case there is temporary no internet connection)

Looking forward to your thoughts.

Hi @dan, thanks for your comprehensive comments.

MQTT has some limitation in data transmission and is only used when there is restriction in bandwidth. Therefore we propose to use SOAP protocol.

Sim800c and sim900 were evaluated and preferred over sim800l due to their ease of upgrading the firmware. However, we propose to use sim5320 due to wide compatibility and increased security integration. Finally, sim8## series are based on 2g network which gradually fading off.

It is possible to add other serial communication feature such as lora and rs485, however the ram of arduino is only 2kb, the chip will run out of ram, and to reduce cost and allow easy integration, atmega328p chip was chosen.

The meter will have a 16*2 LCD to enable monitoring of parameters.

There will be no need for sts token as the recharge will be done via the website/app and credited to the meter over the air.

Hall effect sensor have a high accuracy of measurement based on circuit configuration and emi filtering circuit added.

16*2 LCD screen will be used to in other to reduce cost, also in other to preserve the ram of the chip, as using a graphics LCD will take too much from the chips ram.

Two versions can be made to permit developers to use both 5v and 12v relay.

In other to better foster the development, based on comments received by other persons, a 32bit microcontroller can be considered to integrate other communication features like lora and rs485 and also allow support keypad STS authentication.

Hi Daniel
have you looked at the Cicada project? It support 2G, 3G and 4G networks, and a new wifi module will come out later this year. I think using that interface may be helpful to use a tried and tested comms module, allowing to focus on the other parts.

I also think arduino/atmega16 will represent a bottleneck in the future, and found them to be coming at premium price some time ago, while less hobbyist-friendly MCUs cost less and perform better.

ciao
fabio

Hi @fabio The cicada project makes use of different gsm modules to attain 2g, 3g and 4g connectivity, for 2g connectivity it makes use of sim800l, for 3g and 4g connectivity it makes use of sim7600ce, these are modules to choose from amongst the variety of modules available in the market, however cicada modified the modules by adding a bootstrap capacitor to further stabilize the module due to high surging current when connecting to network.

In our design, we propose to use sim5320, however if hobbyist decide to use sim800l or sim800c or sim900, the structure of the board will be designed to take in any of these modules as they work on same AT commands, also the PCB will be designed to handle any form of voltage sagging or inductive kickbacks either from the module itself or from an external source.

Two design will be made,

  1. on arduino for people who prefer arduino.

  2. on a 32bit microcontroprocessor either (stm32 series or esp32) or as suggested by other developers.

First of all thanks for promoting this interesting open source initiative. From the prospective of mini-grid developers in East Africa, the following points are heavily considered when evaluating a smart meter technology:

  1. Regulatory: In order to protect users by fraud, all smart meters deployed have to comply with the standards imposed by the regulator, which usually consists in detailed testing of a randomly selected batch of meters, prior to installation. There are very severe evaluation criteria that must be met, such as max deviation in reading and reliability of the meter. If test is not passed, none of the meters are authorized to be installed and operated. According to our limited experience with open source Arduino-based energy metering, voltage and current can deviate even above 5% of the reading obtained with certified equipment, usually related to difficulty in proper calibration. Higher lever of design of both hardware and software is required to make this innovation compliant.
  2. Cost: the cost of hardware, assembly and development required for a company should be quantified. Our first assessment is that the cost of smart meters already available on the market might still be very competitive, usually offering standards-compliant equipment, good warranty terms, remote monitoring platforms and support in installation and operation. Assessment on production costs and economy of scale would be useful to clarify the final cost for developer.
  3. GSM: Regarding mini-grid projects in remote areas, connectivity issues are very common, making GSM/2G/3G communication challenging. It is common practice to overcome the problem having a meshed communication structure via RF, in which meters can communicate between each other and finally with a base station, which acts as coordinator and sends data to the cloud via 2G/3G. The base station is usually located in a spot on the grid with good signal. RF is generally reliable and, in case of signal strength issues between meters too far from each other, “dummy meters” can be placed in between with the function of receiving and resending the signal.
  4. GSM SIM cards: having one SIM card per meter may not sound a practical solution, as it implicates additional investment and operational costs.
  5. Power consumption: the smart meter energy consumption represents a cost for the energy provider, as it’s not billed to the final customer. When considering 24/7 use and deployment of thousands of meters, this can represent a consistent load for the energy provider to bear technically and economically. In general, the overall power consumption of a smart meter should not exceed 2 or 3 W.
  6. Data protection: customer privacy and energy consumption patterns make the data sensible, requiring a proper protection system.
  7. Meter tampering option: power theft is already a diffuse problem between energy companies. In most of the cases it consists in meter bypassing. Some meters have a useful tamper warning which notifies the grid operator that the meter was subjected to tamper attempt (such as input/output cable removal) and cuts off the output power till the operator removes the tamper alarm on the monitoring platform.
  8. In the case of open source meters, the code is public which makes the meter hacking accessible to everyone with basic understanding of Arduino and coding. Any change in sensor calibration (such as current reading) or sensors manumission could enable energy meter to underestimate the energy consumption, representing a serious risk for operator. On the other way around, the operator is technically able to change the code to overestimate the consumption and increase the revenues, without customers or authorities being able to realize.

Dear @maathe First of all, thank you for your comprehensive comments. you touched on several important point which I believe if properly addressed would increase the chances of developing a successful product. Allow me to respond to each of your points below.

  1. Regulatory:

We shall implement proper regulatory procedure to ensure typical industry standards are met during calibration and commissioning of the design. The accuracy of all reading will be compared to pre-existing meter, also the deviation to true value will be as little as possible because TRUE RMS reading codes will be used in ansi-c coding syntax, voltage and current will be kept as close as possible to pre-existing meter, as the hardware and software configuration will tailored to ensure compliance.

  1. Cost:

Cost is highly considered in the design factor, more reason why an 8bit commonly available microcontroller was selected alongside another easy to use 32bit microcontroller, instruction manual and design/assembly guide will be part of the deliverables, component cost and mouser/aliexpress link will also be included in the deliverables, this will help developers know how much is to be spent per meter, also design cost is highly affected by order quantity, currency, where component is bought from and other things beyond our control. Our target is that the cost of production will be lower than a comparable off the shelf meter.

3.GSM:

Thanks for highlighting the issue on poor network, however this issue has been addressed in previous comments. Due to RAM limitation on the 8bit atmega328p microcontroller, RF feature won’t be included, however on the 32bit version, RF feature and other serial communication protocol will be included.

The release of these two versions will enable end developers to make a choice of design that best fit their location and solve their problem.

4.GSM SIM cards:

We don’t think having one sim card per design is too much of an investment, almost everyone on planet earth uses a mobile phone with a sim card, which implies it is readily available and cheap.

However for users who may see sim card as an additional cost to the meter, they can opt for the FR enabled version with a base station as described in your comments.

  1. Power consumption:

The power consumption will vary from time to time, as GSM module draw about 2amps when connecting to network, however we don’t think this will be an issue technically or economically as even inverters have offload running wattage as little as 20watts for the best inverter design topology and it doesn’t affect operators technically or economically, however doing a cost comparison between how much power is used by the meter and how much the end user pay per KWH, it should justify the running power on the meter which is negligible during normal operation.

  1. Data protection:

Your point is noted. This is also a top priority topic for us and we will implement industry standard security protocols to ensure we meet high security levels. Each meter will have a unique identifier and access will be password protected.

7.Meter tampering option:

Different tamper proof topology will be employed from hardware to software to ensure the meter is tamper proof, more about this session will be made available in the operation manual for privacy purpose.

8.The code is made public to foster development which is the overall vision and mission of ENAccess. We believe before adoption and commercialisation of product using our open source design as a starting point, developers will need to customise codes to ensure protection. it is also possible to perform a comparison between power transmitted and power consumed for deviation, if deviation is noticed, the operator will pay a visit to the site.

The Cicada project, if I understand, abstracts the GSM/communication module, so its possible to implement any new module you want. Is there something that would prevent a user from expanding the Cicada project with support from the SIM5320 rather than starting from scratch?

It looks like the project is still set up to be able to easily add a new driver for a new chipset - why not add SIM5320.c/SIM5320.h here and update the project accordingly?

I ask because it might allow you to focus on the more interesting parts of your project, rather than rebuild aspects from scratch that could possibly be reused. Plus, expanding Cicada is likely to benefit existing users of that tech as well, while not preventing you from innovating and using Cicada in your final meter product.

What was the outcome for this project?
Hope to hear comments.
Alrami

@alramir Open Smart Meter development is complete and published. Its a single phase Open smart meter. Its available for use and replicate it. All the details including all hardware and software files can be access from EnAccess website- Smartmeter - EnAccess

In case you need additional assistance on this, you can also submit your request for the same from their website itself.

Hi,

Your project for the Open Source GSM SmartMeter looks very promising! We would like to invite you to explore a releated and possibly complimentary project called SolarNetwork:

https://solarnetwork.net/

This 100% open software platform is focused on providing all of the tools, data repository and utilities to create powerful distributed generation apps. Similar to the Open Smart Meter, it has a client software that boots up on an SBC (such as Raspberry Pi) that can persist data from (and control) many different pieces of equipment like solar inverters, kilowatt-hour meters, pyranometer, switches, charge controllers, webcams, weatherstations, EV charging stations and more. The SolarNode also can connect to many software services like Building Management Systems, weather service providers, tariff providers, web storage providers and more. Supporting many data communication protocols and standards such as Modbus, SunSpec Modbus, mBus, CANbus, BACnet, DNP3, RTSP and others, a SolarNode beyond connecting to also connects to a cloud platform called SolarNet which acts as a data repository and application server with a RESTful API. It lets you get started quickly, and I think you’ll find as a developer, it has a lot of the underlying tools you will eventually need in building an Energy Application - without sacrificing your own user interface or spending a ton on data, or comprimising on security or scalability for the future.

When I read about Open Smart Energy Meter, I immediately wrote in because from a “back end” perspective there are a lot of potential synergies there. Like SolarNodes, Arduino based clients can potentially utilize SolarNet, and you may find that beyond kWh and power quality readings, there are use cases to explore where you need to support many other devices and energy flows, and develop logic and triggers at the edge using local site data mixed with data from online sources. This may be interesting but we wish you luck in your exploration and development efforts, and creating novel solutions that have never been done before!

Thanks, John

1 Like