Contributing to Development¶
Solar Router for ESPHome is designed in a modular way to facilitate customization with different power meters and different regulators.
Would you like to contribute? You are welcome and you will find below some recommendations to do so.
Tip: Get inspired by already developed code to go faster.
Developing Hardware¶
You can propose any hardware according to your needs. If this new hardware requires the use of GPIO, the pins used by your hardware must be configured in the vars section associated with your package.
Documentation must be added describing this new hardware and its constraints (e.g.: list of GPIOs and usage). See the chapter updating the documentation below.
Developing a Software Package¶
Setting up the Development Environment¶
To contribute to Solar Router for ESPHome, develop a new feature on your computer and propose a pull request, you must:
- Fork the Solar Router for ESPHome repository on Github
- Clone your forked repository to your PC
- Create a development branch from main
-
Create and activate a Python virtual environment
Go faster with Linux
Add an alias to you venv :
echo "alias venv='. ~/.virtualenvs/python3/bin/activate'" >> ~/.bash_aliases
Reopen you console and callvenvto activate you Python virtual environment. -
Install ESPHome CLI and other dependencies:
-
Install and test your code on your device with the
esphomecommand:Local development
Solar-Router-For-ESPHome is designed to use files stored on GitHub.
Thetoolsdirectory contains the scriptconvert_to_local_source.pywhich allows you to convert ayamlfile pointing to GitHub into a source file with the same name prefixed bylocaland pointing to files located in thesolar-routersubdirectory.
Thus, local modifications will be taken into account immediately by theesphome run local_<my_yaml_file>command. -
Once stabilized, push the changes to your repository
- And finally, propose a pull request from your fork to the official repository
Developing a Power Meter¶
A Power Meter is a component designed to provide and periodically update a sensor named real_power.
This sensor is used by Engines to obtain the value of power exchanged with the grid.
If this new power meter requires specific configuration, the required parameters must be added in the vars section associated with your package.
Documentation must be added describing the power meter and how to configure it. See the chapter updating the documentation below.
Developing Regulators¶
A Regulator must manage the percentage of energy sent to its load based on its regulation level sensor (e.g., regulator_opening for TRIAC/SSR). The level of each regulator can vary from 0 (where no energy is sent to the load) to 100 (where all possible energy is sent to the load).
The overall system state is managed by the router_level sensor, which controls all regulators. When router_level is at 0, all regulators must be off, and when it is at 100, all regulators must be at maximum. For systems with a single regulator, the regulator level generally reflects the router_level, but they remain separate because router_level is used for LED indicators and energy counting logic.
Here is an example regulator implementation (excerpt from regulator_triac.yaml) using the light component and its brightness to control energy diversion:
You can develop one or more regulators to work together in the same system. Each regulator must: - Have its own level sensor ranging from 0 to 100 - Respond to changes in the global system router_level - Manage its specific hardware control logic
If this new power meter requires specific configuration, the required parameters must be added in the vars section associated with your package.
Documentation must be added describing the power meter and how to configure it. See the chapter updating the documentation below.
Updating the Documentation¶
The documentation is written using mkdocs and Material for MkDocs.
To install mkdocs, you must install Python then:
- Create a virtual environment (see Python documentation).
- Install the required modules with the following command
pip install -r requirements.txt.
The documentation is stored in the docs directory. To see your changes in real time in your browser, run the mkdocs serve command and navigate to http://127.0.0.1:8000
Updating the Changelog
The Changelog is only available in the officially published documentation.
The Changelog is updated manually after a new version is released.
The Changelog is generated using git-cliff.
Versions are based on tags.
Lines added to the changelog are based on merge commit messages.
The tools\update_documentation.sh script is designed to update changelog.md, generate and publish the mkdocs documentation on github pages.
The documentation update script is intended to be used only by the repository maintainer.