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

Offline Markus M.

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2169
Antw:battery / batteryLevel / ... -> Vereinheitlichen
« Antwort #60 am: 17 Mai 2018, 15:00:34 »
Wenn es Percent oder Voltage gibt und das Gerät sonst nichts meldet, sollte State trotzdem immer intern berechnet werden.
Wie und bei welchen Werten ist der Kreativität des Modulautors überlassen, aber ich sehe das als das wichtigste Reading der drei an, auf dessen Vorhandensein sich die User verlassen können sollten, sobald ein Gerät Infos zur Batterie meldet.

Was machen wir eigentlich mit den Geräten, die bisher 3 Zustände als ok/low/critical zurückgeben?
FHEM dev + HomeBridge + Lenovo Flex15 + HM-CFG-USB + RFXtrx433 + Fritz!Box 7590/7580/546E

HM Aktor/Sensor/Winmatic/Keymatic/Thermostat, HUE, Netatmo Weather/Security/Heating, Xiaomi AirPurifier/Vacuum, Withings Aura/BPM/Cardio/Go/Pulse/Thermo, VSX828, Harmony, Siro ERB15LE
https://paypal.me/mm0
Zustimmung Zustimmung x 1 Liste anzeigen

Offline Amenophis86

  • Hero Member
  • *****
  • Beiträge: 2325
  • Anti-Statement befreite Zone ;)
Antw:battery / batteryLevel / ... -> Vereinheitlichen
« Antwort #61 am: 18 Mai 2018, 14:04:50 »
Ich stimme dir eigentlich zu, wollte aber nicht jedem Modulautor auch noch aufzwingen, dass batteryState berechnet werden muss. Denke das könnte man auch dem User mittels Userreading überlassen?

Bezüglich critical frage ich mich, ob das vom Author selbst gewählt würde, oder ob das ein Gerät überträgt. Für mich würde ok / low reichen. Wäre aber für mich kein Problem, wenn critical auf mit aufgenommen wird.
FHEM auf Raspberry3, Betriebssystem Jessy, HMLan, HM Komponenten, LD382A, H801, Sonoff, Harmony Hub und vieles mehr. Einfach ein tolles universelles System

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 17742
Antw:battery / batteryLevel / ... -> Vereinheitlichen
« Antwort #62 am: 18 Mai 2018, 14:35:35 »
wäre es nicht schön wenn solche berechnungen die readings aus anderen ableiten zentral gesammelt werden? etwas in der art von ReadingsExtentsion analog zu den SetExtentions. dewpoint fällt mir hier als beispiel ein. es gab für die LaCrosse sensoren den wünsch die berechnung direkt im modul zu machen statt über das dewpoint modul. ich glaube es gibt noch andere sensoren die das lokal berechnen. den code nur an einer stelle zu haben wäre aber besser.

das wäre vielleicht auch etwas für die interfaces. wenn es bestimmte readings gibt kann das modul (oder der anwende) anmelden das davon abgeleitete readings automatisch berechnet werden.

für die batterie könnte es einen zentrale routine geben der man device abhängig den schwellwert konfiguriert um von Spannung oder Prozent auf Status zu kommen.


zu critical: das ein gerät zusätzliche besser aufgelöste informationen liefert als im 'standart' vorgesehen wird  immer wieder passieren. die frage ist wie geht man damit um. die werte einfach zu zu lassen widerspricht der vereinheitlichung und erschwert eine automatisch auswertung.

entweder steckt man diese zusätzlichen werte in ein internal oder ein eigenes device spezifisches reading. z.b. zusätzlich zu batteryState mit low und ok hätte diese device dann noch ein batteryStateRaw mit dem zusätzlich möglichen critical.

auch wenn es hier erst mal nur um den batterie stand geht solle das gesamt bild nicht aus den äugen verloren werden.
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline Wuppi68

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1541
  • Wuppertaler Wimpelbeauftragter
Antw:battery / batteryLevel / ... -> Vereinheitlichen
« Antwort #63 am: 18 Mai 2018, 16:37:34 »
eine Idee zum state von Battery

batteryState: ok|low|special

wobei Special ein Platzhalter für irgendeinen Sonderzustand ist

und dann müsste der Sonderzustand vom Modul in einem anderen Reading dargestellt werden, damit der Anwender dieses auswerten kann

siehe
state = critical
@Boris: state = stale
Jetzt auf nem I3 und primär Homematic

kein Support für cfg Editierer

Support heißt nicht wenn die Frau zu Ihrem Mann sagt: Geh mal bitte zum Frauenarzt, ich habe Bauchschmerzen

Offline Amenophis86

  • Hero Member
  • *****
  • Beiträge: 2325
  • Anti-Statement befreite Zone ;)
Antw:battery / batteryLevel / ... -> Vereinheitlichen
« Antwort #64 am: 18 Mai 2018, 19:16:11 »
Die Berechnung für alles war ja der Ursprung der ganzen Diskussion. Wollte bzw. war dabei ein Modul zu schreiben, welches alle Batterie Werte sammelt und auch mit Geräten, welche nur mit ok / low arbeiten eine Art Skala zu bauen wie lange low schon läuft und wie lange die Batterie vermutlich noch hält.

Finde den Vorschlag von Wuppi gut, aber mir sagt der von justme mit batteryRaw mehr zu. So würde es einheitlich bleiben. Und denke batteryRaw passt von der Bezeichnung auch ganz gut.
FHEM auf Raspberry3, Betriebssystem Jessy, HMLan, HM Komponenten, LD382A, H801, Sonoff, Harmony Hub und vieles mehr. Einfach ein tolles universelles System

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 17742
Antw:battery / batteryLevel / ... -> Vereinheitlichen
« Antwort #65 am: 18 Mai 2018, 19:25:11 »
da fällt mir noch was ein: um leere batterien zu erkennen reicht es nicht auf einen staus low zu reagieren. manchmal (gar nicht so sehr selten) passiert es auch, das ein device einfach weg ist weil es noch nicht mal mehr zum senden des low reicht. das müsste man eigentlich auch berücksichtige. hat dann aber ziemliche überschneidungen mit anderen modulen.
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline Amenophis86

  • Hero Member
  • *****
  • Beiträge: 2325
  • Anti-Statement befreite Zone ;)
Antw:battery / batteryLevel / ... -> Vereinheitlichen
« Antwort #66 am: 18 Mai 2018, 19:36:25 »
Ja, habe auch schon überlegte das auch einzubauen. Aber nach und nach, wird mein erstes Modul. Wenn wir alle Readings gleich benannt haben ist das erste Problem gelöst und dann geht es weiter ;)
FHEM auf Raspberry3, Betriebssystem Jessy, HMLan, HM Komponenten, LD382A, H801, Sonoff, Harmony Hub und vieles mehr. Einfach ein tolles universelles System

Offline Wuppi68

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1541
  • Wuppertaler Wimpelbeauftragter
Antw:battery / batteryLevel / ... -> Vereinheitlichen
« Antwort #67 am: 18 Mai 2018, 20:39:11 »
da fällt mir noch was ein: um leere batterien zu erkennen reicht es nicht auf einen staus low zu reagieren. manchmal (gar nicht so sehr selten) passiert es auch, das ein device einfach weg ist weil es noch nicht mal mehr zum senden des low reicht. das müsste man eigentlich auch berücksichtige. hat dann aber ziemliche überschneidungen mit anderen modulen.

die Kombi aus justme68 und wuppi68 :-)

batteryState: ok|low|special

und batteryRaw MUSS bei special gesetzt sein ansonsten ist es optional
Jetzt auf nem I3 und primär Homematic

kein Support für cfg Editierer

Support heißt nicht wenn die Frau zu Ihrem Mann sagt: Geh mal bitte zum Frauenarzt, ich habe Bauchschmerzen

Offline Markus M.

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2169
Antw:battery / batteryLevel / ... -> Vereinheitlichen
« Antwort #68 am: 19 Mai 2018, 00:02:09 »
batteryState: ok|low|special
Beliebige zusätzliche Readings gerne, aber kein Wert wie special, der alles mögliche bedeuten kann.
Das macht die Sache unnötig komplex und ist wieder genau das was wir vermeiden wollen.
FHEM dev + HomeBridge + Lenovo Flex15 + HM-CFG-USB + RFXtrx433 + Fritz!Box 7590/7580/546E

HM Aktor/Sensor/Winmatic/Keymatic/Thermostat, HUE, Netatmo Weather/Security/Heating, Xiaomi AirPurifier/Vacuum, Withings Aura/BPM/Cardio/Go/Pulse/Thermo, VSX828, Harmony, Siro ERB15LE
https://paypal.me/mm0
Zustimmung Zustimmung x 2 Liste anzeigen

Offline Markus M.

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2169
Antw:battery / batteryLevel / ... -> Vereinheitlichen
« Antwort #69 am: 21 Mai 2018, 14:50:20 »
Ich fange jetzt einfach mal an. Ab morgen im Update:
32_withings: batteryState, batteryPercent
38_netatmo: batteryState, batteryPercent, batteryVoltage
72_XiaomiDevice: batteryState, batteryPercent
FHEM dev + HomeBridge + Lenovo Flex15 + HM-CFG-USB + RFXtrx433 + Fritz!Box 7590/7580/546E

HM Aktor/Sensor/Winmatic/Keymatic/Thermostat, HUE, Netatmo Weather/Security/Heating, Xiaomi AirPurifier/Vacuum, Withings Aura/BPM/Cardio/Go/Pulse/Thermo, VSX828, Harmony, Siro ERB15LE
https://paypal.me/mm0
Gefällt mir Gefällt mir x 7 Liste anzeigen

Offline Amenophis86

  • Hero Member
  • *****
  • Beiträge: 2325
  • Anti-Statement befreite Zone ;)
Antw:battery / batteryLevel / ... -> Vereinheitlichen
« Antwort #70 am: 21 Mai 2018, 15:05:46 »
Top Markus, vielen Dank
FHEM auf Raspberry3, Betriebssystem Jessy, HMLan, HM Komponenten, LD382A, H801, Sonoff, Harmony Hub und vieles mehr. Einfach ein tolles universelles System

Offline Amenophis86

  • Hero Member
  • *****
  • Beiträge: 2325
  • Anti-Statement befreite Zone ;)
Antw:battery / batteryLevel / ... -> Vereinheitlichen
« Antwort #71 am: Gestern um 14:11:16 »
Wie sieht es mit den anderen und ihren Modulen aus? Soll eine Frist gesetzt werden? Denke die endgültige Entscheidung musst du treffen Rudi, oder?
FHEM auf Raspberry3, Betriebssystem Jessy, HMLan, HM Komponenten, LD382A, H801, Sonoff, Harmony Hub und vieles mehr. Einfach ein tolles universelles System

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 18442
Antw:battery / batteryLevel / ... -> Vereinheitlichen
« Antwort #72 am: Gestern um 14:17:01 »
Ein Frist wuerde ich nicht setzen (was machen wir, wenn die Frist abgelaufen ist? wie pruefen wir, dass die Regeln nicht eingehalten wurden?), aber ich werde meine Module ASAP aendern.

Offline papa

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1106
Antw:battery / batteryLevel / ... -> Vereinheitlichen
« Antwort #73 am: Gestern um 14:22:13 »
Kann man denn den Zugriff auf "alte" Readings irgendwie erkennen und loggen ?

Warning: Notify MYBATMON uses obsolete reading battery
Vielleicht auch mit Stacktrace. Damit wird die Migration von bestehendem Code einfacher.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Offline Amenophis86

  • Hero Member
  • *****
  • Beiträge: 2325
  • Anti-Statement befreite Zone ;)
Antw:battery / batteryLevel / ... -> Vereinheitlichen
« Antwort #74 am: Gestern um 14:26:18 »
Ein Frist wuerde ich nicht setzen (was machen wir, wenn die Frist abgelaufen ist? wie pruefen wir, dass die Regeln nicht eingehalten wurden?), aber ich werde meine Module ASAP aendern.

Dafür kenne ich die "Regeln" der Community zu wenig, wie das gehandhabt wird :) Aber zumindest sollte es eine Ankündigung geben mit der Bitte der Umstellung. Die Idee von papa finde ich auch gut, wenn so etwas möglich ist.
FHEM auf Raspberry3, Betriebssystem Jessy, HMLan, HM Komponenten, LD382A, H801, Sonoff, Harmony Hub und vieles mehr. Einfach ein tolles universelles System

 

decade-submarginal