Fensterdrehgriff "frisst" Batterien

Begonnen von Marko1976, 29 September 2025, 17:37:06

Vorheriges Thema - Nächstes Thema

Marko1976

Hallo, ich habe einen Fensterdrehgriff vom Typ HM-SEC-RHS. Dieses Homematik-Classic Gerät "frisst" Batterien schneller als ich sie ersetzen kann.
Zwei neu eingesetzte LR44 Knopfzellen sind spätestens am übernächsten Tag leer - wiederholt.

Sind mit diesem Typ irgendwelche Problme bekannt?
Wie und wo kann ich zur Fehleranlayse ansetzen?


Zwei iedentische Fensterdrehgriffe funktionieren tadellos.

HMInfo gibt bezogen auf das Gerät folgendes wieder:
configCheck done:

 missing register list
    sensor_fenstergriff_schlafzimmerfensterlinks: RegL_00.,RegL_01.

 trigger sent to undefined device
    sensor_fenstergriff_schlafzimmerfensterlinks: 111111


Beta-User

Zitat von: Marko1976 am 29 September 2025, 17:37:06Wie und wo kann ich zur Fehleranlayse ansetzen?
Da du das Ganze ja bereits via hmInfo eingegrenzt hast (und uns den Rest der eigentlich "üblichen" Infos nicht mitteilst, https://forum.fhem.de/index.php?topic=71806.0 und die anderen im Anfängerbereich angepinnten Beiträge):
Lösche den nicht bekannten peer aus dem Device, vielleicht hilft das.
So versucht der Kontakt, diesen jedes Mal zu erreichen, was eben zumindest etwas Energie braucht...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Sailor

Hallo Marko

Zitat von: Marko1976 am 29 September 2025, 17:37:06Hallo, ich habe einen Fensterdrehgriff vom Typ HM-SEC-RHS. Dieses Homematik-Classic Gerät "frisst" Batterien schneller als ich sie ersetzen kann.

Das ist ein generelles Problem bei den HM-SEC-RHS.
Die haben ein generelles Design-Problem, welches mit der Zeit auftritt.
Die Teile gehen dann in eine Unendlich-Sendeschleife bis die Batterie leer ist.

Am Anfang kann man noch einen kompletten Reset durchführen und dann hat man für einen Zeitraum X Ruhe, bevor das Ganze wieder von vorne losgeht.

Ich habe 13 dieser Sensoren im Einsatz und mittlerweile zeigen etwa 10 dieser Sensoren diese Symptomatik.

Werde diese Sensoren demnächst ersatzlos rausschmeißen - Es nervt nur noch.

Ggf, werde ich irgendwann die IP-Variante einsetzen. Dies hat aber eine Systemumstellung zur Folge.

Gruss
    Sailor
******************************
Man wird immer besser...

Marko1976

Zitat von: Beta-User am 09 Oktober 2025, 07:40:51Da du das Ganze ja bereits via hmInfo eingegrenzt hast (und uns den Rest der eigentlich "üblichen" Infos nicht mitteilst, https://forum.fhem.de/index.php?topic=71806.0 und die anderen im Anfängerbereich angepinnten Beiträge):
Lösche den nicht bekannten peer aus dem Device, vielleicht hilft das.
So versucht der Kontakt, diesen jedes Mal zu erreichen, was eben zumindest etwas Energie braucht...
Was soll dieser - gefühlt ohne Komma und Punkt geschriebene - Text jetzt sage? Auf der einen Seite ein "Gutgemacht" und gleich dahinter ein "Böser Bube, wieder falsch". Was denn nun? Irgendwie fehlt in den ersten zwei Zeilen auch ein Wort, jedenfalls nach meinem Gefühl.
Sollten die letzten beiden Zeilen ein Hinweis zu einem Vorgehen sein, wäre es vielleicht besser gewesen diese durch eine Leerzeile zu trennen. Ich weiß nicht wie es anderen geht, ich jedenfalls werde aus dem Post nicht wirklich schlau.

Interessant wäre aber falls die letzten beiden Zeilen eine Anleitung sein sollen auch das wie. Reading oder Attribut löschen, ok - aber wie löscht man einen peer? reicht es das Reading zu löschen in dem der Eintrag steht oder muss man dafür womöglich ein Register löschen? Also viele Unklarheiten die um weitere Detailierung lächzen.

Marko1976

Zitat von: Sailor am 09 Oktober 2025, 11:10:07Das ist ein generelles Problem bei den HM-SEC-RHS.
Die haben ein generelles Design-Problem, welches mit der Zeit auftritt.
Die Teile gehen dann in eine Unendlich-Sendeschleife bis die Batterie leer ist.
Heißt auf gut Deutsch, das Ding ist nicht mehr zu retten oder lohnt sich doch ein Reset-Versuch?
Kann man das mit der Senseschleife irgednie optisch erkennen? Mir ist nur aufgefallen, dass der Griff statt dem grünen oft ein rotes Licht am Ende einer Aktion angezeigt hat. Auch scheint mir die Zeitspanne selbst bei einer Dauersendeschleife extrem knapp um komplett neue Batterien leer zu saugen (waren keine 24h).

vbs

Zitat von: Marko1976 am 09 Oktober 2025, 16:24:41Interessant wäre aber falls die letzten beiden Zeilen eine Anleitung sein sollen auch das wie. Reading oder Attribut löschen, ok - aber wie löscht man einen peer? reicht es das Reading zu löschen in dem der Eintrag steht oder muss man dafür womöglich ein Register löschen? Also viele Unklarheiten die um weitere Detailierung lächzen.
Also ich meine hier eine konkrete Handlungsanweisung aus diesem Satz herauslesen zu können: "Lösche den nicht bekannten peer aus dem Device, vielleicht hilft das.".

In der commandref finde ich Folgendes:
peerBulk <peerch1,peerch2,...> [set|unset]
peerBulk will add peer channels to the channel. All peers in the list will be added.
with unset option the peers in the list will be subtracted from the device's peerList.
peering sets the configuration of this link to its defaults. As peers are not added in pairs default will be as defined for 'single' by HM for this device.
More suffisticated funktionality is provided by peerChan.
peerBulk will not delete existing peers, just handle the given peerlist. Other already installed peers will not be touched.
peerBulk may be used to remove peers using unset option while default ist set.
Main purpose of this command is to re-store data to a device. It is recommended to restore register configuration utilising regBulk subsequent.
Example:
set myChannel peerBulk 12345601,
set myChannel peerBulk self01,self02,FB_Btn_04,FB_Btn_03,
set myChannel peerBulk 12345601 unset # remove peer 123456 channel 01

Also "unset" scheint das Stichwort zu sein. In der letzten Zeile ist ein Beispiel für "unset".