Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[Andersmacher]

Vorab:
Ich frage hier im ioBroker Forum und nicht im HM-Forum, weil es zwar um HM-Sensoren geht, jedoch um States, die man in der CCU2 nicht hat/nicht auswerten kann, sondern nur in ioBroker.

Wenn Batterien (z. B. in einem Rauchmelder) leer werden, geht irgendwann LOWBAT auf true. Nachdem man neue Batterien eingelegt hat, geht LOWBAT wieder auf false.
Entweder, wenn man mit dem Wechseln länger/zu lange wartet oder gleichzeitig mit LOWBAT=true (das habe ich noch nicht eindeutig feststellen können) geht LOWBAT_ALARM von NO ALARM auf ALARM und in der CCU2 wird die Batteriewarnung als Servicemeldung angezeigt. Diese kann man dann in der CCU2 bestätigen, wobei LOWBAT_ALARM dann offenbar auf ACKNOWLEDGED geht, was mir auch sinnvoll erscheint.

Soweit, so gut. Bis hier ist mir alles klar und ich kann die entsprechenden States wunderbar mit farbigen Batteriesymbolen in VIS anzeigen.

Bei mir ist es jedoch so, daß LOWBAT_ALARM auf ACKNOWLEDGED stehen bleibt, selbst wenn man dann irgenwann neue Batterien einlegt und LOWBAT wieder auf false geht. Dadurch habe ich in VIS dann "dauerhaft" ein Batterie-Alarm-Symbol.

Kann jemand dieses Verhalten bestätigen, oder blicke ich etwas nicht?

Wenn das kein Bug, sondern ein Feature ist, wäre meine Lösung:
Ein Blockly, das auf das Rücksetzen von LOWBAT von true auf false triggert und damit dann LOWBAT_ALARM "per Programm" wieder auf NO ALARM setzen.

Oder wie habt Ihr das gelöst?

[norp2k22]

@andersmacher said in Homematic Batteriemeldungen:

Vorab:
Ich frage hier im ioBroker Forum und nicht im HM-Forum, weil es zwar um HM-Sensoren geht, jedoch um States, die man in der CCU2 nicht hat/nicht auswerten kann, sondern nur in ioBroker.

Wenn Batterien (z. B. in einem Rauchmelder) leer werden, geht irgendwann LOWBAT auf true. Nachdem man neue Batterien eingelegt hat, geht LOWBAT wieder auf false.

Also das ist mir neu, das man bei einem HmIP-SWSD die Batterien wechseln kann, oder generell bei einem Rauchwarnmelder.

@andersmacher said in Homematic Batteriemeldungen:

Ein Blockly, das auf das Rücksetzen von LOWBAT von true auf false triggert und damit dann LOWBAT_ALARM "per Programm" wieder auf NO ALARM setzen.

Diese States werden Normalerweise vom HmIP-HAP oder der HmIP-CCU2/3 gesetzt und man hat selbst keinen Schreibzugriff darauf, wenn ich das richtig verstanden habe.

[bahnuhr]

@norp2k22 sagte in Homematic Batteriemeldungen:

oder generell bei einem Rauchwarnmelder.

HM Rauchmelder sind mit Batterie (nicht die IP)
Also die "alte" Serie.

[norp2k22]

@bahnuhr said in Homematic Batteriemeldungen:

@norp2k22 sagte in Homematic Batteriemeldungen:

oder generell bei einem Rauchwarnmelder.

HM Rauchmelder sind mit Batterie (nicht die IP)
Also die "alte" Serie.

Ah ok, dann wurde das wohl mal geändert.
Habe hier nur die aktuelle HmIP Rauchwarnmelder Generation, da ist eine nicht entfernbare Plastik-abdeckung über den Batterien.

[paul53]

@andersmacher sagte: in VIS dann "dauerhaft" ein Batterie-Alarm-Symbol.

In Vis verwende den HM-RPC-Datenpunkt "LOWBAT" und nicht den von HM-Rega erzeugten "_ALARM"-Datenpunkt.

[Andersmacher]

Erst einmal vielen Dank für Eure Rückmeldungen!

Ja, es geht um HM, nicht um HMIP. Hätte ich wohl noch genauer / eindeutiger beschreiben sollen.

@paul53 Hmm, beide Datenpunkte (LOWBAT und LOWBAT_ALARM) stehen bei mir im RPC- und nicht im Rega-Adapter zur Verfügung. Daher war ich bisher der Ansicht, daß das alles mit Rega gar nichts zu tun hat!?

Aber warum meinst du, daß man in VIS den LOWBAT_ALARM-Datenpunkt nicht benutzen soll? Ist der (warum auch immer) "nicht brauchbar"? Oder meinst Du: Man benötigt ihn nicht?
Den LOWBAT_ALARM-Datenpunkt auszuwerten / anzuzeigen fand ich bisher ganz interessant, weil man dadurch ja letztlich den "Bearbeitungsstatus" der Batterie-Servicemeldung darstellen kann. Durch entsprechende Farbgebung der Batteriesymbole sieht man dadurch auch gleich, wenn eine neue/unbestätigte Batteriemeldung eingegangen ist.
Ich benutze bisher also sowohl LOWBAT als auch LOWBAT_ALARM im VIS.

Angenommen, ich würde weiterhin den LOWBAT_ALARM benutzen (wollen), spräche aus Deiner Sicht etwas gegen die oben beschriebene "Rücksetzmethode" bzw. würdest Du anders vorgehen?

[paul53]

@andersmacher sagte: beide Datenpunkte (LOWBAT und LOWBAT_ALARM) stehen bei mir im RPC- und nicht im Rega-Adapter

Das ist richtig, aber die "_ALARM"-Datenpunkte werden vom Rega-Adapter erzeugt. Ohne Rega-Adapter gibt es sie nicht.

@andersmacher sagte in Homematic Batteriemeldungen:

weiterhin den LOWBAT_ALARM benutzen (wollen)

Dann solltest Du "ACKNOWLEDGED" anders behandeln als "ALARM". Ich würde nur LOWBAT auswerten, denn der ist unabhängig von einer Bestätigung auf der CCU-WebUI und zeigt den tatsächlichen Batterie-Zustand.

[Andersmacher]

@paul53 OK, daß die LOWBAT_ALARM-Datenpunkte nur da sind, weil ich den Rega-Adapter installiert habe, war mir bisher nicht bewußt. Warum die dann aber in der RPC- und nicht in der Rega-Instanz gelistet sind, bleibt mir erst einmal unklar.

Unabhängig davon:
Weißt Du oder jemand anderes, ob die Rega-Instanz diese Datenpunkte aus der CCU ausliest (also ob die Datenpunkte auf der CCU eigentlich bereits vorliegen) oder ob die Rega-Instanz diese Datenpunkte aus irgendwelchen Informationen der CCU "erzeugt" und sie dann im ioBroker bereitstellt?
Ich frage weil:
Wenn diese Datenpunkte auf der CCU bereits vorliegen und die Rega-Instanz sie nur ausliest, dann müßte ja auch die CCU dafür sorgen, daß nach einem Batteriewechsel (also wenn LOWBAT wieder von true auf false wechselt) LOWBAT_ALARM von ACKNOWLEDGED auf NO_ALARM zurückgesetzt wird.
Falls Rega sich die Information für ioBroker selber "zusammenbastelt" müßte ja vermutlich Rega das Rücksetzen von LOWBAT_ALARM veranlassen.
Egal, wie rum es wirklich ist, einer von beiden (CCU oder der Rega-Adapter) scheint doch da dann nicht richtig zu funktionieren - oder? Und ich würde annehmen, daß (falls es wirklich ein Bug ist) eine größere "Behebungs-Chance" bsteht, wenn der Bug im Adapter und nicht in der CCU wäre.

Da eine Batterie-Service-Meldung in der CCU auch "von selber verschwindet", wenn man neue Batterien einlegt, spricht aus meiner Sicht einiges dafür, daß das "Problem" im Rega-Adapter und nicht in der CCU liegt!?

[paul53]

@andersmacher sagte: Da eine Batterie-Service-Meldung in der CCU auch "von selber verschwindet", wenn man neue Batterien einlegt,

Die Service-Meldung entspricht LOWBAT.

[Andersmacher]

@paul53 OK, jetzt schnall ich das vielleicht langsam:
Du sagst "LOWBAT_ALARM nicht benutzen", weil die ersten beiden Zustände davon (NO_ALARM und ALARM) redundant zu LOWBAT (false und true) sind. Lediglich LOWBAT_ALARM=ACKNOWLEDGED ist eine unabhängige weitere Info,...
... die man derzeit aber offenbar nur einmal benutzen kann, wenn man sie nach einem Batteriewechsel nicht "manuell" wieder zurücksetzt. Da bleibt für mich doch noch irgendwie ein Bug übrig.

Aber sei es drum, der Rest ist mir jetzt deutlich klarer geworden. Danke!

[Dr. Bakterius]

@andersmacher Du könntest ja die beiden DP auch per Skript verknüpfen und so auswerten. Also wenn LOWBAT auf true und LOWBAT_ALARM auf Alarm, dann Batterie leer und muss bestätigt / getauscht werden. Wenn LOWBAT auf true und LOWBAT_ALARM auf ACKNOWLEDGED, dann wurde zwar bestätigt aber die Batterie noch nicht getauscht. Und wenn LOWBAT_ALARM auf false und LOWBAT_ALARM auf ACKNOWLEDGED, dann ist alles okay. Aber was das bringen soll ist mir auch nicht klar...

[Andersmacher]

@dr-bakterius Die Auswertung, die Du via Skript vorschlägst, habe ich im Prinzip via Signalbilder umgesetzt. Funktioniert auch, aber eben nur einmal bzw. nur "in die eine Richtung", weil LOWBAT_ALARM (zumindest bei mir) nicht mehr zurückgesetzt wird, nachdem die Batterie gewechselt wurde.

Du schreibst: "Aber was das bringen soll ist mir auch nicht klar..."
Einfach nur die Info, ob das "ein bekannter (den ich vielleicht bewußt noch eine Weile ignoriere, weil ich aus Erfahrung weiß, daß der Sensor auch mit einer schlappen Batterie noch einige Wochen läuft) oder ein neuer Alarm" ist.
Ganz klar: Das ist nichts, was man haben muß. Ich fand das einfach nur "nice to have".

Ich kann auch damit leben, wenn das jetzt eben so ist, wie es ist, also nicht automatisch zurück gesetzt wird.
Meine "Uranfrage" (...Kann jemand dieses Verhalten bestätigen, oder blicke ich etwas nicht?...) zielte auch darauf ab, ausschließen zu können, daß ich einfach nur etwas falsch mache.

Aber je länger ich jetzt darüber nachdenke, desto weniger verstehe ich, was das Setzen von LOWBAT_ALARM auf ACKNOWLEDGED für einen Sinn haben könnte, wenn es nicht auch irgendwann (z. B. bei einem Batteriewechsel, also z. B. wenn LOWBAT von true wieder auf false gegangen ist) wieder zurück gesetzt wird.

Aber ich will das jetzt auch nicht dramatisieren, denn es scheint ja für die meisten (alle aus mir (;-)) ohnehin nicht relevant zu sein.

Dank an alle, für Eure Antworten.

[Dr. Bakterius]

@andersmacher sagte in Homematic Batteriemeldungen:

Die Auswertung, die Du via Skript vorschlägst, habe ich im Prinzip via Signalbilder umgesetzt.

Mit dem Skript würde es aber so funktionieren wie du dir das vorstellst. Gibt aber einen zusätzlichen Datenpunkt...

[Andersmacher]

@dr-bakterius Vorab:
Du schriebst in Deinem vorletzten Post: "...Und wenn LOWBAT_ALARM auf false und LOWBAT_ALARM auf ACKNOWLEDGED, dann ist alles okay..."
Ich gehe davon aus, daß Du meintest:"...Und wenn LOWBAT auf false und LOWBAT_ALARM auf ACKNOWLEDGED, dann ist alles okay...", denn LOWBAT_ALARM kann ja nicht zwei Zustände gleichzeitig annehmen.

Jetzt zu Deinem letzten Post:
Hmm, da stimme ich Dir nicht ganz zu, denn wie gesagt:
Ist LOWBAT_ALARM erstmal auf ACKNOWLEDGED gegangen, kehrt es nach einem Batteriewechsel nicht mehr von allein zurück. Das bedeutet doch, wenn LOWBAT das nächste mal auf true geht, steht LOWBAT_ALARM noch immer auf ACKNOWLEDGED und dadurch ist jegliche weitere/erneute Auswertung falsch/sinnlos.

Ich denke, man kann das drehen / auswerten, wie man will (also via Signalbilder, Skript, ...) solange, wie LOWBAT_ALARM von ACKNOWLEDGED nicht wieder zurück gesetzt wird, ergibt das alles keinen Sinn.

Was mir aber gerade bewußt wird:
Ich habe noch nicht getestet (dazu müßte man wohl mal einen Sensor nicht mit Batterien, sondern mit einem einstellbaren Netzteil versorgen, wozu ich momentan keine Möglichkeit habe), ob LOWBAT_ALARM vielleicht genau in dem Augenblick doch noch zurückgesetzt wird, wo LOWBAT erneut auf true geht (also wenn die Batterie das zweite mal leer wird). Wäre aber auch seltsam, weil ja dann der Zustand LOWBAT_ALARM=NO ALARM niemals wieder auftauchen würde.

[Dr. Bakterius]

@andersmacher sagte in Homematic Batteriemeldungen:

ob LOWBAT_ALARM vielleicht genau in dem Augenblick doch noch zurückgesetzt wird, wo LOWBAT erneut auf true geht (also wenn die Batterie das zweite mal leer wird)

Genau das habe ich angenommen. :relaxed:

Wenn es aber einmalig von NO ALARM auf ACKNOWLEDGED geht und da immer verbleibt, ist der DP völlig sinnlos. Kann ich mir nicht vorstellen.

Und natürlich LOWBAT auf false und LOWBAT_ALARM auf ACKNOWLEDGED. War ein Copy&Paste Fehler... :wink:

[Muchul]

Nur mal ein Gedanken Spiel:
Wenn der Datenpunkt nicht aus der CCU kommt, und dieser Datenpunkt gelöscht werden würde, welchen Status hätte dieser, wenn der Adapter ihn wieder neu anlegen würde?