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

Beta-User

Zitat von: vbs am 09 Oktober 2025, 23:01:27Also 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.".
Das war gemeint, aber in der Tat eigentlich erst als 3. Teil, wie der TE korrekt erkannt hat nach einem "Rüffel":

1.: Liefere eine möglichst konkrete Fehlerbeschreibung!
2.: Liefere ein "list" (oder "copy for forum"), selbst, wenn du nicht glaubst, dass das hilfreich sein kann
(1+2= halte dich an die Forenregeln, und falls ausnahmsweise nicht, zeige, dass du sie zur Kenntnis genommen hast, indem du z.B. schreibst: "vermutlich ist das kein FHEM-Problem, sondern ein Harwaredefekt, zu dem ich folgende Beobachtungen gemacht habe: ... 'list' oä. reiche ich gerne bei Bedarf nach").

Vermutlich hat das Ding "Amnesie", hat sich wegen eines wackeligen Batteriekontakts resettet und ist gar nicht mehr gepairt (die CUL_HM-Begriffe "peer" und "pair" kann man in deutscher Sprache im Wiki nachlesen).

Von daher hätte mich weniger der Effekt "Batterie ist schnell leer" an sich interessiert, sondern das Blink-Verhalten der LED von dem Ding, wenn man neue Batterien einlegt ;) .
Praktisch alle LR44-betriebenen Geräte des Herstellers neigen nämlich dazu, irgendwann Wackelkontakte zu entwickeln, was man in der Regel mit Reinigen der Kontakte und "Nachspannen" der Feder soweit in den Griff bekommen kann, das die wieder normal reagieren (das steht vermutlich auch schon mehrfach hier im Forum, wurde aber entweder nicht gesucht, oder eben "einfach nur" nicht gefunden).
Nach einer Amnesie, muss man dann aber (nach Löschen eventuell noch ausstehender Messages aus alten Versuchen) wieder neu pairen usw., womit wir wieder beim fehlenden "list" wären.
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

Prof. Dr. Peter Henning

Zitat von: Marko1976 am 09 Oktober 2025, 16:24:41Also viele Unklarheiten die um weitere Detailierung lächzen.
Unklarheiten behebt man, indem man die Dokumentation zum peering liest.

pah

P.S.: Man lechzt nach etwas.

Marko1976

Zitat von: Beta-User am 10 Oktober 2025, 16:29:17Das war gemeint, aber in der Tat eigentlich erst als 3. Teil, wie der TE korrekt erkannt hat nach einem "Rüffel":
Das war kein Rüffel sondern eine Rückfrage weil ich das NICHT klar identifizieren kann. Für mich war das lediglich ein Text am Stück. Darum habe ich nachgefragt. Aber typisch, dass du das wieder als Angriff Rüffel) auslegst.

Zitat von: Beta-User am 10 Oktober 2025, 16:29:17Liefere eine möglichst konkrete Fehlerbeschreibung!
Was geht da noch ausführlicher?
Zitat von: Beta-User am 10 Oktober 2025, 16:29:17Liefere ein "list" (oder "copy for forum"), selbst, wenn du nicht glaubst, dass das hilfreich sein kann
Hätte ich machen können, aber wie du selbst schreibst handelt es sich wohl viel eher um ein Hardwareproblem, darum habe ich es gelassen um den Threat nicht unnötig aufzublähen. Entschuldigung dafür, dafür, dass ich die Frage so knapp und einfach wie möglich gehalten habe.
Zitat von: Beta-User am 10 Oktober 2025, 16:29:17Von daher hätte mich weniger der Effekt "Batterie ist schnell leer" an sich interessiert, sondern das Blink-Verhalten der LED von dem Ding, wenn man neue Batterien einlegt
Und da wäre ich als unvorbereiteter User nämlich NIE drauf gekommen. Was hat das LED-Verhalten mit dem Leeren der Batterie zu tun? Für mich erst einmal rein gar nichts. Das sind eben die Unterschiede in der Denkweise und statt zigmal drumherum zu reden oder aufzeigen was man alles falsch macht, kann man einfach mal danach fragen und am besten auch kurz erklären warum.

Ich probiere das jetzt mal mit dem Löschen und schaue dann weiter. Frage dazu wäre aber noch sollte man vor dem Löschbefehl die Batterien noch mal tauschen oder ist erfahrungsgemäß so viel Restspannung da, dass der Befehl verarbeitet wird?

Zitat von: vbs am 09 Oktober 2025, 23:01:27Also 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.".
Dieser Satz war ja auch eindeutig nur der Rest nicht. Für jemanden der das aber zum ersten Mal macht fehlt eben die Info wie das geht. Wenn man schreibt lösche dies oder das kann man auch kurz dabei schreiben wie - das würde die Rückfragen (die ja nicht nur von mir hier im Forum immer wieder gestellt werden) deutlich reduziert.