[gelöst] Batterieverbrauch Rauchmelder erhöht, seit Abfrage des Ladezustands

Begonnen von dt2510, 25 April 2018, 15:46:41

Vorheriges Thema - Nächstes Thema

dt2510

Da meine ZWave Rauchmelder über ein Jahr konstant 100% Batterieladung angezeigt haben, habe ich sie mithilfe eines "at" regelmäßig abgefragt.

Ursprüngliche Abfrage (täglich)
define FGSD002_ID25GetBattery at *00:00:01 {fhem("get FGSD002_ID25 battery")}

Danach hat sich eine Veränderung ergeben ... Anfangs minimal, dann kontinuierlich nach unten (s.Bild). Daraufhin hab' ich die Abfrage korrigiert, um nur noch 1x pro Woche den Stand zu aktualisieren.

Korrigierte Abfrage (1x pro Woche)
define FGSD002_ID25GetBattery at *00:00:01 {if ($wday == 0) {fhem("get FGSD002_ID25 battery")}}

Ich weiß allerdings nicht, ob er wirklich nur noch einmal pro Woche abfragt (das at kommt ja immer noch täglich, die Entscheidung ist erst innerhalb des Befehls). Die Batterieleistung nimmt weiterhin viel stärker ab als vorher ...

dt2510

Könnte mir bitte jemand bestätigen, ob die Abfrage im "at" korrekt ist und wirklich nur 1x pro Woche geprüft wird ? Mittlerweile ist die erste Batterie auf 55% runter ....

Otto123

Moin,

du kannst es Dir doch selbst bestätigen. Ersetze doch einfach den Teil
{fhem("get FGSD002_ID25 battery")}durch
Log(3,"GetBattery")
Dann siehst Du einfach im Log ob es funktioniert und siehst auch ob Dein at das Batteriesaugende Problem ist.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

dt2510

da hast du natürlich Recht ... danke ! Teste ich gleich mal ..

dt2510

der Korrekte Befehl war {if ($wday == 0) {Log(3,"GetBattery")}} ...

Mit der Angabe von $wday == 1 (Montag) kam die Meldung im Log ... dann scheint die Entladung ab einem gewissen Punkt wirklich sehr schnell zu sein ...

MadMax-FHEM

Bei dem Rauchmelder kannst du auch ein Notify auf "Aufwachen" machen und dann 'get Name battery' aufrufen.
Dann wird der Aufruf (weil ja wach) sofort bearbeitet.

Das "at" ist sogar irrelevant, da der Rauchmelder die Anfrage eh nur bearbeitet, wenn er wach ist...

Bis dahin wird es eh im Sendepuffer "vorgehalten"...

Wie oft, also in welchem Intervall er aufwacht lässt sich einstellen...
Ebenso wie oft er Werte wie Temp etc. schickt...

Das ist eher relevant für die Batterielebensdauer.
Ebenso in wievielen AssocGroups er ist (also an wie viele Teilnehmer er meldet)...

Bin grad unterwegs aber wenn ich zuhause bin poste ich mal mein Notify...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

dt2510

ich hab' hier schonmal ein List des betreffenden Rauchmelders angehängt

Internals:
   AeonGen5_MSGCNT 7
   AeonGen5_RAWMSG 00040019028407
   AeonGen5_TIME 2018-04-30 11:06:37
   DEF        xxxxxxxx 25
   IODev      AeonGen5
   LASTInputDev AeonGen5
   MSGCNT     7
   NAME       FGSD002_ID25
   NR         161
   STATE      associationAdd 4 1
   TYPE       ZWave
   ZWaveSubDevice no
   homeId     d86af805
   isWakeUp   1
   lastMsgSent 1525079199.4149
   nodeIdHex  19
   READINGS:
     2018-04-28 05:00:40   battery         55 %
     2017-03-03 09:54:49   model           FIBARO System FGSD002 Smoke Sensor
     2017-03-03 09:54:49   modelConfig     fibaro/fgsd002.xml
     2017-03-03 09:54:49   modelId         010f-0c02-1002
     2017-03-03 09:54:49   state           associationAdd 4 1
     2018-04-29 13:57:17   temperature     20.9 C
     2018-04-30 11:06:39   timeToAck       0.026
     2018-04-30 11:06:39   transmit        OK
     2018-04-30 11:06:37   wakeup          notification
Attributes:
   IODev      AeonGen5
   alias      Rauchmelder Schlafzimmer
   classes    ZWAVEPLUS_INFO BASIC VERSION MANUFACTURER_SPECIFIC DEVICE_RESET_LOCALLY ASSOCIATION_GRP_INFO ASSOCIATION POWERLEVEL WAKE_UP BATTERY ALARM CRC_16_ENCAP CONFIGURATION SENSOR_MULTILEVEL MULTI_CHANNEL_ASSOCIATION APPLICATION_STATUS SENSOR_ALARM SECURITY FIRMWARE_UPDATE_MD
   group      Rauchmelder
   icon       secur_smoke_detector
   room       Schlafzimmer,_ZWave
   userattr   Batteries Batteries_map structexclude
   vclasses   ALARM:5 APPLICATION_STATUS:1 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 BASIC:1 BATTERY:1 CONFIGURATION:1 CRC_16_ENCAP:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:3 MANUFACTURER_SPECIFIC:2 MULTI_CHANNEL_ASSOCIATION:2 POWERLEVEL:1 SECURITY:1 SENSOR_ALARM:1 SENSOR_MULTILEVEL:8 VERSION:2 WAKE_UP:2 ZWAVEPLUS_INFO:2


Am Wakeup Intervall hab' ich nix verändert ... hier mal der Log der ersten beiden Tage seit Inklusion

2017-03-03_09:54:49 FGSD002_ID25 associationAdd 5 1
2017-03-03_09:54:49 FGSD002_ID25 associationAdd 4 1
2017-03-03_09:54:49 FGSD002_ID25 model: FIBARO System FGSD002 Smoke Sensor
2017-03-03_09:54:49 FGSD002_ID25 modelConfig: fibaro/fgsd002.xml
2017-03-03_09:54:49 FGSD002_ID25 modelId: 010f-0c02-1002
2017-03-03_09:55:08 FGSD002_ID25 wakeup: notification
2017-03-03_09:55:19 FGSD002_ID25 temperature: 24.9 C
2017-03-03_09:57:47 FGSD002_ID25 wakeup: notification
2017-03-03_09:57:48 FGSD002_ID25 battery: 100 %
2017-03-03_09:57:51 FGSD002_ID25 wakeup: notification
2017-03-03_10:04:50 FGSD002_ID25 temperature: 23.9 C
2017-03-03_10:09:11 FGSD002_ID25 temperature: 22.9 C
2017-03-03_10:17:22 FGSD002_ID25 temperature: 21.9 C
2017-03-03_10:41:38 FGSD002_ID25 temperature: 20.9 C
2017-03-03_15:56:03 FGSD002_ID25 wakeup: notification
2017-03-03_18:02:26 FGSD002_ID25 temperature: 19.9 C
2017-03-03_21:57:53 FGSD002_ID25 wakeup: notification
2017-03-04_03:59:41 FGSD002_ID25 wakeup: notification
2017-03-04_10:01:12 FGSD002_ID25 wakeup: notification
2017-03-04_16:02:36 FGSD002_ID25 wakeup: notification
2017-03-04_19:46:09 FGSD002_ID25 temperature: 20.9 C


und das der letzten 3 Tage

2018-04-28_05:00:40 FGSD002_ID25 battery: 55 %
2018-04-28_05:00:41 FGSD002_ID25 wakeup: notification
2018-04-28_05:30:24 FGSD002_ID25 temperature: 19.9 C
2018-04-28_10:49:40 FGSD002_ID25 temperature: 20.9 C
2018-04-28_11:01:22 FGSD002_ID25 wakeup: notification
2018-04-28_17:02:00 FGSD002_ID25 wakeup: notification
2018-04-28_23:02:26 FGSD002_ID25 wakeup: notification
2018-04-29_01:43:33 FGSD002_ID25 temperature: 19.9 C
2018-04-29_05:03:10 FGSD002_ID25 wakeup: notification
2018-04-29_11:04:12 FGSD002_ID25 wakeup: notification
2018-04-29_13:57:17 FGSD002_ID25 temperature: 20.9 C
2018-04-29_17:04:46 FGSD002_ID25 wakeup: notification
2018-04-29_23:05:21 FGSD002_ID25 wakeup: notification
2018-04-30_05:06:05 FGSD002_ID25 wakeup: notification
2018-04-30_11:06:37 FGSD002_ID25 wakeup: notification


"battery" Werte kommen erst seit 6.März - an dem Tag habe ich das "at" Kommando (täglich) eingebaut. Die einzige frühere "battery" Meldung war am Tag der Inklusion.

MadMax-FHEM

Klar der Batteriewert kommt nur auf Anfrage...
Antwort nur bei "Wakeup"...

Daher das Notify... ;-)

Bis denn, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

MadMax-FHEM

Sieht doch soweit gut aus...

Hast du an Temperatur-Thresholds etc. was geändert?
(trägt dazu bei öfter/weniger oft die Temp zu übertragen -> Batterielebensdauer)

Irgendwo hier gibt es einen Thread bzgl. AssocGroups.
So wie ich Kirkan verstanden habe reicht Assoc 1...
...bei dir ist 4 "komisch".
Hast du den Rauchmelder direkt mit einem Aktor "verbunden"?
Damit er bei Rauchalarm auslöst oder irgendwas schaltet etc.?
(wobei ich grad nicht weiß welche AssocGroup für was genau ist, außer der 1)

Wenn nicht, sollte AssocGroup 1 ("Controller" also IODev/Funkmodul/fhem) reichen...
Ich hab allerdings auch noch mehr als 1 drin, muss ich bei Gelegenheit mal "bereinigen"...

Achso und hier das Notify:

define nZWaveGetBattery notify .*.wakeup:.notification get $NAME battery

Das sollte für alle ZWave-Geräte, die Wakeup sind funktionieren...

Wie gesagt der Batteriewert wird nur "auf Anfrage" übertragen, bei dir also seit dem 'at'.
Wobei halt das 'at' den Aufruf erst mal bis zum nächsten Wakeup des Gerätes in der Send-Queue hält...
Das Notify macht im Prinzip das gleiche allerdings erfolgt die Abfrage, wenn das Geräte meldet, dass es gerade wach ist...

P.S.: einer meiner Rauchmelder war auch lange Zeit auf 100% und dann irgendwann "ratzfatz" leer... Die anderen (ungefähr gleich gekauft) sind noch gut dabei ;)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

dt2510

Zitat von: MadMax-FHEM am 30 April 2018, 20:40:48
Hast du an Temperatur-Thresholds etc. was geändert?
(trägt dazu bei öfter/weniger oft die Temp zu übertragen -> Batterielebensdauer)

So wie ich Kirkan verstanden habe reicht Assoc 1...
...bei dir ist 4 "komisch".
Hast du den Rauchmelder direkt mit einem Aktor "verbunden"?
Damit er bei Rauchalarm auslöst oder irgendwas schaltet etc.?
(wobei ich grad nicht weiß welche AssocGroup für was genau ist, außer der 1)

Ich kann mich nicht erinnern an den Temperatur-Thresholds was verändert zu haben.
Das mit den AssocGroups will ich mir schon genauer ansehen, seit ich FHEM einsetze (mittlerweile über 2 Jahre). Die Rauchmelder (wie alle meine ZWave Aktoren/Sensoren) sind nur in FHEM eingebunden, ich hab' keine direkten Verknüpfungen.

Wenn ich das richtig verstanden habe, liest das notify den Inhalt von battery immer dann wenn sowieso ein wakeup kommt. Wird der Inhalt dabei vom Gerät aktualisiert ? Und wenn ja, wieso wurde der Wert vor meinem "at" nicht beim wakeup aktualisiert ?

MadMax-FHEM

Der Wert "battery" wird nur auf "Nachfrage" vom Gerät geliefert.

Hier ist es lediglich ein anderer "Weg/Mechanismus".

Ohne Abfrage kein Wert. Daher hattest du vor deinem 'at' auch nie eine Aktualisierung...

Bei der Abfrage mit 'at' kommt der Wert, wenn das Gerät aufwacht. Solange "merkt" sich fhem (Sende-Queue) die Anfrage und schickt sie, wenn das Gerät aufwacht.

Mit dem Notify wird "gewartet" bis das Gerät aufwacht und dann die Abfrage geschickt. Gerät ist wach und Antwortet.

Soll heißen egal wie schnell deine 'at' (oder wie oft etc.) nachfragen die Antwort kommt eh erst, wenn das Gerät aufwacht.

Wenn du den Befehl manuell per FhemWeb absetzt kommt ja auch die Meldung: "Abarbeitung beim nächsten Wakeup" (naja oder so ähnlich)

Kurz, da nur Handy...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

dt2510

Hat prima funktioniert ... das notify spart mir etliche at's :) Die schwächste Batterie ist mittlerweile leider auf 50% - ich denke es wird langsam Zeit für einen Satz neue ...

MadMax-FHEM

Bitte gerne!

Also bei 50% würde ich noch nicht hektisch werden...

Ich lasse mir bei 5% eine Nachricht schicken, damit ich dann schon mal Batterien zurecht lege...
...allerdings ging es dann schon recht schnell (unter 1-2 Wochen).

Dazu nutze ich folgendes: https://forum.fhem.de/index.php/topic,82637.0.html
(bzw. halt immer noch meinen "Ursprungscode" ;)   )

Achja, dann den Thread bitte noch als gelöst kennzeichnen, umbenennen in beispielsweise [gelöst] Batterieverbrauch Rauchmelder erhöht, seit Abfrage des Ladezustands per "at"

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)