Frevel: Die Idee einheitlicher Devicenamen und Readings

[plin]

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

[ch.eick]

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.

Code Auswählen Erweitern


<Normname>:Home_own_consumption_from_PV.* {ReadingsVal($name,"Home_own_consumption_from_PV","na")}


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.

[plin]

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

[gvzdus]

@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.

[plin]

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:

Code Auswählen Erweitern

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

[ch.eick]

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.

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.

Code Auswählen Erweitern


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

[plin]

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

Code Auswählen Erweitern

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 TIMESTAMP

oder

Code Auswählen Erweitern

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 TIMESTAMP

oder

Code Auswählen Erweitern

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

[gvzdus]

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.

[gvzdus]

MEIN Thread, kann ich Dich killen? Oder Deine Beiträge editieren und korrigieren?

[justme1968]

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?

[plin]

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.

"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.

+/- 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.

[gvzdus]

@plin:

Ich 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.

[justme1968]

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.

[ch.eick]

MEIN Thread, kann ich Dich killen? Oder Deine Beiträge editieren und korrigieren?

Soll ich noch etwas korrigieren oder raus nehmen?

[plin]

+/-
@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) gehören + und - zu den Metazeichen, deshalb würde ich die im Namen vermeiden. Ja, man kann alles escapen, aber lesbarer wird's ohne \.