Neuer ioBroker-Blog online: Monatsrückblick März/April 2026

[toste]

@Wildbill sagte in [Vorlage] Generische Batteriestandsüberwachung + Vis-ausgabe:

@toste Nein, ich meine nicht verschiedene Instanzen. Beim hm-rpc.0 haben die Homematic-Geräte jeweils mehrere Unterornder von 0 bis x (sieben habe ich teilweise bei Geräten.). Das sind die jeweiligen Channel bei den Geräten. Und bei vielen gibt es in mehreren Channel eben einen Punkt lowbat, nur werden diese anscheinend unterschiedlich oft von Homematic gemeldet. Und die bislang von mir verwendeten Punkte im Channel 0 sind halt die, die anscheinend am wenigsten häufig aktualisiert werden.

Gruss, Jürgen

Dann habe ich das falsch verstanden. Bei meinen Geräten finde ich "lowbat" und lowbat_alarm" immer in Channel "0". Hast du mal ein Beispiel, bei welchen Geräten das so ist? Für die Homematic-IP Geräte gibt es eine Technical Documentation mit der Beschreibung alle Parameter für alle Geräte. Für Homematic Geräte ist das zum Teil hier beschrieben:
https://www.eq-3.de/downloads/download/homematic/hm_web_ui_doku/hm_devices_Endkunden.pdf

[Wildbill]

@toste Hier beispielhaft mal ein optischer Fenstermelder:

Der Punkt lowbat unter Channel 0 hat Zeitsptempel 08.05.2020 21:24 und der im Channel 1 10.05.2020 16:21, also von vorhin erst.
Auch die Rauchmelder haben das so. Andere, wie die Heizungsventile haben einmal den state als lowbat, aber im anderen Kanal separat eine direkte Spannungsanzeige.
Ganz extrem ist es bei der Alarmsirene. Die hat in jedem ihrer 5 Channel einen loabat-Punkt. Aber die werden leider alle nur so alle 2 Tage aktualisiert, wie es aussieht. Habe im Script deshalb nun 2880 (48 Stunden) eingestellt und beobachte mal.

Gruss, Jürgen

[cy_coe]

Hi,

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.

[toste]

@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.

[Pittini]

@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?

[cy_coe]

@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...

[Wildbill]

@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

[Pittini]

@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.

[cy_coe]

@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ß.

[kilasat]

@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]

@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.

[kilasat]

@Wildbill

Was sind das genau für Sensoren an der Phoscon bei dir?

[Wildbill]

@kilasat sagte in [Vorlage] Generische Batteriestandsüberwachung + Vis-ausgabe:

@Wildbill

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

[kilasat]

@Wildbill

Hast Du auch Xiaomi Bewegungsmelder an der Phoscon App dran?

[Wildbill]

@kilasat
Nein, bei mir besteht alles aus Ikea Tradfri-Komponenten.

Gruß, Jürgen

[der-eine]

@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?

[Pittini]

@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.

[der-eine]

@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?

[TDCroPower]

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!

[Pittini]

@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).)