enaccess / opensmartmeter Goto Github PK

The 3D shapes for the following components are not showing

1. Transformer
2. RTC module
3. Cicada wifi module
4. STM32 module
5. RV2
6. Terminal cover button

These shapes are not been rendered because the path for the 3D shapes points to a folder on the developers Laptop. When the project is then loaded to another computer, the software is not able to locate the 3D files because they are not available on the new computer.
Suggestion
Get a complete list of missing shapes or all the external libraries and add them to the repo so that they can always be used in the project. The new folder should then be added to the working paths for kicad as a relative path so that it stays the same no matter the change in computer

How does the device behave if a user (or potentially malicious actor) supplies extremely low or extremely high voltages?

According to the datasheet, metering can be done on the L line and the N line.
On the L line metering a shunt is connected and metering is done.
On the N line metering, a current transformer is used and this is added when there is a plan to meter the neutral line for anti tampering(L+N metering).
Why was the metering done on the Neutral line ? Is it capture energy consumption in a situtation where customer by passes the life wire ?
What happens when there is a fault on the live wire and current flows from the live to the ground without returning through the neutral?

There are a lot of LM350 linear regulators which have a relatiely poor efficency. Are these strictly required or can they be replaced with something else (switching regulator)?

Currently in the PCB and schematics component numbers are used. For example LM350 is used a lot. However, if better to use a reference for example XYZ123. In case we ever have to change the part from LM350 to some similar part in the future the references do not have to be adapted.

Clang-fromat is a commonly used linter and auto formatter for C++, see here

We should add this to format the Software files and add a small CI using Github Actions to make sure new code changes follow the same rules.

The sketch uses two libraries ArduinoJson and LiquidCrystal which needs to be installed via

arduino-cli lib install ArduinoJson
arduino-cli lib install LiquidCrystal

Please document which versions of the libraries are required.

In the smart_energy_meter.ino a myriad of unused variables are declared. This is confusing for collaborators and consumes unnecessary memory.

A few examples

• https://github.com/EnAccess/OpenSmartMeter/blob/main/Firmware%20code/smart_energy_meter/smart_energy_meter.ino#LL40C15-L40C32
• https://github.com/EnAccess/OpenSmartMeter/blob/main/Firmware%20code/smart_energy_meter/smart_energy_meter.ino#L42

After #54 is finished, most of the variables left in smart_energy_meter.ino are most likely unused and can be removed.

The Firmware code ships with a dependency called OneWire here: https://github.com/EnAccess/OpenSmartMeter/tree/main/Firmware%20code/smart_energy_meter/Library/OneWire

It doesn't look like this library is getting used in the code. In fact, removing the library still makes the code compile.

Goal here is drop support for Arduino IDE. We cannot currently use all features of PlatformIO for interoperatability reasons. Dropping support for Arduino IDE will allow us to use all features, like includes and namesspace. This will make the code a bit more intuitive to read.

Steps

• Remove Arduino from CI
• Rename main .ino -> main.cpp
• Rename secondary .ino -> .hpp
• Add #include <Arduino.h>
• Include Header guards in secondary .hpp files

Should only be done, after

• #54
• #55

have been done.

Running KiBot on the currently version of the schematics fails with

ERROR:Malformed component reference `8.192MHz1`

References shouldn't start with a number.

It is not 100% clear how the OpenSmartMeter is secured against external, malicious access. It would be great if this can be clarified.

Define the protocol that will be used to analyse the entered token.

Apparently, the PCB thickness is set to 0, which a.o. confuses KiBot, see context here: INTI-CMNB/KiBot#463 (comment)

TBD: What is a reasonable thickness for the board?

It's not clear which version of the platform library is used. Latest is 2.4.0

Also, it looks like we are using some deprecated version:

ID                       Version Name                  
STM32:stm32              1.9.0   STM32 Cores           
STMicroelectronics:stm32 2.4.0   STM32 MCU based boards
STMicroelectronics:stm8  1.0.0   STM8 MCU based boards

Note the different name schema.

Also, document which board and board part have to be used. From the screenshots it looks like Generic STM32F1 series. However, in default setting this doesn't work, as the default has too small memory.

From some quick testing it looks like the correct FQBN is

STM32:stm32:GenF1:pnum=BLUEPILL_F103C8

Based on the datasheet for the M90E26, there are four mode the metering IC could be set in.
There is a mode that helps the meter know when tampering is taking place by comparing the current running through the live wire to the current running through the neutral wire and if the difference is bigger that the threshold that has been configured in the registers of the metering IC, the meter will detect this.
In anti tampering mode,metering is done on the Live line and the Neutral line and the difference is calculated and compared with the threshold.
There is little information about the mode being used and the possibility of this in the OpenMeter.

KiCAD was released in version 7 recently, see https://www.kicad.org/blog/2023/03/KiCad-7.0.1-Release/

Let's update our files to the latest release.

Compiling the firmware fails with

/Users/d.mohns/Development/OpenSmartMeter/Firmware code/smart_energy_meter/smart_energy_meter.ino:827:7: error: 'using ThingsBoard = class ThingsBoardSized<>' {aka 'class ThingsBoardSized<>'} has no member named 'RPC_subscribe'; did you mean 'RPC_Subscribe'?
  827 |    tb.RPC_subscribe();
      |       ^~~~~~~~~~~~~
      |       RPC_Subscribe

Note the different capitalisation of the S.

Commenting out that line makes the firmware compile.

Currently, it is relatively hard to access the device for maintenance or development. Many wires make it hard to disassemble. In future version of the device this should be taken into account.

The OpenSmartMeter is already equipped with a RS232 connector. Would it be possible to use this for flashing/maintaining of the firmware?

Would your firmware run adequately on https://www.sparkfun.com/products/21326

If so would you consider moving to the MicroMod footprint rather than as a specific dev board footprint?

Currently, we have a library called SamATM90E26_library in our Library directory. However,

• It looks like the code is essentially coming from here: https://github.com/whatnick/ATM90E26_Arduino but not reference is provided
• This code is not used as a library, but instead users actually need to chance the code as part of the calibration process, see here

This can cause a lot of confusion amongst users and should be cleaned up.

This consists of two steps

1. First, move the code from Library folder into the main folder of the code to signal this custom code is part of the Firmware and subject to changes.
2. Refactor the code to re-use as much code from https://github.com/whatnick/ATM90E26_Arduino and move the customisations as part of the calibration into a more clear location.

The firmware source code uses a lot of abbreviated variable names, which are not immediately clear to the reader what they stand for. Few examples are, ind1, ind2, dt, c_chek.

Use verbose naming of variables to make the code structure easier to follow.

Create documentation and share Python script to generate code and test the OpenSmartMeter

--> Give special codes for different cases (SetTime & AddTime)

We are currently using the (deprecated) version 1.9.0 in namespace STM32:stm32, via https://github.com/stm32duino/BoardManagerFiles/raw/master/STM32/package_stm_index.json

The latest version is 2.2.0 in namespace STMicroelectronics:stm32, via https://raw.githubusercontent.com/stm32duino/BoardManagerFiles/main/package_stmicroelectronics_index.json

This can be done by either unpinning or upgrading https://github.com/EnAccess/OpenSmartMeter/blob/main/Firmware%20code/smart_energy_meter/platformio.ini#L18

The repository does not contain a schematic pdf for quick review by anyone who wants to start the project. The kidcad software will have to be installed before one can view the schematic or the developer will have to checkout the readme file for the schematic.

Suggestions:

• The schematic should be saved in an output folder together with the bill of materials (BOM) and Gerber files.
• The schematic should be saved as a PDF file so that it can be easily downloaded and read by developers.
• The schematic should not be squeezed onto a single page. Instead, the blocks of the schematic should be divided into multiple pages.
• The schematic should be drawn according to best practices, such as having the ground ports pointing down and the positive ports pointing up. This will ensure a logical flow when reading the schematic

EnAccess OpenSmartMeterSchematic.pdf

All Documentation has been moved to MkDocs. Only thing missing are the DataSheets

From the code it looks like the firmware is checking validity of the used tokens. However, as the firmware has GSM access to a server. Should this not suffice to verify a token is valid?

The board used in the PCB is actually the Bluepill 128k version. We are running into memory errors with the 64k one.

Steps:

1. Rename the file from .ino to .hpp
2. Add the generic header to the file, namely

#pragma once

// defines

// Arduino base libraries

// third party libraries

// OpenSmartMeter libraries

3. Add #include to the smart_energy_meter.ino (for now, move it to the top of // OpenSmartMeter libraries)
4. Run pio run to build the code, it will probably fail, but will help you with the next 2 steps.
5. Move all variable declarations that are only needed in helpers.hpp from smart_energy_meter.ino
6. Add all #include from other SmartMeterLibraries

Two examples where the above steps have been done for other files, are here

• https://github.com/EnAccess/OpenSmartMeter/pull/53/files
• https://github.com/EnAccess/OpenSmartMeter/pull/52/files

• The Bill of Material is placed in the documentation folder (Hardware documentation). It should be placed in the output folder since it is necessary when making a production of the project.
• Components found in the BOM are sourced from Aliexpress. These components are sourced from different vendors on Aliexpress and it means different shipping fee applies for each component.
• Vendors on Aliexpress sell by reducing the selling price for each and making gains in the shipping cost to attract buyers.(Low selling price, high shipping cost) In the end the buyer spends a lot of money buying all the components.
• Bill of Material should have manufacturers part number, manufacturers name, alternative part number, quantity, designator,footprint etc. A BOM with all these fields can be upload to Octopart or digikey so that it can be quickly sourced.
• Quality of components sourced from Digikey, Mouser etc are relatively better as compared to components sourced from Aliexpress.
• If all the components in the BOM can be sourced from Digikey, they can be shipped together as one package at a cost efficient shipping fee.
• In the current BOM there are 26 components but when the BOM is exported from the KidCAD software, there are 86 unique components in the new BOM.
  

This is a test

Decide where to add OpenPAYGO Token as a submodule in OpenSmartMeter.

@dmohns Where should we store the submodule?

It can create problems in various tools.

• Rename general folder structure
• Rename KiCAD project and generated output files

Currently there are very few comments. Some of the comments describe "what" the code does rather than "why"