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...
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
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.
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 (https://www.eebus.org/), 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
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_cycledas 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 (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.
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
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 ...
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.
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.
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.
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)
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
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.
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.
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.
Zitat von: ch.eick am 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.
Das wäre dann ein Standard für die gesamte FHEM-Gemeinde und alle Modul-Entwickler. Das ist ein hehres Ziel. Kriegen wir das hin? Wir können den ersten Aufschlag machen. <Hoffnung>Wenn wir in Grafana ein paar schicke Standard-Panels anbieten mit drop-down-Auswahl des Devices (aufgrund der Namenskonventionen werden die per regex in entsprechende Variablen gefüllt), dann könnte das irgendwann zum Selbstläufer werden und andere (Modul-)Entwickler werden gefragt werden wieso den Standard nicht unterstützen.</Hoffnung>
Eine Frage ging mir noch durch den Kopf: Wieviele Wechselrichter hat der Durchschnittsbürger? Ich vermute einen. Dann bräuchte man kein Subdevice. Andererseits: Wenn es auch nur bei einer Device-Art Subdevices gibt sollte der Standard dafür eine Lösung bieten.
Bei dem Ansatz sehe ich im Augenblick gesplittete Namenskonventionen
- Für die Device-Namen, die Device und Subdevice berücksichtigen müssen (analog PV_Anlage_1, wobei mir "Anlage" zu wenig sprechend ist)
- für die Readings
Zitat von: plin am 17 Dezember 2020, 15:15:30
Das wäre dann ein Standard für die gesamte FHEM-Gemeinde und alle Modul-Entwickler. Das ist ein hehres Ziel. Kriegen wir das hin? Wir können den ersten Aufschlag machen. <Hoffnung>Wenn wir in Grafana ein paar schicke Standard-Panels anbieten mit drop-down-Auswahl des Devices (aufgrund der Namenskonventionen werden die per regex in entsprechende Variablen gefüllt), dann könnte das irgendwann zum Selbstläufer werden und andere (Modul-)Entwickler werden gefragt werden wieso den Standard nicht unterstützen.</Hoffnung>
Du kannst in jedem Device mit userreadings den Namensstandard dazu ergänzen, oder korrigieren.
Deshalb habe ich ja auch default devices verwendet, wie HTTPMOD, MODBUS, DOIF, DUMMY,.... mit denen kann man jetzt einfach einen anderen Namen für das gelesene reading verwenden.
Das spart die pflege intensive Zwischenschicht. Es würde im besten Fall zwei Templates geben, einmal die "Hersteller" und einmal die normierte Definition.
Da Ihr anscheinend ja auch nicht eine komplette Lösung anstrebt, bei der alle reading Namen normiert sind, bestehen in den Devices dann am besten beide Namen parallel.
Mit einem userreading und einem Trigger lässt sich der normierte Name zusätzlich erstellen.
<Normname>:Home_own_consumption_from_PV.* {ReadingsVal($name,"Home_own_consumption_from_PV","na")}
Zitat
Eine Frage ging mir noch durch den Kopf: Wieviele Wechselrichter hat der Durchschnittsbürger? Ich vermute einen. Dann bräuchte man kein Subdevice. Andererseits: Wenn es auch nur bei einer Device-Art Subdevices gibt sollte der Standard dafür eine Lösung bieten.
Geh besser von zwei aus. Ich bin auch schon in der Planung aufzurüsten. Erstens im Winter ist es zuwenig und zweitens es kommen immer mehr BEV dazu und da kann man zumindest im Sommer viel mit PV erreichen.
Zitat von: ch.eick am 17 Dezember 2020, 16:14:22
Du kannst in jedem Device mit userreadings den Namensstandard dazu ergänzen, oder korrigieren.
Ok, wenn wir den Ansatz verfolgen bedeutet das:
- Den Entwicklern von Modulen und Lösungen kommen wir nicht in die Quere.
- Die gerätespezifischen Readings können nach Bedarf durch den Entwickler festgelegt werden.
- Wir definieren aus der Sicht des Abnehmers (Statistiken, Grafiken, Auswertungen, ...) die Namenskonventionen.
- Die Namenskonventionen sollten im Zweifelsfalle den kompletten möglichen Namensraum berücksichtigen, auch wenn dieser für unsere Grafiken/Auswertungen nur teilweise benötigt wird.
- Grafana-Dashboards sollten dann auf Basis dieser Namenskonventionen so gestaltet werden, dass beim Import eines bereitgestellten Dashboards nur noch die Datenquelle benannt werden muss.
- Device-Namen werden in unseren Auswertungen/Dashboards in neutraler Form ausgewiesen, kein Bezug zu den FHEM-Devicenamen.
@gvzdus: Deckt das Deine Erwartungen an Namenskonventionen ab?
Annahme: Als Datenbank setzen wir auf MariaDB.
VG Peter
Zitat@gvzdus: Deckt das Deine Erwartungen an Namenskonventionen ab?
Sorry, die Family war über das WE fordernd...
Ja, die Zusatzlösung mit userreading ist m.E. völlig ausreichend, weil es auch nur um wenige Daten geht.
Bleibt aber noch die Frage nach der Konvention für Name und Reading. Wenn wir Device und Reading aufsplitten, könnte man ja sagen:
"solar" für Gesamt-PV, "solar_subdevice" für Unterdevices.
Beim Reading wäre ich sehr dafür, zumindest für "power" den Typ (AC/DC) oder die Richtung wegzulassen.
Zitat von: gvzdus am 21 Dezember 2020, 11:09:00
Ja, die Zusatzlösung mit userreading ist m.E. völlig ausreichend, weil es auch nur um wenige Daten geht.
Bleibt aber noch die Frage nach der Konvention für Name und Reading. Wenn wir Device und Reading aufsplitten, könnte man ja sagen:
"solar" für Gesamt-PV, "solar_subdevice" für Unterdevices.
Beim Reading wäre ich sehr dafür, zumindest für "power" den Typ (AC/DC) oder die Richtung wegzulassen.
ok, ich habe das mal durchgespielt. Wenn wir in der Kategorie Devices [grid|solar_nn|battery_nn|home|wallbox_nn|device_nn] benötigen, dann kann ich mit grid, solar, battery leben, aber wieso sollte ich irgendwelche Devices mit "home" benamsen. Im Reading-Namen wär das für mich ok. Selbst wenn ich dem Device via ALIAS einen anderen Namen geben kann, gefällt mir "home" nicht. device_nn könnte diese Wunde vermeiden.
Wenn ich den Ansatz verfolge alles in den Readings abzubilden, würde ich unser Mapping zumindest namentlich abgrenzen, z.B. mit einem Prefix "pv_". Was interessiert mich dann? [power|current|voltage|work|frequency|energy]. Untermengen davon sind für mich [active|reactive|apparent|yield|dc], folglich müssste dieser Teil unmittelbar folgen (active, reactive etc. impliziert ac, deshalb hier nicht mehr besonders erwähnt. Andernfalls müssten wir für dc festlegen, dass alle Werte z.B. "active" sind.). Danach würde ich das Device platzieren [grid|solar_nn|battery_nn|home|wallbox_nn|device_nn]. Die Frage ist dann, ob erst das Intervall und dann die Richtung oder umgekehrt folgen. Auf +/- würde ich verzeichten. Wenn wir mit RexExp arbeiten erfordert das ggf. immer Escapes. from/to müssten meiner Meinung nach reichen. Bei reinen Abnehmern kann dann from/to entfallen.
Das entspricht nicht mehr Christians Reihenfolge, wäre aber für mich eine eingängige Alternative. Strukturiert dargestellt also:
pv_
[power|current|voltage|work|frequency|energy]_
[active|reactive|apparent|yield|dc]_
[grid|solar_nn|battery_nn|home|wallbox_nn|device_nn]_
[actual|daily|weekly|monthly|yearly|total|max]_
[from|to]Der nächste Bitte ...
VG Peter
Zitat von: plin am 22 Dezember 2020, 10:47:51
ok, ich habe das mal durchgespielt. Wenn wir in der Kategorie Devices [grid|solar_nn|battery_nn|home|wallbox_nn|device_nn] benötigen, dann kann ich mit grid, solar, battery leben, aber wieso sollte ich irgendwelche Devices mit "home" benamsen. Im Reading-Namen wär das für mich ok. Selbst wenn ich dem Device via ALIAS einen anderen Namen geben kann, gefällt mir "home" nicht. device_nn könnte diese Wunde vermeiden.
Sorry, das war sicher ein copy/paste Fehler von mir.
Zitat
Wenn ich den Ansatz verfolge alles in den Readings abzubilden, würde ich unser Mapping zumindest namentlich abgrenzen, z.B. mit einem Prefix "pv_". Was interessiert mich dann? [power|current|voltage|work|frequency|energy]. Untermengen davon sind für mich [active|reactive|apparent|yield|dc], folglich müssste dieser Teil unmittelbar folgen (active, reactive etc. impliziert ac, deshalb hier nicht mehr besonders erwähnt. Andernfalls müssten wir für dc festlegen, dass alle Werte z.B. "active" sind.). Danach würde ich das Device platzieren [grid|solar_nn|battery_nn|home|wallbox_nn|device_nn]. Die Frage ist dann, ob erst das Intervall und dann die Richtung oder umgekehrt folgen. Auf +/- würde ich verzeichten. Wenn wir mit RexExp arbeiten erfordert das ggf. immer Escapes. from/to müssten meiner Meinung nach reichen. Bei reinen Abnehmern kann dann from/to entfallen.
Das entspricht nicht mehr Christians Reihenfolge, wäre aber für mich eine eingängige Alternative. Strukturiert dargestellt also:
from/to +/- wäre auch nur wahlweise im Namen. Im Value besser nicht.
Zitat
pv_
[power|current|voltage|work|frequency|energy]_
[active|reactive|apparent|yield|dc]_
[grid|solar_nn|battery_nn|home|wallbox_nn|device_nn]_ <<<< hier wäre ja das home überflüssig, wenn die Verbraucher (Devices) schon drin sind.
[actual|daily|weekly|monthly|yearly|total|max]_
[from|to] <<<< +/- wäre kürzer, aber nicht so sprechend.
Gruß
Christian
Zitat von: ch.eick am 22 Dezember 2020, 12:03:11
from/to +/- wäre auch nur wahlweise im Namen. Im Value besser nicht.
Genau um den Namen geht es mir. Ich habe mir in den letzten Tagen Grafana in Verbindung mit MySQL bzw. MariaDB angeschaut. Da gehen so Dinge wie
SELECT
UNIX_TIMESTAMP(TIMESTAMP) AS time_sec,
cast(VALUE as signed) as value,
READING AS metric
FROM history
WHERE
$__timeFilter(TIMESTAMP) AND
READING REGEXP '^.{5}$'
ORDER BY TIMESTAMPoder
SELECT
UNIX_TIMESTAMP(TIMESTAMP) AS time_sec,
cast(VALUE as signed) as value,
READING AS metric
FROM history
WHERE
$__timeFilter(TIMESTAMP) AND
READING REGEXP '.*ower.*'
ORDER BY TIMESTAMPoder
SELECT TIMESTAMP,VALUE,REGEXP_REPLACE(VALUE,'.*:','') as Energy
FROM `history`
WHERE `DEVICE` = 'Zoe' and `READING` = 'lastCharge'
order by TIMESTAMP desc;RegExp geht also in diversen Varianten auch auf die Namen..
Als 3 Mitspieler seid Ihr beiden (plin+ch.eik) Euch ja schon nahe... Da komme ich mir als Minderheit vor :-)
"home".
"Home" sollte in meiner Vorstellung der Gesamtverbrauch des Hauses sein. Ich mit meiner Konstellation nur wissend, was am Netzübergang rein bzw. rausgeht (der eine offizielle Zähler) plus was mein(e) Wechselrichter zu produzieren behaupten, muss diesen Wert errechnen.
Er interessiert mich aber natürlich besonders. Ich habe natürlich wie jeder anständige Shelly-Nutzer *einige* Verbraucher im Haus, die ich im Detail kenne. Aber die Gesamtsumme des Hausverbrauchs ist für mich eben "home" gewesen.
+/- oder in/out
Damit fremdele ich immer noch. Denn es ergibt m.E. nur bei Zählern Sinn, also für energy - nicht aber für power. Dafür hat der liebe Gott uns die positiven und negativen Zahlen geschenkt, um eine Richtung auszudrücken. Und genau so liefert sie auch der Netzzähler: plus für "Das Netz liefert Dir", minus für "Du speist ein".
Grollend, der Dritte.
MEIN Thread, kann ich Dich killen? Oder Deine Beiträge editieren und korrigieren? :-)
als ich die überschrift gelesen habe dachte ich: oh. der macht ja ein schönes fass auf. das hat schon bei x anläufen nicht funktioniert.
dann habe ich gesehen das es ,nur' :) um pov anlagen gehen soll. da stehen die chancen besser. für av-receiver und multimedia haben wir es ja fast hinbekommen.
die herausforderung ist und bleibt aber die alten vorhandenen devices auch umzustellen.
was aber vermutlich auch nicht einfach wird ist das alle unter einem begriff das gleiche verstehen und es dann auch noch zur anlage passt.
mein s10 pro hat z.b. solarertrag 1 und 2 für zwei stränge. die summe passt aber nie wirklich zum gesamtertrag. stimmt hier die doku nicht? ist es nur ein timing problem weil die werte nicht gleichzeitig ausgelesen werden? oder wird eigentlich etwas ganz anders ausgelesen? ...
ps: ,und genauso so liefert sie dir der netzzähler' stimmt nicht ganz. mein zweirichtungszähler liefert beides getrennt als 1.8.0 und 2.8.0 positiv und die richtung ist nur aus der legende ,zählwerk +a' bzw. zählwerk -a' zu erkennen.
allerdings finde ich +/- für bezug und erzeugung in fhem auch besser. allerdings gibt es die richtung nicht nur bei grid/home/solar sondern auch beim laden/entladen des akkus. und alle möglichen definitionen und kombinationen müssen sinnvoll zueinander passen.
für die darstellung im fronted ist das zusammenfassen jeweils zweier richtungen über das vorzeichen einfacher zu handhaben als das verteilen auf je ein reading pro richtung.
wie schaut es aus wenn man z.b den auto akku auch mit einbezieht. wie passen die richtungen dann?
Zitat von: gvzdus am 22 Dezember 2020, 18:32:27
Als 3 Mitspieler seid Ihr beiden (plin+ch.eik) Euch ja schon nahe... Da komme ich mir als Minderheit vor :-)
Sei nicht traurig. Ich habe ja auch mit einem von Christans erstem Vorschlag abweichenden Ansatz angefangen (siehe mein erstes Posting). Wenn man die Vorschläge einmal durchspielt kommen neue Ideen bzw. andere werden verworfen. Viele Meinungen sind hier hilfreich.
Zitat von: gvzdus am 22 Dezember 2020, 18:32:27
"home".
"Home" sollte in meiner Vorstellung der Gesamtverbrauch des Hauses sein.
Ich habe absolut kein problem mit "home". Mein Kostal Plenticore kann in Verbindung mit dem Kostal Smart Energy Meter die "home"-Werte beziffern. Ich muss nicht rechnen. Wenn Du rechnen musst kannst Du Dir z.B. ein Dummy-Device für die selbstermittelten Readings definieren. Das ändert nichts daran, dass es in den Namenskonventionen vorgesehen sein sollte.
Zitat von: gvzdus am 22 Dezember 2020, 18:32:27
+/- oder in/out
Damit fremdele ich immer noch. Denn es ergibt m.E. nur bei Zählern Sinn, also für energy - nicht aber für power. Dafür hat der liebe Gott uns die positiven und negativen Zahlen geschenkt, um eine Richtung auszudrücken. Und genau so liefert sie auch der Netzzähler: plus für "Das Netz liefert Dir", minus für "Du speist ein".
Ich bin immer noch kein Freund von +/-. Für mich sind from/to bzw. in/out sprechender.
@plin:
ZitatIch bin immer noch kein Freund von +/-. Für mich sind from/to bzw. in/out sprechender.
Nein, das ist natürlich der Beginn allen Übels! Gerade vor 3 Tagen wieder nach langer Zeit einen Wemos mit einem TTL-Lesekopf verbunden: Rx an Tx und umgekehrt, oder schon aus "Patientensicht gedacht?". Die Mediziner haben wenigstens eine Konvention: "Links" ist *immer* aus Patientensicht. Deswegen war ja schon mein allererster Vorschlag eine "Normierung", was positiv und was negativ ist. Aber macht Ihr mal.
@justme:
Wir beide sind auch über die Frage des normierten Modells für eine Farbbirne bei alexa stecken geblieben :-). "rgb", "hsv", "cmyk"? Und was ist beim Rollladen noch mal 100%? Oben oder unten? Etwa gefühlt 20% aller Support-Fälle... Ist ja auch völlig absurd, dass ein Rollladen, den ich zu 0% sehe, auf 100% sein soll.
das problem bei alexa und den anderen sprachassistenen ist: alexa kann nur hsv. wenn das mentale model oder das device nicht passen geht schnell was verloren.
das mit den rollläden ist nicht absurd. hell ist 100% wie bei einer lampe mit dimmer. dunkel ist 0%. ganz normal :).
wie man sieht ist immer das was man gewohnt ist normal :).
wie gut etwas passt sieht man ganz schnell wenn man versucht mit geschlossen augen per sprache zu bedienen oder sich von einem dritten alles vorlesen und beschreiben lässt. mit zu vielen impliziten annahmen geht das schnell schief.
Zitat von: gvzdus am 22 Dezember 2020, 19:16:19
MEIN Thread, kann ich Dich killen? Oder Deine Beiträge editieren und korrigieren? :-)
Soll ich noch etwas korrigieren oder raus nehmen?
Zitat von: gvzdus am 22 Dezember 2020, 21:35:35
+/-
@plin:Nein, das ist natürlich der Beginn allen Übels! Gerade vor 3 Tagen wieder nach langer Zeit einen Wemos mit einem TTL-Lesekopf verbunden: Rx an Tx und umgekehrt, oder schon aus "Patientensicht gedacht?". Die Mediziner haben wenigstens eine Konvention: "Links" ist *immer* aus Patientensicht. Deswegen war ja schon mein allererster Vorschlag eine "Normierung", was positiv und was negativ ist. Aber macht Ihr mal.
Aus Sicht von RegExp (siehe https://de.wikipedia.org/wiki/Regul%C3%A4rer_Ausdruck#Regul%C3%A4re_Ausdr%C3%BCcke_in_der_Praxis (https://de.wikipedia.org/wiki/Regul%C3%A4rer_Ausdruck#Regul%C3%A4re_Ausdr%C3%BCcke_in_der_Praxis)) gehören + und - zu den Metazeichen, deshalb würde ich die im Namen vermeiden. Ja, man kann alles escapen, aber lesbarer wird's ohne \.
eine bitte bzw. vorschlag: könnt ihr sobald sich ein konsens abzeichnet das ganze im wiki dokumentieren. so ähnlich wie für die av geräte hier: https://wiki.fhem.de/wiki/DevelopmentGuidelinesAV
das macht es nicht nur einfacher den aktuellen stand zu sehen sondern später auch zu dokumentieren welche module schon welchen teil unterstützen
Hallo,
vielleicht könnte man sich an die Definition von SunSpec zumindestens bei Solar und Batterie anlehnen ;-). Einige Hersteller unterstützen ja dieses Protokoll und da ist dann die Zuordnung vielleicht etwas leichter. Man braucht da ja nichts neues erfinden.
pejonp
Zitat von: pejonp am 05 Januar 2021, 22:51:39
vielleicht könnte man sich an die Definition von SunSpec zumindestens bei Solar und Batterie anlehnen ;-). Einige Hersteller unterstützen ja dieses Protokoll und da ist dann die Zuordnung vielleicht etwas leichter. Man brächet da ja nichts neues erfinden.
Ich werfe dann mal eebus mit ins Rennen, da habe ich jedoch noch nichts passendes gefunden.