Frevel: Die Idee einheitlicher Devicenamen und Readings

Begonnen von gvzdus, 15 Dezember 2020, 18:12:17

Vorheriges Thema - Nächstes Thema

gvzdus

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:

  powergrid + powersolar + (powerbattery) = powerhome ( + powerwallbox)

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







RolleFHEM-Name
Haushaltszählergrid
solarer Wechselrichtersolar
Batteriespeicherbattery
Heimischer Verbrauch ohne Wallbox (falls getrennt erfassbar)home
Wallboxwallbox (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:



ReadingBeschreibung
powerAktueller 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

Hey, ich hatte ja versprochen hier mit zu machen :D

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:

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.

[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


RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

gvzdus

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

#3
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 :D
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 :D
Beispiel: "MinHomeConsumtion" (Typo, btw.)
Und hier direkt aus der API von Kostal

                        {   '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
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

plin

#4
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.

FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

ch.eick

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

[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
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

plin

Zitat von: ch.eick am 16 Dezember 2020, 10:18:06

[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 ...
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

ch.eick

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.
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

plin

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.
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

gvzdus

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 /)

Plin:
device_subdevice_measurement_direction_cycle

cheick:
[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|+|-]

Mein Senf:
@Christian: Das ist mir "a little bit too much". Erstmal: Wichtig (für den Leser) steht am Anfang oder am Ende. Also entweder ist das Device vorne oder das "Reading" wie "power". Meine Tendenz geht zum Device vorne. Für "power" vorne spräche, dass, wenn die Daten synchron ausgelesen werden, sie als Tupel gespeichert werden können. Gilt natürlich auch für die verschiedenen Readings eines Devices - nur sind m.E. nicht so viele Readings für die Interaktion interessant.

Ich denke aber, vor allem ist "schlank" wichtig. Ich möchte nicht die ganze Welt in einen Namensraum pressen. Ich halte für miteinander interagierende Systeme für *verzichtbar*:

  • 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

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

#11
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
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

gvzdus

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

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.
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

ch.eick

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.
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick