|
Some checks failed
Default / Build (push) Failing after 2m0s
Default / Build UI (push) Failing after 13s
Release / Publish Docker :release (push) Has been cancelled
Release / call-build-workflow (push) Has been cancelled
Release / Publish Github & APT release (push) Has been cancelled
- Configure now asks for the users knowledge level, so advanced mode can be reached without calling with `--advanced` - Add template for solaredge inverter - Add beta template for sungrow inverter - Add template for MQTT based meter - Add more template documentation - Add check and error message for invalid config properties when using templates - Option to specify language specific template descriptions - Option to make params dependent on values of other params - Option to add sponsortoken in advanced mode - Option to set minCurrent in advanced mode - Remove sponsorship requirement from Daheimladen wallbox - Multiple fixes (FritzDect meter, Kostsal Piko meter, ...) |
||
|---|---|---|
| .. | ||
| definition | ||
| docs | ||
| README.md | ||
Templates folder documentation
Folders
- defintion: hold all device templates definitons in yaml files
- charger: all charger templates
- meter: all meter templates
- vehicle: all vehicle templates
- docs: content is generated via
go generate ./..using the above templates for the evcc documentation page to be used
Template Documentation
The following describes each possible element in a yaml file
template
template expects a unique template name for the current device class (charger, meter, vehicle are device classes)
description
description expects a human readable description of the device, best containing the name of the product. Values are language specific names via de, en, generic (if string is language independent)
generic
generic: true defines templates that are typically not a hardware product, but rather generic implementations that can be used by a variety of products (e.g. inverters with sunspec support) or for software components like vzlogger.
guidedsetup
guidedsetup if the device can be used for a guided setup, which are devices that provide multiple meter usages, or meter devices that are typically installed with specific other devices. Mostly used for meter devices that provided multiple usage data with the same user input. These devices are then sorted at the bottom of the product list.
enable
enable: true to define that this device can be used for guidedsetup
linked
Allows to define a list of meter devices that are typically installed with this device
template
template expects the linked device template value
usage
usage expects the meter usage type this device will be used for
Possible values:
grid: for grid meterspv: for pv inverter/meterbattery: for battery inverter/meter
multiple
multiple:true to define that multiple devices of this template can be added
excludetemplate
excludetemplate defines a linked device template value. If defined and a device of the linked template is added, then this linked template won't be considered in the flow
Example Use Case: With SMA Home Manager, there can be a SMA Energy Meter used for getting the PV generation or multiple SMA PV inverters. But never both together. So if the used added an SMA Energy Meter, then the flow shoudn't ask for SMA PV inverters.
capabilities
capabilities provides an option to define special capabilities of the devie
Possible Values:
iso151182: true: If the charger supports communicating via ISO15118-2
requirements
requirements provides an option to define various requirements / dependencies that need to be setup
Possible Values:
sponsorshipt: true: If the device requires a sponsorship tokeneebus: true: If the device is accessed via the eebus protocol and thus requires the corresponding setuphems: sma: If the device can be used as an SMA HEMS device, only used for the SMA Home Manager 2.0 right nowdescription: expects language specific texts viade,ento provide specific things the user has to do, e.g. minimum firmware versions or specific hardware setup requirementsuri: a link providing more help on the requirements
loglevel
loglevel defindes the name that can be used in the levels configuration for adjusting the log level of individual devices/components/...
params
params describes the set of parameters the user needs to provide a value for.
base
base reference value of a predefined params set defined in parambaselist.yaml, so these params don't need to be redefined in each template. The example and default values for each predefined value can be overwritten.
name
name expects a name for the parameter, which will be used in the render section to reference the param and provide the user entered value.
Note: There a few default name values with specific internal meaning and consequences!
Predefined name values:
usage: specifies a list of meter classes, the device can be used for. Possible values aregrid,pv,battery, andchargermodbus: specifies that this device is accessed via modbus. It requires thechoiceproperty to have a list of possible interface values the device provides. These values can bers485andtcpip. The command will use either to ask the appropriate questions and settings. Therendersection needs to include the string{{include "modbus" .}}in all places where the configuration needs modbus settings.
Modbus Options
id: Device specific default for modbus IDport: Device specific default for modbus TCPIP portbaudrate: Device specific default for modbus RS485 baudratecomset: Device specific default for modbus RS485 comset
description
description allows to define user friendly and language specific names via de, en, generic
dependencies
dependencies allows to define a list of checks, when this param should be presented to the user, if it should be only in special cases
name
name referenced the param name value
check
check defines which kind of check should be performed
Possible values:
empty: if thevalueof the referencedparamnameshould be emptynotempty: if thevalueof the referencedparamnameshould be NOT emptyequal: if thevalueof the referencedparamnameshould match the value of thevalueproperty
value
value property is used in the equal check
required
required: true defines if the user has to provide a value. Default is false
mask
mask: true defines if the user input should be masked, e.g. for passwords. Defaut is false
default
default defines a default value to be used. For these cases the user can then simply press enter in the CLI.
example
example provides an example value, so the user can get an idea of what is expected and what to look out for
valuetype
valuetype allows to define the value type to let the CLI verify the user provided content
Possible values:
string: for string values (default)bool: fortrueandfalsevalues. Ifhelpis provided, than that help text is presented as the questionnumber: for int valuesfloat: for float valuesstringlist: for a list of strings, e.g.used for defining a list ofidentifiersforvehicleschargemodes: for a selection of charge modes (includingNonewhich results in the param not being set)
advanced
advanced allows to specify if the param should only be asked if the cli is run with --advanced. Mostly used for non required params that are meant for users with advanced needs and knowledge.
help
help expects language specific help texts via de, en
render
render contains the internal device configuration. All param name values can be used as a template variable, e.g. {{ .host }} for a param named host. The content is a go template, so all of go template feature can be used, e.g. {{- if ... }} statements, etc.