HM-SEC-SD-2 - Batterie leer nach einem Jahr ?!

[Pfriemler]

Ich habe jetzt mal das Attribut burstaccess bei allen auf 0_off gestellt.

Das bedeutet nur, dass FHEM diesem Gerät keine Nachrichten mehr senden wird, wenn das einen Burst erfordert. Der SD reagiert weiter auf alle anderen Bursts mit Aufwachen.
Im Gegenteil könnte das sogar bewirken, dass die Teamalarmierung nicht mehr funktioniert. Check das mal mit einem teamCall ...
Man möge mich berichtigen, wenn ich falsch interpretiere.

[frank]

Das bedeutet nur, dass FHEM diesem Gerät keine Nachrichten mehr senden wird, wenn das einen Burst erfordert. Der SD reagiert weiter auf alle anderen Bursts mit Aufwachen.
Im Gegenteil könnte das sogar bewirken, dass die Teamalarmierung nicht mehr funktioniert. Check das mal mit einem teamCall ...
Man möge mich berichtigen, wenn ich falsch interpretiere.

ich denke, dass hier burstAccess 0_off keine auswirkung hat, da die einstellung der default wert sein müste.
deinen gedanken hatte ich aber auch. am besten also testen, wie du schon sagtest.

[bugster_de]

Oh je, das zeigt mal wieder, dass ich von Homematic keine Ahnung habe, was schon mal schlecht ist. Ich stelle also burstAccess wieder zurück auf 1_auto.

Das Team funktioniert aber trotzdem. Wenn ich am Team Device in FHEM einen Alarm auslöse, dann hupen alle. Ob das aber auch geht, wenn ein einzelner Rauchmelder auslöst weiß ich mangels Test natürlich nicht.

Ich habe jede Menge anderer Homematic Devices im Haus im Einsatz aber die stehen alle bei burstAccess auch auf 1_auto. Sowohl die Netzgebundenen als auch die Batteriebetriebenen. Dabei fällt mir ein: ich habe in einem Raum auch einen Homematic Heizkörper-Thermostaten mit Batterie. Da ist ebenfalls nach maximal 3 Monaten die Batterie leer. Hatte mir bisher dabei nichts gedacht, da ich vermutete, der Motor brauche halt einiges an Strom. Aber 3 Monate sind schon arg kurz.
Umgekehrt habe ich einen Aussentemperatur Sender der nun seit 2014 mit der ersten Battere im Einsatz ist.

Mein Nachbar hat ein paar Homematic-IP Geräte. Keine Ahnung wie die konfiguriert sind, aber immer wenn er ein neues Gerät hinzufügt sehe ich das auch bei mir in FHEM. Jetzt weiß ich z.B. immer, wie warm es bei ihm im Wohnzimmer ist Kann es daran liegen?

[Pfriemler]

Oh je, das zeigt mal wieder, dass ich von Homematic keine Ahnung habe, was schon mal schlecht ist. Ich stelle also burstAccess wieder zurück auf 1_auto.

Wir haben alle mal klein angefangen. Manche sind dann irgendwann größer geworden 

Das Team funktioniert aber trotzdem.

Dann wird es eher sein wie frank sagte: Die Einstellung ist für FHEM ohne Belang bzw. wird gekonnt ignoriert.

Ob das aber auch geht, wenn ein einzelner Rauchmelder auslöst ...

Ich wüsste nicht warum dann nicht.

ich habe in einem Raum auch einen Homematic Heizkörper-Thermostaten mit Batterie. Da ist ebenfalls nach maximal 3 Monaten die Batterie leer.

Bissl kurz. Aber da kann viel Regelung eine Rolle spielen, gepeerte Fensterkontakte mit aktiviertem AES. burstAccess ist FHEM's Einstellung, ob die Geräte auf bursts reagieren wird in "burstRx" festgelegt (wenn überhaupt beeinflussbar) und muss für den Betrieb mit Fensterkontakten oder gekoppelten Wandthermostaten aktiv sein. Aber auch in diesem Fall halten meine Thermostatbatterien im Keller fast ein Jahr.

Umgekehrt habe ich einen Aussentemperatur Sender der nun seit 2014 mit der ersten Battere im Einsatz ist.

Sicher kein HomeMatic. Aber faszinierend finde ich auch, dass ein "TCM"-Sensor (hat btw nichts mit Tchibo zu tun) aus einer Billigwetterstation im Minutentakt Telegramme absondert und ich mich nicht erinnern kann, jemals dort Batterien ersetzt zu haben ... drei Jahre mindestens jedenfalls.

Aber nun wird es mystisch:

Mein Nachbar hat ein paar Homematic-IP Geräte. Keine Ahnung wie die konfiguriert sind, aber immer wenn er ein neues Gerät hinzufügt sehe ich das auch bei mir in FHEM.

Du solltest uns verraten, wie Du das schaffst. Denn die Einbindung von HM-IP gelingt FHEM derzeit nur über den Umweg einer separaten CCU und Anbindung derselben mittels Modul HMCCU.

Sicher dass es HM-IP ist? Wie auch immer:

Kann es daran liegen?

MaSgW nein.

[frank]

Oh je, das zeigt mal wieder, dass ich von Homematic keine Ahnung habe, was schon mal schlecht ist.

ich hoffe, du möchtest das ändern, sonst wird dein batterie problem nicht keiner. langfristig eventuell noch grösser. 

burst mode

hierbei handelt es sich um eine spezielle betriebsart für die kommunikation mit geräten,  die mit batterien betrieben werden.

um batterie zu sparen, wird das funkmodul der geräte so oft wie möglich ausgeschaltet. in diesen "schlafphasen" kann man die geräte also nicht ansprechen.
aufwecken lassen sich diese geräte immer über den configtaster. ansonsten wachen sie nur auf, wenn sie etwas zu melden haben (fenstersensoren), oder regelmässig in gewissen intervallen (tempsensoren). das ist natürlich schlecht, wenn man sofort mit geräten kommunizieren will/muss ohne manuell den configtaster drücken zu müssen.

hierzu gibt es nun das burst verfahren. dabei wird der funkempfang nicht komplett abgeschaltet, sondern in einen "halbschlaf" (burst mode) versetzt. in dieser betriebsart kann nur ein spezielles funkmuster erkannt werden, die burstmessages, wodurch das gerät dann geweckt wird, um diese messages genauer zu verarbeiten.

ein grosses problem ist nun, das geräte im burst mode bei jeder burst message aufwachen. nicht nur bei messages, die speziell an dieses gerät gesendet werden, sondern alle burst messages, die im funkbereich gesendet werden. also zb auch vom nachbarn.

das aufwachen bedeutet natürlich batterieverbrauch.
und da die rauchmelder immer im burstmode arbeiten, liegt es nahe, dass der hohe batterieverbrauch durch burst messages in ihrem funkbereich verursacht werden.
wenn ausserdem lowbat bei unterschiedlichen rm immer nachts um 2 gemeldet wird, ist die wahrscheinlichkeit hoch, dass zu dieser zeit ein "burst gewitter" über deinem standort liegt. bei mir gab es mal einen batterie alarm am nachmittag.

ein entsprechendes fhem.log habe ich noch nicht gesehen.
was sagt "get hminfo configCheck"?
zeige mal die ausgabe von "get hminfo msgStat".
und die ausgabe "get hminfo protEvents".
auch ein list von einem rm könnte sinnvoll sein.

das attr burstAcces würde ich erst einmal grundsätzlich aus dem system entfernen. so wie es sich bisher anhört, wirst du es auch nicht vermissen. 

[Pfriemler]

... dabei wird der funkempfang nicht komplett abgeschaltet, sondern in einen "halbschlaf" (burst mode) versetzt.

m.W. genauer gesagt: Der Funkempfänger ist schon aus, wird aber zyklisch extrem kurz eingeschaltet. Findet er in dieser Zeit ein Burstmuster, wacht der Aktor komplett auf und hört sich das nach dem Burst kommende normale Funktelegramm an. Ist es für ihn bestimmt, wird es ausgeführt, ansonsten legt er sich wieder schlafen.
Oder stell Dir einen Schlafsaal mit 100 Menschen vor. Jeder hat ein bestimmtes Morsezeichen zugewiesen, was ihn wecken soll. Der Aufseher klingelt bei jedem Weckruf erst mal Sturm, so dass alle aufwachen - dann das Morsezeichen. Dann steht der eine auf und alle anderen legen sich wieder schlafen ...
Und dann stell Dir vor, wie kaputt alle sind, wenn es in der Nacht 100x Sturm geklingelt hat, auch wenn 90 hätten durchschlafen können 

[frank]

Und dann stell Dir vor, wie kaputt alle sind, wenn es in der Nacht 100x Sturm geklingelt hat, auch wenn 90 hätten durchschlafen können 

so gesehen ist bugster mit nur 1x sturm klingeln im halben jahr wirklich gut bedient. 

[bugster_de]

Hi,

wow, Danke für die vielen kompetenten Antworten!
Schlafsaal: BMW hatte mal das gleiche Problem beim 5er: sobald einer mit einem Funkschlüssel gedrückt hat sind alle 5er BMW im Umfeld auch aufgewacht und haben die komplette Bordelektronik geweckt. Normalerweise kein Problem, aber wenn das Auto am Flughafen, wo die Dichte an baugleichen Fahrzeugen hoch ist für 6 Wochen stand, dann war die Autobatterie platt.
Auf Homematic bezogen: wenn wir also nur genügend Homematic Installationen in der Nachbarschaft haben, wird auf jeden Fall einer dabei sein, der burst Kommandos schickt und somit habe ich eigentlich keine Chance, mein Problem zu lösen.

was sagt "get hminfo configCheck"?
zeige mal die ausgabe von "get hminfo msgStat".
und die ausgabe "get hminfo protEvents".
auch ein list von einem rm könnte sinnvoll sein

siehe Ausgaben in den Anhängen anbei. Alle Devices, die mit HM_xxx benamst sind sind nicht von mir sondern von Nachbarn. Die Rauchmelder sind die SD_xxx Geräte

ch hoffe, du möchtest das ändern, sonst wird dein batterie problem nicht keiner. langfristig eventuell noch grösser. 

naja ich möchte eigentlich nicht, muß aber wohl, wenn ich irgendwann mal durchschlafen will

Thermostat: wie gesagt, der regelt da immer vor sich hin, weshalb ich mir bisher dabei nichts gedacht habe, da der Antriebsmotor ja auch habhaft Strom braucht. Er ist aber schon mit einem virtuellen Wandthermostaten gekoppelt. Ergo Burst wohl aktiv.

Du solltest uns verraten, wie Du das schaffst.

Ich hatte jahrelang diese kleine,runde Homematic zu Ethernet Büchse im Einsatz (weiß nicht mehr wie die heißt). Und von einem Tag auf den anderen hatte ich dauernd disconnects etc. Irgendwann fiel es mir wie Schuppen aus den Haaren: das muß der neue Nachbar sein. Der hat jede Menge Homematic IP im Einsatz, was sich mit der alten, runden Kiste nicht verträgt; bringt diese wohl zum Absturz. Also habe ich auf Funk-LAN Gateway umgestellt und seither tauchen immer wieder neue Homematic Geräte bei mir in FHEM auf, die nicht von mir sind. Ich dachte immer das sind neue HM-IP Geräte vom Nachbarn. Warum die sich automatisch pairen ist mir ein Rätsel, aber ich stelle nun immer das attribut ignore auf 1 und ich sehe sie erstmal nicht mehr. Waren aber bisher immer nur Sensoren. Ich warte ja noch drauf, dass sich da mal ein Aktor registriert, damit ich mal schalten kann und dann schauen bei welchem Nachbarhaus sich was tut

Umgekehrt habe ich einen Aussentemperatur Sender der nun seit 2014 mit der ersten Battere im Einsatz ist.
Sicher kein HomeMatic.

doch. HM-WDS10-TH

[Pfriemler]

Auf Homematic bezogen: wenn wir also nur genügend Homematic Installationen in der Nachbarschaft haben, wird auf jeden Fall einer dabei sein, der burst Kommandos schickt und somit habe ich eigentlich keine Chance, mein Problem zu lösen.

Naja ... vielleicht kann man auch mit dem Nachbarn reden, dass er ein bisschen zur Funkhygiene beiträgt.

... jahrelang diese kleine,runde Homematic zu Ethernet Büchse  ... von einem Tag auf den anderen hatte ich dauernd disconnects etc. Irgendwann fiel es mir wie Schuppen aus den Haaren: das muß der neue Nachbar sein. Der hat jede Menge Homematic IP im Einsatz, was sich mit der alten, runden Kiste nicht verträgt; bringt diese wohl zum Absturz.

Soweit richtig, aber es gibt ein Firmwareupdate für den HMLAN, dann verträgt er auch HM-IP ohne Absturz. Aber er liest das natürlich nicht - es ist technisch unmöglich, gerade versehentlich.

...tauchen immer wieder neue Homematic Geräte bei mir in FHEM auf, die nicht von mir sind.

Das können dann aber keine IP sein. Möglich dass der Nachbar eine CCU betreibt und beide Familien dort versammelt. Alles was er an Nicht-IP in Betrieb nimmt, landet per autocreate dann auch bei dir. ignore ist exakt das Mittel der Wahl dafür.

HM-WDS10-TH

Donnerwetter. So lange schafft hier kein HM-Gerät mit einem Batteriesatz.

[bugster_de]

HM-WDS10-TH
Donnerwetter. So lange schafft hier kein HM-Gerät mit einem Batteriesatz.

yep ist mir auch völlig schleierhaft wie der das macht. Ich warte quasi täglich darauf dass die Batterien in die Knie gehen. Sobald die mal leer sind, schaue ich nach, welcher Hersteller das war. Danach kaufe ich nur noch von dem

aber es gibt ein Firmwareupdate für den HMLAN

da hatte ich damit rumgemacht, aber irgendwas war damas, warum das auch nicht ging. Weiß nicht mehr. Ich habe eh ziemlich zügig aufgegeben und mir gleich die neuen Homematic Funk Gateways gekauft

[bugster_de]

So, ich kruschtele das mal wieder hervor. Ich habe ja die ganzen Sachen wie oben beschrieben umgesetzt. Bei dem einen Melder waren jetzt nach 8 Wochen schon wieder die Batterien leer. Ich glaube die sind defekt. Zwar komisch dass alle 5 defekt wären, aber irgendwas stimmt da nicht.

Logfiles und sonstige Konfigs habe ich ja im Thread unten angehängt

[LuckyDay]

Zitat

    HM-WDS10-TH

Donnerwetter. So lange schafft hier kein HM-Gerät mit einem Batteriesatz.

meiner ist von Ende 2011 und lüppt immer noch mit dem ersten Satz Batterien

[Pfriemler]

... Bei dem einen Melder waren jetzt nach 8 Wochen schon wieder die Batterien leer. Ich glaube die sind defekt. Zwar komisch dass alle 5 defekt wären, aber irgendwas stimmt da nicht.

Mann, was für eine Sch...e - das würde mich ja auch ärgern. Mein Bei(nk)leid. 

Ich bin ratlos bezüglich einer Idee, wie man den Verursacher der Burstkanonaden herausbekommen kann. Wenn das Problem nicht doch im eigenen Haus ist.
Hatten wir schon gefragt ob Du sicher bist, dass bei Dir im Haus nachts nicht irgendwas Amok läuft - ein Allroundschlag "getConfigs" oder so? Manch einer lässt ja sein FHEM allnächtlich neu starten und dann laufen zumindest bei mir auch diverse getConfigs an ... (nein, ich starte nicht regelmäßig neu, ich meinte nur dass es da recht normal ist) ...

[martinp876]

Nur auch mal Klugscheißern zum burst.
Die prozessoreinheit sollte schlafen. Ein Teil des Empfängers muss allerdings immer  wach sein. ein stromsparender Teil. Wenn jemand etwas vom Device will schickt er eine intensive Sequenz. Alle burst Empfänger wachen etwas weiter auf und horchen auf die Adresse. Wenn sie nicht gemeint sind schalten sie wieder ab.
Ein sd muss immer auf empfang sein. Sollte ein anderer alarm auslösen muss!!!! Er das sofort sehen.

Das zyklische aufwachen sind die wakeup devices. Bspw thermometer oder heizungssteurung. Langsame kommunikation.

Kommunikation zwischen devices geht mit wakeup nahezu nie ( 2 ausnahmen)

Das alles sollte die bat nichrpt so schnell leer machen. Somit auch keine hilfe für dein problem. Sorry

[Pfriemler]

Mit "zyklisch" meinte ich weiter oben keinesfalls Zeiten im Stile wakeUp. Die Schalterschnittstellen (SCI etc) überwachen ihre Eingänge auch nicht kontinuierlich, sondern   prüfen sie 4x pro Sekunde. Das dient alles der Stromersparnis. Ob nun die Empfänger in den Burstgeräten im Dauerbetrieb hören oder extrem kurz in solchen Abständen, dass sie einen Burst nicht verpassen, ist letztlich irrelevant für das Verständnis - der Prozessor bleibt da außen vor und wird nur bei Bedarf vom Funkmodul geweckt.

Ein hoher Batterieverbrauch legt aber nahe, dass dieses Wecken zu oft passiert. Es müssen wohl auch nicht zwingend HM-Bursts sein, die da wecken - möglicherweise sind auch nur ähnliche Signale ausreichend für den Weckvorgang...?