02 Architecture Constraints - s-allius/tsun-gen3-proxy GitHub Wiki
Constraints | Description, Background |
---|---|
Moderate hardware requirements | Operation is intended on low-cost environments, such as Raspberry Pi or NAS servers |
CPU independent | Code should run on little and big endian machines, and should not make assumptions about the CPU architecture |
Implementation in Python | Python is easy to read, has high cross-platform compatibility and many standard libraries. Only the latest Python major release is supported and no downward compatibility is guaranteed. This enables the use of new features and keeps the code lean |
Asynchronous Design | The inverters transmit data in short phases separated by long pauses. Asynchronous programming improves performance and responsiveness and at the same time enables a low CPU load during pauses |
Docker | The proxy is only provided as a Docker container. This means that all dependencies are also supplied and do not have to be installed and configured individually |
Home Assistant Add-on |
The proxy is also provided as Home Assistant Add-on. An Add-on is a docker container with a defined interface to th HA supervisor. |
Dependencies | To minimise maintenance costs, dependency on external modules should be kept to a minimum. If possible, Python standard modules should be favoured |
Constraints | Description, Background |
---|---|
Documentation | An arc42 structure is used to document the architecture. Inline documentation should be executed as DocStrings |
Source code analysis | For Static Application Security Testing (SAST) SonarCloud is integrated CI pipeline |
Publication as open source | The source code will be made available as an open source project on GitHub |
Conventions | Description, Background |
---|---|
Context Manager | Wherever possible, Python Context Managers should be used to easily ensure the release of resources that are no longer required. If this is not possible, an explicit close method is used, which must be called before an instance is released. |
Owner of the connection instances | All dynamic instances belong to a higher-level inverter instance (class InverterBase). This is instantiated when a connection between inverter and proxy is established and lives until the connection is closed again. During this connection termination, the close methods of all subordinate instances must be called. This can be done in a tree structure, whereby the root is always the superordinate inverter instance! This process can also be triggered by subordinate instances via callbacks. |
No __del__ methods | No __del__ methods should ever be used in the project! The close methods should release all circular references to ensure that the objects are released quickly by the garbage collector. If this is not done completely, this leads to memory leaks. The Python garbage collector can recognise and release these circular dependencies between unused objects. However, no __del__ method must be defined for this. |