Skip to content

Features to add to developer docs #2

Open
@jesserockz

Description

@jesserockz

Overview/High-level

  • Basic introduction/home page
  • Introduction to hardware interfaces (I2C, SPI, UART, GPIOs)
  • Various commonly-used consts/variables (CONF_*, AUTO_LOAD, to_code, etc.)
  • FAQ

Code

  • Basic component CONSTs (AUTO_LOAD, DEPENDENCIES, CODEOWNERS, MULTI_CONF, MULTI_CONF_NO_DEFAULT)
  • Always use the api generation script if you modify api.proto
  • use walrus operator for optional config gathering - sensor_config := config.get(CONF_SENSOR) - except for boolean values.
  • No AUTO_LOADing the main platform components (sensor, binary_sensor etc)
  • Any literal string used more than once should be defined as a constant.
  • Configuration keys (i.e. those that appear as keys in YAML) should be defined (even if only used once) as constants of the form CONF_XXX where XXX is the upper-case version of the YAML key.
  • Configuration constants used only in a single component should be defined within that component. If the same constant is used in 2 or more components it may be migrated to esphome/const.py. If it appears in 4 or more components it must be migrated to esphome/const.py (will fail CI checks otherwise.)
  • Coroutine priorities (see [core] Update some coroutine priorities esphome#6755)

Tests

  • All components should have test yaml files located in tests/components/<component name>/test.<platform>.yaml and this yaml should contain every configuration option being set and any actions and conditions the component has.

Documentation

  • Documentation example is to be minimum required to compile, optional configs not to be included. Pin values should always be the string REPLACEME
  • Example should not include dependent components, but a sentence and link to the relevant configuration documentation
  • If a component is used exclusively, or primarily, on a single specific board (i.e. with dedicated pin numbers) a complete configuration for the component on that board may be included as a sample at the end of the doc, clearly identified as being for that hardware. This should not replace the generic example configuration.

Traps for the unwary

  • If you just added a new validation function and your code blows up, check that the validation function has return value at the end.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions