Volkszähler Architektur

architecture-discussion.md

Volkszähler Architecture

Current architecture

The as-is architecture looks like this:

aquire -> persist -> visualize

Each compontent is implemented separately with persist and visualize sharing a github repository.

aquire

Bundled implementation: vzlogger (c++)

Other implementations: various potentially integrated by using node-red. Examples include:

• ebusd
• gosdm
• goelster

persist

Bundled implementation: middleware (php)

Other implementations: influxdb (from vzlogger)

visualize

Bundled implementation: frontend (plain js)

Other implementations: grafana (using mysql, simple-json or grafana-json datasources with gravo adapter).

Proposed architecture

An extendend pipeline could make the architecture more flexible while improving maintainability by defining a smaller functional surface per component:

aquire -> ingest -> persist -> visualize
             |                      ^
             +----------------------+

aquire

For sake of maintainability it might make sense to:

• split aquire into specific implementations, potentially using a "simpler" programming language
• agree on a small set output protocols for aquire
• define additional aquire implementations for specific purposes
• small admin UI (?)

Implementation

• input-specific daemons with mqtt as output protocol.
• output using mqtt with homie specification for publishing additional properties for auto-configuring ingest

ingest

ingest is able to ingest data from aquire and other data sources. It provides additional, general capabilities:

• aggregation and batch handling
• limited but extendable set of output protocols
• push notification
• small data UI
• calculations (optional)

Implementation

• use homie specification for subcribing to input
• parse additional properties for auto-configuration
• output using mqtt, websockets, volkszaehler API and influxdb (?)

persist + visualize

persist and visualize remain unchanged. While not unique to Volkszähler they already exist and represent huge complexity. Additional persist implementations are possible, including e.g. like influxdb etc.

Coupling

Coupling of new components like aquire or ingest could use established protocols like mqtt. This would allow to open even the ingest stage's functionality to addtitional non-volkszaehler aquire implementations without additional glue logic.

Configuration

• support auto-wiring as much as possible
• support yaml configuration files
• allow using a common configuration file (?)