Bug/729 add remove variables and components from schema for device model

[maaikez]

Describe your changes

With this pull request, it is possible to remove and add variables (and their attributes and characteristics) and components for all other components than only EVSE and Connector.

It also removed the use of config.json, so everything is now added to the component schema's, which are renamed to component config. The values from the 'default config' are now added to the new 'component config' json files.

There is one TODO left in the ocpp_types file. If the changes are ok there, I can also change the generator to do exactly that. Otherwise I have to solve it another way.

I also made a pull request in everest core (EVerest/everest-core#822) and are still busy with some changes in everest utils (https://github.com/EVerest/everest-utils/tree/feature/715-combine-component-schemas-and-config-in-one-file).

Issue ticket number and link

#729
#715

Checklist before requesting a review

• I have performed a self-review of my code
• I have made corresponding changes to the documentation
• If OCPP 2.0.1: I have updated the OCPP 2.0.1 status document
• I read the contribution documentation and made sure that my changes meet its requirements

[Pietfried]

Looks nice. Just added a couple of suggestions. Make sure to update the dependency in EVerest/everest-core#822 once this is merged

[Pietfried]

Suggested change

	/// or
	/// changed.
	/// or changed.

[Pietfried]

You mean in the generate_component_config.py right? Not sure if this still works and if we still need it. It was based on a modified version of the dm_component_vars.csv that we haven't made public due to uncertainty about the license

[maaikez]

So you don't generate it anymore?
(I just want to be sure it is not removed when the file is regenerated)

[Pietfried]

Suggested change

	Those will be removed, changed or added. Those will be removed, changed or added to the database as well.
	Those will be removed, changed or added to the database as well.

[Pietfried]

You could put this into a separate function so this reads a little better. You could also reusue it within L604

[acnixvkh]

@maaikez, I encountered some difficulty adapting my configuration when changes from this pull request appeared in my copy of EVerest. Although it is working again, I am unsure if my approach is correct and would appreciate your confirmation.

Scenario: I want to change a value defined in the standardized schemas or define a value for a variable that has no default value in the standardized schemas. To do this, I create a new schema in the sub-directory component_config/custom/. This new schema repeats much of the code from the original schema in component_config/standardized/ with only the "value" element added or changed.

Example: To set ContractCertificateInstallationEnabled from component_config/standardized/ISO15118Ctrlr.json to true, I create component_config/custom/config.json with the following content:

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "name": "ISO15118Ctrlr",
  "properties": {
    "ContractCertificateInstallationEnabled": {
      "variable_name": "ContractCertificateInstallationEnabled",
      "characteristics": {
        "supportsMonitoring": true,
        "dataType": "boolean"
      },
      "attributes": [
        {
          "type": "Actual",
          "mutability": "ReadWrite",
          "value": true
        }
      ],
      "description": "If this variable is true, then ISO 15118 contract certificate installation/update as described by use case M01 - Certificate installation EV and M02 - Certificate Update EV is enabled. If this variable is false, then ISO 15118 contract certificate installation/update as described by use case M01 - Certificate installation EV and M02 - Certificate Update EV is disabled.",
      "type": "boolean"
    }
  }
}

Question: Is this the correct approach to adapt configurations in libocpp, or is there a more efficient method to avoid repeating large portions of code?

[maaikez]

@acnixvkh Ah never thought of this way. No you should just change the ISO15118Ctrlr.json and set the correct value there. Although this might just work, but I am not sure.

The default values are confusing, I will remove them in the future.