Batteriestatus und Speicherung des letzten Wechsel

Begonnen von Amenophis86, 12 Januar 2018, 19:23:20

Vorheriges Thema - Nächstes Thema

my-engel

#255
ZitatHast du (kürzlich) ein event-on-change-reading gesetzt!?

Ja, aber in einem ganz anderem Gerät was nichts mit Batterie und HM-CC-RT-DN zu tun hat...
in den Devices HM-CC-RT-DN steht niergendwo event-on-change-reading

Internals:
   DEF        356A8F
   FUUID      5c43081c-f33f-0edb-ea17-f26635cec50d8b40
   FVERSION   10_CUL_HM.pm:0.206330/2019-12-01
   HMUARTLGW_MSGCNT 626
   HMUARTLGW_RAWMSG 0500004E918610356A8F0000000A8CB7C70000
   HMUARTLGW_RSSI -78
   HMUARTLGW_TIME 2020-01-12 13:11:45
   IODev      MapleCUN_2.1
   LASTInputDev HMUARTLGW
   MSGCNT     1867
   MapleCUN_1.1_MSGCNT 606
   MapleCUN_1.1_RAWMSG A0F918610356A8F0000000A8CB7C70000::-95.5:MapleCUN_1.1
   MapleCUN_1.1_RSSI -95.5
   MapleCUN_1.1_TIME 2020-01-12 13:11:45
   MapleCUN_2.1_MSGCNT 635
   MapleCUN_2.1_RAWMSG A0F918610356A8F0000000A8CB7C70000::-59.5:MapleCUN_2.1
   MapleCUN_2.1_RSSI -59.5
   MapleCUN_2.1_TIME 2020-01-12 13:11:45
   NAME       Wohnzimmer.OG.FensterRechts
   NOTIFYDEV  global
   NR         57
   NTFY_ORDER 50-Wohnzimmer.OG.FensterRechts
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 Wohnzimmer.OG.FensterRechts_Weather
   channel_02 Wohnzimmer.OG.FensterRechts_Climate
   channel_03 Wohnzimmer.OG.FensterRechts_WindowRec
   channel_04 Wohnzimmer.OG.FensterRechts_Clima
   channel_05 Wohnzimmer.OG.FensterRechts_ClimaTeam
   channel_06 Wohnzimmer.OG.FensterRechts_remote
   lastMsg    No:91 - t:10 s:356A8F d:000000 0A8CB7C70000
   protLastRcv 2020-01-12 13:11:45
   protRcv    635 last_at:2020-01-12 13:11:45
   protRcvB   4 last_at:2020-01-12 09:02:44
   protSnd    3 last_at:2020-01-12 01:30:25
   protState  CMDs_done
   rssi_MapleCUN_2.1 cnt:1 min:-51 max:-51 avg:-51 lst:-51
   rssi_at_HMUARTLGW cnt:626 min:-85 max:-74 avg:-76.84 lst:-78
   rssi_at_MapleCUN_1.1 cnt:606 min:-100.5 max:-82 avg:-91.41 lst:-95.5
   rssi_at_MapleCUN_2.1 cnt:635 min:-69.5 max:-58.5 avg:-60.5 lst:-59.5
   READINGS:
     2020-01-11 11:04:10   Activity        alive
     2020-01-11 22:06:48   CommandAccepted yes
     2018-08-10 17:10:01   D-firmware      1.4
     2018-08-10 17:10:01   D-serialNr      LTK0135431
     2018-08-10 21:50:32   PairedTo        0x123456
     2018-08-10 21:50:32   R-backOnTime    10 s
     2018-08-10 21:50:32   R-btnLock       off
     2018-08-10 21:50:32   R-burstRx       on
     2018-08-10 21:50:32   R-cyclicInfoMsg on
     2018-08-10 21:50:32   R-cyclicInfoMsgDis 0
     2018-08-10 21:50:32   R-globalBtnLock off
     2018-08-10 21:50:32   R-localResDis   off
     2018-08-10 21:50:32   R-lowBatLimitRT 2.1 V
     2018-08-10 21:50:32   R-modusBtnLock  off
     2018-08-10 21:50:32   R-pairCentral   0x123456
     2020-01-12 13:11:45   actuator        0
     2020-01-12 13:11:45   battery         low
     2020-01-12 13:11:45   batteryLevel    2.2
     2020-01-12 09:02:44   controlMode     auto
     2020-01-12 13:11:45   desired-temp    17.5
     2020-01-12 13:11:45   measured-temp   18.3
     2020-01-12 13:11:45   motorErr        lowBat
     2018-08-10 21:25:15   sabotageAttack_ErrIoAttack cnt 2
     2020-01-12 01:30:25   state           CMDs_done
     2020-01-12 01:30:25   time-request    -
   helper:
     HM_CMDNR   145
     cSnd       ,11123456356A8F8004
     mId        0095
     peerFriend
     peerOpt    -:thermostat
     regLst     0
     rxType     140
     supp_Pair_Rep 0
     ack:
     expert:
       def        1
       det        1
       raw        0
       tpl        0
     io:
       newChn     +356A8F,00,00,00
       nextSend   1578831105.98144
       prefIO     
       rxt        2
       vccu       virtualCCU
       p:
         356A8F
         00
         00
         00
     mRssi:
       mNo        91
       io:
         HMUARTLGW:
           -78
           -78
         MapleCUL_1.1:
         MapleCUN_1.1:
           -95.5
           -95.5
         MapleCUN_2.1:
           -53.5
           -53.5
         MapleCUN_3.1:
     prt:
       bErr       0
       sProc      0
       sleeping   1
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       prs        1
     rssi:
       MapleCUN_2.1:
         avg        -51
         cnt        1
         lst        -51
         max        -51
         min        -51
       at_HMUARTLGW:
         avg        -76.8498402555909
         cnt        626
         lst        -78
         max        -74
         min        -85
       at_MapleCUN_1.1:
         avg        -91.4183168316832
         cnt        606
         lst        -95.5
         max        -82
         min        -100.5
       at_MapleCUN_2.1:
         avg        -60.5031496062992
         cnt        635
         lst        -59.5
         max        -58.5
         min        -69.5
     shRegW:
       07         04
     tmpl:
Attributes:
   IODev      MapleCUN_2.1
   IOgrp      virtualCCU
   actCycle   000:10
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     1_allReg
   firmware   1.4
   icon       sani_heating
   model      HM-CC-RT-DN
   room       Obergeschoss->Wohnzimmer
   serialNr   LTK0135431
   subType    thermostat
   webCmd     getConfig:clear msgEvents:burstXmit


Gruß Uwe

MadMax-FHEM

#256
Hi Uwe,

hmm, eigenartig...
...weil ja die Readings erst aktualisiert wurden...

Gut, ich benutze (immer noch) "meinen" Ursprungscode...
Aber der ist im Kern gleich...

Und tut nach wie vor...
(habe erst heute eine Telegram-Nachricht bzgl. Batteriewechsel bekommen, gut es war kein Heizkörpertermostat sondern ein Homematic Wandthermostat aber die sind ja bzgl. "battery" gkeich)

Anmerkung: zukünftig lists besser in "code-Tags", das '#' im "Menü"... ;)

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)

my-engel

Hallo Joachim,

habe wieder gleichen Stand wie vorher, auch 0.0 statt "0.0" bringt nichts.
Bin nun wieder auf Ursprungscode.
Es verhält sich so als ob irgendwo event-on-change-reading gesetzt wäre.
Ich finde nur keine Attribute. Um beim Bsp.-Device zu bleiben:
setreading Wohnzimmer.OG.FensterRechts batteryLevel 2.0
Telegram und "rgBatterieStatus" funktionieren,
dann warten bis automatisch das Device seine Readings bekommt und auch dann funktioniert "rgBatterieStatus".
Alle weiteren Readings werden im Device also im Wohnzimmer.OG.FensterRechts - HM-CC-RT-DN aktualisiert
aber nicht in die readingGroup "rgBatterieStatus" übertragen...
hast Du hier noch eine Idee?

MfG Uwe

MadMax-FHEM

#258
Das mit "0.0" und 0.0 ist "egal", Perl ist da (leider ;)  ) ziemlich tolerant...
Es wäre nur "korrekter" weil es ja um numerische Werte statt um Zeichenketten geht ;)

Hmm, einzig was ich so mitbekommen habe ist, dass irgendwann mal bei ReadingsGroup "etwas" bzgl. Events etc. umgebaut wurde aber mittlerweile wieder laufen soll(te)...

Und wie geschrieben: bei mir kein Problem.

Du kannst ja mal den Eventmonitor öffnen und einen Filter setzen und sehen, ob entsprechende Events bzgl. battery kommen...

Wenn die kommen, dann höchstens das Notify was ja die Berechnungsroutine anwirft prüfen, ob das triggert...

EDIT: wobei wenn das mittels setzen durch setreading tut... Dann sollte das ja gehen...

Wenn die Events nicht kommen, dann eben prüfen warum nicht.
Sehe aber aktuell nichts...

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)

sepultura30

Zitat von: MadMax-FHEM am 12 Januar 2020, 12:08:50
Hmmm, kann ich nicht nachvollziehen...

Habt ihr kürzlich (also unter 3 Wochen) ein fhem Update gemacht?

Gruß, Joachim

Hallo Joachim,

ich mache täglich Updates und hier mal das Readings wie es bei mir ist.


setstate Thermostat_Ess CMDs_done
setstate Thermostat_Ess 2019-01-20 21:40:35 .D-devInfo 00FFFF
setstate Thermostat_Ess 2019-01-20 21:40:35 .D-stc 59
setstate Thermostat_Ess 2017-11-22 17:35:35 .R-btnLock off
setstate Thermostat_Ess 2017-11-22 17:35:35 .R-globalBtnLock off
setstate Thermostat_Ess 2017-11-22 17:35:35 .R-localResDis off
setstate Thermostat_Ess 2020-01-10 22:40:10 .R-lowBatLimitRT 2.4 V
setstate Thermostat_Ess 2017-11-22 17:35:35 .R-modusBtnLock off
setstate Thermostat_Ess 2020-01-12 22:04:35 .protLastRcv 2020-01-12 22:04:35
setstate Thermostat_Ess 2020-01-12 11:20:44 Activity alive
setstate Thermostat_Ess 2020-01-10 22:40:08 CommandAccepted yes
setstate Thermostat_Ess 2019-01-20 21:40:35 D-firmware 1.4
setstate Thermostat_Ess 2019-01-20 21:40:35 D-serialNr OEQ0855361
setstate Thermostat_Ess 2020-01-10 22:40:10 PairedTo 0x945612
setstate Thermostat_Ess 2017-11-22 17:35:35 R-backOnTime 10 s
setstate Thermostat_Ess 2017-11-22 17:35:35 R-burstRx on

MadMax-FHEM

Würdest du bitte (wie geschrieben) ein list posten!?

So sehe ich zwar, dass die Readings (bei dir) so heißen aber so kann man keine Idee entwickeln: warum

Weil ich auch nichts gelesen hätte, dass da etwas geändert wurde...

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)

FunkOdyssey

Zitat von: DeeSPe am 31 Oktober 2019, 10:18:05
Ja, es liegt daran dass das notify auf battery, batteryLevel und batteryPercent reagiert.
Ändere doch einfach den Trigger des notify:
define NO.BatterieNotify notify .*:(battery|batteryLevel)\s.* {BatteryStatusFunction($NAME, $EVENT)}

Gruß
Dan

Oh Mist. Ich merke jetzt gerade erst, dass der gesamte Notify mit dieser Änderung seit Monaten nicht mehr funktioniert. Ich habe anstatt \s.* auch ein einfaches $ ausprobiert. Alles ohne Erfolg.

Hast du noch einen Tipp? Danke.

MadMax-FHEM

Also ich habe ein Notify auf "nur" battery.*

Weil doch meist also zumindest bei mir die Geräte:

battery
batteryPercent
batteryValue
...

haben.
Und (zumindest bei mir) auch immer zusammen kommen, slso sollte ein Device mehrere "Batterie-Readings" haben (eigentl. haben bei mir alle Devices mind. 2 davon)...

Zu viel auslösen/berechnen schränke ich dann bei den Devices mittels event-on-change-reading so ein, dass aber immer noch aktuelle Werte in der ReadingsGroup angezeigt werden...

Mehr Tipp fällt mir nicht ein...

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)

sepultura30

Zitat von: MadMax-FHEM am 12 Januar 2020, 22:32:39
Würdest du bitte (wie geschrieben) ein list posten!?

So sehe ich zwar, dass die Readings (bei dir) so heißen aber so kann man keine Idee entwickeln: warum

Weil ich auch nichts gelesen hätte, dass da etwas geändert wurde...

Gruß, Joachim

Hallo Joachim,

wie gewünscht das list vom Device :)


Internals:
   DEF        5B0461
   FUUID      5c44ee7a-f33f-784a-1fe6-292cd529b2de6cb8
   IODev      myHmUART
   LASTInputDev myHMLANGW
   MSGCNT     51
   NAME       WandThermWohn
   NOTIFYDEV  global
   NR         122
   NTFY_ORDER 50-WandThermWohn
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 WandThermWohn_Weather
   channel_02 WandThermWohn_Climate
   channel_03 WandThermWohn_WindowRec
   channel_06 WandThermWohn_remote
   channel_07 WandThermWohn_SwitchTr
   lastMsg    No:06 - t:70 s:5B0461 d:000000 00DC23
   myHMLANGW_MSGCNT 17
   myHMLANGW_RAWMSG 050000300684705B046100000000DC23
   myHMLANGW_RSSI -48
   myHMLANGW_TIME 2020-01-13 12:18:57
   myHmUART_MSGCNT 17
   myHmUART_RAWMSG 050000320684705B046100000000DC23
   myHmUART_RSSI -50
   myHmUART_TIME 2020-01-13 12:18:57
   myRemoteHmUART_MSGCNT 17
   myRemoteHmUART_RAWMSG 0500003C0684705B046100000000DC23
   myRemoteHmUART_RSSI -60
   myRemoteHmUART_TIME 2020-01-13 12:18:57
   protLastRcv 2020-01-13 12:18:57
   protRcv    17 last_at:2020-01-13 12:18:57
   rssi_at_myHMLANGW cnt:17 min:-49 max:-47 avg:-48.05 lst:-48
   rssi_at_myHmUART cnt:17 min:-50 max:-48 avg:-49.47 lst:-50
   rssi_at_myRemoteHmUART cnt:17 min:-62 max:-60 avg:-61.05 lst:-60
   .attraggr:
   .attrminint:
     state:900
   Helper:
     DBLOG:
       desired-temp:
         myDbLog:
           TIME       1578914036.72651
           VALUE      22.0
       measured-temp:
         myDbLog:
           TIME       1578914036.72651
           VALUE      22.0
   READINGS:
     2020-01-11 02:39:04   .R-btnLock      off
     2020-01-11 02:39:04   .R-globalBtnLock off
     2020-01-11 02:39:04   .R-localResDis  off
     2020-01-12 01:31:15   .R-lowBatLimitRT 2.4 V
     2020-01-11 02:39:04   .R-modusBtnLock off
     2020-01-13 12:18:57   .protLastRcv    2020-01-13 12:18:57
     2020-01-13 12:00:52   Activity        alive
     2020-01-13 10:00:03   CommandAccepted yes
     2020-01-11 02:38:07   D-firmware      1.3
     2020-01-11 02:38:07   D-serialNr      OEQ0760983
     2020-01-13 01:14:29   LastLowBattMailSent 1
     2020-01-13 01:19:24   PairedTo        0x945612
     2020-01-11 02:39:04   R-burstRx       on
     2020-01-11 02:39:04   R-cyclicInfoMsg on
     2020-01-11 02:39:04   R-cyclicInfoMsgDis 0
     2020-01-11 02:39:04   R-pairCentral   0x945612
     2020-01-13 01:19:24   RegL_00.        00:00 01:01 02:01 09:01 0A:94 0B:56 0C:12 0F:00 11:00 12:18 16:00 18:00 19:00 1A:00
     2020-01-13 12:00:38   RegL_07.       
     2020-01-13 12:13:56   battery         ok
     2020-01-13 12:13:56   batteryLevel    3.2
     2020-01-13 12:13:56   desired-temp    22.0
     2020-01-13 12:13:56   measured-temp   22.0
     2020-01-13 01:19:18   powerOn         2020-01-13 01:19:18
     2020-01-13 01:19:18   recentStateType info
     2020-01-13 10:00:04   state           CMDs_done
     2020-01-13 01:19:20   time-request    -
   helper:
     HM_CMDNR   6
     PONtest    1
     mId        00AD
     peerFriend
     peerOpt    -:thermostat
     regLst     0
     rxType     6
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +5B0461,00,01,00
       nextSend   1578914338.03532
       prefIO     
       rxt        0
       vccu       VCCU
       p:
         5B0461
         00
         01
         00
     mRssi:
       mNo        06
       io:
         myHMLANGW:
           -48
           -48
         myHmUART:
           -44
           -44
         myRemoteHmUART:
           -60
           -60
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       prs        1
     rssi:
       at_myHMLANGW:
         avg        -48.0588235294118
         cnt        17
         lst        -48
         max        -47
         min        -49
       at_myHmUART:
         avg        -49.4705882352941
         cnt        17
         lst        -50
         max        -48
         min        -50
       at_myRemoteHmUART:
         avg        -61.0588235294118
         cnt        17
         lst        -60
         max        -60
         min        -62
     shRegW:
       07         02
     tmpl:
Attributes:
   .mId       00AD
   IODev      myHmUART
   IOgrp      VCCU
   actCycle   000:10
   actStatus  alive
   autoReadReg 4_reqStatus
   event-min-interval state:900
   expert     2_raw
   firmware   1.3
   icon       hm-tc-it-wm-w-eu
   model      HM-TC-IT-WM-W-EU
   msgRepeat  1
   room       Esszimmer,Heizung,Wohnzimmer
   serialNr   OEQ0760983
   subType    thermostat
   webCmd     getConfig:clear msgEvents

MadMax-FHEM

Also zunächst mal: danke! ;)

Dann: komisch ist, dass einige "Register-Readings" (gekennzeichnet durch R-...) OHNE Punkt und andere wiederum MIT Punkt da sind.

Normal war (ist denke ich immer noch): OHNE Punkt!

Daher mal ergründen (neuer Thread in Homematic) WARUM das bei dir so ist...
(evtl. mache ich mal ein Update und schaue, ob das bei mir dann auch so kommt / denke aber, dass man davon schon mehr gelesen hätte, wenn?)


Und dann werde ich selbst aus der Beschreibung bzgl. event-min-interval nicht so ganz schlau...
Nutze nur event-on-change-reading...

Aber könnte es sein, dass event-min-interval NUR auf state OHNE event-on-change-reading etc. dazu führt, dass eben nur noch Events für state kommen!?
https://wiki.fhem.de/wiki/Event-min-interval

Schon mal den Eventmonitor geöffnet!?

Oder ging es bei dir "nur" um die Berechnung? ;)
(Bei so viel "Durcheinander" kann man schon mal was aus dem Auge verlieren ;)  )

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)

Wzut

Zitat von: MadMax-FHEM am 13 Januar 2020, 13:11:48
Dann: komisch ist, dass einige "Register-Readings" (gekennzeichnet durch R-...) OHNE Punkt und andere wiederum MIT Punkt da sind.
Nix komisch, war bei mir schon immer so :)
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

MadMax-FHEM

Zitat von: Wzut am 13 Januar 2020, 15:44:36
Nix komisch, war bei mir schon immer so :)

Und was heißt immer!?
Ab wann/wie lange schon immer? ;)

EDIT: auch "gemischt" oder alle mit/ohne Punkt!?

Also bei mir (und wohl den Meisten, zumindest die lists die ich gesehen habe ;) ) noch nie so...

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)

Wzut

puhh , ja wann habe ich mir den HM-CC-RT-DN gekauft ... ??? die ältesten Readings sind vom August 2018, könnte hinkommen.

Punkt gewinnt mit 6:5 :)
2018-08-07 07:47:23   .R-btnLock      off
2018-08-07 07:47:23   .R-globalBtnLock off
2018-08-07 07:47:23   .R-localResDis  off
2018-08-07 07:47:23   .R-lowBatLimitRT 2 V
2018-08-07 07:47:23   .R-modusBtnLock off
2020-01-13 16:17:48   .protLastRcv    2020-01-13 16:17:48

2018-08-07 07:47:23   R-backOnTime    10 s
2018-08-07 07:47:23   R-burstRx       on
2018-08-07 07:47:23   R-cyclicInfoMsg on
2018-08-07 07:47:23   R-cyclicInfoMsgDis 0
2018-08-07 07:47:23   R-pairCentral   0x230960
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

MadMax-FHEM

Danke!

Hmmm...

Ich denke ich werde mal im Homematic Forum die Frage stellen ;)

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)

FunkOdyssey

Zitat von: MadMax-FHEM am 13 Januar 2020, 00:17:39
Also ich habe ein Notify auf "nur" battery.*

Weil doch meist also zumindest bei mir die Geräte:

battery
batteryPercent
batteryValue
...

haben.
Und (zumindest bei mir) auch immer zusammen kommen, slso sollte ein Device mehrere "Batterie-Readings" haben (eigentl. haben bei mir alle Devices mind. 2 davon)...

Zu viel auslösen/berechnen schränke ich dann bei den Devices mittels event-on-change-reading so ein, dass aber immer noch aktuelle Werte in der ReadingsGroup angezeigt werden...

Mehr Tipp fällt mir nicht ein...

Gruß, Joachim

Ich versuche nun folgende Schreibweise (Doppelpunkt ergänzt) und warte auf das Event.
.*:(battery|batteryLevel):\s.* {BatteryStatusFunction($NAME, $EVENT)}