Allgemeiner (optionaler) Support für Units (Unit.pm)

[rudolfkoenig]

Hmm. Ich habe das gelesen, und ich sehe aber keine neuen Argumente. Man kann was machen, was man teilweise auch jetzt machen kann. Warum das Wert ist, dafuer die zusaetzliche Komplexitaet in Kauf zu nehmen, erschliesst sich mir nicht. Nicht falsch verstehen: ich sperre mich nicht prinzipiell gegen Aenderungen. Ich will nur wissen, ob irgendein Aufwand es Wert ist.

Btw. der Patch ist mit 100k (Unit.pm kommt ja ploetzlich mit) gross genug, dass ich nicht alle Nebenwirkungen verstehe. Und die, die ich verstehe (z.Bsp. wie $lang eingebaut ist, neue Abhaengigkeit in fhem.pl von JSON.pm, die readingsDesc Implementierung), ist mir die Vorteile (noch) nicht Wert.

[Loredo]

Ich habe den list-Befehl nun so umgeändert, dass er mit parseParams() arbeitet. Die Regex-Funktion für den 3. Parameter funktioniert jetzt abwärtskompatibel zur bisherigen Version.
Außerdem habe ich den Language Support nun so abgekapselt, dass der Device-Hash nicht mehr verändert wird. Dafür wird in replaceTemplate() eine Deep-Kopie von $defs{$name}{readingDesc} mittel Perl::Clone angefertigt und dann entsprechend für die Anzeige aufbereitet. Im readingDesc Hash sieht man deshalb nun auch vollständig alle Inhalte.


Die Sprache wird dabei ganz einfach so gewählt, dass bei Vorhandensein eines Hashes der Form {key}{sprache} ein {key} umgewandelt wird, bevor die Ausgabe verarbeitet wird und schließlich die beiden Template Vorlage "tmpl" und "tmpl_long" durch ihre Werte ersetzt werden. In diesen Templates wird alles, was mit %% umgeben ist, durch entsprechende Werte aus dem readingsDesc Hash ersetzt, sofern es einen entsprechend benannten Scalar-Key gibt. Das ist auch schon die ganze Magie, nichts großartiges.


Eine gute Idee davon wie das alles gemeint ist gibt eine Ansicht auf den aktuellen ReadingsType Hash:

Code Auswählen Erweitern


setreadingdesc rtype=?


[Loredo]

Btw. der Patch ist mit 100k (Unit.pm kommt ja ploetzlich mit) gross genug, dass ich nicht alle Nebenwirkungen verstehe. Und die, die ich verstehe (z.Bsp. wie $lang eingebaut ist, neue Abhaengigkeit in fhem.pl von JSON.pm, die readingsDesc Implementierung), ist mir die Vorteile (noch) nicht Wert.

Eigentlich greift alles aus Unit.pm ja erst, wenn man showUnits=1 gesetzt hat und zusätzlich ein Modul tatsächlich den Support dafür eingebaut hat oder ein Benutzer anfängt entsprechende Attribute manuell zu setzen.
Ist denn ein vollständiges Verständnis dafür notwendig, solange die Schnittstelle bzw. der Übergang genau bekannt ist? Es wird kein zusätzlicher Code ausgeführt, solange showUnits=0 steht.




@André: Ich finde wir brauchen readingsFormat nicht. Stattdessen würde ich ein Device-Attribut "readingsTypes" haben wollen, um Readings-Typen auf Globaler und Device-Ebene als Anwender definieren zu können.

[klaus.schauer]

Beim EnOcean-Modul sehe ich durchaus Bedarf für ein möglichst universelle Reading-Funktionen einschl. der Unit-Ausgabe.

Ich möchte kurz beschreiben, wie die Daten im Modul in drei Varianten empfangen und aufbereitet werden:

# Kanalbeschreibung mit Hilfe der in den Profildefinitionen vorab festgelegten Werte und Wertebereiche

I. d. R. wird dabei nur der Wert auf die Variablengenauigkeit gerundet ausgegeben. Die Einheit ist dann der commandref zu entnehmen.

# Kanalbeschreibung, über das Datentelegramm selbst, mit Angaben zum Wertebereich, zu Einheiten und der Genauigkeit

Hier wird die Ausgabeformatierung und Rundung zur Laufzeit berechnet. Zusätzlich gibt es in den meisten Fällen ein zusätzliches Reading, das die Einheit beschreibt z. B. temperatureUnit zu temperature

# Kanäle, die während des Anlernvorgangs beschrieben werden

Jeder Kanal wird über folgende Parameter definiert:
1. Kanaltyp: Data, Flag, Enumertion
2. Signaltyp: abhängig vom Kanaltyp z. B. on/off, auto/cooling/heating, power (W)/ frequency (Hz)/ time (s)
3. Wertetyp: Current value, set point absolute, set point relative

Weiterhin werden Parameter für die Umsetzung und Formatierung der Daten selbst beschrieben:

1. Auflösung: 2 bit - 32 bit
2. Skalierung min: x 1, ..., x 10.00.000, x 0.1, ..., x 0.000000001
3. Skalierung max: x 1, ..., x 10.00.000, x 0.1, ..., x 0.000000001
4. Engineering min: -128 ... 127
5. Engineering max: -128 ... 127

Für diesen Kanaltyp werden neben dem formatierten Wert zusätzliche Readings xUnit, xChannelType, xValueType je Kanal ausgegeben.

Für das EnOcean-Modul wäre es deshalb ideal und notwendig, dass diese o. a. Parameter zur Laufzeit an die readingsUnitBulkUpdate() oder readingsUnitSingleUpdate() übergeben werden könnten.

Vielleicht gibt es ja auch einen anderen gleichwertigen Ansatz.

Mir würde es insgesamt helfen, wenn die vorgestellten neuen Funktionen mit Hilfe eines Programmbeispiels zur Werteübergabe beschrieben würde.

[Loredo]

Einfacher wäre es, wenn du es dir selbst ansiehst, Klaus, und Feedback gibst, was ggf. noch fehlen würde. Ich kann mich selbst nicht in die EnOcean Welt eindenken.
Das Wunderground Modul gibt ein extrem gutes Beispiel darüber ab, wie die Zuweisung von Reading-Typen funktioniert. Bisher ist es vornehmlich mit dem Hintergrund von Wettermodulen definiert. Die Builtin-Readingtypen sollten aber eigentlich bereits mehr als ausreichend für die allermeisten FHEM-Readings sein.


Zentraler Ansatz ist allerdings nicht zwangsläufig die eingehenden Werte, die mit readingsBulkUpdate() geschrieben werden vorher umzuwandeln und den formatierten Wert in fhem.save abzuspeichern. Vielmehr sollen die Daten, wann immer möglich, als Rohdaten erhalten bleiben, um dann für die Anzeige umformatiert und ggf. auch konvertiert zu werden. Aktuell kann man noch nicht von einer Einheit in die andere umrechnen lassen, da mein Ansatz anders ist als der von André. Es gibt Reading-Typ-Gruppen und innerhalb einer dieser Gruppen soll es dann möglich sein von einer in die andere Einheit umzurechnen. Für die metrischen Angaben fehlt dazu nicht viel, aber auf gleiche Weise wird man dann auch von Fahrenheit in Celsius etc. umrechnen lassen können. Das Readings-Attribut "rtype" zu setzen bedeutet also in erster Linie zu sagen, in welchem Format der aktuelle Readings-Wert einzuordnen ist. Später ist ein Readings-Attribut "convert" vorgesehen, welches dann ebenfalls einen rtype enthält. Die Formatierungsfunktion soll dann automatisch anhand der unterschiedlichen Readings-Attribute ermitteln, ob und wie in das gewünschte Anzeigeformat umgewandelt werden kann. Dafür gibt es auch schon eine Menge Definitionen in UConv.pm, die ich als Hilfsfunktionen dafür vorgesehen habe.