Hallo zusammen,
vor einiger Zeit gab es ja bereits einmal eine Diskussion zum Thema Readings mit Einheiten zur Interpretation oder nicht. Vor kurzem habe ich von HomeMatic den neuen Schaltaktor inkl. Leistungsmessung erworben. Bei diesem Gerät gibt es mehrere Readings mit Zahlenwerten und unterschiedlichen Einheiten. Für mich daher ein Paradebeispiel für die Tatsache, dass meiner Meinung nach so etwas langsam her muss:
siehe dazu das angehangene Bild "Ist-Zustand".
Daher habe ich mich einfach mal an den Versuch gemacht folgendes zu implementieren:
- Die Funktion readingsBulkUpdate bekommt einen weiteren optionalen Parameter $unit => readingsBulkUpdate($hash, $reading, $value, $changed, $unit)
Die Einheit welche dort in Form eines Strings übergeben wird, wird in $hash->{READINGS}{reading}{UNIT} gespeichert.
(analog dazu wurden die Funktionen setReadingsVal und readingsSingleUpdate entsprechend angepasst)
- Die Einheit wird nicht im Eventstring mitgefeuert (notifys)
- Beim Aufruf von ReadingsVal kann mit einem optionalen Parameter (0/undef oder 1) die Einheit mit ausgegeben werden => ReadingsVal($devicename,$readingname,$default,$with_unit)
- mit der neuen Funktion ReadingsUnit kann man die Einheit eines Readings explizit abfragen => ReadingsUnit($devicename,$readingname,$default,$with_unit)
- FHEMWEB zeigt als Frontend die Units mit an, sofern sie gesetzt sind (evtl. sollte man irgendwie durch Formatierung erkennbar machen, dass die Einheit nicht Bestandteil des eigentlichen Wertes ist.
Zum Ausprobieren habe ich bei einem meinem Modul YAMAHA_AVR testweise angewandt und habe die beiden Volume-Readings mit Einheiten ausgestattet. Siehe dazu das Bild "Soll-Zustand".
Ein Aufruf von
{ReadingsVal("AV_Receiver","volume","")} liefert nachwievor "28" zurück.
Mit optionalem $with_unit Flag:
{ReadingsVal("AV_Receiver","volume","", 1)} liefert es "28 %" zurück.
Um dies auch mit dem list-Befehl zu verdeutlichen musste dieser ebenfalls angepasst werden um die Einheiten auszugeben.:
Readings:
2014-01-02 22:36:29 input airplay
2014-01-02 22:36:29 inputName AirPlay
2014-01-02 22:36:29 mute off
2014-01-02 22:36:29 power on
2014-01-02 22:05:46 presence present
2014-01-02 22:36:29 state on
2014-01-02 22:36:29 volume 28 %
2014-01-02 22:36:29 volumeStraight -53 dB
Sie sind nun in einer separaten Spalte aufgelistet und daher nicht Bestandteil des eigentlich Wertes.
Für mich persönlich währe das eine angenehme Lösung um sowohl die Einheiten in der GUI abzubilden aber dennoch keine Probleme bei Notify-Regexp und ständigem Ersetzen der Werte bei ReadingsVal().
Im Anhang findet ihr die Änderungen als Diff-File. Die Änderungen sind nicht komplett wirklich an allen relevanten Funktionen durchgeführt worden. Ich habe mich vorerst nur auf das Szenario "Modul erzeugt Readings mit und ohne Einheiten" beschränkt.
Ich möchte euch daher diesen Vorschlag einmal darlegen und fragen, was eure Meinung dazu ist?
Viele Grüße
Markus
Hallo,
ich bin solange gegen solche Lösungen bis jemand substantiell neue Argumente ins Feld führt, um die Einheitenfrage über Interfaces zu lösen zu überdenken.
Siehe geschlossene Gruppe fhem-developers für den damaligen Diskurs und Wiki für den Mehrheitsvorschlag.
Viele Grüße
Boris
Die Einheit kann Teil eines Events sein, der Benutzer kann auch leicht nur auf den Wert zugreifen. Wenn nicht, dann sollte das optimiert werden. In 99% der Faelle ist es klar, was das fuer eine Einheit ist, und wenn nicht, dann soll es in der Doku erwaehnt sein. Meiner Ansicht nach ist der Gewinn nahe Null.
Auf der anderen Seite stehen kompliziertere Funktionen und Datenstrukturen, Leute, die zwanghaft versuchen
irgendwelchen Zahlen eine Einheit zuzuordnen, und der Aufwand, moeglichst alle Frontends und Module anzupassen.
-> Ich bin dagegen
Zitat von: rudolfkoenig am 02 Januar 2014, 22:57:22
In 99% der Faelle ist es klar, was das fuer eine Einheit ist, und wenn nicht, dann soll es in der Doku erwaehnt sein. Meiner Ansicht nach ist der Gewinn nahe Null.
In vielen Fällen mag es durchaus direkt ersichtlich sein in welcher Einheit ein Reading angegeben ist. Aber angesichts der Tatsache, dass FHEM nicht nur von Programmierern und Bastlern verwendet wird, sondern auch von Quereinsteigern genutzt wird, welche sich durchaus öfters die Frage stellen werden, was diese ganzen Zahlenwerte da zu bedeuten haben? Natürlich kann man dann immer in der Doku nachblättern, aber ob das den Spaßfaktor wirklich hebt ist eine andere Frage.
Ein Frontend hat ja die Aufgabe Daten zu visualisieren und meiner Meinung gehören da auch Einheiten zur Interpretation hin, natürlich nur dann, wenn es sinnvoll ist. Jedem Wert eine Einheit zu verpassen funktioniert nicht.
Zitat
Auf der anderen Seite stehen kompliziertere Funktionen und Datenstrukturen, Leute, die zwanghaft versuchen
irgendwelchen Zahlen eine Einheit zuzuordnen, und der Aufwand, moeglichst alle Frontends und Module anzupassen.
-> Ich bin dagegen
Kompliziertere Funktionen und Datenstrukturen: Stimm ich dir zu.
Leute, die zwanghaft versuchen irgendwelchen Zahlen eine Einheit zuzuordnen: Das wird durchaus passieren, aber ich denke da wirst du und auch die Community schon den Finger heben wo es unsinnig ist.
und der Aufwand, moeglichst alle Frontends und Module anzupassen: Anpassungen in einigen Modulen wird es durchaus geben. Aber es müssen ja nicht alle Module angepasst werden. Da es sich ja um einen optionalen Wert handelt, wird es auch nur dort Änderungen an Modulen, wo es sinnvoll erscheint. Also dort wo Readings mit Zahlenwerten auftreten, wo es sinnvoll ist, die Einheit zu benennen (z.B. Dauer in Sekunden, Prozentwerte,...). Ich will um Gottes Willen NICHT alle Readings in allen Modulen anpassen.
Ist meine persönliche Meinung zu dem Ganzen. Aber ich respektiere es auch, wenn ihr es nicht wollt.
Viele Grüße
Markus