Batteriestatus und Speicherung des letzten Wechsel

gent · 14 Februar 2023, 20:42:16

Die Dummies, ReadingsGroup und Notify werden ja im Raum Z-System->BatteryCheck angelegt. Das steht ja in der Zeile

 my $Room = "Z_System->BatteryCheck"; #room for the dummys

Wenn ich das jetzt nachträglich ändern will, was muss ich dann tun? Reload des Moduls und dann nochmal die BatteryStart ausführen?

LG Holger

MadMax-FHEM · 14 Februar 2023, 21:03:45

Ich denke du kannst einfach bei dummy, readingsGroup etc. das room Attribut ändern.

Wichtig sind/ist nur der Name der/des dummy, da bei dem/denen ja Readings in der Sub (die per "Battery-notify" aufgerufen wird) gesetzt werden...

Die Sub zum Anlegen ist ja "nur" damit man das nicht selbst/manuell alles anlegen muss und die Namen etc. "zusammenspielen"...

EDIT: und es ist kein Modul, sondern ein paar Subs (zum Anlegen) und per notify aufgerufen zum "Berechnen" und "Setzen" von Readings und senden von Nachrichten etc.

Gruß, Joachim

gent · 12 Juli 2023, 00:28:51

Hi,

habe gerade entdeckt, dass der Batteriestatus meiner Fenstersensoren HM-SEC-SCO nicht upgedatet werden. Direkt in den Devices wird der Battery-Status von vor wenigen Minuten angezeigt. Im der Readings Group rgBatteryStatus sehe ich den Status vom 2023-05-06 11:00:30

Ist klar, was ich meine?

Viele Grüße
Holger

MadMax-FHEM · 12 Juli 2023, 07:59:13

Wie wäre es mit einem list des HM-SEC-SCO?

event-on- Attribute gesetzt?

Gruß, Joachim

gent · 04 August 2023, 21:01:05

Code Auswählen

defmod BD.Fenster CUL_HM 697742
attr BD.Fenster .mId 00C7
attr BD.Fenster DbLogExclude .*
attr BD.Fenster IOgrp VCCU:CUL_1
attr BD.Fenster actCycle 002:50
attr BD.Fenster actStatus alive
attr BD.Fenster alias Badezimmerfenster
attr BD.Fenster autoReadReg 4_reqStatus
attr BD.Fenster devStateIcon devStateIcon closed:fts_door open:fts_door_open
attr BD.Fenster event-on-change-reading .*
attr BD.Fenster expert defReg,rawReg
attr BD.Fenster firmware 1.0
attr BD.Fenster model HM-SEC-SCO
attr BD.Fenster peerIDs 00000000,6951BB03
attr BD.Fenster room 02_Mitte->Bad,CUL_HM
attr BD.Fenster serialNr PEQ0579708
attr BD.Fenster subType threeStateSensor

setstate BD.Fenster open
setstate BD.Fenster 2020-12-22 19:47:15 .D-devInfo 810101
setstate BD.Fenster 2020-12-22 19:47:15 .D-stc 80
setstate BD.Fenster 2019-01-10 19:22:08 .R-msgScPosA open
setstate BD.Fenster 2019-01-10 19:22:08 .R-msgScPosB closed
setstate BD.Fenster 2019-01-10 19:22:08 .R-transmDevTryMax 6
setstate BD.Fenster 2019-01-10 19:22:08 .R-transmitTryMax 6
setstate BD.Fenster 2023-08-02 22:12:18 .associatedWith BD.Fenster,BD.Fenster,BD.Thermostat_WindowRec
setstate BD.Fenster 2023-05-10 19:20:25 .peerListRDate 2023-05-10 19:20:25
setstate BD.Fenster 2023-08-04 20:15:21 .protLastRcv 20230804201521
setstate BD.Fenster 2023-08-02 22:21:33 Activity alive
setstate BD.Fenster 2021-10-09 17:50:01 CommandAccepted no
setstate BD.Fenster 2020-12-22 19:47:15 D-firmware 1.0
setstate BD.Fenster 2020-12-22 19:47:15 D-serialNr PEQ0579708
setstate BD.Fenster 2023-08-04 20:15:21 IODev CUL_1
setstate BD.Fenster 2023-05-10 19:20:24 PairedTo 0x753347
setstate BD.Fenster 2019-08-19 20:24:22 R-BD.Thermostat_WindowRec-expectAES off
setstate BD.Fenster 2019-08-19 20:24:22 R-BD.Thermostat_WindowRec-peerNeedsBurst on
setstate BD.Fenster 2019-01-10 19:22:08 R-cyclicInfoMsg on
setstate BD.Fenster 2019-01-10 19:22:08 R-eventDlyTime 0 s
setstate BD.Fenster 2019-01-10 19:22:08 R-pairCentral 0x753347
setstate BD.Fenster 2019-01-10 19:22:08 R-sabotageMsg on
setstate BD.Fenster 2019-01-10 19:22:08 R-sign on
setstate BD.Fenster 2023-05-10 19:20:23 RegL_00. 00:00 02:01 09:01 0A:75 0B:33 0C:47 10:01 14:06
setstate BD.Fenster 2023-05-10 19:20:25 RegL_01. 00:00 08:01 20:9C 21:00 30:06
setstate BD.Fenster 2023-05-10 19:20:26 RegL_04.BD.Thermostat_WindowRec 00:00 01:01
setstate BD.Fenster 2019-08-19 20:24:21 aesCommToDev ok
setstate BD.Fenster 2019-08-19 20:24:20 aesKeyNbr 00
setstate BD.Fenster 2023-08-04 20:15:21 alive yes
setstate BD.Fenster 2023-08-04 20:15:21 battery ok
setstate BD.Fenster 2023-05-31 18:57:29 cfgState ok
setstate BD.Fenster 2023-08-04 20:15:21 commState CMDs_done
setstate BD.Fenster 2023-08-04 20:15:21 contact open (to VCCU)
setstate BD.Fenster 2023-08-02 22:12:18 peerList BD.Thermostat_WindowRec
setstate BD.Fenster 2023-05-10 18:22:01 powerOn 2023-05-10 18:22:01
setstate BD.Fenster 2023-08-04 20:15:21 recentStateType info
setstate BD.Fenster 2023-08-04 20:15:21 sabotageError off
setstate BD.Fenster 2023-08-04 20:15:21 state open
setstate BD.Fenster 2020-12-22 19:12:22 trigDst_BD.Thermostat noConfig
setstate BD.Fenster 2023-08-04 11:25:22 trigger_cnt 180

LG

MadMax-FHEM · 04 August 2023, 21:19:34

Zitatattr BD.Fenster event-on-change-reading .*

Und wo/wie soll dann ein regelmäßiges Update erfolgen?

Wenn du aktuelle Batteriewerte willst bzw. regelm. Updatrs, musst du mind. dafür event-on-update-reading setzen...

Gruß, Joachim

gent · 10 August 2023, 21:41:02

Das habe ich aber bei den HM Thermostaten (HM-TC-IT-WM-W-EU) und den Reglern (HM-CC-RT-DN) auch nicht gesetzt und die melden ganz regelmäßig den aktuellen Batteriezustand. Irgendwas muss da bei den Fensterkontakten anders laufen, aber was?

Edit:
Ich sehe gerade, dass ich bei den Thermostaten und den Reglern überhaupt kein event-on... definiert habe.

minierm · 13 August 2023, 18:55:15

Ich habe die Benachrichtigung in eine Funktion ausgelagert, damit man leichter Anpassungen der Benachrichtigung vornehmen kann.

Code Auswählen

sub Battery_Send_Alarm {
    my ($Text) = @_;
    #send message via TelegramBot
    fhem("set TelegramBot message \@\@User $Text");
    # use your own function
    #SendAlarm($Text);
}

Und überall

Code Auswählen

fhem($msg." ".mit

Code Auswählen

Battery_Send_Alarm(ersetzt.

LutzG · 22 November 2023, 21:58:12

Hallo @All,

laut: https://wiki.fhem.de/wiki/DevelopmentGuidelines#BatteryReadings
sollen doch diese Readings "Standard" werden:

batteryState
batteryPercent
batteryVoltage

Aber in den Scripten habe ich nicht gefunden, dass diese Readings ausgewertet werden:

@Amenophis86 du hattest doch schon Mal versucht die Readings zu "vereinheitlichen":
https://forum.fhem.de/index.php?topic=87575.0
Ich verstehe nicht, warum sind die "Standard" - Readings nicht in das Skript gelangt?

Hintergrund:
Ich habe einige Zigbee-Teile von Lidl / Sonnoff / TRADFRI (Ikea) über Zigbee2MQTT eingebunden, die bringen zum Beispiel (nur) "battery / "batterymV" oder andere nicht "standardkonforme" Readings, denen ich (mit Hilfe des Forums) den "Standard" eingehaucht habe (userReading):

Code Auswählen

batteryVoltage:batterymV.* {ReadingsNum($name,'batterymV',0)/1000}, batteryPercent:battery.* {ReadingsNum($name,'battery',0)}, batteryState {if (ReadingsNum($name, "battery", 0) > 25) {return "ok"} else {return "low"}}

Leider übersteigt es meine Fähigkeiten, dem Skript den "Standard" zu verpassen. Ich würde es sehr gern nutzen, da ich die Art der Auswertung echt Spitze finde.

Vielleicht ein Beispiel-Device welches Probleme macht:

Code Auswählen

define MQTT2_zigbee_Lidl_Kontakt_1 MQTT2_DEVICE zigbee_Lidl_Kontakt_1
attr MQTT2_zigbee_Lidl_Kontakt_1 userattr myBattWechsel my_batteryType
attr MQTT2_zigbee_Lidl_Kontakt_1 DbLogExclude .*
attr MQTT2_zigbee_Lidl_Kontakt_1 alias zigbee_Kontakt_Wohnungstuer
attr MQTT2_zigbee_Lidl_Kontakt_1 devStateIcon open:fts_window_1w_open@red closed:fts_window_1w@green  Secure..true:secur_open@red Secure..false:secur_locked@gree online:10px-kreis-gruen offline:10px-kreis-rot
attr MQTT2_zigbee_Lidl_Kontakt_1 devicetopic zigbee2mqtt/Lidl_Kontakt_1
attr MQTT2_zigbee_Lidl_Kontakt_1 event-on-change-reading .*
attr MQTT2_zigbee_Lidl_Kontakt_1 genericDeviceType ContactSensor
attr MQTT2_zigbee_Lidl_Kontakt_1 homebridgeMapping ContactSensorState=state,values=closed:CONTACT_DETECTED;;open:CONTACT_NOT_DETECTED
attr MQTT2_zigbee_Lidl_Kontakt_1 icon fts_window_1w
attr MQTT2_zigbee_Lidl_Kontakt_1 jsonMap contact:state
attr MQTT2_zigbee_Lidl_Kontakt_1 model zigbee2mqtt_ContactSensor
attr MQTT2_zigbee_Lidl_Kontakt_1 myBattWechsel 0
attr MQTT2_zigbee_Lidl_Kontakt_1 my_batteryType 2xAAA
attr MQTT2_zigbee_Lidl_Kontakt_1 readingList $DEVICETOPIC:.* { my $ret=json2nameValue($EVENT,'',$JSONMAP);; $ret->{state}=$ret->{state} eq 'true' ? 'closed' : 'open';; return $ret }\
zigbee2mqtt/Lidl_Kontakt_1/availability:.* availability
attr MQTT2_zigbee_Lidl_Kontakt_1 room Zimmer->Flur,Geräte->Zigbee
attr MQTT2_zigbee_Lidl_Kontakt_1 stateFormat availability\
state\
 Battery: battery%\
Secure: tamper
attr MQTT2_zigbee_Lidl_Kontakt_1 userReadings batteryPercent {ReadingsNum($name,'battery','0')}, batteryState {if (ReadingsNum($name, "battery", 0) > 25) {return "ok"} else {return "low"}}
#   CID        zigbee_Lidl_Kontakt_1
#   DEF        zigbee_Lidl_Kontakt_1
#   FUUID      637bcf1a-f33f-be0c-9804-9ecba85255e59624
#   FVERSION   10_MQTT2_DEVICE.pm:0.279350/2023-09-05
#   IODev      mqtt2server
#   LASTInputDev mqtt2server
#   MSGCNT     74
#   NAME       MQTT2_zigbee_Lidl_Kontakt_1
#   NR         237
#   STATE      online
#closed
# Battery: 41.5%
#Secure: false
#   TYPE       MQTT2_DEVICE
#   eventCount 73
#   mqtt2server_CONN mqtt2server_172.18.0.4_52536
#   mqtt2server_MSGCNT 74
#   mqtt2server_TIME 2023-11-22 21:04:02
#   JSONMAP:
#     contact    state
#   READINGS:
#     2023-11-21 02:10:42   IODev           mqtt2server
#     2022-11-22 00:25:02   associatedWith  MQTT2_zigbee_bridge
#     2022-11-21 20:19:24   attrTemplateVersion 20220622
#     2023-11-21 02:11:01   availability    online
#     2023-11-22 21:04:02   battery         41.5
#     2023-11-22 21:04:02   batteryPercent  41.5
#     2023-11-22 21:04:02   batteryState    ok
#     2023-11-22 21:04:02   battery_low     false
#     2023-11-22 21:04:02   last_seen       2023-11-22T20:04:02.803Z
#     2023-11-22 21:04:02   linkquality     255
#     2023-11-22 21:04:02   state           closed
#     2023-11-22 21:04:02   tamper          false
#
setstate MQTT2_zigbee_Lidl_Kontakt_1 online\
closed\
 Battery: 41.5%\
Secure: false
setstate MQTT2_zigbee_Lidl_Kontakt_1 2023-11-21 02:10:42 IODev mqtt2server
setstate MQTT2_zigbee_Lidl_Kontakt_1 2022-11-22 00:25:02 associatedWith MQTT2_zigbee_bridge
setstate MQTT2_zigbee_Lidl_Kontakt_1 2022-11-21 20:19:24 attrTemplateVersion 20220622
setstate MQTT2_zigbee_Lidl_Kontakt_1 2023-11-21 02:11:01 availability online
setstate MQTT2_zigbee_Lidl_Kontakt_1 2023-11-22 21:04:02 battery 41.5
setstate MQTT2_zigbee_Lidl_Kontakt_1 2023-11-22 21:04:02 batteryPercent 41.5
setstate MQTT2_zigbee_Lidl_Kontakt_1 2023-11-22 21:04:02 batteryState ok
setstate MQTT2_zigbee_Lidl_Kontakt_1 2023-11-22 21:04:02 battery_low false
setstate MQTT2_zigbee_Lidl_Kontakt_1 2023-11-22 21:04:02 last_seen 2023-11-22T20:04:02.803Z
setstate MQTT2_zigbee_Lidl_Kontakt_1 2023-11-22 21:04:02 linkquality 255
setstate MQTT2_zigbee_Lidl_Kontakt_1 2023-11-22 21:04:02 state closed
setstate MQTT2_zigbee_Lidl_Kontakt_1 2023-11-22 21:04:02 tamper false

Wäre toll, wenn auch der "Standard" im Skript ausgewertet wird!

Viele Grüße, Lutz

MadMax-FHEM · 22 November 2023, 22:15:16

Einheitlich ist (leider) noch nichts...

Ich schaue mir das morgen mal an...

Gruß, Joachim

MadMax-FHEM · 23 November 2023, 00:06:03

Hmm, also evtl. ginge das hier:

EDIT: nein geht (nat.) nicht siehe nächste Posts $:-\$

Bei

Zitat#############################################
# XiaomiFlowerSens Devices
#############################################

Das hier:

Code Auswählen

 elsif($BatteryType[0] eq "batteryLevel"  && InternalVal($Device, "TYPE", "undef") eq "XiaomiFlowerSens")

gegen das hier tauschen:

Code Auswählen

 elsif($BatteryType[0] eq "batteryLevel"  && (InternalVal($Device, "TYPE", "undef") eq "XiaomiFlowerSens" || InternalVal($Device, "TYPE", "undef") eq "MQTT2_DEVICE"))

bzw. damit nicht (plötzlich) alle MQTT2_DEVICE Devices "geprüft" werden (wobei auch entsprechend an dem battery-notify eingeschränkt werden kann bzw. eh nur Devices mit irgendwas Battery hier aufgerufen werden sollten?)

Code Auswählen

 elsif($BatteryType[0] eq "batteryLevel"  && (InternalVal($Device, "TYPE", "undef") eq "XiaomiFlowerSens" || (InternalVal($Device, "TYPE", "undef") eq "MQTT2_DEVICE" && AttrVal($Device, "my_batteryType", "n.a.") ne "n.a.")))

EDIT: Klammerfehler korrigiert 8so hoffe/denke ich)

Gruß, Joachim

LutzG · 23 November 2023, 17:14:02

Hallo Joachim, @All,

ich glaube nicht, dass das funktioniert, "batteryLevel" haben die Device nicht, das ist ja das, was ich meine. Wenn ich richtig gelesen habe, werden (nur):

battery
batteryLevel
batteryTemperature

ausgewertet, die Standards: "batteryPercent, batteryState, batteryVoltage" nicht.

Vielleicht verstehe ich auch was völlig falsch, zum Beispiel ist mir schleierhaft, wie das für FBDECT funktioniere soll:

Code Auswählen

elsif($BatteryType[0] eq "batteryLevel"  && (InternalVal($Device, "TYPE", "undef") eq "XiaomiFlowerSens" || InternalVal($Device, "TYPE", "undef") eq "FBDECT"))

Es wird doch bei dem Device das Reading "batteryLevel" gelesen, oder? Dass hab ich bei "FRITZ!DECT 440" und FRITZ!DECT 301 aber nicht.

Ich schicke Mal ein Screenshot, Bat01.jpg ist das Ergebniss von dem Script, Bat02.jpg sind das Ergebniss von:

Code Auswählen

defmod rg_BatterieLevel readingsGroup .*:[Bb]atteryPercent
attr rg_BatterieLevel DbLogExclude .*
attr rg_BatterieLevel comment als doif: https://forum.fhem.de/index.php/topic,131349.msg1255415.html#msg1255415
attr rg_BatterieLevel notime 1
attr rg_BatterieLevel room System->BatteryCheck
attr rg_BatterieLevel valueFormat {my $value = ($VALUE =~ m/(\d+)/)?$1:$VALUE;;;; return "0" if( $value < 20 );;;; return "25" if( $value < 40 );;;; return "50" if( $value < 60 );;;; return "75" if( $value < 80 );;;; return "100";;;;}
attr rg_BatterieLevel valueIcon {'batteryPercent.0' => 'measure_battery_0@red','batteryPercent.25' => 'measure_battery_25@red','batteryPercent.50' => 'measure_battery_50@orange','batteryPercent.75' => 'measure_battery_75@green','batteryPercent.100' => 'measure_battery_100@green'}

Du darfst diesen Dateianhang nicht ansehen. Du darfst diesen Dateianhang nicht ansehen.

Viele Grüße, Lutz

MadMax-FHEM · 23 November 2023, 17:40:45

Ja, sorry, mein Fehler.
Ich hab mich in deinem List/RawDef wohl verkuckt

Ich schaue gleich noch mal...

Bzgl. deiner DECT bzw. alle Devices die bei dir (noch) nicht gehen wäre eine RawDef/copyForForum hilfreich.
Die Batteriewerte (in den dummy) kommen aber erst, wenn sich beim Batterie-Reading auch was ändert/tut (event-on-change-... Drum hab ich bei mir event-on-update für Batterie-Readings drin)

Gruß, Joachim

MadMax-FHEM · 23 November 2023, 17:53:18

Dann werfe ich hier mal etwas bzgl. BatteryPercent ins Rennen

(hast du die Beiträge hier [von mir] mal durch, ob nicht schon mal was gepostet wurde bzgl. batteryPercent oder weitere Abfragen? Leider landet das nicht in git)

Also "einfach" einen weiteren Code-Block anfügen.

Code Auswählen

  #############################################
  # MQTT2_DEVICE Devices that have my_batteryType attribute!
  #############################################
 elsif(InternalVal($Device, "TYPE", "undef") eq "MQTT2_DEVICE" && AttrVal($Device, "my_batteryType", "n.a.") ne "n.a.")
 {
   $ActBatLevel = ReadingsNum($Device, "batteryPercent", "0");

   if($ActBatLevel > 75)
   {
     # set date/time for changed battery if it was low before (so probably a change happended)
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") eq "low" || ReadingsVal($BatteryStatus, $Device, 100) < 25)
      {
        fhem("setreading $BatteryChanged $Device $text_changed");
      }

      # set the battery value to 75% - 100%
      fhem("setreading $BatteryStatus $Device 100");

      # set the signal state back to none
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
      {
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }
    }
  }

EDIT: Klammer korrigiert...

EDIT: Evtl. ist auch das hier ok:

Code Auswählen

  #############################################
  # MQTT2_DEVICE Devices that have batteryPercent Reading
  #############################################
 elsif($BatteryType[0] eq "batteryPercent" && InternalVal($Device, "TYPE", "undef") eq "MQTT2_DEVICE")
 {
   $ActBatLevel = ReadingsNum($Device, "batteryPercent", "0");

   if($ActBatLevel > 75)
   {
     # set date/time for changed battery if it was low before (so probably a change happended)
     if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") eq "low" || ReadingsVal($BatteryStatus, $Device, 100) < 25)
      {
        fhem("setreading $BatteryChanged $Device $text_changed");
      }

      # set the battery value to 75% - 100%
      fhem("setreading $BatteryStatus $Device 100");

      # set the signal state back to none
      if(ReadingsVal($BatteryStatusBot, $SignalDevice, "none") ne "none")
      {
        fhem("setreading $BatteryStatusBot $SignalDevice none");
      }
    }
  }

EDIT: Klammer korrigiert...

Die Abfrage bzgl. Device-Type o.ä. Abfragen sind drin, da manche Devices zwar batteryPercent (in diesem Beispiel oder auch batteryLevel o.ä.) haben aber mit unterschiedlichen Formatierungen bzw. mit/ohne Einheiten oder %-Zeichen o.ä.
Wobei das mit ReadingsNum ja "ausgebügelt" werden müsste...

Ich habe dazu jetzt einen Block aus dem git-Code genommen und auf batteryPercent angepasst.
Wenn du einen anderen Code als Grundlage hast, dann poste das doch mal...

Meinen Code kann ich nicht direkt posten, da ich (inzwischen) einfach zu viele andere Dinge eingebaut habe, die nur bei mir funktionieren (dürften)...

~~EDIT: das notify muss u.U. auch erweitert werden? damit eben auch bei batteryPercent ein Aufruf erfolgt...~~ (stecke jetzt nicht mehr so tief drin in dem code hier...)
EDIT: hab grad geschaut, müsste noch passen...

Gruß, Joachim

MadMax-FHEM · 23 November 2023, 19:37:26

Jetzt hab ich deinen letzten Post noch mal gelesen...

Geht es dir um FBDECT oder (wie ich dachte/denke) MQTT2_DEVICE?

Aber das Prinzip ist immer gleich:

erst mal prüfen um welches Reading und Device Typ es sich handelt.
Device Typ weil manche Typen trotz gleicher Readings/Readingnamen andere Werte etc. liefern.

Aber evtl. könnte/sollte man das mal (wieder) vereinheitlichen, also den Code hier...

Die Schwrllen, also wann bei einem Gerät die Batteriewarnung kommen sollte könnte man pro Device per Attribut angeben, wenn es fehlt, dann halt irgendwann unter 25% oder so...

Alles Ideen aber zu wenig Zeit $:-\$

Ich habe ja den Batterie-Typ schon beim Device verattributet und auch eine Funktion die prüft (anhand meines "Batterielagers") , ob ich noch habe oder kaufen sollte...

Und auch wie lange (in Wochen) die Batterien so pro Gerät halten...

Mal sehen...

Gruß, Joachim