Attribute zur Manipulation von Readings

[zap]

Mal grundsätzlich eine Frage in die Entwickler Runde: Seht Ihr einen Nutzen in der Einführung neuer allgemeiner Attribute zur Manipulation von Reading Werten?

Hintergrund meiner Frage: in meinem Modul HMCCU habe ich solche Attribute implementiert, da die Werte, die die CCU an FHEM meldet, nicht immer sprechend sind (z.B. "True" statt "on" oder "open"). Manchmal sind die Werte auch nicht im gewünschten Bereich (z.B. 0-1 statt 0-100).

Daher habe ich in HMCCU ein Attribut zum Ersetzen von Werten und ein weiteres zur Skalierung von Werten implementiert. Natürlich kann man das auch mit Userreadings lösen, erkauft das aber mit zusätzlichen Readings und ggf. auch Events.

Falls der Vorschlag auf Unterstützung stößt, würde ich mich bereit erklären, dafür einen Patch zu liefern.

Syntaktisch könnte man es so lösen:

scaleValue MyReading:MinAlt:MaxAlt:MinNeu:MaxNeu MyReadin2:...

substituteValue MyReading:true:on,false:off ...

Ggf könnte man mit substitute auch Wertebereiche ersetzen, z.B. Bei Rollläden (alles von 10-100% soll als offen gewertet werden)

substitute MyLevel:#0-9:closed,#10-100:open

[Thorsten Pferdekaemper]

Mal grundsätzlich eine Frage in die Entwickler Runde: Seht Ihr einen Nutzen in der Einführung neuer allgemeiner Attribute zur Manipulation von Reading Werten?

Ich nicht. Ich bin der Auffassung, dass die Module, die direkt (Hardware-)Geräte unterstützen möglichst das liefern sollen, was das Gerät halt liefert. Bei Homematic(-Wired) ist das eben das, was im XML steht. Ansonsten hat mir bisher immer userReading vollkommen gereicht.
Gruß,
   Thorsten

[dev0]

@zap: Ist das nicht jetzt schon mit dem Modul readingsChange möglich?

[Loredo]

Das klingt nach RType/Unit.pm.


Gruß

Julian

[CoolTux]

Ich hätte da jetzt nicht so die große Nachfrage.

[justme1968]

abgesehen von anderen argumenten: es gibt durchaus fälle bei denen ein modul probleme bekommt wenn man ihm unter dem hintern readings ändert. so etwas generell zu erlauben ist also keine gute idee.

ansonsten gibt es schon user readings, readingsCange und eventMap sowie stateFormat und set magic um gewisse aspekte zu beeinflussen.

alles andere ist meiner meinung nach sache des frontend und gehört in das rtype units konzept. nicht ins modul oder backend.

gruss
   andre

[Markus M.]

Auch nicht.
Wenn ein Prozentwert nur intern von 0-1 dargestellt wird aber in einem anderen UI oder einer App von 0 bis 100 sehe ich z.B. kein Problem, ihn generell im Modul auch auf 0-100 umzusetzen. Selbiges bei 0/1, wenn alle anderen Readings textbasiert sind oder irgendwas nicht in Englisch ankommt.