Frevel: Die Idee einheitlicher Devicenamen und Readings

gvzdus · 15 Dezember 2020, 18:12:17

Ich leite mal humorvoll ein: Schimpft mich gerne völlig falsch hier im Forum, weil ich das Wesen von FHEM völlig verkannt habe: Jede FHEM-Installation muss so einzigartig wie wir selbst sein! Selbst, wenn man nur Code-Blöcke als Anfänger eingibt: Die Transferleistung, zu erkennen, wo es "genau so" heissen muss, weil es ein Modulname oder ein Befehl ist, versus "hier darfst Du Dir einen Namen" aussuchen, ist der erste Beweis einsetzender Erkenntnis! 100%-Zustimmung? Dann besser jetzt nicht weiterlesen...

Ich habe mich von meiner Aktivseite her ja mit justme zusammen bei FHEMConnector ausgetobt. Ehrlich gesagt: Es hat seinen Charme, den Leuten "set alexa restart" zu sagen, statt "set <hier-dein-alexaDevice-Name> restart". Wo es aber m.E. den Austausch klar behindert, ist beim Thema EnergieManagement oder auch nur -Visualisierung.
Das Thema hat 3 Aspekte:

Datenerfassung: Auslesen von Wechselrichter, Netzübergang, ggf. Batterie und Wallbox
Visualisierung und Reporting
Steuerung von Verbrauchern

Und meine Vorstellung ist, dass es überwiegend Vorteile hätte, zwischen 1. und 2. / 3. eine Schicht vereinheitlichter Namen zu verwenden. Denn damit könnten wir - vom Grafana-Template bis zu Modulen - Konfigurationen und Code austauschen. Es würde auch das Lese-Verständnis von Beispielen erhöhen, hieße z.B. der Wechselrichter nicht mal Kostal1 oder SMA, sondern "solar".

Mein Vorschlag ist, in diesem Thread - nennen wir ihn den Frevel-Thread - einheitliche Namen zu diskutieren und in einer Wiki-Seite zu dokumentieren.

Ich fange mal mit ein paar Gedanken an: Um keine verdrehte Vorzeichenlogik zu haben, sieht ein Haushalt so aus:

power_grid + power_solar + (power_battery) = power_home ( + power_wallbox)

Damit habe ich auch schon die ersten "Device-Namen" vorgeschlagen:

Rolle	FHEM-Name
Haushaltszähler	grid
solarer Wechselrichter	solar
Batteriespeicher	battery
Heimischer Verbrauch ohne Wallbox (falls getrennt erfassbar)	home
Wallbox	wallbox (oder vehicle?)

Begründung: So viel Englisch können wir wohl alle. Und wir reden von "Grid2Vehicle", "Vehicle2Home" u.s.w.
Haben wir mehrere Solaranlagen, heissen sie solar1 und solar2 oder wie auch immer, aber dann füttern wir per notify o.ä. das "solar"-Device.

1. Vorschlag zu den Readings:

Reading	Beschreibung
power	Aktueller Wert ohne Mittelung o.ä., stets in Watt ohne Einheit angegeben

Selbst, wenn sich helle Begeisterung über diese Vorschläge regen sollte: Beim nächsten Punkt bin ich mir schon unsicher: Es ist sinnvoll, ein festes Intervall zu haben. Z.B. 1 Minute oder 5 Minuten. Denn z.B. meinen Wechselrichter lese ich alle 30 Sekunden aus, andere vielleicht minütlich. Daneben habe ich aber z.B. den Hauszähler mit quasisekündlichen Werten. Bestimme ich nun im System aus "home", "grid" und "solar" den Wert für "home" aus "solar"+"grid", so kann der Wert temporär sogar negativ sein, wenn die Sonne frisch hinter der Wolke hervorkommt.
Sollte man für das Festintervall eher ein "solar_1min.power" definieren, oder "solar.power_1min"?

Ich mache hier erst einmal Pause...

ch.eick · 15 Dezember 2020, 19:05:09

Hey, ich hatte ja versprochen hier mit zu machen

Mein WR heißt PV_Anlage_1 im Fhem, im Melderegister, im der GbR beim Finanzamt.
Was ist mir dem Speicher, wenn er im Hausnetz ist oder hinter dem WR im DC Bereich? Bei mir ist er zweimal abzufragen, einmal direkt und einmal über den WR.
Muss ich dann die readings in einem Device zusammenfassen, oder gehören sie zu dem jeweiligen?
Die Verbraucher lassen sich leider auch nicht sooo schön in der DbLog abfragen, ein PV_* vor dem Namen könnte das schon beheben und auch dort sollten die readings dann zB mit power vereinheitlicht werden.
Allerdings sollte die Device definition schon besser sehr nah am Hersteller sein, da man ansonsten dort Verständnisprobleme bekommt.

In meiner Implementierung habe ich schon mal versucht die zusammenhängenden Devices darzustellen:

Code Auswählen


11.2 	Beispiel Pool
11.2.1	Pool_Softube (dummy Modul)
11.2.2	Pool_PV (DOIF Modul)
11.2.3	Pool_Signale (Shelly Modul: shelly1pm)
11.2.4	Pool_Counter (HourCounter Modul)
11.2.5	Pool_Status (readingsGroup Modul)

Leider tauchen diese Devices aber auch in mehreren Gruppen im FhemWeb auf und dort passen dann die Namen doch wieder nicht zusammen

Nun aber wieder zurück zum Thema. Meine erste frage wäre, an welcher Stelle sollte man diese Abstraktionsebene einfügen, um möglichst wenig Mehraufwand zu haben?
Im Normalfall kopiere ich aus der Herstellerdokumentation eine Tabelle mit Namen in den Editor meiner Wahl und erstelle mir daraus die RAW Befehle.
Auch ich weiche von den Herstellerangaben ab und versuche eine Gruppierung der readings schon im Namen zu bekommen, was jedoch für andere Anwender schon für zu lange reading Namen führt.

Dann kommen noch diese groß und klein Buchstaben, die im Englischen etwas weniger vorkommen, um aber _ zuvermeiden dann wieder doch sehr beliebt sind

In Deinem Beispiel lässt sich die Benamsung sehr schön lesen, aber ein runtergesetzter Zeichensatz ist technisch nicht implementiert

, da finde ich den _ besser.

power_grid + power_solar + (power_battery) = power_home ( + power_wallbox)

Ich habe hier mal begonnen die readings des Kostal Plenticore zu analysieren.

Code Auswählen


[active|reactive|apparent|yield]_[power|current|voltage|work|frequency|energy]_[ac|dc]_[grid|solar_nn|battery_nn|home|wallbox_nn|device_nn]_[actual|daily|weekly|monthly|yearly|total|max]_[from|to|+|-]

Hierbei ist device_nn z.B.
Wärmepumpe
Waschmaschine
Spülmaschine
Trockner
Spülmaschine
Wirlpool
Pool
diverse Accu Ladesteckdosen

Dabei fehlen natürlich noch komplett die Gerätespezifischen Daten, wie Name, Seriennummer, Schuhgröße, IP-Adresse,... die man besser noch in Gruppen zusammenfasst, damit man sie zusammen anlisten kann.

Wir haben also einiges an Arbeit vor uns.

Viele Grüße
Christian

gvzdus · 15 Dezember 2020, 22:06:08

Moin Christian,

Lass' uns einfach mal vorstellen, der eine von uns liefert Daten über sein System, der andere visualisiert. Weil Du z.B. Deine Lösung als fertiges AMI-Image bei Amazon zur Verfügung stellst und sagst: "Schnapp Dir das Image, ziehe eine Instanz hoch und feede MQTT rein. Du kriegst: Geile Graphiken, die weltbeste Prognosemaschine für Solarertrag - whatever". Nur rein fiktiv. Unsere Verbindung sei MQTT.

ZitatMein WR heißt PV_Anlage_1 im Fhem, im Melderegister, im der GbR beim Finanzamt.

Und in meinem MQTT-Feed muss ich mich hiervon trennen. Vorschlag: "solar/power" für Solarertrag.

ZitatWas ist mir dem Speicher, wenn er im Hausnetz ist oder hinter dem WR im DC Bereich? Bei mir ist er zweimal abzufragen, einmal direkt und einmal über den WR.

Die Verluste bei AC/DC sind selbstverständlich als Hausheizung beabsichtigt und werden dem Hausbereich zugeschlagen

Nach meinem Vorschlag wäre "battery/power" positiv, falls Energie geliefert wird (Du betreibst ihn ja zu diesem Zweck, nicht zum Laden). Wenn die Steuerung z.B. DC-seitig 300 Watt aus der Batterie liefert, um am Netzübergang auf 0 zu kommen, mögen nur 260 Watt im Haus genutzt werden, das Haus verbraucht aber insgesamt 300 Watt.

Bleiben wir beim "Du visualisierst, ich bin das FHEM eines Hilflosen". Lass' uns die Batterie zunächst weglassen - habe ich ohnehin nicht. Mit "solar/power" und "grid/power" könntest Du mir schon hübsche Graphen aufbereiten, und Tages-, Jahresreports erstellen. Ich würde noch vorschlagen, "solar/energy_in" und "grid/energy_in" plus "grid/energy_out" zu definieren. Das sind Zählerstände in Wh, die - sagen wir - mindestens stündlich kommen müssen, besser 5-minütlich. "in" ist "Plus", "out" ist "Minus" (grid/energy_out also "Wattstunden eingespeist"). Während "power"-Werte halt für Reports eher schwierig sind, stammen die "energy"-Werte aus den Zählern in den Wechselrichtern / Haushaltszähler. Richtig genau nimmt man es ja vor allem bei der Einspeisevergütung.

Das ist aber doch jetzt noch ein relativ übersichtlicher Namensraum

Du bist mir um LWP und Batterie voraus. Und um die HighTech-Walzen-Waschmaschine - wo gibt es so was außer bei Manufaktum? Ich bin Dir ab Februar wohl um ein BEV voraus.

Wir könnten jetzt noch das definieren, was Du so umfassend strukturiert als Variablen abgelegt hast - aber das in nicht so spannend: Modulausrichtungen u.s.w. Schön gemacht!

Aber bei der Gelegenheit auch Kritik an Deiner Kostal-Wiki-Seite, die ich top-down durchgelesen habe. Ich verliere den Überblick. Und ich verstehe schon in Deinem Text nicht mehr, was eine Variable bei Dir bedeutet. Beispiel: "MinHomeConsumtion" (Typo, btw.) Wenn mich jemand fragt, was das heißt? Das ist natürlich der niedrigste (Standby-)Verbrauch eines Haushalts, wenn gerade alle Schaltverbraucher (Kühlschrank etc.) Pause haben. Ich bin 50, also *eigentlich* nicht die Youtube-Generation. Trotzdem: Die Seite könnte etwas mehr in die Richtung "Ich bin Christian, und ich zeige Euch in diesem Video meine Haussteuerung. (Likebetteln). Alle Konfigurationen für Bämm-FHEM könnt Ihr Euch unten unter diesem Video runterladen. Aber erst mal, was ich mache. <Vorstellung, was Du eigentlich damit machst>. (Abobetteln)."

Gut, ich schweife ab. Lass uns bei den "MQTT-Topics" bleiben.

ch.eick · 15 Dezember 2020, 23:40:07

Zitat von: gvzdus am 15 Dezember 2020, 22:06:08
Aber bei der Gelegenheit auch Kritik an Deiner Kostal-Wiki-Seite, die ich top-down durchgelesen habe. Ich verliere den Überblick. Und ich verstehe schon in Deinem Text nicht mehr, was eine Variable bei Dir bedeutet. Beispiel: "MinHomeConsumtion" (Typo, btw.) Wenn mich jemand fragt, was das heißt? Das ist natürlich der niedrigste (Standby-)Verbrauch eines Haushalts, wenn gerade alle Schaltverbraucher (Kühlschrank etc.) Pause haben. Ich bin 50, also *eigentlich* nicht die Youtube-Generation. Trotzdem: Die Seite könnte etwas mehr in die Richtung "Ich bin Christian, und ich zeige Euch in diesem Video meine Haussteuerung. (Likebetteln). Alle Konfigurationen für Bämm-FHEM könnt Ihr Euch unten unter diesem Video runterladen. Aber erst mal, was ich mache. <Vorstellung, was Du eigentlich damit machst>. (Abobetteln)."

Okay, das nur zu Grundlage...
Wenn ich ehrlich bin, habe ich dort einfach angefangen meine Dokumentation zu schreiben, als ich den Überblick verloren habe

Ich werde keine Streaming Kanal aufmachen und stehe über Likes und Abos

Der Aufbau der Wiki ist von oben nach unten in den Dingen, wie man sie einrichten sollte.
Und die Namen kommen halt vom Hersteller, das ist das was ich vorhin bereits geschrieben hatte.

Und jetzt weiter...
Ich verstehe sehr gut was Du als Gedanke umsetzen möchtest und da bedarf es einer Schnittstellen Definition mit genormten Feldern, damit man von beliebigen Quellen
mit beliebigen Zielen Kommunizieren kann und darüber die fakten austauscht. Schau mal hier eebus, das sieht vielversprechend aus und
wenn die Hersteller auch mit machen, dann wird das auch was. Ich habe gerade gesehen Kostal macht da auch mit

Um die Kurve zu bekommen wäre Deine Datenaufbereitung mit Diagrammen und Prognosen auch ein Gerät, das standardisiert und normiert die Daten erhält. Wo das
dann verwendet wird wäre total unabhängig. Ich schenke mir die Schlagworte, die ich bei meinem Arbeitgeber, einem der Welt größten IT Unternehmen, täglich zu hören bekomme

Ob man nun die Daten mit MQTT durch die Gegend schicken muss weiß ich nicht so wirklich. Eine Datenbank mit einem gescheiten Datenmodel sollte es auch tun, das kann
auch in der Cloud sein, jedoch bevorzuge ich es doch eher lokal bei mir.
Wenn ich die mega Änderungen bei SMA und Kostal so beobachte, dann weiß man sowieso nicht wie lange diese Firmen noch existieren werden, oder wer sie als nächstes kaufen
wird. Danach kommt wieder eine totale Umstellung oder der Service ist einfach weg und wird durch einen anderen kostenpflichtigen ersetzt. Mist schon wieder vom Thema weg.

Ich schmeiß mich weg, dat nen ich mal nah am Hersteller

Beispiel: "MinHomeConsumtion" (Typo, btw.)
Und hier direkt aus der API von Kostal

Code Auswählen


                        {   'access': 'readwrite',
                            'default': None,
                            'id': 'Battery:MinHomeComsumption',
                            'max': None,
                            'min': '50.0',
                            'type': 'double',
                            'unit': 'W'},

Aber das werde ich natürlich korrigieren, also falsch auslesen und richtig schreiben. Danke für den Hinweis, das zieht sich jetzt bis in die Datenbank hinein.
EDIT: Glück gehabt, es war doch nur in den Devices zu korrigieren und lief nicht in die Datenbank.

Viele Grüße
Christian

plin · 16 Dezember 2020, 07:36:46

Hi,

ich stoße jetzt auch mal dazu. Ich besitze einen Kostal Plenticore, Kostal Smart Energy Meter und als Großabnehmer eine Zoe. Eventuell kommen später Klimaanlagen dazu. Ich habe Christians Wiki-Definitionen 1:1 übernommen, bin aber auch nicht 100% glücklich und baue mir (als Lernkurve und um die eigenen Gedanken zu sortieren) eine Parallelwelt in eigenen Datenbanktabellen. Seit einiger Zeit nutze ich das alte InfluxDB-Modul, um meine Zeitreihen dann in Grafana zu visualisieren. Mittlerweile auch DbLog und eigene Tabellen.

Der erste (schnelle) Gedanke am Morgen ist folgende hierarchische Struktur:

device_subdevice_measurement_direction_cycle

das könnte dann z.B. sein:

solar_pv1_power_out_1min
grid_phase1_power_in_1min
grid_total_power_in_1min

Ich habe mir das ganze noch nicht in ruhe durch den Kopf gehen lassen, ist aber das was mein Gehirn spontabn ausgespuckt hat.

VG Peter

P.S. Wenn was draus werden sollte können wir gerne die von mr angefangene Seite https://wiki.fhem.de/wiki/Solar-/PV-%C3%9Cbersicht zur Beschreibung des Standards nutzen.

P.P.S. Wie gehen wir mit home-from-grid und home-from PV um? Da home keine Leistung generiert, also alles "in" ist, könnte man die "direction" dafür verwenden. Z.B. "fromgrid", "frompv". Ansonsten müsste es ein Level davor sein, z.B. device_subdevice_source_measurement_direction_cycle. subdevice geht aus meiner Sicht nicht, weil wir dies dann nicht mehr für unsere Großabnehmer wie "Waschmaschine" nutzen können.

ch.eick · 16 Dezember 2020, 10:18:06

Hallo Peter,
Ich hatte hier bereits mit der Zusammenfassung bestehender Möglichkeiten begonnen.

Code Auswählen


[active|reactive|apparent|yield]_[power|current|voltage|work|frequency|energy]_[ac|dc]_[grid|solar_nn|battery_nn|home|wallbox_nn|device_nn]_[actual|daily|weekly|monthly|yearly|total|max]_[from|to|+|-]

Hierbei ist device_nn z.B.
Wärmepumpe
Waschmaschine
Spülmaschine
Trockner
Spülmaschine
Wirlpool
Pool
diverse Accu Ladesteckdosen

plin · 16 Dezember 2020, 16:39:46

Zitat von: ch.eick am 16 Dezember 2020, 10:18:06
Code Auswählen Erweitern
[active|reactive|apparent|yield]_[power|current|voltage|work|frequency|energy]_[ac|dc]_[grid|solar_nn|battery_nn|home|wallbox_nn|device_nn]_[actual|daily|weekly|monthly|yearly|total|max]_[from|to|+|-]

Wenn die in einem Dummy-Device als Metaebene gesammelt werden wird das aus Device-Sicht unübersichtlich (weil alle Messwerte querbeet verteilt sind) und aus Messwert-Sicht schön sauber strukturiert.

Mal abwarten welche Meinungen hier so eintrudeln ...

ch.eick · 16 Dezember 2020, 18:27:25

Zitat von: plin am 16 Dezember 2020, 16:39:46
Wenn die in einem Dummy-Device als Metaebene gesammelt werden wird das aus Device-Sicht unübersichtlich (weil alle Messwerte querbeet verteilt sind) und aus Messwert-Sicht schön sauber strukturiert.

Also so, wie es jetzt auch ist

und wir haben noch nicht mal einen anderen Hersteller mit drin.

Eventuell lohnt ein Blick zur solaranzeige.de , denn dort werden bereits eine Vielzahl verschiedener Geräte unterstützt und es lohnt nicht in Fhem Konkurrenz auf zu bauen.
Meine Implementierung zielt mehr auf die Steuerung mit etwas Darstellung drum rum und bei der Solaranzeige würde ich es eher andersherum sehen.

plin · 16 Dezember 2020, 20:18:25

Ja, die Kernfrage ist: Was will ich sehen bzw. was brauche ich. Eventuell noch die Usability in Grafana (der trennschärfste Begriff kommt ganz vorne, z.B. power [sprich Metrik]) oder die Verwendung in ReadingsGroups (macht das jemand???).

Mein Gehirn denkt eher hierarschich, daher der Wurf von heute Morgen. Alles schön geclustert und strukturiert runtergebrochen. Bedeutet aber ich muss ggf. immer den Device-Namen, den SUb-Device-Namen eingeben bevor es spannend wird.

gvzdus · 16 Dezember 2020, 20:33:49

Moin, ich mache mal eine Zwischenrunde plus meinem Senf:

Der Konsens:

lowercase
Englisch, zumindest bei Allgemeinbegriffen wie "grid", "home"
Im FHEM-Namensraum "_" als Separator (bei MQTT mutmaßlich /)

Die Differenzierung active|reactive|apparent|yield - die werfen viele Geräte eh nicht raus
ac / dc
die Richtung. Die ergibt sich bei power aus dem Vorzeichen. Bei "energy" ist sie hingegen wichtig. Daher "energy-in" und "energy-out" (- statt _)
Das Intervall

Warum kein Intervall? Ich würde zu absoluten Zählerständen bei "energy" neigen. Dann sind Pausen wegen ... keine Lücken, sondern Ungenauigkeiten.

Bei "solaranzeige.de" vorbeischauen finde ich sinnvoll. Hab's noch immer nicht installiert, aber man sollte ja auf den Demo-Seiten die Bezeichnungen der Messwerte sehen können. Ich könnte mir allerdings vorstellen, dass da auch eher chaotisch vorgegangen wurde, weil ja alles aus einer Hand kommt.

Soweit mein Feedback.

gvzdus · 16 Dezember 2020, 20:37:08

So, den letzten Beitrag von plin hatte ich nicht berücksichtigt (Pech des langen Textes). "plins" Schema finde ich gut. Was ist bei nur einem Gerät? "totel" war wohl ein Tippfehler. Vorschläge:

solar_all_...
solar_total_...
solar__... (2 Unterstriche = no subdevice)

plin · 16 Dezember 2020, 21:13:10

Zitat von: gvzdus am 16 Dezember 2020, 20:33:49
Warum kein Intervall? Ich würde zu absoluten Zählerständen bei "energy" neigen. Dann sind Pausen wegen ... keine Lücken, sondern Ungenauigkeiten.

Für den Grafana-Einsteiger ist es einfacher energy-pro-Intervall direkt verfügbar zu haben, als über SQL-Statement in Grafana die Differenz (Intervall-Ende - Interval-Anfang) zu bilden.

Zitat von: gvzdus am 16 Dezember 2020, 20:33:49
Was ist bei nur einem Gerät?
solar__... (2 Unterstriche = no subdevice)

"__" verwirrt die Leute. Die denken dann sie hätten sich vertippt. "1" ist die eine klarere Ansage.

Zitat von: gvzdus am 16 Dezember 2020, 20:33:49
"totel" war wohl ein Tippfehler.

War wohl zu früh. Obwohl: phonetisch ist es etwas weniger falsch

.

P.S. Differenzierungen wie AC/DC etc. werden wir nicht los. Wenn wir einen übergreifenden Standard definieren wollen müssen wir dafür einen Platz vorsehen. Vermutlich irgendwo in der Mitte.

P.P.S. [active|reactive|apparent] sehe ich in der Gegend von sub-measurement

gvzdus · 16 Dezember 2020, 21:20:27

Zu Intervall:
Friedensangebot: Hinten beginnt der Gedöns-Teil. Für Wirkleistung, für Intervall, für m/w/d

Zu "__" vs. "_total_" vs. "_all_". Die Frage war: Vielleicht haben diverse Menschen mehrere Solaranlagen. Viele aber nur einen Haushaltszähler, eine Solaranlage, eine Batterie, eine Wallbox.
Nehmen wir den Visualisierungs-Usecase: Eine Cloud-GUI (fiktives Beispiel) guckt, was Du an Daten reingeschoben hast. Bei "solar_.*_power.*" wird sie wuschig und weiß, was sie damit anfangen kann. Ist sind da 5 Werte, bietet sie Dir ein Pulldown, welcher Wert es nun sein soll. Mein Default wäre aber: "Die Gesamtsumme". Also Dein "_total_". Deswegen finde ich den Wert "Summe über die Devices" (oder ein Einzelnes) besonders wichtig.

plin · 16 Dezember 2020, 22:28:09

Mmhh, was kommt denn nach der Festlegung der standardisierten Metaebene? Lösungen, Programme, Coding, Visualisierung. Dann wird sich der total-Wert aus der Summe der Einzelwerte 1...n bilden. Die Lösungen die dazu führen sollte der Anwender per cut&paste übernehmen können. Dann schießen wir denen mit unseren Programmen das total-Reading kaputt, wenn es keine 1...n gibt.

ch.eick · 17 Dezember 2020, 11:06:58

Moin,

ich sehe diese Namensänderungen direkt im Device, das mit dem Gerät kommuniziert.
Dort sollte entweder direkt der richtige/gewünschte Name gesetzt werden.
Fehlende Werte sollten auch hier mir userreadings erzeugt werden.

Somit wird es für jedes Gerät, das der Anwender verwendet eine "genormte" Version geben, die dann von den Werten weiterverarbeitet werden kann.
Jeder WR, der eingebunden wird hat somit die selben readings und unterscheidet sich nur im Device Namen. Es können natürlich auch noch weitere readings im
Device vorhanden sein, die halt noch nicht normiert sind.