Reading

Readings sind i.d.R. modulabhängig und geben zusammen mit Attributen und Internals den aktuellen Zustand des dahinter liegenden physischen oder virtuellen Geräts wieder.

Allgemeines

Readings geben in FHEM wieder, welche Einstellungen oder Messwerte (allg. Gerätedaten) am jeweiligen Gerät vorliegen. So hat ein Temperatursensor ein Reading für die Temperatur, ein Lichtsensor hat ein Reading für die Helligkeit und ein Schalter ein Reading für An/Aus. Je nach Gerätefamilie (zWave, FS20, Homematic,...) werden Readings in FHEM und Gerätedaten möglichst synchron gehalten. Zu Ausnahmen später mehr.

Readings werden mit dem define-Befehl des jeweiligen Devices oder bei den ersten Übertragungen mit jenem angelegt und mit Werten gefüllt.

Beim Herunterfahren von FHEM werden die bekannten Werte aller Readings entweder in das statefile oder die Konfigurationsdatenbank geschrieben. So können sie beim Start von FHEM wieder ausgelesen und in die entsprechenden Readings der Geräte geschrieben werden. Damit entsteht ein wahrscheinlich halbwegs aktueller Zustand aller Geräte, ohne dass beim Start von FHEM erst alle Geräte abgefragt werden müssen, was aber bei den meisten per Funk angesprochenen Gerätefamilien wegen der 1%-Regel mitunter sehr lange dauern würde.

Alle Geräte haben Readings, deren Werte entweder vom Modulcode oder mit dem Befehl setreading verändert werden können. Werden dabei moduleigene Readings gesetzt, können mitunter unerwünschte Nebenwirkungen auftreten. Es können aber auch mit diesem Befehl neue Readings erzeugt werden, die bspw. zum Zwischenspeichern dienen sollen. So können Readings auch mit dem Kommando deletereading entfernt werden. Wobei hier durch das Löschen von modulinternen Readings sehr sicher Fehler in der Ausführung von FHEM auftreten werden.

Abgrenzung zu Attributen

siehe den entsprechenden Abschnitt bei Attribut.

userReadings

Einen Sonderfall eigener Readings stellen userReadings dar. Diese können insbesondere für Geräte-interne Berechnungen genutzt werden, oder zur Erstellung von Readings mit Informationen aus verschiedenen Readings. Beispiel: Aus einzeln übermittelten r, g und b-Werten einen rgb-Wert bilden, mit dem sich das devStateIcon einfärben läßt. Ähnlich wie bei notify und anderen Event-Handlern empfiehlt es sich, einen möglichst engen Trigger zu definieren, damit nur bei Änderungen relevanter Ausgangswerte auch eine Neuberechnung des userreadings erfolgt.

Readings im STATE darstellen

Sollen andere als das Reading state in der Geräteübersicht angezeigt werden, erfolgt dies in der Regel über das Attribut stateFormat. Näheres hierzu ist im Artikel DeviceOverview anpassen zu finden.

Auf Änderungen reagieren

Um auf Änderungen von Readings zu reagieren, verwenden Sie einen Eventhandler, z.B. ein notify, um Trigger durch sich ändernde Readings einzuschränken oder diese regelmäßig ohne Änderung zu erzeugen, verwenden Sie event-on-change-reading bzw. event-on-update-reading und event-min-interval.

ReadingsGroup

ReadingsGroup stellt eine Möglichkeit dar, neben Readings auch [[Attribut|Attribute] strukturiert darzustellen. Mit Hilfe dieses Moduls können auch den End-Anwendern auf einfache Weise vielfältige Einstellmöglichkeiten zur Verfügung gestellt werden.