Collect 15min energy metrics

[andig]

@naltatis hier der erste Aufschlag für 15min Metriken. Daten werden jeweils für 15min gesammelt und dann in die metrics Tabelle geschrieben.

TODO

• [x] entities (CRUD)
• [x] add meter usage column (grid, pv, ...)
• [x] split consumption and production
• [ ] use energy where possible
• [ ] add reading metrics from DB

[andig]

@naltatis siehst Du warum Integration nicht geht?

[naltatis]

I'd suggest keeping it simpler and not introduce a foreign key relation. This is something we'd then have to manually manage. My suggestion would be to introduce a mandatory "type" (or category) and an optional "name" (device).

Types: home, pv, battery_import, battery_export, grid, feedin, charger, aux, ext, solar_forecast, solar_forecast_plus_24h

The types are similar to your existing meter types but they dont have to be limited to that (see home).

Name: db:12, charger_goe, ...

Advantages:

• fast to query and group (one table, no joins)
• query by specific device (charger_goe) or by type (pv)
• no need to manage entity table (what happens if user removes charger_goe from yaml or renames)?
• overall metrics (this year pv production) stay complete, even if you remove/replace a device
• easy to read and manually cleanup (human)

Disadvantages:

• slightly more data stored (strings instead of ids). SQLite is good in optimizing/compressing this! Possible optimization: We could store type as number from Go type enum. Similar to configs.class field.

Naming: Lets use energy instead of val. We'll likely want to add additional (optional) fields like cost, co2, ... later.

[naltatis]

@naltatis siehst Du warum Integration nicht geht?

Auf Anhieb nicht. Der Test versucht evcc mit einer ungültigen Datenbank zu starten. Hier geht jetzt scheinbar was kaputt. Siehe fatal-db.evcc.yaml

[andig]

Interessant. Würden wir bei fehlender DB erwarten, dass die site überhaupt angelegt wird?

[andig]

Es wäre gut, wenn wir die Diskussion von den Anforderungen statt von der Implementierung her führen würden. Fwiw:

I'd suggest keeping it simpler and not introduce a foreign key relation. This is something we'd then have to manually manage.

That's already done in the current code.

My suggestion would be to introduce a mandatory "type" (or category) and an optional "name" (device).

Mir ist nicht klar, wie wir die verwenden würden bzw. zu welchem Zweck wir Beide Attribute brauchen?

no need to manage entity table (what happens if user removes charger_goe from yaml or renames)?

Gleicher Punkt wie drüber- ich habe noch kein klares Bild, wie wir die verwenden würden.

overall metrics (this year pv production) stay complete, even if you remove/replace a device

Super use case! Wäre ein weiterer Grund für eine entity Tabelle- dort würde dann auch die Kategorie hin gehören.

Naming: Lets use energy instead of val. We'll likely want to add additional (optional) fields like cost, co2, ... later.

In einem orthogonalen Schema nicht.

fast to query and group (one table, no joins)

Joins sind perfekt für Geschwindigkeit ;)

[andig]

battery_import, battery_export, grid, feedin

Wollen wir Import/Export separat modellieren oder sind das zwei Seiten einer Medaille? Letzteres hätte den Vorteil, dass der Accumulator das intern handlen könnte (=2 Spalten pos/neg). Anderenfalls brauchst Du immer zwei Updates damit die "andere" Seite weiss, dass sich der Timestamp des letzten Updates geändert hat, auch wenn es keine Wertänderung gibt.

[naltatis]

Naming: Lets use energy instead of val. We'll likely want to add additional (optional) fields like cost, co2, ... later.

In einem orthogonalen Schema nicht.

Ich weiß nicht, was du mit ortohonalem schema meinst, aber die Kosten für diese geloggt Energiemenge würde ich damit direkt verbunden sehen und nicht noch eine allgemein Kostenloggingtabelle aufmachen.

[naltatis]

My suggestion would be to introduce a mandatory "type" (or category) and an optional "name" (device).

Mir ist nicht klar, wie wir die verwenden würden bzw. zu welchem Zweck wir Beide Attribute brauchen?

Unterschiedliche Arten von Auswertung. Einmal das klassische "Gibt mir mal ne Jahresübersicht meiner PV Produktion". Dann würde ich einfach nach Kategorie "pv" filtern, aufsummieren und fertig. Egal wie viele WRs an der Produktion beteiligt sind oder waren. Keine joins, einfach super simples group und sum.

Ich kann mir aber auch im Breakdown pro Wechselrichter vorstellen. Dann würde ich zusätzlich noch nach Gerät gruppieren.

Geht beides auch mit Joins, die Frage ist nur was wir dadurch wirklich gewinnen.

[andig]

Schau mal, ist schon umgesetzt. Aktuell:

• grid/device name
• pv/device name
• virtual/home

Für home habe ich eine Gruppe "virtueller" Zähler angedacht, die einen errechneten Meßwert repräsentieren (auch wenn an der Stelle egtl. nur "home" relevant ist). Lässt sich das Schema durchziehen?

[andig]

Bi-directional:

• grid/device name
• battery/device name
• ext/ device name
• aux/ device name

Uni-directional:

• pv/device name
• loadpoint/ loadpoint name (TODO)

Uni-directional/ single instance:

• home

Prices, solar and future forecasts: later

[tpd-opitz]

Please change https://github.com/evcc-io/evcc/blob/180145ed56dbfc11d52d071a030c4f2ef4fe382a/meter/tibber/types.go#L24-L28 to

type Subscription struct {
	ID        string
	Status    string
	PriceInfo PriceInfo `graphql:"priceInfo(resolution: QUARTER_HOURLY)"`
}