Autor Thema: battery / batteryLevel / ... -> Vereinheitlichen  (Gelesen 7861 mal)

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 19491
Antw:battery / batteryLevel / ... -> Vereinheitlichen
« Antwort #105 am: 08 Juni 2018, 17:45:59 »
Hab den Patch von sledge fuer MAX eingecheckt.
Habe nicht damit gerechnet, dass man batteryState an 4 verschiedenen Stellen erstellen muss.

Offline HCS

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2970
Antw:battery / batteryLevel / ... -> Vereinheitlichen
« Antwort #106 am: 10 Juni 2018, 16:16:41 »
Wie wäre es denn, die Umstellung auf die neuen Readings (also den rename) an featurelevel 5.9 zu binden?

Offline Sidey

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2145
Antw:battery / batteryLevel / ... -> Vereinheitlichen
« Antwort #107 am: 02 Juli 2018, 22:24:21 »
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
Signalduino, HMLan, Raspberry Pi, Mysensors, ESPEasy, HABridge für Echo
Gefällt mir Gefällt mir x 2 Liste anzeigen

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15263
  • s/fhem\.cfg/configDB/g
Antw:battery / batteryLevel / ... -> Vereinheitlichen
« Antwort #108 am: 04 Juli 2018, 15:36:47 »
zumindest bei 41_OREGON.pm scheint es ein Problem zu geben.

https://forum.fhem.de/index.php/topic,89120.0.html
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 14.12.2018 - 18:30 Uhr

Offline Amenophis86

  • Hero Member
  • *****
  • Beiträge: 2493
  • Anti-Statement befreite Zone ;)
Antw:battery / batteryLevel / ... -> Vereinheitlichen
« Antwort #109 am: 29 Oktober 2018, 21:44:16 »
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.
« Letzte Änderung: 29 Oktober 2018, 21:47:19 von Amenophis86 »
FHEM auf Raspberry3, Betriebssystem Jessy, HMLan, HM Komponenten, LD382A, H801, Sonoff, Harmony Hub und vieles mehr. Einfach ein tolles universelles System
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2444
    • HMCCU
Antw:battery / batteryLevel / ... -> Vereinheitlichen
« Antwort #110 am: 04 November 2018, 13:28:16 »
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:

attr ccudef-readingname ^(.+\.)?LOW_?BAT$:batteryState
attr ccudef-substitute LOWBAT,LOW_BAT!(0|false):ok,(1|true):low
CCU3 mit diversen Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für den Rest (Sonos, AVR, Meteohub, Beacons, Heizung, Hue)
IOBroker VIS
Maintainer der Module FULLY, Meteohub und HMCCU (Schnittstelle CCU2 - FHEM = best of both worlds approach)