[Vorlage] Generische Batteriestandsüberwachung + Vis-ausgabe
-
@Wildbill Für den Fensterkontakt kann ich dies bestätigen. Eigentlich sind alle Systemrelevanten Parameter immer in Channel 0. Die anderen Kanäle sind ja zur Kommunikation mit anderen Geräten. Ich habe mit "LOWBAT" aus Channel "0" noch nie Probleme gehabt. Viele von Beispielen hier im Forum oder im Internet verwenden m.E. immer Channel 0.
-
@cy_coe sagte in [Vorlage] Generische Batteriestandsüberwachung + Vis-ausgabe:
Ich habe auch Probleme mit LOWBAT Meldungen. Ich bekomme immer ein "Object "..." does not exist".
Egal ob ich auf den Datenpunkt per hm-rpc oder per mqtt drauf zugreife.Versteh grad nicht was mqtt mit ner lowbatmeldung zu tun hat, und mit was Du auf was und warum zugreifst. Kannste bitte Dein Problem mal etwas präziser schildern?
-
@Pittini Naja, wenn ich den Datenpunkt vom hm-rpc Adapter nehme, bekomme ich: "getState "hm-rpc.0.OEQ1205605.0.LOWBAT" not found (3) states[id]=null".
Da steht aber auch tatsächlich nichts drin - nichtmal 'false'. Ich kann aber auf die Thermostaten auch per mqtt zugreifen, und dort habe ich beim LOWBAT auch ein 'false' drin stehen (deswegen habe ich das ausprobiert). Sollte prinzipiell eigentlich egal sein, woher die Daten kommen, denke ich.
Muß ich bei LOWBAT noch irgendwas anderes beachten? Habe da nur den Raum und als Funktion "BatterieSpannung_30" drin - also genau so, wie ich das auch bei Zahlenwerten gemacht habe... -
@cy_coe
Mach doch mal Screenshots von den Datenpunkten bzw. der Objektstruktur. Und einen kleinen Auszug aus dem Log, was um die Fehlermeldung herum so alles passiert.Gruss, Jürgen
-
@cy_coe sagte in [Vorlage] Generische Batteriestandsüberwachung + Vis-ausgabe:
Da steht aber auch tatsächlich nichts drin - nichtmal 'false'.
Wenn da nix drinsteht isses logisch dass das Skript mault, da scheint aber dann was grundsätzliches bei Dir im argen zu liegen.
Ich kann aber auf die Thermostaten auch per mqtt zugreifen, und dort habe ich beim LOWBAT auch ein 'false' drin stehen (deswegen habe ich das ausprobiert). Sollte prinzipiell eigentlich egal sein, woher die Daten kommen, denke ich.
An sich ja, aber es ist schon relevant wie die Ordnerstruktur drüber beschaffen ist, weil auf den Parent Channel zugegriffen wird
Muß ich bei LOWBAT noch irgendwas anderes beachten? Habe da nur den Raum und als Funktion "BatterieSpannung_30" drin - also genau so, wie ich das auch bei Zahlenwerten gemacht habe...
Nein, da is nix besonderes zu beachten, aber ohne weitere Details wie Logs, Screenshot von der Objektliste etc. werden wir dem Problem nicht auf die Schliche kommen.
-
@Pittini said in [Vorlage] Generische Batteriestandsüberwachung + Vis-ausgabe:
Wenn da nix drinsteht isses logisch dass das Skript mault, da scheint aber dann was grundsätzliches bei Dir im argen zu liegen.
Ja, das befürchte ich auch. Ich muß mir die ganze Geschichte mit den Thermostaten bei mir wohl nochmal genau anschauen. Habe auch den Verdacht, daß da noch was schimmelig ist. Ich melde mich dann wieder, wenn ich mehr weiß.
-
@Pittini - Danke Carlo. Super Script wie immer.
Hat jemand eine Idee, ob die Xiaomi Sensoren am Conbee II irgendwie vernünftige Batteriewerte ausgeben? Habe hier immer nur 100% stehen. Kann nicht stimmen, da es am Gateway bereits nur noch 65% hatte
-
@cy_coe said in [Vorlage] Generische Batteriestandsüberwachung + Vis-ausgabe:
@Pittini said in [Vorlage] Generische Batteriestandsüberwachung + Vis-ausgabe:
Wenn da nix drinsteht isses logisch dass das Skript mault, da scheint aber dann was grundsätzliches bei Dir im argen zu liegen.
Ja, das befürchte ich auch. Ich muß mir die ganze Geschichte mit den Thermostaten bei mir wohl nochmal genau anschauen. Habe auch den Verdacht, daß da noch was schimmelig ist. Ich melde mich dann wieder, wenn ich mehr weiß.
So, jetzt läuft es immerhin schonmal bei drei Thermostaten, bei denen der Datenpunkt jetzt auch ein 'false' zurückgibt. Damit funktioniert auch dein Skript bei mir. Der Fehler lag also eindeutig bei meinem System.
-
Was sind das genau für Sensoren an der Phoscon bei dir?
-
@kilasat sagte in [Vorlage] Generische Batteriestandsüberwachung + Vis-ausgabe:
Was sind das genau für Sensoren an der Phoscon bei dir?
Unter Sensoren landen alle Bewegungsmelder, Fernbedienungen und ähnliches. Also alles was keine Lampe ist.
Gruß, Jürgen
-
Hast Du auch Xiaomi Bewegungsmelder an der Phoscon App dran?
-
@kilasat
Nein, bei mir besteht alles aus Ikea Tradfri-Komponenten.Gruß, Jürgen
-
@Pittini sagte in [Vorlage] Generische Batteriestandsüberwachung + Vis-ausgabe:
Bisher nicht, es gibt aber den Lastmessage Datenpunkt, der bisher immer die letzte Warnmeldung ausgab, das könnte man durchaus auf alle Warnmeldungen erweitern. Werd ich wohl im nächsten update einbauen. Was auch noch geplant ist, ist ne Erkennung und Warnung ob ein Gerät schon "tot" ist, anhand der letzten Aktualisierung.
Wird für die "toten" Gerät auch mal eine Auflistung (verkettung) geben? Wäre genau so sinnvoll denke ich wie bei den mit den unterschrittenen V Level.
Was meinst Du?
-
@der-eine sagte in [Vorlage] Generische Batteriestandsüberwachung + Vis-ausgabe:
Wird für die "toten" Gerät auch mal eine Auflistung (verkettung) geben? Wäre genau so sinnvoll denke ich wie bei den mit den unterschrittenen V Level.
Was meinst Du?Naja, nen Zähler dafür gibts ja unter "javascript.0.BatterieUeberwachung.DeadDeviceCount" und in der Lastmessage sollten se auch drin sein. Kann man schon machen, aber eigentlich ging ich nicht davon aus dass wer soviele tote Geräte hat dass man gleich ne Liste dafür braucht.
-
@Pittini den Zähler hab ich schon gesehen. Ist es nicht so, wenn die Batterie als „tot“ gemeldet wird in Last Message und danach eine Batterie unter die 2,4V geht die Nachricht für die Tote Batterie überschrieben wird?
-
Ich bedank mich hier auch erst einmal bei dir für das umfangreiche Script Projekt, dass mir auch direkt als eines der wichtigesten Punkte bei der Nutzung von Batterie betriebenen Smart Geräten war.
Ich würde gerne auf deine Lösung wechseln, denn meine Lösung ist/war eine Blockly Lösung bei der ich meine batterie betriebenen Geräte manuell ins Script hinzufügen bzw. pflegen musste.Was ich in deiner Lösung ein wenig vermisse und das habe ich in meiner Lösung eingebaut, ist eine "eigene" Telegram Nachricht mit benutzerwichtigen Informationen... bei mir die notwendige Batterie für das gemeldete Gerät.
Ich habe dies folgendermaßen gelöst...
Könntest du so etwas ebenfalls einbauen, das in der Telegram Info die passende Batterie für das Gerät mit geschickt wird?
Wenn das gehen würde wäre ich sofort bei deinem Script dabei! -
@TDCroPower sagte in [Vorlage] Generische Batteriestandsüberwachung + Vis-ausgabe:
Ich würde gerne auf deine Lösung wechseln, denn meine Lösung ist/war eine Blockly Lösung bei der ich meine batterie betriebenen Geräte manuell ins Script hinzufügen bzw. pflegen musste.
Was ich in deiner Lösung ein wenig vermisse und das habe ich in meiner Lösung eingebaut, ist eine "eigene" Telegram Nachricht mit benutzerwichtigen Informationen... bei mir die notwendige Batterie für das gemeldete Gerät.
Könntest du so etwas ebenfalls einbauen, das in der Telegram Info die passende Batterie für das Gerät mit geschickt wird?
Wenn das gehen würde wäre ich sofort bei deinem Script dabei!Sorry wenn ich das jetzt so sage, aber, der Wunsch scheint mir nicht zu Ende gedacht. Der von Dir beschriebene Vorteil, eben nicht jedes Gerät im Skript anlegen zu müssen würde verloren gehen wenn für jedes Gerät ein Batterietyp im Skript hinterlegt werden soll. Oder wie anders stellst Du Dir vor dass das Skript an die Infos kommen soll welche Batterie in welchem Gerät steckt? Über die Spannung geht schon mal nicht, denn z.B. 1,5V haben sowohl AA, als auch AAA Batterien.
TRotzdem gibt es imho eine Lösung, da ja der Name des Gerätes gemeldet wird, schreib doch da einfach den Batterietyp dahinter wenn das so wichtig ist (Ich persönlich weis welche Batterie in welches Gerät kommt).) -
@Pittini hast natürlich Recht, aber in meinem Fall habe ich nicht unter der Spannung unterschieden, sondern anhand des Batterie Typen AA, AAA, CR1632 und CR2450.
Bei den ganzen Batterie Geräten kommen ja im Normalfall keine anderen Typen mehr reinDer Sinn dabei war das auch meine Frau sofort weiß welche Batterie sie für die Auswechslung benötigt bzw. ich ohne Ausbau der Batterie den "Lagerbestand" des Types überprüfen kann und gegebenenfalls nach bestellen muss.
Gerade durch die ZigBee und Bluetooth Gerät ist die Anzahl der Batterie betriebenen Smart Geräte bei uns drastisch gestiegen und wird weiter steigen, da noch "lücken" vorhanden sind die per Sensor gemessen werden sollen.
-
@TDCroPower sagte in [Vorlage] Generische Batteriestandsüberwachung + Vis-ausgabe:
hast natürlich Recht, aber in meinem Fall habe ich nicht unter der Spannung unterschieden, sondern anhand des Batterie Typen AA, AAA, CR1632 und CR2450.
Das ist für ne Batteriestandsüberwachung aber auch wieder nicht praktikabel, weil ich nicht weis wieviele (grad bei AA und AAA) Batterien im Gerät sind und somit, wenn ich das als Funktionskennung nehmen würde, wiederum nicht weis welche Spannung den nun die Sollspannung ist.
Bei den ganzen Batterie Geräten kommen ja im Normalfall keine anderen Typen mehr rein
Würde ich so nicht unterschreiben, die Xiomi Teile verwenden z.B. gern auch CR2032
Der Sinn dabei war das auch meine Frau sofort weiß welche Batterie sie für die Auswechslung benötigt bzw. ich ohne Ausbau der Batterie den "Lagerbestand" des Types überprüfen kann und gegebenenfalls nach bestellen muss.
Wie schon gesagt, schreibs in den Namen mit rein, oder leg ne Liste für die Frau an wieviele von welchem Typ in welches Gerät gehören oder leg einfach immer genug auf Lager
Gerade durch die ZigBee und Bluetooth Gerät ist die Anzahl der Batterie betriebenen Smart Geräte bei uns drastisch gestiegen und wird weiter steigen, da noch "lücken" vorhanden sind die per Sensor gemessen werden sollen.
Da mag ich ja auch gar nicht wiedersprechen, ist hier das selbe.
-
Das wichtigste ist doch, dass man rechtzeitig benachrichtigt wird und die Reaktionszeit entsprechend vorhanden ist um zu tauschen oder um zu bestellen. Das hängt nun von dem eingestellten Schwellwert ein.
