Selbstbau HM_WDS10_TH_O mit Luftdruckmessung

Tom Major · 21 Dezember 2018, 23:33:29

Interessanter Punkt. A0 muss auf jeden Fall definiertes Potential haben da kein interner pull-up/down vorhanden ist.
Bei meinen MAX44009 Modulen war die Brücke bei Lieferung schon gelötet.
https://raw.githubusercontent.com/TomMajor/AskSinPP_Examples/master/HB-UNI-Sensor1/Images/HB-UNI-Sensor1_HW1.jpg

PeMue · 22 Dezember 2018, 19:42:34

Hallo Gregor,

Zitat von: gregor am 21 Dezember 2018, 10:00:05
Gelöst: Ursache für die 0-Werte von MAX44009 war der offene A0 Anschluss.

gut zu wissen. Ich habe ein paar Module gekauft und mal beim ersten geschaut. Da war die Brücke drin. Bevor ich die anderen einsetze, schaue ich mir das an.

Danke + Gruß

Peter

vbs · 27 Dezember 2018, 11:49:56

Ich hab einen Universalsensor von Dirk der viele Jahre alt ist (4?) und ich hab das Problem, dass die Batterie häufig gewechselt werden muss. Ich hatte es mir neulich notiert und da hat ein Satz Batterien nur ca. 6 Wochen gehalten. Ist doch nicht normal oder? Im Moment halten sie etwas länger, aber ich glaube ursprünglich war eine Lebensdauer zwischen 2 und 4 Jahren prognostiziert.

Ich verwende 2 AAA Eneloops. Ich weiß, Akkus sind wohl nicht ideal in dem Zusammenhang, aber es wäre für mich auch ok, wenn die Batterien statt 2 Jahren nur 1 Jahr oder so halten würden. Nur halt 6 - 8 Wochen sind mir dann doch zu wenig.
Ich hab die Akkus neulich mit einem Technoline BC700 refresht und kam auf eine Kapazität von >700 mAH. Der Sensor hat nach meinem Verständis einen StepUp-Wandler, der auch für eine bessere Batterieausnutzung sorgt.

Hat da jemand eine Idee, woran das liegen könnte? Danke!

PeMue · 27 Dezember 2018, 11:58:46

Zitat von: vbs am 27 Dezember 2018, 11:49:56
Hat da jemand eine Idee, woran das liegen könnte? Danke!

Welche Firmware hast Du drauf? Hast Du den Sensor mit irgendwas gepeert? Ggf. könnte die Platine auch feucht geworden sein und Du hast einen Nebenschluß zu den Akkus.
Wenn Du ein Strommessgerät hast, würde ich mal messen (Standby, bzw. Daten verschicken).

Gruß Peter

gloob · 27 Dezember 2018, 12:00:32

Zitat von: vbs am 27 Dezember 2018, 11:49:56
Ich hab einen Universalsensor von Dirk der viele Jahre alt ist (4?) und ich hab das Problem, dass die Batterie häufig gewechselt werden muss. Ich hatte es mir neulich notiert und da hat ein Satz Batterien nur ca. 6 Wochen gehalten. Ist doch nicht normal oder? Im Moment halten sie etwas länger, aber ich glaube ursprünglich war eine Lebensdauer zwischen 2 und 4 Jahren prognostiziert.

Ich verwende 2 AAA Eneloops. Ich weiß, Akkus sind wohl nicht ideal in dem Zusammenhang, aber es wäre für mich auch ok, wenn die Batterien statt 2 Jahren nur 1 Jahr oder so halten würden. Nur halt 6 - 8 Wochen sind mir dann doch zu wenig.
Ich hab die Akkus neulich mit einem Technoline BC700 refresht und kam auf eine Kapazität von >700 mAH. Der Sensor hat nach meinem Verständis einen StepUp-Wandler, der auch für eine bessere Batterieausnutzung sorgt.

Hat da jemand eine Idee, woran das liegen könnte? Danke!

Hast du es mal mit normalen Batterien versucht? Ein Step-Up Wandler kann die Akkus schön tiefenentladen, was sie überhaupt nicht mögen.

Tom Major · 27 Dezember 2018, 12:34:06

Zitat von: vbs am 27 Dezember 2018, 11:49:56
Ich hab einen Universalsensor von Dirk der viele Jahre alt ist (4?) und ich hab das Problem, dass die Batterie häufig gewechselt werden muss. Ich hatte es mir neulich notiert und da hat ein Satz Batterien nur ca. 6 Wochen gehalten. Ist doch nicht normal oder? Im Moment halten sie etwas länger, aber ich glaube ursprünglich war eine Lebensdauer zwischen 2 und 4 Jahren prognostiziert.

Ich verwende 2 AAA Eneloops. Ich weiß, Akkus sind wohl nicht ideal in dem Zusammenhang, aber es wäre für mich auch ok, wenn die Batterien statt 2 Jahren nur 1 Jahr oder so halten würden. Nur halt 6 - 8 Wochen sind mir dann doch zu wenig.
Ich hab die Akkus neulich mit einem Technoline BC700 refresht und kam auf eine Kapazität von >700 mAH. Der Sensor hat nach meinem Verständis einen StepUp-Wandler, der auch für eine bessere Batterieausnutzung sorgt.

Hat da jemand eine Idee, woran das liegen könnte? Danke!

6 Wochen klingt definitiv viel zu wenig. Als Erstes den Ruhestrom messen, der müsste mit Step-Up im Bereich ca. 10-20 uA liegen. Die 6 Wochen lassen einen viel höheren Ruhestrom vermuten.

vbs · 27 Dezember 2018, 14:13:12

Danke für die vielen Antworten!

Zitat von: PeMue am 27 Dezember 2018, 11:58:46
Welche Firmware hast Du drauf? Hast Du den Sensor mit irgendwas gepeert? Ggf. könnte die Platine auch feucht geworden sein und Du hast einen Nebenschluß zu den Akkus.
Wenn Du ein Strommessgerät hast, würde ich mal messen (Standby, bzw. Daten verschicken).

Firmware ist die 0.15, gepeert ist nichts. Elektrisch sieht es für mich als Laien unverdächtig aus. Hier mal ein List des Devices:

Code Auswählen

Internals:
   DEF        <ID>
   HMLAN0_MSGCNT 589
   HMLAN0_RAWMSG E0B69DC,0000,6A902015,FF,FFBF,01A2700B69DCF1554400CA00279E0000103F09C4
   HMLAN0_RSSI -65
   HMLAN0_TIME 2018-12-27 13:53:58
   IODev      sys_culHm
   LASTInputDev HMLAN0
   MSGCNT     1163
   NAME       env_thpl
   NOTIFYDEV  global
   NR         215
   NTFY_ORDER 50-env_thpl
   STATE      T: 20.2 L: 41.59 P: 1014.2
   TYPE       CUL_HM
   lastMsg    No:01 - t:70 s:0B69DC d:F15544 00CA00279E0000103F09C4
   protLastRcv 2018-12-27 13:53:58
   protRcv    576 last_at:2018-12-27 13:53:58
   protSnd    588 last_at:2018-12-27 13:53:58
   protState  CMDs_done
   rssi_at_HMLAN0 cnt:589 min:-74 max:-55 avg:-60.22 lst:-65 
   rssi_at_sys_culHm cnt:574 min:-86 max:-38 avg:-66.31 lst:-38 
   sys_culHm_MSGCNT 574
   sys_culHm_RAWMSG 0501002601A2700B69DCF1554400CA00279E0000103F09C4
   sys_culHm_RSSI -38
   sys_culHm_TIME 2018-12-27 13:53:58
   Helper:
     DBLOG:
       batVoltage:
         benDbLog:
           TIME       1545915238.92425
           VALUE      2.50
       humidity:
         benDbLog:
           TIME       1545913888.9032
           VALUE      73
       luminosity:
         benDbLog:
           TIME       1545915238.92425
           VALUE      41.59
       pressure:
         benDbLog:
           TIME       1545915238.92425
           VALUE      1014.2
       statHumidityDayLast:
         benDbLog:
           TIME       1545865198.10183
           VALUE      Min: 78 Avg: 87 Max: 93
       statHumidityHourLast:
         benDbLog:
           TIME       1545911998.07949
           VALUE      Min: 68 Avg: 70 Max: 71
       statLuminosityDayLast:
         benDbLog:
           TIME       1545865198.10183
           VALUE      Min: 0.01 Avg: 145.46 Max: 965.00
       statLuminosityHourLast:
         benDbLog:
           TIME       1545911998.07949
           VALUE      Min: 2201.00 Avg: 2527.11 Max: 2938.00
       statPressureDayLast:
         benDbLog:
           TIME       1545865198.10183
           VALUE      Min: 1017.3 Avg: 1018.6 Max: 1020.1
       statPressureHourLast:
         benDbLog:
           TIME       1545911998.07949
           VALUE      Min: 1014.0 Avg: 1014.3 Max: 1014.6
       statTemperatureDayLast:
         benDbLog:
           TIME       1545865198.10183
           VALUE      Min: 3.7 Avg: 4.7 Max: 5.4
       statTemperatureHourLast:
         benDbLog:
           TIME       1545911998.07949
           VALUE      Min: 5.5 Avg: 5.6 Max: 5.8
       temperature:
         benDbLog:
           TIME       1545915074.23616
           VALUE      20.2
   READINGS:
     2018-12-26 13:22:32   Activity        alive
     2016-03-07 18:17:08   CommandAccepted yes
     2016-03-08 23:12:03   D-firmware      0.15
     2016-03-08 23:23:48   D-serialNr      <mySerial>
     2016-03-07 18:17:09   PairedTo        <HMID>
     2016-03-07 18:16:17   R-altitude      0 m
     2016-03-07 18:16:17   R-burstRx       off
     2016-03-07 18:16:17   R-ledMode       off
     2016-03-07 18:17:09   R-lowBatLimitTHPL 2.1 V
     2016-03-07 18:16:17   R-pairCentral   0xF15544
     2016-03-07 18:16:17   R-transmDevTryMax 3
     2018-12-27 13:53:58   batVoltage      2.50
     2018-12-27 13:53:58   battery         ok
     2016-03-08 23:11:35   fwUpdate        fail:notInBootLoader
     2018-12-27 13:31:28   humidity        73
     2018-12-27 13:53:58   luminosity      41.59
     2016-03-08 23:12:03   powerOn         2016-03-08 23:12:03
     2018-12-27 13:53:58   pressure        1014.2
     2016-03-08 23:12:03   recentStateType info
     2018-12-27 13:53:58   statHumidityDay Min: 67 Avg: 86 Max: 93
     2018-12-26 23:59:58   statHumidityDayLast Min: 78 Avg: 87 Max: 93
     2018-12-27 13:53:58   statHumidityHour Min: 67 Avg: 70 Max: 73
     2018-12-27 12:59:58   statHumidityHourLast Min: 68 Avg: 70 Max: 71
     2018-12-27 13:53:58   statHumidityMonth Min: 67 Avg: 85 Max: 95
     2018-11-30 23:59:58   statHumidityMonthLast Min: 55 Avg: 85 Max: 98
     2018-12-27 13:53:58   statHumidityYear Min: 1 Avg: 73 Max: 99
     2017-12-31 23:59:58   statHumidityYearLast Min: 28 Avg: 77 Max: 100
     2018-12-27 13:53:58   statLuminosityDay Min: 0.00 Avg: 691.32 Max: 3494.00
     2018-12-26 23:59:58   statLuminosityDayLast Min: 0.01 Avg: 145.46 Max: 965.00
     2018-12-27 13:53:58   statLuminosityHour Min: 27.84 Avg: 1367.98 Max: 2753.00
     2018-12-27 12:59:58   statLuminosityHourLast Min: 2201.00 Avg: 2527.11 Max: 2938.00
     2018-12-27 13:53:58   statLuminosityMonth Min: 0.00 Avg: 414.94 Max: 4219.00
     2018-11-30 23:59:58   statLuminosityMonthLast Min: 0.00 Avg: 647.00 Max: 5183.00
     2018-12-27 13:53:58   statLuminosityYear Min: 0.00 Avg: 1673.92 Max: 65535.00
     2017-12-31 23:59:58   statLuminosityYearLast Min: 0.00 Avg: 1829.12 Max: 65535.00
     2018-12-27 13:53:58   statPressureDay Min: 1013.8 Avg: 1015.7 Max: 1017.6
     2018-12-26 23:59:58   statPressureDayLast Min: 1017.3 Avg: 1018.6 Max: 1020.1
     2018-12-27 13:53:58   statPressureHour Min: 1013.8 Avg: 1014.0 Max: 1014.2
     2018-12-27 12:59:58   statPressureHourLast Min: 1014.0 Avg: 1014.3 Max: 1014.6
     2018-12-27 13:53:58   statPressureMonth Min: 978.3 Avg: 1004.4 Max: 1022.0
     2018-11-30 23:59:58   statPressureMonthLast Min: 995.2 Avg: 1007.7 Max: 1025.1
     2018-12-27 13:53:58   statPressureYear Min: 970.0 Avg: 1004.8 Max: 1238.7
     2017-12-31 23:59:58   statPressureYearLast Min: 964.7 Avg: 1005.6 Max: 1032.2
     2018-12-27 13:53:58   statTemperatureDay Min: 2.7 Avg: 5.0 Max: 20.2
     2018-12-26 23:59:58   statTemperatureDayLast Min: 3.7 Avg: 4.7 Max: 5.4
     2018-12-27 13:53:58   statTemperatureHour Min: 5.5 Avg: 10.9 Max: 20.2
     2018-12-27 12:59:58   statTemperatureHourLast Min: 5.5 Avg: 5.6 Max: 5.8
     2018-12-27 13:53:58   statTemperatureMonth Min: -2.8 Avg: 5.6 Max: 20.2
     2018-11-30 23:59:58   statTemperatureMonthLast Min: -3.6 Avg: 6.5 Max: 17.0
     2018-12-27 13:53:58   statTemperatureYear Min: -10.7 Avg: 12.0 Max: 124.1
     2017-12-31 23:59:58   statTemperatureYearLast Min: -8.4 Avg: 11.3 Max: 33.5
     2018-12-27 13:53:58   state           T: 20.2 L: 41.59 P: 1014.2
     2018-12-27 13:53:58   temperature     20.2
   helper:
     HM_CMDNR   1
     PONtest    1
     _98_statistics env_stats
     mId        F102
     regLst     ,0
     rxType     132
     supp_Pair_Rep 0
     ack:
     bm:
       CUL_HM_Attr:
         cnt        2
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        27.12. 13:27:23
         max        0.0909099578857422
         tot        0.0909450054168701
         mAr:
           set
           env_thpl
           event-on-change-reading
           luminosity,humidity,pressure,temperature,battery
       CUL_HM_Get:
         cnt        5
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        27.12. 11:11:44
         max        0.0090491771697998
         tot        0.0101521015167236
         mAr:
           HASH(0x55c1ab30eb98)
           env_thpl
           ?
       CUL_HM_Set:
         cnt        979
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        27.12. 03:07:09
         max        0.148144006729126
         tot        3.15117120742798
         mAr:
           HASH(0x55c1ab30eb98)
           env_thpl
           ?
     expert:
       def        1
       det        1
       raw        0
       tpl        0
     io:
       newChn     +0B69DC,00,00,00
       nextSend   1545915239.07361
       rxt        0
       vccu       VCCU
       p:
         <HMID>
         00
         00
         00
       prefIO:
         sys_culHm
     mRssi:
       mNo        01
       io:
         HMLAN0:
           -65
           -65
         sys_culHm:
           -30
           -30
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   00
       qReqStat   00
     role:
       chn        1
       dev        1
     rpt:
       IO         sys_culHm
       flg        A
       ts         1545915238.89966
       ack:
         HASH(0x55c1ab30eb98)
         018002F155440B69DC00
     rssi:
       at_HMLAN0:
         avg        -60.2292020373514
         cnt        589
         lst        -65
         max        -55
         min        -74
       at_sys_culHm:
         avg        -66.3101045296167
         cnt        574
         lst        -38
         max        -38
         min        -86
     tmpl:
Attributes:
   IODev      HMLAN0
   IOgrp      VCCU:sys_culHm
   actCycle   000:10
   actStatus  alive
   alias      THPL-Sensor
   autoReadReg 4_reqStatus
   event-on-change-reading luminosity,humidity,pressure,temperature,battery
   event-on-update-reading stat.*Last,batVoltage
   expert     1_allReg
   firmware   0.15
   group      System
   icon       temp_outside
   model      HB-UW-Sen-THPL-O
   peerIDs    00000000,
   room       Wetter
   serialNr   UWS7398093
   subType    THPLSensor

Code Auswählen

Hast du es mal mit normalen Batterien versucht? Ein Step-Up Wandler kann die Akkus schön tiefenentladen, was sie überhaupt nicht mögen.

Hatte ich tatsächlich mal versucht, aber war nicht grundlegend anders (evtl. etwas länger). Aber was du sagst ist interessant, da mir aufgefallen ist, dass das BC700 beim Laden der Eneloops die manchmal gar nicht erkennt und ich sie dann mit einem "dummen" Ladegerät ein paar Sekunden vorladen muss, damit sie vom BC700 erkannt werden. Das würde absolut passen zu dem, was zu sagst.
Also schrotte ich die Akkus damit auf Dauer wegen des StepUps? Muss jedoch sagen, dass ich das schon ein paar Jahre so mache und die Eneloops noch bei über 700 mAH sind.

Code Auswählen

6 Wochen klingt definitiv viel zu wenig. Als Erstes den Ruhestrom messen, der müsste mit Step-Up im Bereich ca. 10-20 uA liegen. Die 6 Wochen lassen einen viel höheren Ruhestrom vermuten.

Habe gesehen, dass ich jahrelang brav die Batteriespannugn in die Datenbank geschrieben habe. Anbei mal ein Plot davon. Da kann man die 6 Wochen ganz gut sehen. Also es sind immer so zwischen 4 und 8 Wochen.

Ich hoffe, ich hab nix falsch gemacht: Ich komme beim Messen mit Multimeter auf 1660 uA im Idle

Musste Skala auf "mA" stellen, mit "uA" hat der Controller nicht gestartet bzw. nicht geblinkt beim Herstellen der Verbindung (sorry, bin Noob). Das kommt von der Größenordnung ganz gut hin, wenn ich eine Batteriekapazität von ca. 1500 mAH annehme. Komme dann ca. 40 Tage raus. Und da ist noch nicht der erhöhte Strom beim Senden drin.

Scheint also wirklich so zu sein, dass er einen sehr hohen Idle-Strom hat. Hat jemand eine Idee wie sowas kommen kann? $:-\$

Tom Major · 27 Dezember 2018, 14:35:01

Zitat von: vbs am 27 Dezember 2018, 14:13:12

Ich hoffe, ich hab nix falsch gemacht: Ich komme beim Messen mit Multimeter auf 1660 uA im Idle Musste Skala auf "mA" stellen, mit "uA" hat der Controller nicht gestartet bzw. nicht geblinkt beim Herstellen der Verbindung (sorry, bin Noob). Das kommt von der Größenordnung ganz gut hin, wenn ich eine Batteriekapazität von ca. 1500 mAH annehme. Komme dann ca. 40 Tage raus. Und da ist noch nicht der erhöhte Strom beim Senden drin.

Scheint also wirklich so zu sein, dass er einen sehr hohen Idle-Strom hat. Hat jemand eine Idee wie sowas kommen kann? $:-\$

Hmm, das er überhaupt nicht in den sleep geht kann es wahrscheinlich nicht sein, da müssten schon 3mA fließen und nicht 1,6.
https://github.com/TomMajor/AskSinPP_Examples/tree/master/Info/Ruhestrom#%C3%BCberpr%C3%BCfung-des-ruhestroms

Irgendwas zieht "Nebenstrom", systematisch I/O pins, Sensoren usw. prüfen so weit möglich.

Edit: Gut wäre auch eine Vergleichsmessung mit einem zweitem Sensor falls vorhanden und eine Messung ohne Step-Up um dort Fehler auszuschließen.

vbs · 27 Dezember 2018, 15:56:44

Hm ok danke, da muss ich dann mal tiefer einsteigen. Heißt ja vermutlich, die Sensoren entweder mal ganz ablöten oder so ablöten, dass man dazwischen Strom messen kann? Im Idealfall so, dass ich es hinterher auch wieder zusammen bekomme.

Ich spekulier mal so rum: kann wohl kein Problem mit der Firmware sein? Die Firmware sollte sich ja für alle Benutzer identisch verhalten (bei gleichem Hardwareaufbau, was ich mal voraus setze). Könnte es was mit den Fuses zu tun haben? Die sind ja sozusagen auch Software und wenn ich mich recht erinnere, dann sind die unabhängig von der Firmware.
Zur Hardware: klar, einen Kurzschluss irgendwo könnte ich mir auch als Erklärung vorstellen, aber dann würde der Sensor doch auch zumindest teilweise nicht funktionieren? Ist ein Bauteildefekt denkbar, der zu dem Stromverbrauch führt, aber trotzdem zu keiner Fehlfunktion?

EDIT:
Zweitsensor hab ich leider nicht.

vbs · 27 Dezember 2018, 16:14:09

Zum Beispiel: ich hab damals vor Jahren ein bisschen mit dem Board rumdebuggt. Das hab ich damals mit deinem AVR Dragon gemacht. Ich meine über debugWire. Das wiederum muss man ja per Fuse erst aktivieren. Könnte mir vorstellen, dass ich das nie wieder ausgeschaltet habe

Code Auswählen

debugWIRE und Sleepmode
Bei eingeschaltetem debugWIRE sind die Sleepmodes unwirksam. Es lässt sich zwar das richtige Verhalten, z.B. die Funktion des Timer2 mit einem Uhrenquarz im Power Save, beobachten. Der Stromverbrauch wird jedoch nicht gesenkt! Eine Messung des Stroms führt somit nicht zu praxisgerechten Ergebnissen.

https://www.mikrocontroller.net/articles/DebugWIRE

vbs · 27 Dezember 2018, 17:18:55

Blöd, Fuses sehen leider ok aus mMn... DebugWire ist nicht an. Ich fand das so plausibel

Tom Major · 27 Dezember 2018, 23:58:05

Zitat von: vbs am 27 Dezember 2018, 15:56:44
Hm ok danke, da muss ich dann mal tiefer einsteigen. Heißt ja vermutlich, die Sensoren entweder mal ganz ablöten oder so ablöten, dass man dazwischen Strom messen kann? Im Idealfall so, dass ich es hinterher auch wieder zusammen bekomme.

Ich spekulier mal so rum: kann wohl kein Problem mit der Firmware sein? Die Firmware sollte sich ja für alle Benutzer identisch verhalten (bei gleichem Hardwareaufbau, was ich mal voraus setze). Könnte es was mit den Fuses zu tun haben? Die sind ja sozusagen auch Software und wenn ich mich recht erinnere, dann sind die unabhängig von der Firmware.
Zur Hardware: klar, einen Kurzschluss irgendwo könnte ich mir auch als Erklärung vorstellen, aber dann würde der Sensor doch auch zumindest teilweise nicht funktionieren? Ist ein Bauteildefekt denkbar, der zu dem Stromverbrauch führt, aber trotzdem zu keiner Fehlfunktion?

EDIT:
Zweitsensor hab ich leider nicht.

Da du SMD Sensoren hast, würde ich die als Letztes ablöten da nicht so einfach wieder draufzubekommen

, glaub auch nicht das es daran liegt.
Ich kenne die Firmware 0.15 nicht, geht die auch sicher in den sleep? Da wäre ein 2. Gerät zum Vergleichen ideal gewesen.
Fuses sehen gut aus.
Ich würde wahrscheinlich als Erstes am Step-Up suchen, den testweise deaktivieren und mit 3V direkt den Strom messen..

The-Holgi · 28 Dezember 2018, 10:07:52

Hallo,
habe auch 3 von den Sensoren.
2 mit der Firmware 0.12 und einen mit 0.14.
Bei den beiden mit der 0.12 Firmware sind auch nach 6 Wochen die Batterien leer.
Wenn man den Sensor jedoch vorher kurz stromlos macht, also kurz eine Batterie raus und wieder rein, halten die Batterien mehrere Monate.
Es sieht so aus, als ob der Sensor sich nach ca. 6 Wochen ,,aufhängt".
Habe es bisher auch nicht geschafft die Firmware zu aktualisieren.
Gruß Holger

frank · 28 Dezember 2018, 11:06:02

der fehler wurde aber in fw0.14 behoben, und sollte damit auch in 0.15 nicht vorhanden sein.

ZitatBugfixes:
Fix millis() overflow bug. Now, the sensor stays in sleep mode after 49 days, so battery should not drained anymore

ich habe bei meinem sensor mit fw0.14 aber auch den eindruck, dass der batterieverbrauch gegenüber früher gestiegen ist. allerdings habe ich nur vermutungen, da ich in diesem sensor, wegen dem stepup, immer altbatterien, die in anderen devices bereits low gezeigt haben, noch ziehmlich lange nutzen konnte. das nicht funktionierende reading poweron macht eine analyse auch nicht einfacher.

der aktuelle batteriesatz, neue billigbatterien vom discounter, ist bereits nach 11,5 tagen von 3,3v auf 2,8v gesunken. das ist jedenfalls zu viel.

erste auffälligkeiten habe ich seit oktober wahrgenommen. da der sensor aussen unter einem dachvorsprung hängt, habe ich erst tiefe temperaturen und andauernde hohe luftfeuchtigkeit als ursachen in erwägung gezogen. aber das hätte mir früher dann eigentlich auch schon auffallen müssen. damals waren die batterien aber noch von einem anderen discounter.
beim batteriewechsel ist mir auch keine besondere feuchtigkeit im gehäuse aufgefallen.

ein zweiter sensor ist bereits vor ca. 1,5 jahren an selber position verstorben. bei dem habe ich den stepup im verdacht, habe aber noch keine zeit und lust verspürt das genau zu untersuchen.

scheinbar wird es nun dringend nötig, denn einen 3. sensor habe ich nicht mehr.

edit:
mein sensor ist ein vollbestückter universalsensor für innen.
model: HB-UW-Sen-THPL-I

vbs · 28 Dezember 2018, 11:52:51

Mir ist eingefallen, dass ich gelogen hab: ich hab doch einen Zweitsensor

Innensensor der sein Dasein vergessen im Kühlschrank fristet... Ist auch Firmware 0.15. Da halten die Batterien tatsächlich mehrer Jahre (siehe Plot), jedoch zwei AA (anstatt zwei AAA). Und ich hab den Strom gemessen im Idle und messe tatsächlich nur ca. 20 uA (anstatt 1600 uA wie bei meinem Außensensor).

Also einen generellen Firmware-Bug in der 0.15 würde ich damit ausschließen.