Falsche Batteriewerte?

[Pittini]

Xiaomi Tür/Fenster Kontakte haben bekanntlich eine Batterie Sollspannung von 3V. Das Problem, die ausgegebenen Volt und Prozentwerte passen absolut nicht zusammen, siehe Bild. Beispiel 3V Sollspannung, angezeigte Ist Spannung von 2.975 Volt ergibt 58.7% - das ist rechnerischer Unsinn. Sollte der Wert schon eine min Limit Spannung intern berücksichtigen, so ist es untransparent und macht eine Vergleichbarkeit mit anderen Geräten unmöglich.

[Diginix]

Das ist die Formel: this.percent = Math.round(((data.voltage - 2655) / 5.45) * 10) / 10; Die Min Spannung von 2,655 V hat sich bei mir über Jahre als recht brauchbar erwiesen. Daher habe ich die Formel angepasst. Eine wirklich volle Batterie hat 3,2 V. Bei 3 Volt ist sie längst nicht mehr voll. Die Formel berechnet das einfach linear. Du gehst nicht wirklich davon aus dass 100% Kapazität sich von 3 bis 0 Volt erstrecken. Das ist sicher bei anderen Adapter auch nicht so und wenn dann ist es dort falsch. Weiterhin erhebt kein Adapter Anspruch auf Vergleichbarkeit zw. den states und andere Adapter berechnen die Werte sicher auch anders. Außerdem haben andere Geräte auch evtl. andere Abschaltspannungen. Deine Aussage "vollkommen falsche Werte" ist schlicht unsachlich. Intransparenz bei einem open source Projekt war sicher nicht ernst von dir gemeint? (April April)

Die alte Formel war übrigens diese: this.percent = ((data.voltage - 2200) / 10);

Ergäbe bei dir 77,5%. Dann würden noch 45% da stehen, der Sensor aber längst nicht mehr arbeiten. Das fändest du dann plausibel, vergleichbar und toll?

Was wäre denn dein Vorschlag für eine korrekte Formel? Gern als Commit.

[Pittini]

Ich arbeite grad an nem generischen Batterieüberwachungsskript. Solange Spannungen angegeben werden ist das kein Problem das vergleichbar umzurechnen. Nun gibt es aber halt Geräte die NUR Prozent ausgeben, was erstmal auch kein Problem ist solange das echte Batteriekapazitätsprozent sind (wie z.B. bei deconz (hab ich mir sagen lassen, hab das selber nicht)). Der mihome Adapter gibt aber keine gemäß der Rolle entsprechenden "battery.prozent" aus, sondern eher sowas wie lifetime% bei dem schon ein min. Limit eingerechnet wird. Jetzt hab ich also 2mal nen Prozentwert mit gleicher Rolle und Unit, aber unterschiedlicher Definition. Das musste ich Usereinstellbar machen da es keine vernünftige Weise gibt rauszufinden was der angegebene Prozentwert darstellt. Jetzt setzt zusätzlich mein Skript auch minLimits (bei 3V Geräten tatsächlich auch 2.65V) ein um Warnungen auszugeben, was überall unproblematisch ist, nur beim mihome muss ich erstmal rückwärts rechnen. Das erst mal vorab als Erklärung. Die Formel hab ich im sourcecode schon gefunden und gegen das Limit von 2.655 is auch nix zu sagen, nur ist bei diesem Verfahren entweder die %Angabe falsch oder die zugewiesen Rolle battery.prozent. Ich hab jetzt extra auch mal etliche neue Batterien nachgemessen (mit nem Fluke), mehr als 3.06 Volt hatte keine, aber das ist ja an sich auch nicht das Problem. Und doch, ja, ich gehe davon aus dass 100% Kapazität sich von 0-3V erstrecken es ist ja Batteriekapazität und nicht gültigesSpannungsfenster oder Lifetime%, hoffe Du verstehst worauf ich raus will. Damit is auch klar was ich für ne Formel verwenden würde: this.percent = ((data.voltage / 3)*100); Nennspannung is nu mal Nennspannung, und wenn die Batt bissl mehr hat, gibts halt erstmal Werte über 100%. Mit Intransparenz meinte ich, das Otto NormalUser oftmals gar nicht die Fähigkeit mitbringt sich die Formel im Quellcode zu suchen und somit für ihn die Entstehung des gezeigten Wertes intransparent ist. Was ich plausibel brauchbar und toll finde sieht z.B. so aus, ich berechne einfach beide % Werte und lass den User Entscheiden was er verwenden will.:

PS: Kann man doch vernünftig dikutieren, keine Grund das persönlich zu nehmen und angepisst zu reagieren ;) .

[Diginix]

Verstehe, aber es gibt real keine Batterie auf der Welt deren Kapazität sich von 0-max Volt erstreckt. Prozentwerte über 0 unterhalb der Funktionstüchtigkeit des Gerätes kenne ich bei keinem Gerät. Weder E-Auto, Smartphone noch Notebook gehen schon vor 0% Akku aus. Weil die Batterie aber noch weit über 0 Volt hat und deiner Theorie nach ja also noch >0% wird das nie so angezeigt. Deswegen warnen Geräte ja auch nicht selten bei 10 oder 15%, was aber ein toten Gerät nicht mehr kann. Selbst wenn die Formel 0-3V für die 100% nutzen würde, wäre sie unbrauchbar um mit den Protzenten zu arbeiten. Denn du weiß nicht bei welchem Prozentwert welches Gerät aussteigt. Verstehe also nicht was dann besser wäre. Wenn deconz das tatsächlich bis 0 V ausgibt ist mMn dort der Fehler zu suchen.

Einfach anzupassen wäre die Formel wenn man annimmt dass alles über 3,0 Volt "Bonus" ist und die 100% erst fallen wenn die 3,0 Volt unterschritten werden. Dann erstrecken sich die 100% aber immer noch auf das nun kleinere Fenster zw. 2,65 und 3,0 Volt. Eine Logarithmische Formel kann ich nicht leisten. Parallel die Rolle des Objektes anzupassen ist natürlich kein Problem. Ändert nur nichts an der eingeschränkten Verwendbarkeit für dein Szenario.

Die ursprüngliche Formel hätte dir also auch nichts genützt und mein Ziel war es deren Wert überhaupt plausibel zu machen. Das ist er nun. Denn für Ottonormalverbraucher ist der Wert nun genau wie bei seinem Smartphone oder anderen batteriebetriebenen Dingen. Bei 0% stellt das Gerät die Arbeit ein. Meine Überwachung warnt sogar schon ab 30% weil durchaus auch schon Xiaomi Sensoren bei 2,8 Volt die Arbeit eingestellt haben. Bzw. im Außenbereich bei niedrigen Temp. die Spannung dann schnell noch mehr zusammenbricht.

Abschließend: Jeder darf hier neue Ideen committen und Bluefox o.a. entscheidet über die Sinnhaftigkeit.

PS: Mich hat der clickbaiting Titel einfach nur geärgert. Der ist inhaltlich falsch und unsachlich. Nichts ist vollkommen falsch.

[Pittini]

PS: Mich hat der clickbaiting Titel einfach nur geärgert. Der ist inhaltlich falsch und unsachlich. Nichts ist vollkommen falsch.

Da geb ich Dir recht und hab den Titel deshalb angepasst. Entstanden isser in der Form halt weil ich mich drüber geärgert hatte jetzt noch ne Ausnahme einbauen zu müssen ;). Sorry dafür.

Letztendlich werd ich wohl mit der/den Ausnahmen leben müssen, deine Argumentation kann ich nachvollziehen, und die irgendwie reinverwursten müssen, evtl. über den Adapternamen etc. Hab ja auch noch die Fälle wo überhaupt nur lowbat true/false gemeldet wird, das ist auch schon drin. Ne genau Wissenschaft isses eh nicht, weil eben wie Du ja schon sagtest es auch Geräte und Temperatur Abhängigkeiten gibt. Das Skript soll aber zumindest nen Hinweis geben welche Batterie unter nem einstellbaren Limit ist, und welche noch im Limit aber von allen die niedrigste ist (zwecks nachkaufen) und ich denk das klappt jetzt auch mit dem update das heut rausgeht. Mach das ja für die Community, nur für mich wär das viel einfacher. Kannst ja mal reinguggen heut abend: https://github.com/Pittini/iobroker-Batterienauswertung.

[thatso]

Nachdem ich mich auch schon über den Datenpunkt battery.percent gewundert habe und die Argumentation mit der Endspannung von rund 2.65 V als Lebenszeitende und damit 0 % befürworte: wie wäre es, den Datenpunkt einfach umzubenennen in battery.lifetime? Oder zumindest zusätzlich zur jetzigen Prozentangabe einen zusätzlichen Punkt in der Art battery.expected.lifetime einzuführen? Damit wäre der Unterschied zwischen einem wie auch immer berechneten und einem direkt vom Sensor ausgelesenen Wert sofort ersichtlich. Überhaupt wäre es eine tolle Sache, wenn dies als Programmierrichtlinie für alle Adapter festgelegt werden könnte, damit man eben nicht bei jedem einzelnen herausfinden muß, was denn nun tatsächlich hinter einer Prozentangabe steckt.

[Pittini]

Nachdem ich mich auch schon über den Datenpunkt battery.percent gewundert habe und die Argumentation mit der Endspannung von rund 2.65 V als Lebenszeitende und damit 0 % befürworte: wie wäre es, den Datenpunkt einfach umzubenennen in battery.lifetime? Oder zumindest zusätzlich zur jetzigen Prozentangabe einen zusätzlichen Punkt in der Art battery.expected.lifetime einzuführen?

Grundsätzlich gehe ich mit Deiner Idee konform, meine aber es müßte ganz korrekt device.lifetime heißen. Weil die Batterie in einem anderen Gerät (theoretisch) noch ne Zeit funktionieren könnte.

[thatso]

[...] meine aber es müßte ganz korrekt device.lifetime heißen.

Das fände ich allerdings noch verwirrender als die jetzige Prozentangabe, denn:

Weil die Batterie in einem anderen Gerät (theoretisch) noch ne Zeit funktionieren könnte.

Unwahrscheinlich. Wenn die Lebensdauer-Ende-Spannung der Batterie erreicht ist, ist das recht endgültig und geräteunabhängig. Aber schlimmer: device.lifetime impliziert das Gerät/den Sensor selbst. Man assoziiert dabei unweigerlich, der Sensor wäre jetzt für die Tonne.

[Pittini]

Aber schlimmer: device.lifetime impliziert das Gerät/den Sensor selbst. Man assoziiert dabei unweigerlich, der Sensor wäre jetzt für die Tonne.

Stimmt auch wieder. Dann device.battery.lifetime

[thatso]

@Pittini : der Bezug zum Sensor ist doch implizit mit dem Datenpunkt schon vorhanden. Insofern bringt device. keinen Mehrwert an Information - das könnte man allen Datenpunkten voranstellen, verlängert aber nur den Namen. ;-)

[Diginix]

Ohne eure rege Diskussion stören zu wollen. Nennt mir mal bitte ein Gerät bei dem der SOC nicht einfach Batterieprozente sind und derart kreative Namen trägt. Und parallel hätte ich gern mal ein Screenshot von Objekten anderer Adapter bei denen das so ist.

btw: Ich habe schon "leere" Batterien aus Xiaomi Sensoren in Shutterbrillen vom Samsung TV oder IR Fernbedienungen gepackt > keine Funktion. Eine Knopfzelle mit 2,6 V ist für die Tonne.

[thatso]

Fortschritt bringt es mit sich, daß einer damit anfangen muß, um Mitläufer anzuregen. Wäre doch schön, wenn das konsequent umgesetzt würde, oder etwa nicht?

[Diginix]

Normal ist was die Mehrheit macht. SOC ist SOC und bei 0% ist die Spannung immer >0 Volt. Da müsst ihr noch einige Millionen von Ingenieuren überzeugen. Aber ihr findet sicher einen passenden Namen und dann kann der gern übernommen werden.

[thatso]

Ich dachte immer, Open Source würde vom Mitmachen leben ... Du vermittelst da gerade einen anderen Eindruck. So nebenbei habe ich der Auffassung, daß 0 % nicht 0 V entspricht, nie widersprochen. Wieso sollen wir einen Namen finden? Hast Du keine eigene Meinung dazu?

[Diginix]

Nicht falsch verstehen. Ich befürworte jegliche sinnvolle Aktivität. Habe mich doch selbst hier eingebracht und diverse kleine Bugs behoben. Aber bei der Begrifflichkeit sehe ich das Engagement verschwendet. Es ist mMn kein Bug sondern eine persönliche Befindlichkeit. Ich finde "battery.percent" treffend, stammt auch nicht von mir, hätte ich aber genau so benannt. Alles andere klingt nur kompliziert und verkrampft. Es gibt übrigens bei jedem Objekt noch Beschreibung (desc). Da könnte man ja ansetzen.

[thatso]

Ok, mein letzter Kommentar klang evtl. etwas hart. Geht aber eher allgemein darum, daß einfach mit viel Enthusiasmus losgelegt wurde und irgendwo der Anwender auf der Strecke blieb, überwiegend wegen fehlender Dokumentation. Daher kommen ja erst solche Missverständnisse, wenn ein Datenpunkt wie hier (und auch in anderen Adaptern) Prozent heißt, aber für viele unerwartet dann mehr Rechenformeln als vermutet dahinter stecken.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within the next 7 days. Please check if the issue is still relevant in the most current version of the adapter and tell us. Also check that all relevant details, logs and reproduction steps are included and update them if needed. Thank you for your contributions. Dieses Problem wurde automatisch als veraltet markiert, da es in letzter Zeit keine Aktivitäten gab. Es wird geschlossen, wenn nicht innerhalb der nächsten 7 Tage weitere Aktivitäten stattfinden. Bitte überprüft, ob das Problem auch in der aktuellsten Version des Adapters noch relevant ist, und teilt uns dies mit. Überprüft auch, ob alle relevanten Details, Logs und Reproduktionsschritte enthalten sind bzw. aktualisiert diese. Vielen Dank für Eure Unterstützung.

[jayfizzle]

I have still problems with the battery. After the update to version 1.3.4 all my motion sensors are displaying 100%. This is impossible because i'm using them already for months.

[Diginix]

How is the voltage value? 0% until 100% range is between 2.655 volt and 3.000 volt. If your batterie has still above 3.0 volt, you'll see 100%. Even after months. The nominal voltage of this battery type is 3 volt. So, all above is "bonus".

[jayfizzle]

the voltage is from 2.995 - 3.045. That means that the displayed value (100%) should be correct. Nehme an da fast alle meine Bewegungssensoren noch bei ca 3.000 Volt liegen, diese auch korrekt dargestellt werden sollten. Oder sollte der Sensor mit 2.995 volt eher sowas wie 99% anzeigen?

[Diginix]

2,995 ergibt 98,55%, gerundet 98,6%. Wenn da 100% angezeigt werden, stimmt eigentlich was nicht. Ich habe einen Motion Sensor der gerade auch genau diese Spannung hat und bei mir sieht es so aus:

Die Formel ist: (Batteriespannung - 2,655) / 0,00345

[jayfizzle]

Habe die Instanz mal neu gestartet, nun wird mir auch dein Wert angezeigt. danke und Gruß

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within the next 7 days. Please check if the issue is still relevant in the most current version of the adapter and tell us. Also check that all relevant details, logs and reproduction steps are included and update them if needed. Thank you for your contributions. Dieses Problem wurde automatisch als veraltet markiert, da es in letzter Zeit keine Aktivitäten gab. Es wird geschlossen, wenn nicht innerhalb der nächsten 7 Tage weitere Aktivitäten stattfinden. Bitte überprüft, ob das Problem auch in der aktuellsten Version des Adapters noch relevant ist, und teilt uns dies mit. Überprüft auch, ob alle relevanten Details, Logs und Reproduktionsschritte enthalten sind bzw. aktualisiert diese. Vielen Dank für Eure Unterstützung.

[stale[bot]]

This issue has been automatically closed because of inactivity. Please open a new issue if still relevant and make sure to include all relevant details, logs and reproduction steps. Thank you for your contributions. Dieses Problem wurde aufgrund von Inaktivität automatisch geschlossen. Bitte öffnet ein neues Issue, falls dies noch relevant ist und stellt sicher das alle relevanten Details, Logs und Reproduktionsschritte enthalten sind. Vielen Dank für Eure Unterstützung.