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

Offline Dr. Boris Neubert

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 4340
Antw:battery / batteryLevel / ... -> Vereinheitlichen
« Antwort #30 am: 10 Mai 2018, 22:20:23 »
als Alternative für N/A würde ich folgendes vorschlagen:

Voltage = 0
Percentage = 111

sind beides Werte die "niemals" vorkommen und noch 1 Byte

goto https://forum.fhem.de/index.php/topic,87575.msg801052.html#msg801052
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

Offline Amenophis86

  • Hero Member
  • *****
  • Beiträge: 2513
  • Anti-Statement befreite Zone ;)
Antw:battery / batteryLevel / ... -> Vereinheitlichen
« Antwort #31 am: 16 Mai 2018, 10:26:55 »
Gut, neuer Vorschlag. Anstelle von N/A setzen wir -1 und schreiben in die Dokumentation, dass -1 für unbekannt steht. Wir haben keinen String, jeder normale User dürfte bei -1 merken, dass es etwas nicht stimmt und mit etwas nachdenken, oder suchen finden für was es steht. Und ob nun N/A oder -1 im Forum angefragt wird dürfte auf das gleiche hinauslaufen denke ich.
FHEM auf Raspberry3, Betriebssystem Jessy, HMLan, HM Komponenten, LD382A, H801, Sonoff, Harmony Hub und vieles mehr. Einfach ein tolles universelles System

Offline Dr. Boris Neubert

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 4340
Antw:battery / batteryLevel / ... -> Vereinheitlichen
« Antwort #32 am: 16 Mai 2018, 11:28:18 »
Hallo,

ich bin der Meinung, dass Readings vereinheitlicht werden sollten. Wenn die Lösung über Interfaces kein Interesse findet, dann eben über eine identische Benennung und Befüllung in gleicher Systematik über verschiedene Module hinweg. Ich bin aber dagegen, zusätzliche Readings einzuführen und diese mit Dummy-Werten zu belegen für Messgrößen, die ein Modul nicht zur Verfügung stellt. Der Verwender muss damit umgehen können, dass ein Reading nicht existiert, und das ist m.E. nicht aufwendiger zu implementieren als auf einen Dummy-Wert in einem Reading zu reagieren.

@Amenophis86: oder habe ich jetzt auf eine Fragestellung reagiert, die gar nicht die Deine war?

Viele Grüße
Boris
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!
Zustimmung Zustimmung x 1 Liste anzeigen

Online CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 17210
Antw:battery / batteryLevel / ... -> Vereinheitlichen
« Antwort #33 am: 16 Mai 2018, 11:41:39 »
Es gibt doch schon eine Vereinheitlichung im Mediabereich. Findet man sogar im Wiki. Warum nicht einfach sowas auch für battery fest vorgeben? Man muss nur wissen wie es aussehen soll  ;D
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.me/MOldenburg
Mein GitHub: https://github.com/LeonGaultier
kein Support für cfg Editierer

Offline Amenophis86

  • Hero Member
  • *****
  • Beiträge: 2513
  • Anti-Statement befreite Zone ;)
Antw:battery / batteryLevel / ... -> Vereinheitlichen
« Antwort #34 am: 16 Mai 2018, 12:13:22 »
@Amenophis86: oder habe ich jetzt auf eine Fragestellung reagiert, die gar nicht die Deine war?

Fast. Also ich fasse es nochmal zusammen. Wir sind uns einig, dass es nur noch 3 battery Readings geben soll. Bei den Namen gibt es noch keine 100% Einigkeit, aber der Vorschlag von Rude trifft es aus meiner Sicht am Besten:
Zitat
batteryState
batteryPercent
batteryVoltage

Nun besteht die Frage nach den Werten, welche die Readings annehmen können. Rudi hat zurecht eingeworfen, dass manche Geräte (in seinem Fall Z-Wave) zwar für battery ok / low senden und auch eine Zeitlang einen batteryPercent Wert. Nur sobald battery low annimmt der Percent werde nicht weiter gesendet wird und damit defakto unbekannt ist. Nun ist die Frage was passiert mit dem vorhandenen Reading batteryPercent, sobald dieses nicht mehr den wirklichen Wert, sondern quasi nur den letzten Wert anzeigt. Vorgeschlagen wurde:
- Reading auf N/A setzen => Problem String in einem Nummerischen Reading
- Reading auf 0 oder anderen Wert setzen => Problem, dass der Wert ja defacto falsch ist.


Damit haben wir aktuell "eigentlich" uns auf eine vereinheitlichung (nur noch drei Readings und deren Namen) geeinigt. Nun bleibt die Frage nach den Werten der Readings, die angenommen werden können und damit die von mir oben nochmal skizzierten Probleme. Daher mein Vorschlag anstelle eines Strings (N/A) oder eines falschen Werts (0 bei zB noch 10% was wir ja nicht wissen) einfach -1 zu nehmen. Daran sollte jeder erkennen, dass der Wert entweder nicht mehr übermittelt wird, oder inzwischen unbekannt ist. Und dies soll auch nur genommen werden, wenn das Reading bereits vorhanden ist. Geräte, welche nur ok / low übermitteln, müssen ja jetzt nicht extra batteryPercent oder batteryVoltage bekommen, wenn dies gar nicht abgefragt werden kann.
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: 17791
battery / batteryLevel / ... -> Vereinheitlichen
« Antwort #35 am: 16 Mai 2018, 13:49:02 »
nur kurz:

readings die es (aktuell) nicht gibt sollte man löschen -> problem: die frontends bekommen das nicht mit und zeigen weiter den alten wert an. sollte generell gelöst werden

readings die es zwar prinzipiell gibt, die aber aktuell einen undefinierten wert haben sind etwas anders. hier sollte es unknown oder ähnlich geben. nicht einen künstlichen wert außerhalb des bereiches. auch für -1 oder 111 müsste ein frontend angepasst werden wenn es einem gültigen prozent wert erwartet aber dann etwas außerhalb bekommt. also lieber gleich richtig.

manchmal ist es nicht ganz eindeutig welcher der beiden fälle passt.
 
es wäre schön wenn die diskussion nicht wieder im sande verläuft und in einem zweiten durchgang das ganze auch auf andere readings ausgefegt wird. und danach die units dran kommen :).

bei dieser art diskussion ist es übrigens oft hilfreich wenn man sich das ganze auch aus dem blickwinkel alternativer frontends wie z.b. sprach steuerung und sprachausgabe sowie der automatischen und device unabhängigen verarbeitung vorstellt.

also z.b.: was brauche ich um auf eine gesprochene anfrage den batterie status aller geräte auf deutsch anzusagen. oder nur der kritischen.

ohne sonderbehandlung für bestimmte geräte.
« Letzte Änderung: 16 Mai 2018, 13:54:05 von justme1968 »
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
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline Markus M.

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2515
Antw:battery / batteryLevel / ... -> Vereinheitlichen
« Antwort #36 am: 16 Mai 2018, 17:20:01 »
readings die es zwar prinzipiell gibt, die aber aktuell einen undefinierten wert haben sind etwas anders. hier sollte es unknown oder ähnlich geben.

Die Readings sind ja nicht unbedingt undefiniert, sie werden nur nicht übertragen.
Was spricht dagegen, in dem Fall einfach nur kein Update zu machen?
Oder in dem konkreten Beispiel von Rudi einfach aus dem Modul eine 0 zu setzen.

Wenn ein Device beispielsweise nur Percentage oder Spannung meldet, muss das battery Reading eben vom Modul intern berechnet werden.

Meinem Verständnis nach geht es hier nämlich eben nicht darum, nur Device Readings 1:1 abzubilden, sondern global identisch definierte Readings samt gültiger Werte zu haben. Und N/A sehe ich definitiv nicht als solchen Wert, das ist im Zweifelsfall nur ein verschwendeter Event auf den man nicht sinnvoll reagieren kann.


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

Offline Amenophis86

  • Hero Member
  • *****
  • Beiträge: 2513
  • Anti-Statement befreite Zone ;)
Antw:battery / batteryLevel / ... -> Vereinheitlichen
« Antwort #37 am: 16 Mai 2018, 19:34:01 »
Mir ging es in erste Linie darum, dass die Readings Device übergreifend zumindest gleich benannt sind. Das zweite wäre, wenn sie auch noch gleiche Wertebereich hätten. Ich finde auch, dass battery kein Reading ist, was berechnet werden muss. Wenn ein Gerät nur Voltage oder Percent übergibt, dann muss es auch kein battery Reading geben in meinen Augen. Dann arbeitet doch jeder lieber mit dem genaueren Wert und wenn nötig erstellt man sich ein userreading.
FHEM auf Raspberry3, Betriebssystem Jessy, HMLan, HM Komponenten, LD382A, H801, Sonoff, Harmony Hub und vieles mehr. Einfach ein tolles universelles System

Offline Dr. Boris Neubert

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 4340
Antw:battery / batteryLevel / ... -> Vereinheitlichen
« Antwort #38 am: 16 Mai 2018, 20:03:38 »
Nun ist die Frage was passiert mit dem vorhandenen Reading batteryPercent, sobald dieses nicht mehr den wirklichen Wert, sondern quasi nur den letzten Wert anzeigt.

Hmm. Das Übliche ist es doch, dass ein Reading den zuletzt übermittelten Wert beibehält. Wann ist ein Reading veraltet (stale), also was ist genau das Kriterium? Ich habe ja immer noch den Timestamp, der mir sagt, wielange schon keine Aktualisierung mehr kam. Wenn ich eine Batteriüberwachung machen würde, würde ich zusätzlich anzeigen/auswerten, wielange das Batterie-Reading nicht mehr aktualisiert wurde.
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 17791
Antw:battery / batteryLevel / ... -> Vereinheitlichen
« Antwort #39 am: 16 Mai 2018, 20:09:34 »
ich denke hier muss man unterscheiden oben ein reading nur 'alt' ist weil kein neuer wert kommt oder ob es tatsächlich nicht mehr gültig ist wie im batterie beispiel von oben.

wichtig ist das ganze nicht nur im batterie kontext zu sehen sondern allgemein. z.b. readings für jeden verpassten anruf auf einem anrufbeantworter. wenn einige oder alle anrufe abgehört wurden müssen die alten readings verschwinden und die übrigen aufrücken. sonst lässt sich das automatisch nicht vernünftig darstellen und auswerten.
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 Dr. Boris Neubert

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 4340
Antw:battery / batteryLevel / ... -> Vereinheitlichen
« Antwort #40 am: 16 Mai 2018, 20:14:18 »
wichtig ist das ganze nicht nur im batterie kontext zu sehen sondern allgemein. z.b. readings für jeden verpassten anruf auf einem anrufbeantworter. wenn einige oder alle anrufe abgehört wurden müssen die alten readings verschwinden und die übrigen aufrücken. sonst lässt sich das automatisch nicht vernünftig darstellen und auswerten.

Völlig d'accord, Andre.

An dieser Stelle läuft die Diskussion Gefahr, weiter in unspezifiziertes Terrain vorzudringen. Gibt es eine Stelle im Wiki, wo wir alle offenen konzeptionellen Punkte in FHEM parken können?
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

Offline Amenophis86

  • Hero Member
  • *****
  • Beiträge: 2513
  • Anti-Statement befreite Zone ;)
Antw:battery / batteryLevel / ... -> Vereinheitlichen
« Antwort #41 am: 16 Mai 2018, 20:28:08 »
Und wie soll dann weiter entschieden werden? Verstehe nicht ganz was du damit meinst Boris.
FHEM auf Raspberry3, Betriebssystem Jessy, HMLan, HM Komponenten, LD382A, H801, Sonoff, Harmony Hub und vieles mehr. Einfach ein tolles universelles System

Offline Dr. Boris Neubert

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 4340
Antw:battery / batteryLevel / ... -> Vereinheitlichen
« Antwort #42 am: 16 Mai 2018, 20:32:52 »
Und wie soll dann weiter entschieden werden? Verstehe nicht ganz was du damit meinst Boris.

Ich meine, dass wir uns in diesem Thema auf die Batterien konzentrieren und die weiteren grundsätzlichen Fragestellungen parken.

Was ich noch nicht verstanden habe: wie kann ein Reading vorübergehend einen undefinierten Stand haben?

(davon hängt meine weitere Argumentation ab, dass ein Reading m.E. entweder grundsätzlich da ist oder nicht)
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

Offline Amenophis86

  • Hero Member
  • *****
  • Beiträge: 2513
  • Anti-Statement befreite Zone ;)
Antw:battery / batteryLevel / ... -> Vereinheitlichen
« Antwort #43 am: 16 Mai 2018, 21:11:26 »
Ah, Jop da bin ich bei dir. Denke das macht Sinn.

Edit:
Zu deiner Frage. Wenn ich Rudi richtig verstanden habe, dann meldet Z-Wave zB bis zum Wert 15%, den genauen Prozent Wert. Ab dann wird nur noch ein bestimmter Bit übermittelt, aber nicht mehr der Prozentwert der Batterie. Daher wir bei ihm battery immer auf ok gelassen und ab dem Bit kommt dann Battery auf low aber der Wirkliche Prozentwert, ist nicht mehr bekannt. Der kann ja zwischen 0-15% sein. Und da will er nicht einfach etwas ausgeben, was nicht stimmen könnt, somit will er den Prozentwert auf N/A setzen.
« Letzte Änderung: 16 Mai 2018, 21:17:38 von Amenophis86 »
FHEM auf Raspberry3, Betriebssystem Jessy, HMLan, HM Komponenten, LD382A, H801, Sonoff, Harmony Hub und vieles mehr. Einfach ein tolles universelles System

Offline Markus M.

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2515
Antw:battery / batteryLevel / ... -> Vereinheitlichen
« Antwort #44 am: 16 Mai 2018, 21:24:10 »
Was ich noch nicht verstanden habe: wie kann ein Reading vorübergehend einen undefinierten Stand haben?

Siehe Beispiel von Rudi oben: in einem Byte wird entweder der Batteriestand in Prozent übertragen, oder der Zustand "Batteriewarnung".

Die Argumentation war, dass der Batteriestand dann irgendwo zwischen dem letzten Wert und 0 ist, wir ihn aber nicht kennen - und sein Vorschlag war, dann stattdessen N/A zu setzen.

Ich bin anderer Meinung, mir ist es aber egal ob in diesem Fall dann im Modul die 0 gesetzt wird oder der alte Wert stehen bleibt. Hauptsache nicht N/A, um das Reading in jedem Fall numerisch zu halten.
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