[Vorlage] Generische Batteriestandsüberwachung + Vis-ausgabe
-
@Wildbill sagte in [Vorlage] Generische Batteriestandsüberwachung + Vis-ausgabe:
Kann es sein, dass es Probleme gibt, wenn einem Datenpunkt zwei Räume oder Funktionen zugeordnet sind? Von FHEM habe ich ein paar Geräte, die haben einmal iobroker und dann eben den Raum selbst als Raum. in FHEM werden so die Datenpunkte markiert, die zu iobroker gehen sollen.
Zwei Räume sind eigentlich nicht vorgesehen weil von der Logik her ein Gerät nur in einem Raum sein kann, das wär auch nicht zuzuordnen, woher soll das Skript wissen welchen Raum es jetzt melden soll? Sollte es trotzdem zwei Räume geben wird der erste Raum der Aufzählung genommen.
Ebenfalls habe ich ein paar Datenpunkte, die zwei Funktionen zugewiesen haben, einmal den neuen fürs Script und einen anderen.
Mehrere Funktionen sind möglich und vorgesehen. Das Skript sucht sich "seine" Funktion da raus.
Und ein Raum heisst "Hinterer Raum" ohne die ". Kann das Leerzeichen hier Probleme machen?
Ich vermeide es grundsätzlich bei iwelchen Bezeichnungen die keine reinen Bezeichnungstexte sind, Leerstellen oder Umlaute zu verwenden, ich verwende da immer _ und für Umlaut ae usw, deswegen kann ich Dir das nicht sicher sagen. Das Skript wandelt sowas sogar bei Ausgaben in "schöne" Texte um, Vermutlich gehts weil sonst schon andere gejammert hätten, aber ohne Garantie.
-
@Pittini
Ich habe mal getestet. Es liegt wohl nicht daran, dass die Datenpunkte in FHEM zwei Räume haben, sondern an den Datenpunkten an sich. Ich habe bei einem den Raum "iobroker" entfernt. Wenn ich ihn weglassen startet das Skript ganz normal, wenn ihm die Funktion BatterieSpannung_30 zuweise, kommt es gleich zu obiger Fehlermeldung. So sieht der Datenpunkt aus, wie er aus dem FHEM-Adapter kommt:
Gruss, Jürgen
EDIT: Kann es sein, dass sich das Script daran stört, dass der Datenpunkt als Wert ok hat?
-
@Wildbill sagte in [Vorlage] Generische Batteriestandsüberwachung + Vis-ausgabe:
EDIT: Kann es sein, dass sich das Script daran stört, dass der Datenpunkt als Wert ok hat?
Das vermute ich auch grad (gabs bisher noch nie und hat noch keiner gebraucht), ich schau mir das grad mal genauer an, gib mir paar Minuten.
Edit: Jap daran liegts, was meldet er denn wenn nicht ok? Dann bau ich das mit rein.
Edit2: Hab neue Version auf Git, alles was Text ist und nicht Status ok hat wird als leer gesehen, ok als voll. Bitte mal testen obs so klappt.
-
@Pittini
Die neue Version hole ich mir gleich. Aktuell grüble ich bei einem weiteren komischen Effekt. Warum wird mir der Bewegungsmelder im Bild als der mit der leersten Batterie angezeigt? Sowohl die Spannung als auch der prozentuale Wert liegt höher, als bei anderen:
So sehen die Datenpunkte in iobroker aus:
Gruss, Jürgen
-
Und der Test mit der aktuellen Version schlug leider dennoch fehl. Habe einen der FHEM-Datenpunkte dazu genommen, extra den zweiten Raum iobroker entfernt, aber es kommt dennoch die Fehlermeldung wie am Anfang. So sieht der Datenpunkt aus:
Wenn die Batterie leer wird meldet er AFAIK lowbat.
Gruss, Jürgen -
@Wildbill sagte in [Vorlage] Generische Batteriestandsüberwachung + Vis-ausgabe:
Die neue Version hole ich mir gleich. Aktuell grüble ich bei einem weiteren komischen Effekt. Warum wird mir der Bewegungsmelder im Bild als der mit der leersten Batterie angezeigt? Sowohl die Spannung als auch der prozentuale Wert liegt höher, als bei anderen:
Stell mal Testweise Zeile 18 auf false. Es gibt nämlich dummerweise 2 Varianten was die % bedeuten können, die einen Adapter sagen die reine Batteriekapazität an, Also bei 3V Soll und Anzeige 50% hat die Batterie 1,5V. Die andere Variante rechnet intern das aufs Gerät um, also wieder 3V Soll, Anzeige 50%, (Gerät würde unter 2,6Volt ausfallen) ergibt dann ne Batteriespannung von 2,8V.
-
@Pittini
Wenn ich das auf false stelle, dann muss ich plötzlich viele Batterien tauschen:
Das mit FHEM kann ich auch anders lösen. Ich erstelle mir eigene Datenpunkte die ich dann per Skript auf true/false schalte. Die paar FHEM-Geräte sind eh nur noch Altlasten, die ich nach und nach ersetze. Wegen mir brauchst Du da keine große Energie rein stecken. Das mit der Anzeige verwirrt mich gerade mehr.
Gruss, Jürgen
-
@Wildbill sagte in [Vorlage] Generische Batteriestandsüberwachung + Vis-ausgabe:
Und der Test mit der aktuellen Version schlug leider dennoch fehl.
Hm, das ist aber sehr seltsam. Klick doch bitte bei dem Datenpunkt mal auf das Bleistiftsymbol, dann auf Raw und mach mir nen Screenshot davon.
-
@Pittini
So sieht das RAW aus:Das mit den Prozentwerten überlege ich gerade. In Phoscon werden mir bei dem gelben Gerät auch 87% angezeigt, bei den anderen auch die unter %bat angezeigten Werte. Wenn die 87% in Phoscon bedeuten, dass 13% der Batterie "fehlen", dann wären die Spannungen unter Uist ja doch korrekt (wenn es linear wäre) und entspräche den Tatsachen. Dann müsste ich entweder Umin runter setzten oder wirklich tauschen gehen. Da es aber CR2032 sind, die recht tief runter gehen, werde ich wohl eher Umin runter nehmen. Oder liege ich da nun falsch?
Gruss, Jürgen
-
Nein, mit ProzMeansLive = true; muss es richtig sein. Sonst zeigt es mir bei neuen Geräten mit neuen Batterien ja 0% Uist und -400% abgelaufene Lebensdauer an, was nicht sein kann. Also, warum denkt er, dass 2.48Volt weniger als 2.40 Volt sind?
Gruss, Jürgen
-
@Wildbill sagte in [Vorlage] Generische Batteriestandsüberwachung + Vis-ausgabe:
Und der Test mit der aktuellen Version schlug leider dennoch fehl.
Also ich hab mir jetzt grad extra ne "virtuelle" Testbatterie gebaut, entsprechend Deinen Rawdaten und der den Status ok verpasst.
und die nimmt er jetzt einwandfrei mit dem update:
Zeig mir bitte nochmal das Log vom Skript.
-
@Wildbill Du könntest doch über "alias" die Datenpunkte die "ok" zurückmelden auf "true/false" konvertieren?!
-
@Wildbill sagte in [Vorlage] Generische Batteriestandsüberwachung + Vis-ausgabe:
Also, warum denkt er, dass 2.48Volt weniger als 2.40 Volt sind?
Das is ne Gute Frage, da muß ich mal in die Formeln guggen ob da was nicht passt, wollte mich erstmal um die FHEM Geschichte kümmern, eins nach dem anderen.
-
@Pittini
Kein Stress. Das mit Alias-Datenpunkten true/false hatte ich vor. Aber wenn es ohne geht, ist es auch gut. Ich füge jetzt erst einmal die restlichen unkritischen Datenpunkte wieder zu. Doppelte Zuweisung bei Funktion scheint schon einmal keine Rolle zu spielen.Gruss, Jürgen
-
@Wildbill So, also die Sache mit der niedrigsten Batt stimmt schon so, wenn auch nicht auf den ersten Blick ersichtlich warum.
Die Werte sind ja nur über % Vergleichbar. Batterien die nur ok, true/false etc. melden werden bei der ermittlung der niedrigsten Batt nicht berücksichtigt, die melden ja nur quasi voll oder leer.
Wenn ich jetzt Deine Liste nehm und diejenigen rausstreich die nicht berücksichtigt werden, schaut das gleich logischer aus:
-
@Pittini
So, zum FHEM-Problem, das ist irgendwie keines mehr. Warum auch immer war noch Script 1.5.2 in iobroker aktiv. Habe das neue nochmal rein kopert, neu gestartet und passt.
Zum Batteriestand verstehe ich das nicht ganz. Vergleichen wir den gelben sensor27 zum Beispiel mit sensor3 3 Zeilen tiefer.
Der gelbe wird in Phoscon mit Batteriestand 87% angezeigt. Sensor3 hat in Phoscon nur noch 60%. Die Spannungen sind komischerweise aber gerade andersrum. Der mit 87% zeigt mehr Spannung als der mit nur 60%. Da müsste doch die Spannung bei dem mit nur 60% niedriger sein und der gelb angezeigt werden?Gruss, Jürgen
EDIT: Die Prozentwerte aus Phoscon %live entsprechen eigentlich schon den %bat denke ich. Und irgendwie wird das im Skript dann doppelt gemoppelt?
-
@Wildbill Ich schau mir das später oder morgen nochmal an, jetzt bin ich erstmal weg
Solltest Du die Möglichkeit dazu haben, miß doch mal die 60% Batterie mit nem Voltmeter, dann sollten wir sicher wissen was die 60% eigentlich meinen. -
@Pittini
Kein Problem, eilt nicht, ich habe jetzt wenigstens mal alle Batterien mit drin, auch die von FHEM.Ich gehe davon aus, dass eine Batterie, die Phoscon mit 60% an iobroker meldet weniger Spannung hat, als eine, die 82% anzeigt. Denn komplett neue Batterien werden mit 100% angezeigt und die Werte werden nach und nach niedriger, nie höher. Deshalb sollte ein Sensor mit aktuell 87% ( der oben mit 2,48Volt angezeigt wird) IMHO eigentlich mehr Spannung haben als ein Sensor der mit 60% gemeldet wird, der aber mit 2,64Volt aus dem Skript kommt. Die letzte Spalte %live wäre hier ja IMHO der korrekte prozentuale Wert, nur die vorletzte Spalte %bat dreht das dann irgendwie um und der mit eigentlich niedrigerer Spannung hat dann hier den höheren Wert. Ich glaube fast, ich muss doch ProzMeansLive = false stellen. Dann stimmt die Reihenfolge, soweit ich sehe. Ich muss dann wohl doch die Umin runter setzen und es passt dann. Die CR2032 gehen ja AFAIK noch bis knapp an die 2 Volt runter.
Gruss, Jürgen
EDIT: Ja, das wars doch. Noch die Mindestspannung runter und schon schaut alles gut aus. Fasse zusammen: Reihenfolge stimmt nun und die FHEM-Datenpunkte sind auch mit drin, obwohl doppelte Raumbelegeung. Ebenso die, die nun zwei Werte bei Funktion zugeordnet haben. Deconz, FHEM, HM-RPC laufen nun einwandrei. VIELEN DANK
-
@Wildbill sagte in [Vorlage] Generische Batteriestandsüberwachung + Vis-ausgabe:
Kein Problem, eilt nicht, ich habe jetzt wenigstens mal alle Batterien mit drin, auch die von FHEM.
Hab noch ne Änderung zum FHEM Thema gemacht, ohne die gibts nen Fehler bei Werteänderung. Is auf Git unter gleicher Version. Die Umin solltest nicht zu weit runtersetzen unter 2,6V fallen z.B. mein Xiaomi Sensoren schon aus.
-
@Pittini
Hi, habe eben die aktuelle Version gezogen. Betraf die Änderung auch das Zurückschalten auf den state "ok" wenn man die Batterie getauscht hat? Ich hatte da nämlich gestern Abend noch einen Thermostat in FHEM, der leere Batterien gemeldet hat, was im Script auch ausgewertet wurde. Nur ist die Änderung nach erfolgtem Wechsel wohl am Script vorbei gegangen, die Batterie wurde weiterhin als leer angezeigt. Erst als ich es eben aktualisiert und neu gestartet habe, ist die Anzeige im VIS auf grün und die Batterie ist wieder voll. Ich habe allerdings gestern das Script auch nicht mehr neu gestartet, da die FHEM-Geräte eine Weile brauchen, bis sie States an die Zentrale melden. Aber heute morgen war der state definitv auf ok, im Script aber nicht berücksichtigt.
Ansonsten scheint alles zu laufen, wie es soll.
Gruss, Jürgen
