Fensterdrehgriff "frisst" Batterien

[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:

Code Auswählen Erweitern

configCheck done:

 missing register list
    sensor_fenstergriff_schlafzimmerfensterlinks: RegL_00.,RegL_01.

 trigger sent to undefined device
    sensor_fenstergriff_schlafzimmerfensterlinks: 111111

[Beta-User]

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

[Sailor]

Hallo Marko

Hallo, 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

[Marko1976]

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

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]

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.

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]

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.

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:

Code Auswählen Erweitern

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]

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

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.

[Prof. Dr. Peter Henning]

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

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

Liefere eine möglichst konkrete Fehlerbeschreibung!

Was geht da noch ausführlicher?

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

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

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?

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

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.

[Prof. Dr. Peter Henning]

Was hat das LED-Verhalten mit dem Leeren der Batterie zu tun? Für mich erst einmal rein gar nichts.

Schon mal überlegt, woher die Energie für die Lichtaussendung kommt? Offenbar nicht.

Das sind eben die Unterschiede in der Denkweise

Sicher nicht, eher in der Qualität.

pah

[Beta-User]

Schon mal überlegt, woher die Energie für die Lichtaussendung kommt? Offenbar nicht.

Nun ja, nach meiner Erfahrung ist die LED da, um etwas anzuzeigen.

Der TE hat irgendwo hier dann (nach dem ersten Post) verlauten lassen, er könne eine übermäßig lange rot-Phase beobachten. Das _klingt_ danach, als würde die LED sagen wollen: Meine MCU kann was nicht ordnungegemäß versenden, ich bekomme keine Antwort.
Von daher ist es nicht nur die LED, die Energie braucht, sondern halt auch die MCU und der Transceiver .

Von daher _könnte_ es sogar richtig sein, was der TE mittels hmInfo ermittelt hatte.

Hier also nochmal mein eigentlicher Lösungsversuch: Versuche, die Kontaktsituation an den Batterien zu verbessern. Das schadet m.E. in keinem Fall .
Danach könnte man sehen, ob wirklich ein fehlerhaftes peering da ist, das Ding noch gepairt usw..

Das sind eben die Unterschiede in der Denkweise

Genau deswegen fragt man doch andere: Man kommt selbst nicht alleine weiter und braucht einen "Schubs".


Daher nochmal mein "Rüffel" (an (!) den TE!): RTFM of this forum, also lies die angepinnten Beiträge im Anfängerbereich, dann schreibst du hoffentlich nicht nochmal sowas:

kann man einfach mal danach fragen und am besten auch kurz erklären warum.

Vielleicht hilft insbesondere https://forum.fhem.de/index.php?msg=105687 und der darin verlinkte Beitrag zu verstehen, dass du es bist, der etwas haben will und daher Bringschulden zu erfüllen hast .

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

Vielleicht noch ein Gedanke dazu, weil ich bisher auch keine passende Hardware-Alternative gesehen habe und definitiv keinen Bock mehr auf diesen Hersteller habe:
Baustein 1 wäre https://forum.fhem.de/index.php?topic=71413.0
Die MCU+Transceiver könnte man eventuell mit einem ESP32-H2 ersetzen (energieeffizienz-optimierter ZigBee-SOC, https://www.espressif.com/en/products/socs/esp32-h2).

[Marko1976]

Vielleicht hilft insbesondere https://forum.fhem.de/index.php?msg=105687 und der darin verlinkte Beitrag zu verstehen, dass du es bist, der etwas haben will und daher Bringschulden zu erfüllen hast

Mal ganz klar zur Verdeutlichung, ich habe NULL Schuld zu erbringen! Wenn du nicht helfen willst, dann lass es einfach. Ich stelle eine Frage und liefere so gut es geht Informationen dazu. Wenn ich etwas vergesse, kann man danach fragen und gut ist. Doch deine Art und Weise hilft eh Null. Immer nur aus dem Kontext gerissene Zitate die dann keinen Sinn und Verstand mehr haben bzw. völlig verfälscht werden. Also danke, aber nein - darauf hab ich keinen Bock. Entweder du willst helfen, dann drück dich klar und verständlich aus oder lass es. Wenn etwas fehlt, leifere ich es gerne nach wenn ich es vegessen habe und kann. Doch ich habe weder Bock noch Zeit alles 10 Mal zu lesen nur um dann doch nicht zu verstehen was du willst. Wenn du denkst, das Rätselraten der Weg zur Lösung ist ...

Was den Rest angeht, laut Bedienungsanleitung sagt ein rotes Licht einzig, dass das gesendete Signal nicht bestätigt wurde, nichts anderes. Und die Zentrale - ein einfaches Gateway vom Typ eQ3-HM-LGW - hängt am Stromnetz, eine Unterversorgung ist also AUSGESCHLOSSEN. Und das würde für jede Variante, egal ob CCU oder was anderes gelten, die sind alle Stromgebunden.

Ach und als persönliche Anmerkung - deine Art Sätze zu formulieren kommt derart überheblich und besserwisserisch rüber, das es zum ko**en ist. Vielleicht solltest du mal Korrekturlesen was du schriebst und vor dem Posten über die Außenwirkung nachdenken. Und ja, das schreibe ich ganz bewusst hier und jetzt. Denn ich bin ein Mensch - vielleicht unwissender als du - aber ein Mensch. Jemand der um Hilfe fragt und keine dritte unbeteiligte Person. Doch als solcher fühle ich mich nicht in einer Kommunikation mir dir. Und dass muss ich mir nicht antun.

[Beta-User]

Wenn du nicht helfen willst, dann lass es einfach.

Ich gehe davon aus, dass künftige, emotional weniger vorbelastete Leser dieses Threads mit einem ähnlich gelagerten Problem wie du, eventuell meine Ausführungen als hilfreich emfinden könnten.

Ansonsten ist es verblüffend, wie gut unsere Kommunikation hier zu dem paßt, was in dem verlinken Artikel als stereotypisch beschrieben wird...