Add battery, pv and aux titles

[panzerdev]

Is your feature request related to a problem? Please describe.
I have installed more then one PV inverters and configured also more then one inverter in the config. Now I would like to see which inverter contributes how much to the total by name/label.

Describe the solution you'd like
Right now there is only a Tooltip to show the power by inverter and I would suggest a listing of the inverters and their power when there is more then one. Could be an expanding view with a plus or arrow to operate.

Additional context
Add any other context or screenshots about the feature request here.

[andig]

Similar to batteries, would be consistent.

[StevieC121176]

So wie in dem Vorschlag oben (rote Linie) wird es eng werden in der mobilen Ansicht auf Telefonen und Tablets (Hochformat).
Eine Anzeige im Tooltip wäre in diesem Fall aber schon hilfreich. z.Bsp. vor der Wattzahl den Namen der Anlage aus der yaml.

[RTTTC]

I would like this feature added too.

[naltatis]

I like the idea of being able to expand details for the production and batterie entries if there are more than one. It's much nicer than the current tooltip solution because it could stay open permanently.

Currently we don't have display names for the individual PVs and batteries. This is something we would have to introduce. Yes we could go with PV1, PV2, PV3, but I guess most users would have more meaningful names "Carport, Main roof, ..." that they would want to see there.

[panzerdev]

api.Meter needs a Title like in Vehicle:

evcc/api/api.go

Lines 49 to 51 in 14d2ba9

	type Meter interface {
	CurrentPower() (float64, error)
	}

evcc/api/api.go

Line 141 in 14d2ba9

Title() string

This site meterMeasurement needs a Title property:

evcc/core/site.go

Lines 34 to 36 in 14d2ba9

	type meterMeasurement struct {
	Power float64 `json:"power"`
	}

This should be all on the backend side because the frontend gets the meterMeasurement slice published.

[andig]

We won't add additional titles at this time. We can still display multiple PVs like batteries. Seems we shouldn't have started with displaying individual devices at all ;)

[panzerdev]

We won't add additional titles at this time. We can still display multiple PVs like batteries. Seems we shouldn't have started with displaying individual devices at all ;)

Why not? Everything should have meta data. Could even be a key value object containing labels or whatever the user would like to put in a meta information. Why should this be a big deal?

[andig]

It is not particularly important compared to our current priorities.

[naltatis]

What do you mean?

We can still display multiple PVs like batteries.

From my point of view the visualization of multiple pvs and batteries is quite similar right now. Only difference is, that we show power instead of kWh/%, but the mechanism is the same: tooltip, one line per device.

[RTTTC]

Currently we don't have display names for the individual PVs and batteries. This is something we would have to introduce. Yes we could go with PV1, PV2, PV3, but I guess most users would have more meaningful names "Carport, Main roof, ..." that they would want to see there.

If we name them Carport, MainRoof etc, instead of PV1, PV2 in yaml, it would already be a solution, right?

[andig]

What do you mean?

Nvm. I thought we didn‘t have the tooltip yet.

[panzerdev]

Maybe a a first interrim solution we could at least add a name/label in the popup?

I can do a PR no problem.

[andig]

I can do a PR no problem.

Ich möchte keine neue can of worms aufmachen. Das Feature fügt keine lebenswichtige Funktionalität hinzu. Alle Messwerte sind auch heute verfügbar. Unsere Prioritäten liegen aktuell anders.

[panzerdev]

Das ganze Thema ist durch die aktuelle Meter Implementierung schon ein ganz schönes Brett, habe aufgegeben als ich zu den dekorierten meters kam. Habe die Idee verfolgt einen generischen key value store einzuführen und da waren die Änderungen minimal.

Habe keinen PR aufs evcc repo gemacht und erstmal nur in meinem fork verbaut. Wer interesse hat kann sich den code hier gern klauen für sich selber.

panzerdev#2

Ansonsten steht das Thema ja zur Diskussion.

[andig]

Habe die Idee verfolgt einen generischen key value store einzuführen und da waren die Änderungen minimal.

Lass uns das doch neu anschauen, wenn wir mit Ui Config durch sind. Da wird sich an den internen Strukturen ohnehin noch einiges ändern (müssen). Je weniger Ballast wir dabei mitschleppen, desto besser. Danach sind die Karten wieder neu gemischt. Es muss ja kein "nein" für immer sein sondern ein "jetzt nicht". Danke fürs Verständnis!

[andig]

Sollten wir- wenns soweit ist- auch für aux Zähler machen. Required for #6029.

[PeterPablo]

Just to add from #10335, which is mentioned here only implicitly: Please add title to the MQTT topics of meters.

[andig]

Ich sehe drei technische Möglichkeiten:

1. Alle Zähler/Charger um weitere Felder erweitern, analog embed bei Fahrzeugen. Das sind viele Änderungen und eigentlich brauchen die Zähler die Daten nicht. Fahrzeuge übrigens auch nicht, aber es gibt auch welche die diese Daten im Api schon mitliefern. Also vielleicht doch.
2. Alle Zähler/Charger mittels Decorators wrappen um zusätzliche Fähigkeiten/Felder zu ergänzen. Logik schön separiert, aber viel Aufwand, die Wrapper bei jedem neuen Interface ajour zu halten.
3. Separate Metadaten- das hatte @panzerdev schonmal vorgeschlagen, wäre aber eine zweite Lösung fürs gleiche Problem. Hässlich.

Nichts davon überzeugt mich so, dass ich die Lösung umsetzen wollte :(

[panzerdev]

@andig der Vorschlag mit den separaten Metadaten war auch ein wenig weiter gefasst. Falls du Tags bzw. Labels aus andere Bereichen kennst, dann weißst du wie hilfreich die sein können um zb. in der nachverarbeitung auf diese Infos reagieren zu können. Benutze beim Docker zb. labels mit domains drinnen um das reverse proxy file automatisch zu generieren.

Der Metadatenansatz sollten wenn dann für alle Objekte sein und auch wieder mit rausgegeben werden für Anschlussverwendung innerhalb und außerhalb von evcc.

[andig]

Das ist genau der Punkt. Konsistente Lösungen wären schön. Beim Fahrzeug ist es ein Zwitter da der Title auch vom Fahrzeug-API genommen werden kann. Dann müsste das Fahrzeug also die Metadaten kennen oder (inversion of control) die Metadaten selbst anbieten. Ich hab noch nichts gefunden was mich so richtig begeistert hätte.

[andig]

Der Metadatenansatz sollten wenn dann für alle Objekte sein und auch wieder mit rausgegeben werden für Anschlussverwendung innerhalb und außerhalb von evcc.

Damit stellt sich die Frage, welche Daten Metadaten und welche eigene Daten sind?

[panzerdev]

Der Metadatenansatz sollten wenn dann für alle Objekte sein und auch wieder mit rausgegeben werden für Anschlussverwendung innerhalb und außerhalb von evcc.

Damit stellt sich die Frage, welche Daten Metadaten und welche eigene Daten sind?

evcc muss doch da nicht opinionated sein. Ein einfaches Key Value System mit strings as keys und string als value sollte doch jeden anwendungsfall abedecken. in nen string kann ja ne zahl rein, oder auch ein json object zb.

[RobBboR]

Gerade wollte ich dieses Feature vorschlagen, als ich gesehen habe, dass es ja schon ein Issue dafür gibt.

Noch ein Aspekt, der bisher nicht erwähnt wurde:
Auf dem Smartphone gibt es keinen Tooltip, so dass man die Einzelwert dort nicht einsehen kann.

Bei meinen 2 Erzeugern (SolarEdge PV und OpenDTU Balkonkraftwerk) kennt evcc als einziges System alle interessanten Werte im Haus (zusammen mit SMA EV Charger). Es wäre super, wenn ich alle momentanen Werte an ein und derselben Stellen einsehen könnte, ohne zwischen verschiedenen Apps hin und her wechseln zu müssen.

[naltatis]

Auf dem Smartphone gibt es keinen Tooltip, so dass man die Einzelwert dort nicht einsehen kann.

Auf Touch-Geräten solllte der Tooltip "on click" funktionieren.