Batterien (nur) eines Funk-Wandthermostats alle 2,5 Monate leer

Begonnen von FunkOdyssey, 07 April 2016, 09:46:40

Vorheriges Thema - Nächstes Thema

FunkOdyssey

Gestern habe ich mich wieder geärgert, als ich eine Benachrichtigung von FHEM erhalten habe:
Die Batterie eines Funk-Wandthermostat (HM-TC-IT-WM-W-EU) ist wieder (fast) leer.
Das Limit (lowBatLimitRT) von 2,2 Volt wurde erreicht.
Da mich dieses Thermostat schon öfter mit einem zu frühen Batteriewechsel geärgert hatte, habe ich im Comments-Attribut die Zeilen mal protokolliert:

ZitatBatterietausch
07.11.2015
29.01.2016
07.04.2016

Lustigerweise habe ich mehrere Wandthermostate, die ich am gleichen Tag angeschafft habe und quasi auch in der gleichen "Klimazone" hängen, die immer noch mit der Originalbatterie laufen. Sogar die RSSI-Werte sind nahezu identisch. Ich mache mit den Geräte auch nicht mehr, als T/H auszulesen. Kein Peering. Keine Stellantriebe. Nur Auslesen und in FHEM anzeigen.

Habt ihr einen Tipp für mich?

List vom Device:
Internals:
   DEF        XXXXXX
   IODev      hmusb2
   LASTInputDev hmusb2
   MSGCNT     2138
   NAME       sz_thermo
   NR         647
   NTFY_ORDER 50-sz_thermo
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 sz_thermo_weather
   channel_02 sz_thermo_Climate
   channel_03 sz_thermo_WindowRec
   channel_06 sz_thermo_remote
   channel_07 sz_thermo_SwitchTr
   hmusb2_MSGCNT 1067
   hmusb2_RAWMSG EXXXXXX,0000,22F9E022,FF,FFB7,E38470XXXXXX00000080C12E
   hmusb2_RSSI -73
   hmusb2_TIME 2016-04-07 09:41:10
   hmusb_MSGCNT 1071
   hmusb_RAWMSG EXXXXXX,0000,048A277E,FF,FFBA,E38470XXXXXX00000080C12E
   hmusb_RSSI -70
   hmusb_TIME 2016-04-07 09:41:10
   lastMsg    No:E3 - t:70 s:XXXXXX d:000000 80C12E
   protLastRcv 2016-04-07 09:41:10
   protSnd    1 last_at:2016-04-07 04:06:17
   protState  CMDs_done
   rssi_at_hmusb avg:-73.36 min:-77 max:-70 lst:-70 cnt:1071
   rssi_at_hmusb2 avg:-73.51 min:-81 max:-68 lst:-73 cnt:1067
   Readings:
     2016-04-06 12:31:02   Activity        alive
     2016-03-15 20:18:40   CommandAccepted yes
     2016-03-15 20:17:47   D-firmware      1.2
     2016-03-15 20:17:47   D-serialNr      LEQXXXXXXXX
     2016-03-15 20:18:40   PairedTo        0xXXXXXX
     2016-03-15 20:18:40   R-btnLock       off
     2016-03-15 20:18:40   R-burstRx       on
     2016-03-15 20:18:40   R-cyclicInfoMsg on
     2016-03-15 20:18:40   R-cyclicInfoMsgDis 0
     2016-03-15 20:18:40   R-globalBtnLock off
     2016-03-15 20:18:40   R-localResDis   off
     2016-03-15 20:18:40   R-lowBatLimitRT 2.2 V
     2016-03-15 20:18:40   R-modusBtnLock  off
     2016-03-15 20:18:40   R-pairCentral   0xXXXXXX
     2016-04-07 09:41:00   battery         low
     2016-04-07 09:41:00   batteryLevel    2.3
     2016-04-07 09:41:00   desired-temp    17.0
     2016-04-07 09:41:00   measured-temp   19.3
     2016-04-07 04:06:17   state           CMDs_done
     2016-04-07 04:06:17   time-request    -
   Helper:
     HM_CMDNR   227
     PONtest    1
     mId        00AD
     rxType     6
     Expert:
       def        1
       det        1
       raw        0
       tpl        0
     Io:
       newChn     +XXXXXX,00,00,00
       nextSend   1460014870.55215
       rxt        0
       vccu       vccu
       p:
         XXXXXX
         00
         00
         00
     Mrssi:
       mNo        E3
       Io:
         hmusb      -70
         hmusb2     -71
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       dev        1
     Rssi:
       At_hmusb:
         avg        -73.3650793650794
         cnt        1071
         lst        -70
         max        -70
         min        -77
       At_hmusb2:
         avg        -73.5126522961574
         cnt        1067
         lst        -73
         max        -68
         min        -81
     Shregw:
       07         02
     Shadowreg:
Attributes:
   IODev      hmusb
   IOgrp      vccu
   actCycle   000:10
   actStatus  alive
   autoReadReg 4_reqStatus
   event-on-change-reading .*
   expert     1_allReg
   firmware   1.2
   model      HM-TC-IT-WM-W-EU
   msgRepeat  1
   serialNr   LEQxxxxxxx
   subType    thermostat
   webCmd     getConfig:clear msgEvents

frank

2016-03-15 20:18:40   R-burstRx       on
wozu brauchst du burst, den batterie-killer?
schon mal mit hminfo configcheck und protoevents geschaut?
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

FunkOdyssey

Okay, danke für den Tipp. Burst scheint bei den Geräten per default eingeschaltet zu sein. Das habe ich bei den anderen auch. Ehrlich gesagt habe ich das Kapitel "Burst" damals in den Anleitungen übersprungen, weil ich das - glaube ich - nicht brauche. Ich kann das jedenfalls ausschalten. Wobei das auch nicht die Ursache sein kann.




Wonach genau soll ich in HMINFO denn schauen?

configCheck liefert zwar ein paar Inhalte, aber zu den Thermostaten nur folgendes (gekürzt):

configCheck done:
...
templist mismatch
    kind_thermo_Climate: file: ././tempList.cfg for kind_thermo_Climate does not exist
    sz_thermo_Climate: file: ././tempList.cfg for sz_thermo_Climate does not exist
    wz_thermo_Climate: file: ././tempList.cfg for wz_thermo_Climate does not exist


Worauf muss ich bei protoEvents achten?
Ich würde die Ausgabe hier ja nun gerne posten, aber durch beim "set xyz regset burstRx off" habe ich dort einige "Pendings" bei den Geräten. Vorher war das recht übersichtlich.

cmdPend : -
Snd: 2
Resnd: -
CmdDel: -
ResndFail: -
Nack: -
IOerr: -

frank

ZitatWonach genau soll ich in HMINFO denn schauen?
nach auffäligkeiten. viel funk => viel batterie.
dein posting sieht aber ok aus.

ZitatWobei das auch nicht die Ursache sein kann.
warum?
bei jedem burst in der luft, egal von wem, wacht das device auf und schaut => ist die message für mich. vielleicht empfängt dieses device mehr burst messages, als die anderen?

ist die fw 1.2 bei allen gleich?
hast du homematic nachbarn?
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

betateilchen

Schick das Teil an den Händler zurück und lass es austauschen. So einen batteriefressenden Wandthermostaten hatte ich auch mal, seit dem Austausch ist das Problem verschwunden.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

FunkOdyssey

#5
Zitat von: frank am 07 April 2016, 10:36:03
warum?
bei jedem burst in der luft, egal von wem, wacht das device auf und schaut => ist die message für mich. vielleicht empfängt dieses device mehr burst messages, als die anderen?

Ich dachte, dass dann der Batterieverbrauch bei allen Thermostaten gleich sein sollte, da burst ja bei allen aktiv ist.

Zitat von: frank am 07 April 2016, 10:36:03
ist die fw 1.2 bei allen gleich?
hast du homematic nachbarn?

Die Firmware ist identisch. Ich habe sogar ein Diff vom list der Geräte durchgeführt.
Im Umkreis habe ich keine HM-Nachbarn.

Zitat von: betateilchen am 07 April 2016, 11:21:34
Schick das Teil an den Händler zurück und lass es austauschen. So einen batteriefressenden Wandthermostaten hatte ich auch mal, seit dem Austausch ist das Problem verschwunden.

Ich werde das mal beobachten. Vorher werde ich das Gerät mal auf Werkseinstellungen zurücksetzen. Irgendwie verhält sich das Thermostat sowieso merkwürdig, da (nur bei diesem) die cmd_pending gerade auch nicht direkt abgearbeitet wurden.
Das war ursprünglich mein erstes Thermostat, mit dem ich damals erst einmal Erfahrung sammeln musste. Nicht, dass ich irgendetwas verdreht habe. Ich will nur die Logs in FHEM nicht verlieren. Mal schauen.

Hollo

Ich habe das mit 1 von 5 Heizungsthermostaten...
da hält der Batteriesatz 4 Wochen.
Alle identische Firmware und werden quasi identisch angesteuert.
Fazit: der wird jetzt ausgetauscht, und dann sehe ich weiter.
FHEM 6.x auf RPi 3B Buster
Protokolle: Homematic, Z-Wave, MQTT, Modbus
Temp/Feuchte: JeeLink-Clone und LGW mit LaCrosse/IT
sonstiges: Linux-Server, Dreambox, "RSS-Tablet"

FunkOdyssey

Wie ich in einem anderen Thread erfahren habe, sollte man burst eingeschaltet lassen. Vermutlich haben viele andere User auch burst aktiv und die Batterie hält dennoch länger. Also wird der Grund wahrscheinlich woanders liegen. Hmm. Ich will das Thermostat ungern reklamieren, da ich ein Ersatzgerät (bei Amazon) dann teuer nachkaufen müsste.

MarcelK

Ich schätze mal ganz grob ein aktiver Burst Modus benötigt 200mAh zusätzlich im Jahr. Evtl noch etwas mehr bei viel Funk-Last in der Luft. Ein Satz Micro-Batterien hat typisch rund 2400mAh Kapazität. D.h. die Lebenszeit wird definitiv reduziert, aber sie liegt trotzdem noch in Jahren und nicht in Monaten.

MattG

Und da dachte ich, ich wäre alleine mit dem Problem: Von den 15  batteriebetriebenen Homematic-Geräten, die ich inzwischen in Betrieb habe, hatte ich zwei vergleichbare Fälle. Ein Außenthermometer und ein Fensterkontakt waren Batteriefresser und saugten innerhalb von 4-6 Wochen die Batterien leer. Habe ich beide umgetauscht und der Ersatz tut's jetzt schon viele Monate. Ich habe bei ELV bestellt, die sogar so kulant waren, dass ich das Austauschgerät bestellen konnte bevor ich das kaputte zurückgeschickt habe - so hatte ich keine Lücke.
Am Burst kann's nicht liegen: Alle Thermostate haben bei mir wegen der Fensterkontakte Burst an und trotzdem hält die Batterie zwei Jahre.