battery / batteryLevel / ... -> Vereinheitlichen

[rudolfkoenig]

Hab den Patch von sledge fuer MAX eingecheckt.
Habe nicht damit gerechnet, dass man batteryState an 4 verschiedenen Stellen erstellen muss.

[HCS]

Wie wäre es denn, die Umstellung auf die neuen Readings (also den rename) an featurelevel 5.9 zu binden?

[Sidey]

Hi,

ich habe soeben die folgenden Module an die neuen Reading Konvention angepasst:

14_Hideki.pm
14_SD_WS.pm
14_SD_WS07.pm
14_SD_WS09.pm
41_OREGON.pm


Grüße Sidey

[betateilchen]

zumindest bei 41_OREGON.pm scheint es ein Problem zu geben.

https://forum.fhem.de/index.php/topic,89120.0.html

[Amenophis86]

Ich wollte das Thema nochmal pushen, in der Hoffnung, dass noch weitere Modulautoren folgen. Insbesondere für Homematic (CUL_HM) würde ich mir die Änderung wünschen

Ich fasse zusammen
- es gibt die drei Readings batteryState, batteryPercent, batteryVoltage
- Wertebereich:
batteryState: ok|low
batteryPercent: \d{1,2}|100
batteryVoltage: \d+.\d+
- das jeweilige Modul setzt _nur_ die Readings, die es aus den aktuellen Daten vom Geraet bestimmen kann. Konkret: niemand kann sich darauf  verlassen, welche der drei battery Readings vorhanden sind (es gibt nicht ueberall ein batteryState). Wenn das Geraet frueher ein Percent gemeldet hat, aber in der letzten Nachricht nur state, dann wird das Percent Reading nicht angefasst.

[zap]

Für HMCCUDEV und HMCCUCHN kann sich das jeder selbst einstellen. Um es für alle per HMCCU angebundenen Devices zu definieren, genügt es folgende Attribute im I/O Device einmalig zu setzen:

Code: [Auswählen]

attr ccudef-readingname ^(.+\.)?LOW_?BAT$:batteryState
attr ccudef-substitute LOWBAT,LOW_BAT!(0|false):ok,(1|true):low